Introduction to Git Branch Model

This is the third article where I try to give a summary about git, but this one concerns only branching strategy and release management. And be different for the other two git introduction Introduction to Git - Continued and Introduction to Git article, this one talk more about philosophy.

Since Vincent Driessen has already provide a great article introducing branch model as A successful Git branching model. So I will just re-compose his article here to complete my Git tutorial article.

Summary

[The above image is adopted from https://nvie.com/posts/a-successful-git-branching-model/.]

Branches:

Philosophy:

Decentralized but Centralized

[The above image is adopted from https://nvie.com/posts/a-successful-git-branching-model/.]

Technically Git is a DVCS without a thing as central repo since all users own a complete code base. However, in practice, in order to make file synchronizing more of ease, there is usually a repo stands in the middle to give access channel to each other with the convention name origin. Each developer update files (pulls and pushes) to origin. And each developer can also optionally pull changes from each other, although not the common cases.

The Main Branches

[The above image is adopted from https://nvie.com/posts/a-successful-git-branching-model/.]

The central origin repo holds two main branches with an infinite lifetime which are master and develop and should be familiar to every development team Git user.

Considering origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.

Considering origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. This is where any automatic nightly builds are built from.

When the source code in the develop branch reaches a stable point and is ready to be released, all of the changes should be merged back into master somehow and then tagged with a release number with the intermediary release possibly.

By strictly following above rules, theoretically, a Git hook script can be employed to automatically build and roll-out the software to production servers every time there is a commit on master.

The Supporting Branches

Generally, supporting branches are with a limited life time and will be removed eventually. There could be at least 3 types of supporting branches as following:

Although technically equal, as their name reveals, those branches are for specific purposes and bound to strict rules as to which branches may be their originating branch and which branches must be their merge targets.

Feature Branches

Feature branches may branch off from develop and must merge back into develop with any naming pattern except for master, develop, release-* or hotfix-*.

Feature branches are used to develop new features for the upcoming or a distant future release.

Feature branches typically exist in developer repos only, not in origin.

[The above image is adopted from https://nvie.com/posts/a-successful-git-branching-model/.]

Related command lines:

## creating a feature branch
git checkout -b the-new-feature develop

## incorporating a finished feature on develop
git checkout develop
git merge --no-ff the-new-feature
git branch -d the-new-feature

## push to central repo
git push origin develop

The --no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. In this way, some clues of historical existence of feature branch are kept.

[The above image is adopted from https://nvie.com/posts/a-successful-git-branching-model/.]

Release Branches

Release branches may branch off from develop and must merge back into develop and master with naming pattern release-*.

Release branches support preparation of a new production release allowing for minor bug fixes and preparing meta-data for a release (version number, build dates, etc.).

Adding large new features in release branch is strictly prohibited and should be done in develop branch.

The key moment to branch off a new release branch from develop is when develop (almost) reflects the desired state of the new release.

Related command lines:

## creating a release branch
git checkout -b release-1.2 develop
# ./bump-version.sh 1.2
git commit -a -m "Bumped version number to 1.2"

## finishing a release branch
git checkout master
git merge --no-ff release-1.2
git tag -a 1.2

git checkout develop
git merge --no-ff release-1.2

git branch -d release-1.2

Hotfix branches

Hotfix branches may branch off from develop and must merge back into develop and master with naming pattern hotfix-*.

Hotfix branches are very much like release branches in that they are also meant to prepare for a new production release, albeit unplanned, raised from the necessity to act immediately upon an undesired state of a live production version.

Related command lines:

## creating the hotfix branch
git checkout -b hotfix-1.2.1 master
# ./bump-version.sh 1.2.1
git commit -a -m "Bumped version number to 1.2.1"
# ./fix-production-problem.sh
git commit -m "Fixed severe production problem"

## finishing a hotfix branch
git checkout master
git merge --no-ff hotfix-1.2.1
git tag -a 1.2.1

git checkout develop
git merge --no-ff hotfix-1.2.1

git branch -d hotfix-1.2.1

And notice, when a release branch currently exists, the hotfix changes is recommended to be merged into that release branch, instead of develop.


* cached version, generated at 2019-06-21 23:17:41 UTC.

Subscribe by RSS