Branching strategy for git

[Geert Janssens]

This topic has been brought up before but we never really came to a consensus on how we 
want to organize our branches in the official git repository. Yet I want to get a final decision on 
this before we open a master for feature development again.

To refresh memory here is a link to the thread on gnucash-devel last year January about this 
topic:

http://lists.gnucash.org/pipermail/gnucash-devel/2013-January/034843.html

The model I defended in that thread is more or less this (quoted from 
http://lists.gnucash.org/pipermail/gnucash-devel/2013-February/034878.html )

- one branch for future development (features, refactoring, anything too complex for a stable 
release)
- there can be subbranches for separate features or refactoring efforts 
that get merged into the main development branch when they are 
considered ready
- one branch for stable development (bugfixes, translation updates). 
This branch gets merged into development regularly to get all bugfixes 
into the future development as well
- one release branch. The only direct commits here are those purely 
related to releasing, like updating the version number. Other than that 
it receives bugfixes and translation updates merged in from the stable 
branch.

This setup leverages the git history to keep track of which changes go where. It solves the 
problem of forgotten backports (there no longer are any) and makes sure that all bugfixes 
eventually end up in all branches that should carry them.

This obsoletes our current BP/AUDIT machinery which was adopted because svn history was not 
capable of managing this on its own.

At some point we had some kind of a gatekeeper to tell which bugfixes were allowed on stable 
and which aren't. This person tracked the AUDIT mails to know which commits to verify. If we 
want to re-establish this function in the future I think the easiest way would be as follows:
- only the gatekeeper can push to the central stable branch.
- bugfixes are done on their local stable branches and they send pull requests (or patches) for 
review to the gatekeeper
- the gatekeeper evaluates the pull requests/patches and accepts or rejects.

Using pull requests once more leverages one of the powers of git.



Since that long-winded thread I have found some workflows as recommended by other projects 
managed in git. I have collected some links to such workflows in our wiki [1]. Reading those you 
will find they all more or less start on a similar basis. I find it rather amusing we got to such a 
similar result by independently thinking about this. Some workflows add more branches in the 
mix, like an integration branch. We may want to discuss if those extra's make sense in the small 
team we currently are.

Please give your feedback on whether or not we  want to adopt such a workflow. If so we really 
need to review the Backporting stuff on our Git wiki page.

Geert

[1] http://wiki.gnucash.org/wiki/Git#Branching_and_Merging