Simple release management with Git

Git is not only a convenient distributed VCS, but also a release preparation tool.
The article will review the flow of the example of Java-projects on Maven. The article may be useful for developers of small and medium-sized teams, the basic knowledge of git is implied. The material overlaps with git-flow , but a simpler version is described here.
In the classic case, there is one master branch in the repository, and assemblies are made from it. If the project is built on the build server, it can lead to confusion - several different builds under the same version, the set of commits that get released is not clear (for example, if the build is done automatically by a trigger on the VCS).

How to solve this problem

')

The first thing you can do is to enter the auxiliary release branch, into which the regular merge from the master is made (the screenshot is made in TortoiseGit, the timeline is bottom-up). For maven-projects at the time of merge in pom-files, the version of SNAPSHOT is replaced with the release version. If done correctly, this is the only conflict. It is advisable to put a tag with the version number. After that, the major-up SNAPSHOT version is done in the master branch, so the master is always SNAPSHOT, release is always not. Accordingly, the build server is configured on the release branch for production assemblies.
The disadvantage of the two-master and release branches is the inability to make a hotfix without releasing new functionality from the master, which can be critical.

Enter hotfix branch

To do this, you can enter the hotfix branch, which will grow from the commit preceding the merge in release. The first commit in this thread will be a minor-up SNAPSHOT version (1 in the illustration). Next, the corrections are made on the release and master branches. With merge in release, a single conflict is resolved in favor of fixing the non-SNAPSHOT-minor-version (2), with merge in the master, the version remains from the master (3). After the merge in release, a minor-up SNAPSHOT version (4) is made in the hotfix branch. Before the next major release, hotfix merges into master - so we won't lose all the fixes. After completion of the preparation of branches, they are sent to the origin-repository.

What we have in the end

The main advantages of the solution:

• cleanup with releases; one release version corresponds to exactly one commit
• by regulating repository rights, roles in a team are clearly separated: developer, reviewer, tester / release manager
• in the case of a normal course of things, you don’t have to push --force, risking overwriting someone else’s edits, the probability of losing valuable changes is minimal
• There is no need to regularly create new configurations according to the template on the build server (as opposed to the option of creating a new branch for each major release)
• The scheme is relatively simple, it is quite convenient. We use options with two and three branches in almost all our projects.

The disadvantages include the inability to release hotfix in the previous major release. It is also impossible to type release only from the necessary commits. This is solved by complicating the flow and is beyond the scope of this article.

For many, there is nothing new here, but judging by the same github, the absolute majority of open-source projects use the simplest scheme with one branch.

And what flow do you use?

Useful links: ProGit , Git How To