Re: Git workflow (was: Re: Planner xml field additions)

[Kurt Maute <kurt maute us>]

On Sat, 2009-04-25 at 13:47 +0200, Maurice van der Pot wrote:
> On Sat, Apr 25, 2009 at 06:11:43AM -0400, Kurt Maute wrote:

> I believe the reason is that commits on A may get a new ID after being
> rebased on the head of master. Some of those commits (the ones that are
> part of the history of Aa) will also remain in the repository under
> their old ID. Git won't see that they are the same and will consequently
> produce conflicts when merging Aa with master for instance.

So sounds like this is what Linus was talking about when he said not to
pull from master only, not his working branches, because your code will
have his random thoughts incorporated.

> Also an interactive rebase lets you edit the order of commits, delete
> commits, squash multiple commits into one, etc. This is the cleaning up
> functionality that may be useful for a topic branch that went through a
> lot of experimentation and rewriting.

Yeah, I like the idea of being able to clean up the branch history
before merging back with master.

> Now if you are working on a topic branch on your own, then rebase is
> actually a good thing to use. You do not want your history littered with
> "merge" commits if all you wanted to do was check if your code in
> progress still worked with the latest master.
> 
> In the case multiple people are working on a topic branch, they can
> discuss for themselves if/when they want to rebase. Some options
> they would have are:
> 1) don't rebase, just merge in master at certain points in time. 
>    Merging doesn't cause unnecessary conflicts for people who have
>    branched from this topic branch.
> 2) agree to do a rebase and have everybody create a clean branch
>    afterwards.
> 3) a combination of both. You could merge during development and rebase
>    once you think it's done. Linus has a point when he says that this
>    invalidates the testing you have done on the code before the rebase.
> 
> So if we just rebase our private branches and stop rebasing if they
> become public for collaboration, and if we also do not merge from master
> continuously, then we can always decide at a later stage if we still
> need to clean up or if we can merge to master straightaway.

Sounds good to me.

> > I don't really understand how someone would destroy someone else's
> > history
> 
> I think they mean if you have been pulling other people's work into your
> branch (for instance some kernel developer pulling from some
> contributor) and you rebase (and clean up) before you push it upstream
> (or Linus pulls from you), the upstream branch will not get the history
> as it was in the downstream branches you pulled from.

ok, that makes sense.


So the basic rules of thumb would be:

* Keep master branch clean & distribution ready
* When creating a new branch, always pull from master (do not pull from
someone else's branch)
* Keep your branch clean (or at least, rebase it so it makes for a clean
merge back to master)
* Clean means:
  - keep your history readable
  - don't expose your crap (don't push out half finished junk)
* rebase only when it makes sense to (don't rebase unrelated stuff into
your branch)
* If its not clean, don't merge it with master


-- 
Kurt Maute <kurt maute us>