Git Flow Explained: Quick and simple

Hi I hope you guys are doing good, you might wonder why another gitflow article when there are tons of articles already out there unfortunately many of them, I go through have too much detail which kind of irritating when someone like me is looking for simple and quick explanation rather than bombarded with a bunch of information.

Before we get started, let me clear a few things, I am not introducing anything new in gitflow process, presenter (nvie) of this development model explains the gitflow process in great detail in this link, however I try to break things down into simple and easy steps to make the gitflow understanding easier.

I am assuming that you know the basics of git, if you are new to git then you can follow the link below to get started with git, the best part about this guide is about how simply it explains git concepts.

git - the simple guide - no deep shit!

so let’s get started with gitflow.

Main Branches

Master (Represent production-ready state of source code)
Develop (Represent Latest delivered development changes or also called integration branch)

Supporting Branches

These branches are created as per need once completed you can delete them.

Feature branches (feature/???)
Release branches (release/???) e.g release-*
Hotfix branches (hotfix/???) e.g hotfix-*

??? Depend upon the naming convention you prefer or anything that is preferred by your organization.

so let’s start exploring them one by one.

Feature branches

May branch off from: develop
Must merge back into: develop

1. Feature branches are also sometimes called topic branches
2. Merge back to develop when we definitely want to add the new feature to the upcoming release, if the feature is unstable/incomplete do not merge feature in to develop branch
3. Typically exist in developer repos only, not in origin.
4. Use --no-ff flag to merge changes in to develop branch to keep track of the historical existence of feature branches
5. Delete feature branches when they are finished or discard them in case of bad experiment.

Release branches

May branch off from: develop
Must merge back into: develop and master

1. Represent preparation of a new production release to deploy changes on Testing server
2. Do bug fixing in this branch, bug fixes may be continuously merged back into the develop branch
3. In this branch Adding large new features here is strictly prohibited
4. All features that are targeted for the release must be merged into develop
5. Create a release branch with a name reflecting the new version number
   e.g (git checkout -b release-1.7 develop)
6. If release branch is ready to be released on the production server do the following steps
   1. Merge release branch into master
   2. Create tag for future reference, e.g. (1.7)
   3. Merge changes back to develop branch
   4. Delete release branch

Hotfix branches

May branch off from: master
Must merge back into: develop and master

1. Hotfix branches are created from the master branch
   (e.g) git checkout -b hotfix-1.7.1 master
2. Fix the bug in hotfix branch, when finished with bug fixing perform the following steps
   1. Merged hotfix branch into master
   2. Create Tag for future reference e.g (1.7.1)
   3. Merge changes back to develop branch (Section Exception Case)
   4. Delete hotfix Branch

Exception Case

The one exception to the rule here is that, when a release branch currently exists, the hotfix changes need to be merged into that release branch, instead of develop. Back-merging the bug fix into the release branch will eventually result in the bug fix being merged into develop too, when the release branch is finished. (If work in develop immediately requires this bug fix and cannot wait for the release branch to be finished, you may safely merge the bug fix into develop branch)

i hope this guide helped you in getting a quick understanding of gitflow process, if you any questions/suggestions do let me know in your response, i will try address them asap.

Thanks, bye.