In this article, I will walk you through my personal branching and merging strategy that I follow.
If you have not gone through Part 1, I recommend that you read that first.
In every project, we always have two infinite branches: master, and develop
Master Branch
master branch is the default and also the main branch.
origin/master to be the main branch where the source code of HEAD always points to a version tag and always remains in production-ready state.
No direct commit should be pushed to master branch.
Develop Branch
develop branch is always forked from master; in the words it has master as its ancestor.
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.
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.
Based on different requirement we have three main type of branches:
- Feature
- Release
- Hotfix
Feature Branches
A feature must be branched off from
developbranch and must be merged back intodeveloponly.
A feature branch is created when there is a new feature to be released in the future.
git chckout sj/feature/user_authentication develop
Note:
- This is what I follow for naming my branches, it's only personal preference.
So,
sjwill be initial of developer working on the feature followed by type of the branch, in this casefeatureand then actual phrase describing the feature - If there is any bug on
developbranch a bugfix branch should be created instead of featuresj/bugfix/user_authentication_issuesand it should follow the same merging strategy as a feature branch
When the work on the feature branch is finished, it must be merged back into the develop branch.
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff sj/feature/user_authentication # --no-ff makes sure to create a merge commit
Updating ea1b82a..05e897
(Summary of changes)
$ git branch -d sj/feature/user_authentication
Deleted branch sj/feature/user_authentication(was 05e9897).
git push origin develop
Release Branches
A feature must be branched off from
developbranch and must be merged back into firstmasterand then intodevelop.
Release is a temporal supporting branch to support preparation of a new production release. This means mainly bug fixing, documentation, version number upgrades etc.
$ git checkout -b release-v2.5 develop
Switched to a new branch "release-v2.5"
$ vi package.json # change version to v2.5 and update other configs
Files modified successfully
$ git commit -a -m "Bumped version to v2.5"
[release-v2.5 74d9343] Bumped version to v2.5
1 files changed, 1 insertions(+), 1 deletions(-)
After work is done on a release branch it must first merged into master because every new commit on master becomes a new release.
Also, that commit must be tagged with a version number for future references.
Finally, the changes made on the release branch need to be merged back into develop, so that future releases also contain changes made in the release branch.
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-v2.5
Merge made by recursive.
(Summary of changes)
$ git tag -a v2.5
We also need to merge the release branch into develop as well so that it contains changes from the release branch
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff release-v2.5
Merge made by recursive.
(Summary of changes)
After this branch is merged into both master and develop, it is safe to delete it. As it has served its purpose, so we don't need it anymore.
$ git branch -d release-v2.5
Deleted branch release-v2.5 (was ff879fe).
Hotfix Branches
A hotfix branch must be branched off from
masterand must be merged back into firstdevelopand then intomaster.
A hotfix branch is created from master branch if there is some critical bug arises on production that needs to be release as soon as possible.
$ git checkout -b hotfix-v2.5.1 master
Switched to a new branch "hotfix-v2.5.1"
$ vi package.json # change version to v2.5.1
Files modified successfully, version bumped to v2.5.1
$ git commit -a -m "Bumped version to v2.5.1"
[hotfix-v2.5.1 41e785b] Bumped version to v2.5.1
1 files changed, 1 insertions(+), 1 deletions(-)
After fixing the bug,
$ git commit -m "Fixed registeration validation issue on production"
[hotfix-v2.5.1 ab785d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-)
Finally, the fixes made on the hotfix branch need to be merged back into develop, so that future releases also contain fixes made in the hotfix branch.
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff hotfix-v2.5.1
Merge made by recursive.
(Summary of changes)
$ git tag -a v2.5.1
Next, add those bugfixes in develop, too:
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-v2.5.1
Merge made by recursive.
(Summary of changes)
When a release branch already exists, the hotfix changes need to be merged into that release branch, instead of develop. But If changes are necessary in develop branch, it can be merged into develop instead
Finally, remove the temporary hotfix branch as well:
$ git branch -d hotfix-v2.5.1
Deleted branch hotfix-v2.5.1 (was ab785d6).
I hope you enjoyed the article, thanks for reading 😊