Workflow description for git usage for in-house development

Question

The company I work for wants to have monthly releases, and I am trying to convince them to switch to git. I believe the proper git-way to handle this is to have a integration branch for each release (i.e. monthly) and have feature branches off the integration branches for new development and changes. The environment is loaded with interdependencies and sometimes a feature has to be postponed to a different month because of delays in required features from other external systems. The projects will generally have activity on 2-3 integration branches in parallel and the activity is confined to a group of people who are in fairly close contact. (Which means I suspect we can use rebasing as long as we're on the last integration branch¸which is true at least half of the time for half of the people)

There's a fair amount of people involved, so I really need some straight guidelines of how to do this, both a logical explanation of the branch/merge structure and the practical git commands to do this. Does anyone know of such a description that is reasonably well fit for such a workflow ?

Answer 1

a logical explanation of the branch/merge structure

The structure basically follows what you said: an integration branch, and features branches.
In this kind of workflow, it is key to understand, as you did, that all development will not make it to the next release.
But with a DVCS, it is also key to understand a branch can be published and clone.

That last point (publication) will have a big influence on the merge commands , namely:

• merge
• rebase.

Whenever a developer has to merge his work on any integration branch (he pulled from a "central" repository), I would recommend:

# switch back to previous release tag (from where feature branches for next release where done)
$ git checkout previousReleaseTag
# create one's own private
$ git checkout -b myIntegrationBranch
# merge or cherry-pick what we want to actually put in the next release
$ git merge... from our feature branch
# rebase that private integration branch on top of actual integration branch
$ git rebase integrationBranch

The last rebase will rewrite the history of your local consolidations, but in a branch you will not publish anyway (so no harm done).
Once all your new features are working, you can merge back that private branch to the current HEAD of the relevant integration branch.

The "private branch - merge or cherry pick - rebase - local resolution - merge back" is a necessary workflow since several team will have to merge their work to a common branch. They need to replay what they want to publish in a private branch before merging it to the common branch, otherwise each team could break what is represented by the HEAD of the common branch.

Other details in the questions:

• git commit frequency
• git releases management (another merge workflow)
• JC Hamano articles (thanks to Jakub Narębski)