some git thoughts, personal and feature branches

Bart Cerneels bart.cerneels at kde.org
Tue Aug 11 11:20:48 CEST 2009


On Tue, Aug 11, 2009 at 10:30, Mark Kretschmann<kretschmann at kde.org> wrote:
> On Wed, Aug 5, 2009 at 10:50 AM, Ian Monroe<ian at monroe.nu> wrote:
>> First off I don't really understand why everyone went and made
>> personal repos, its like people thought they were required (most seem
>> unused). I think its just causing confusion. Unless you want a pretty
>> handy way to share your work as you work on it, just commit and push
>> to the mainline repo. Its more straightforward and also a handy way to
>> share your work. :)
>>
>> So to define (at least how I use these words):
>> mainline: the new trunk
>> personal branch: basically this is your local work that you decided to
>> publish. No one else has commit rights to it. Likely you'll merge the
>> work here relatively quickly into mainline.
>> feature branch: working on some new feature with 1 or more other
>> developers. Might go weeks or months without merging into mainline.
>>
>> But anyways, on a personal branch, where remote 'origin' is Amarok mainline.
>> to sync with master:
>> git checkout personal-branch
>> git remote update
>> git rebase origin/master
>> git push -f
>>
>> push -f is needed since rebase changes history. push -f is bad if
>> other people are making commits to your personal branch, since they
>> will be pretty screwed if. But then its not a personal branch, its a
>> feature branch by definition. :)
>>
>> so to merge master on a feature branch:
>> git checkout somefeature
>> git remote update
>> git merge origin/master
>> git push
>>
>> And then weeks later when you finish the feature branch, and let
>> everyone else know:
>> git remote update
>> git rebase origin/master
>> git push -f #update feature branch
>> git push origin somefeature:master #merge into mainline
>>
>> So push -f still isn't requried for merging into mainline isn't
>> required (which is good, since its impossible) since rebase has only
>> been editing the history of commits that aren't in mainline.
>>
>> The key is to not mix up whether its a personal branch or a feature
>> branch. :) You can't rebase and then expect a plain 'push' to work to
>> your personal branch. And if this is all really confusing for you,
>> stop publishing your personal branches and just use mainline. :P
>
> Bump! I still see a lot of "Merge branch master" commit logs. It would
> be nice to get a consensus on the "rebase vs merge" debate.
>
> Please read Ian's mail if you haven't, I think he managed to put it
> all into perspective :)
>
> --
> Mark Kretschmann

I also don't agree with the "I don't want to rebase because it
rewrites history"-sentiment but willing to discuss this.

An alternative could be to hide (or have the option to, like
SVN_SILENT) the merge commits from the commit mails. I'm sure Ian can
come up with a technical solution.

Bart


More information about the Amarok-devel mailing list