First of all, Merry Christmas everyone (even though it is a bit late)! In this blog post, I want to talk about an introduction to Git branching strategy. The simple question before starting this post: "Have you ever said to yourself that Git in software development is a mistake?" If you're asking the same question to me, my answer is absolutely yes. I used to have a lot of bloody tragedies in Git, especially if the team has a lot of members. The problem may be caused by you or your lovely teammate, which made you to summon everyone in the room to fix the Git issue.

I will provide an example project in https://github.com/freedomofkeima/Git-Branching.

Starting the Bloody Project

Every great projects in Git start with git init. You will commit your usual "Initial Commit" and push your project to Git repository.

At this point, you will be presented with master branch (origin/master) and you need to create a development branch, which will be named as dev branch (origin/dev).

git checkout -b dev  # create a new dev branch for daily development
git status  # ensure that you're in dev branch
git push origin dev  # push this newly created branch to origin/dev

It is recommended to update your default branch to dev branch. Most likely, you will not interact with master branch until the next tagging/release. This dev branch will be used as your current HEAD in development environment, while the HEAD of master branch should be consisted of production-ready code.

Let's say we have two team members, which are named by Maki and Saitama. Maki will develop "Feature A" while Saitama will develop "Feature B". Maki decides to create a new Issue in Github, and set the due date to a certain milestone ("Christmas Feature").

In Maki-PC (from local dev branch):

git checkout -b christmas-feature-a  # Create "Feature A" branch for Christmas milestone

. . .  # Create test.txt
git add --all  # Add all modified and untracked files, it is recommended to check "git status"
git commit -a -m "Add test.txt"
git push origin christmas-feature-a

At this point, you will have 3 branches in your repository: master, dev, and christmas-feature-a. After pushing the commit above, Maki decides to go to America and creates a temporary pull request in Github (base = dev, compare = christmas-feature-a). In the same time, Maki puts a tick in "Issue #1" for her first task.

In Saitama-PC (from local dev branch):

git checkout -b unknown-feature-b  # Create "Feature B" branch for unknown milestone

. . . # Create test3.txt
git add --all  # Add all modified and untracked files, check "git status" previously is recommended
git commit -a -m "Add test3.txt"
git push origin unknown-feature-b

. . .  # Create test4.txt
git add --all  # Add all modified and untracked files, check "git status" previously is recommended
git commit -a -m "Add test4.txt"
git push origin unknown-feature-b

Saitama decides to create a pull request directly from this commit. Maki reviews this pull request and she gives a LGTM message (Looks Good To Me). Saitama merges unknown-feature-b branch (origin/unknown-feature-b) to dev branch (origin/dev) and close the pull request. After merging, branch unknown-feature-b is deleted from origin.

In Saitama-PC (still in unknown-feature-b local branch):

git checkout dev  # go back to dev branch
git pull origin dev  # pull latest merge from pull request in origin/dev branch
git branch -d unknown-feature-b  # delete branch safely after origin branch is removed (using -d instead of -D)

At this point, it should be impossible to have a conflict between dev branch with master branch, since dev should always reflect the newest state of your development. We will create a release version 1.0.0 with current HEAD in dev branch.

In Saitama-PC (currently in dev local branch):

git checkout -b release-1.0.0  # Create a snapshot branch for release 1.0.0 from current HEAD in dev
git checkout master  # Go back to master branch, you may also add the tag before merging to master
git merge --no-ff release-1.0.0  # Merge all changes from release-1.0.0 to master branch (without fast forward)
git checkout dev # Go back to dev branch
git merge --no-ff release-1.0.0  # Merge all changes from release-1.0.0 to dev branch (without fast forward)

At this point, some people prefer to delete the release-1.0.0 branch, while the others keep it for traceability purpose.

Now, you are also ready to create a release version for your clients. You can add a new tag by:

git tag -a 1.0.0  # Add a versioning tag from release-1.0.0
git push origin 1.0.0  # Push tag to repository

You will have a ready-to-serve release, as shown in the following screenshot:

Up until this point, you have learned 4 types of branching: master branch, dev branch, feature branches, and release branches (as a snapshot). We will proceed to the 5th type: hotfix branches. This branch is quite different from your typical feature branches because it needs master branch as its base. This branch serves as severe bug fixes in production environment.

I will skip the step-by-step commands tutorial here. The outline of the steps are provided below:

1. Create a hotfix-1.0.0 branch with git checkout -b hotfix-1.0.0 master
2. Create a commit to fix the underlying bug
3. Create a pull request in Github (base: master, compare: hotfix-1.0.0), wait until several people review your code
4. Merge this branch (hotfix-1.0.0) to master branch
5. Merge back hotfix-1.0.0 branch to dev branch (so it keeps consistent for future releases)
6. Create a new release-1.0.1 branch from master branch as a snapshot
7. Create a new tag (git tag -a 1.0.1 and push it to origin)
8. Delete hotfix-1.0.0 branch safely

--

At this point, you will have 5 branches in your repository: master, dev, christmas-feature-a, release-1.0.0, and release-1.0.1. In addition, you will have 2 releases under your "releases" tab. If Maki decides to continue her work, her changes are not tainted from other changes https://github.com/freedomofkeima/Git-Branching/pull/2. Finally, other people can review those features independently and merge those branches to dev branch after all tests are successfully passed.

Additional note: Some people prefer to differentiate hotfix and release branches (they put the tag to hotfix branch, instead of creating a release branch). The others prefer not to store both of them in their repository.

Now, you have learned five basics of branching: master branch for HEAD in production, dev branch for HEAD in development, feature branches, release branches, and hotfix branches. If you mistakenly create a commit in wrong branch, you can actually undo it (before pushing it to the repository by):

git reset --soft HEAD^  # revert last commit
git checkout [correct_branch_name]  # move to correct branch
git commit  # create a commit in the correct branch

Feel free to correct me if I've written something wrong. Happy holiday!

--
Iskandar Setiadi
Software Engineer at HDE, Inc.
Freedomofkeima's Github