Advice on git release management & confusion

Question

We're a team of 6 devs and we've transitioned from TSVC(on TFS2010) to git(on Gitlab) for almost a year now. We've adopted the release model from http://nvie.com/posts/a-successful-git-branching-model and it's working but we're struggling at times to fit in.

Background: We're maintaining an in-house web app for only 1 exclusive client. Generally we have 2 type of releases:

minor: bugfixes & small change requests
major: major change request which usually takes months to deliver

Both type of releases can only be deployed to production upon client's approval.

We have 4 types of branches, master, release, develop and topic branches. We branched off a new release from master once a release is ready to go out. For CR, we initially branch from develop, though later we found that it's quite redundant, hence we now branch from master. Topic branch are bugfixes and small CR, which is branch from either the on going release or master branch. When we merge enough bugfixes into a release branch, or when an urgent bugfix needs to be release, we'll prepare that release branch to go out, and start a new release branch. We usually do our releases bi-weekly or monthly on a fixed weekday. We also update the major release branch by merging minor release branch into it upon each release.

We use Gitlab's CI to build our package on every push, and we'll deploy the last built package to our testing environment to be tested by our test team. When the release branch is stable, the final package pass the test and the release approved by client, the same package is then used for the production deployment.

Below are some of our confusion.

Since we always deploy from the tip of the release branch, we feel that there's no need to merge that back into master. The commit which merge release into master is not the one that got deployed. If we were to use the final merged commit, then we will have to go through the testing cycle again, which seems redundant. Should we still keep master?
develop branch doesn't seems to fit in our workflow too, should we drop it as well?

At the end, what seems to work for us is only having minor & major release branches, but we want to know if that's the recommended way or there's better release model that we can follow.

"The commit which merge release into master is not the one that got deployed." if this is true, then there's something confusing with your flow because all merges to master should be fast forward, so they should be the same commit hash. — Jeff Puckett
@JeffPuckettII right, it's not the same commit hash. So this is where we should be looking at, thanks — faulty

AnoE AnoE · Accepted Answer · 2016-07-26T12:41:00

We do the same type of development as you.

For us, Dymitruk's branching model http://dymitruk.com/blog/2012/02/05/branch-per-feature is perfect. In a nutshell, it does away with development and release branches and uses only master, featureXXX, qa (pre-release testing) and ci (continuous integration) branches, the last one being more technical and quite optional.

The system heavily depends on git rebase and git rerere, hence works only with git (I don't know if any other VCS has something like rerere), and is very clean and powerful.

Advice on git release management & confusion

1 Answers