This question already has an answer here:
- Git branching and tagging best practices 2 answers
I a little while ago I joined a new development team and recently we had our first major release. We've used Git since the beginning of the project and by now are somewhat comfortable with it. However, now that the product is in the field, we are discovering new issues/processes that need to be established. Up to this point, everything we've done was by referencing the very popular successful branching model post, which indeed has been very helpful
Currently we have the following branches, all live and all being updated:
- master - only released, stable code (tagged every time release is cut)
- develop - wide open. used for long term development
- hotfix-1.0.1 - branched off master's 1.0.0 tag for small, very targetted fixes which are already lining up
- release-1.1 - This is a small incremental release that we want to push relatively soon so we wanted to manage it separately from develop and to limit scope of changes.
These are the merging rules we are establishing:
- If a code change is made in release-1.1, it must be merged up to develop.
- If a code change is made in hotfix-1.0.1, it must be merged up to release-1.1.
- Nobody except for one team member should merge anything into master and that merge only happens when a product version is about to be shipped.
My questions are:
- When should the merges take place? As soon as the fix is applied in lower-level branch? Or periodically in chunks of changes? If periodically, how do you typically determine merge period?
- Who should do the merges? Person making the original code change? Or one individual who would be designated as "Director of Git Services"?
Reason I'm asking all this is because it seems that while Git is very flexible (and I do love that part about it), it also allows you to easily shoot yourself in the foot. With just few commands, someone could easily, and hopefully not on purpose, merge new development right into hotfix that should ship out in 2 days.
Many of us are new to Git and we are still feeling our way around the tool. I was thinking how my other companies/teams handled such concepts in the past and I think the biggest difference is that most other source control products that I've used, work with individual commits, so each developer could be responsible for making sure his fixes are applied to the correct places. But with Git, when one developer runs:
git checkout release-1.1 git merge hotfix-1.0.1
... after his commit, those commands will end up merging an entire branch including code that he has never seen before and may not be the best person to resolve, if there are any conflicts.