git workflow draft

[Johannes Sixt]

Am 2/16/2011 22:10, schrieb Stephen Kelly:
> As one of the people asked to describe my idea of the workflow (which should 
> focus on rebasing, not merging) I put  write up here:
> 
> http://community.kde.org/20110213_GitWorkflowAgenda/StevesIdea
> 
> http://thread.gmane.org/gmane.comp.kde.scm-interest/2007
> 
> The emphasis is on creating a 'nice' stream of commits which it is possible 
> to review (if applicable) and which apply against the target branch. This 
> way a reviewer (or archeologist looking for the source ofg a bug) doesn't 
> have to analyse commits in the branch which are workarounds for bugs in 
> master, find the merge from master and the removal of the workaround, 
> analyse the master branch in the same timeframe to see what needed to be 
> merged in etc etc. 

Now I get it: The reason why you are advocating a rebase based workflow is
because the goal should be a series of self-contained, easy-to-review,
tested(!) commits.

That is, when someone (an individual or a group of collaborators) produces
a new feature, the result should be a (not too long) series of "clean"
commits. To achieve this, it is necessary to use git-rebase in order to
fold, split, and rearrange the commits. This sort of rebasing should
happen after a group of collaborators has produced a potentially messy
history with merges and fixups of earlier commits, and before the feature
nears publication to a wider audience. (You mentioned an example elsewhere
in this thread.)

So far, we are in the same boat, absolutely.

HOWEVER:

> The topic branch is an addition to the master branch. It should be relevant 
> against the current master and 'clean' and nice. Happy and good. No useless 
> merges. There should be no recommendation in documentation to 'merge a topic 
> branch into master'. The recommendation should be to rebase instead. This is 
> my recommendation. There has been some discussion on the scm interest list, 
> but I wouldn't call it concensus at this point.

We disagree here: How a topic branch (that was prepared like above) ends
up in the master branch is an *entirely* different story.

When you develop a new feature, it is a very important choice on which
version of the software you base it on. I am advocating to base a feature
on a well-known, stable state. If you choose to base the feature on
"today's master", you are actually building a house on moving grounds. How
can you be sure that your product will be stable?

The corollary is that a new topic should be based on a project state that
is no younger than necessary (to have all prerequisites that you need), so
that you can be sure that it was already tested by a as many people as
possible. Ideally, today, every feature targeted for 4.7 should be based
on the 4.6.0 release tag, whenever possible.

As a consequence, you must not rebase the finished topic onto master, but
you must merge it.

-- Hannes