[haiku-development] Our Git branching and merging policy (was Re: [haiku-commits] Re: haiku: hrev43263 - in src/apps/debugger: files user_interface/gui/team_window)
- From: Ryan Leavengood <leavengood@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 14 Nov 2011 16:00:06 -0500
Moving this discussion to haiku-development:
On Mon, Nov 14, 2011 at 6:10 AM, Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:
>
> If you have applied your local changes directly to master (i.e. you have
> not done an explicit merge), you can use 'git pull --rebase' to rebase
> those local changes to the top of the updated master. You can even do this
> repeatedly if someone has pushed while you were busy solving rebase
> conflicts.
In general I think a 'git pull --rebase' strategy for master work is
good, though as you indicate it can have issues at times. In which
case maybe we should all try to follow the policy shown in the article
you link. There are even shell scripts for it:
https://gist.github.com/590895
I think there are other similar, but more advanced, tools on GitHub.
> You can find a much more elaborate description of the problem here:
>
> http://notes.envato.com/developers/rebasing-merge-commits-in-git/
Good information, thanks for the link.
Further, linked off the above is this:
http://nvie.com/posts/a-successful-git-branching-model/
Everyone will need to read it to understand, but the short version is
to have a policy of keeping master always in a release state, with
most work occurring in a develop branch. He also advocates the --no-ff
option for git merge, which doesn't ever do a fast forward, but always
includes a merge commit even if it isn't needed. The purpose of this
is to clearly mark where a feature branch was integrated. I think this
definitely makes sense.
I think we should seriously consider using a similar model. Of course
the branch names could be different for us. His develop could be our
master, his master our release branch, and his release branches our
pre-release. Whatever the case, the names aren't as important as the
concept.
Of course we haven't yet had a full R1 release, and we haven't been
worried about doing hotfixes to the alpha releases. But once we do
release R1, this becomes a real concern. In which case adopting that
branching and release policy or similar might be a good idea.
> I'm a bit torn on the topic of which kind of "clean" history we should aim
> for: I can see the point of rebasing, but I don't think it's really
> important to try to maintain a linear history in our master.
> After all, doing your local work on branches (instead of doing them
> directly on master) is encouraged and when merging those, you will create
> merge commits anyway.
I think there is a pretty simple strategy: merge commits should serve
a purpose. They should indicate that work done in a branch was merged.
They shouldn't just indicate that someone updated their repo, which is
probably what we will have as merge commits in master if everyone does
a normal git pull.
> What we *should* definitely avoid, though, is the degenerate case described
> in the article above, with duplicate commits and dangling branches. So:
> rebasing on master is ok if you know what you're doing. If not, please
> learn to live with those merge commits.
In general I think the heavy use of Git branches is a more advanced
workflow (though one we should all eventually move to), so hopefully
the people doing that will know to do a 'git fetch' then 'git rebase
-p origin/master' to preserve merge commits. If you aren't merging
work in from branches but working directly in master, git pull
--rebase is pretty safe.
--
Regards,
Ryan
Other related posts:
