git workflow draft

[Andreas Hartmetz]

On Thursday 17 February 2011 09:01:05 Johannes Sixt wrote:
> 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.
> 
As somebody who usually runs master, I see a bit of a problem here. Everybody 
who is working on a feature will not be testing master (aspects related and 
unrelated to the branch) while doing so. This may or may not turn out to be a 
problem in practice.

Maybe we'll find rules of thumb to choose the right base for topic branches. 
Like "usually latest stable unless you rely on features of master" or "usually 
master unless changes in master would interfere with your work"...
A checklist with obvious and not so obvious arguments for / against choosing a 
particular base could also help make decisions on a case-by-case basis.

Does that sound reasonable or is it just my lack of git experience making me 
suggest such things?