git workflow draft

[Johannes Sixt]

Am 2/17/2011 12:10, schrieb Andreas Hartmetz:
> On Thursday 17 February 2011 09:01:05 Johannes Sixt wrote:
>> 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 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.

You do have a point here. However, I believe that it should not be a
problem in practice:

You start a topic from a stable state that is not today's master. You
develop the topic for a few days, or a week or two. During this time, you
do diligent testing, and at the end you are reasonably sure to have a new
good state. The goal here is that your testing does not suffer from
unrelated breakages introduced by other topics that are in flight.

At this point, you want to make sure the topic is good when it's merged
into master. Do that. And repeat all tests.

Now it's time to publish the topic. You do so by pushing the topic branch
(not the merge!). You encourage others to merge the topic into their
*private* repositories to get wider exposure and testing.

Yourself, you keep running the merged state, of course. You would also do
the regular merges from upstream that you used to do. See? You are still
testing master. If you like, you would merge topic branches offered by
others to test their topics as well.

When your topic has cooked sufficiently long, you would repeat the merge
into today's master (remember: do not expose your own private, messy merge
history to others), and push the result upstream. Now the topic is in master.

> 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.

If the project hygenie that I sketched above were applied universally,
today's master would actually be a reasonable choice (contrary to what I
said earlier).

Until then, a relaxed rule is probably sufficient: Choose a starting point
that is convenient; but DO NOT CHANGE IT once you have done serious
development, because a change (aka rebase) basically invalidates all your
tests.

And common sense says: If you are cleaning up your messy topic history
using git-rebase in such a way that you have to re-test every new commit
anyway, you CAN choose a new starting point.

-- Hannes