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 develop branch and must be merged back into develop only.

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, sj will be initial of developer working on the feature followed by type of the branch, in this case feature and then actual phrase describing the feature
• If there is any bug on develop branch a bugfix branch should be created instead of feature sj/bugfix/user_authentication_issues and 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 develop branch and must be merged back into first master and 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 master and must be merged back into first develop and then into master.

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 😊