git workflow draft
j.sixt at viscovery.net
Thu Feb 17 08:01:05 GMT 2011
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:
> 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,
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.
> 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.
More information about the kde-core-devel