Git Flow – everything that you need to know for your everyday work

Posted On February 12, 2022

Working with Git is one of the most important things that you could learn as a software developer. There are many different strategies for how we can work with Git and branches. I will focus here on the most popular approach for mobile projects – Git Flow. You will find here all the basic stuff that you will need for your everyday work

What types of branches do we have?

• develop – ongoing development is happening here
• release – branch with release candidates sent to QA, or in partially rollout
• master/main – branch where there is current production code, 100% rollout
• feature – new features/improvements
• fix – fix bugs
• hotfix (optional) – bugs, that are critical on master, and should be delivered ASAP
• epic (optional) – bigger features, treat it like temporary develop for some bigger feature.

As a developer, I want to…

…work on a story.

The easiest part. When you want to deliver a new feature, improvement, etc.

• git checkout develop
• git fetch
• git pull
• git checkout -b feature/{story-name-here}, example feature/and-123-new-feature
• Work on a feature, push commits, and when ready…
• git push
• Create a PR from your feature branch to develop
• NOT merge master, hotfix, release or develop 
• You can merge with squash

…work on a bug.

Starting to be a little tricky. In Git Flow your code live in a multiverse. Similar to one that you know from the Spiderman movie. There are multiple branches, living at the same time with multiple versions of the code. You have to understand where is a bug, and how fast you should deliver it.

…work on a bug on release.

Bugs that were found out by QA’s during the regression tests, or during the partial rollout. What is also important, these bugs have to be blockers, that we don’t want to release to the users, they can’t wait for the next release.

• git checkout release
• git fetch
• git pull
• git checkout -b fix/{story-name-here}, example fix/and-666-huge-bug
• Work on a bug, push commits, and when ready…
• git push
• Create a PR from fix branch to release
• NOT merge master or hotfix or develop 
• You can merge with squash

…work on a bug on develop.

Bugs found that can wait for the next release.

• git checkout develop
• git fetch
• git pull
• git checkout -b fix/{story-name-here}, example fix/and-666-huge-bug
• Work on a bug, push commits, and when ready…
• git push
• Create a PR from fix branch to develop
• NOT merge master or hotfix or release
• You can merge with squash

…work on a bug on master.

These bugs are critical and were found on the current production version. Can’t wait for the next release, we need to deliver them ASAP.

• Create hotfix branch from master if there is no any.
• Checkout on hotfix 
• git checkout -b hotfix/{story-name-here}, example hotfix/and-666-huge-bug
• Work on a bug, push commits, and when ready…
• git push
• Create a PR from hotfix branch to hotfix
• NOT merge master or develop or release (only hotfix)
• You can merge with squash

…release a new version.

We can release a new version from two branches: develop, master. Most of the time we release by creating a release branch from the develop and ship new release candidate.

…release a new version with new features.

• git fetch
• git checkout release (or create new release branch, depends on your strategy)
• git merge (without squash) origin/develop.
• Run your deploy scripts or whatever you do to build a new release
• Send release build to QA
• Create a PR from feature release to develop AND master
• Work on fixes from release
• If you need to send a new version, just run your deploy scripts
• When release is 100% shipped merge to develop AND master
• Merge, but NOT squash

…release a new version with hotfix.

• git fetch
• git checkout hotfix (or create a new hotfix branch, depends on your strategy)
• git merge (without squash) origin/master.
• Run your deploy scripts or whatever you do to build a new release
• Send release build to QA
• Create a PR from feature hotfix to develop AND master
• Work on fixes from hotfix
• If you need to send a new version, just run your deploy scripts
• When hotfix is 100% shipped merge to develop AND master
• Merge, but NOT squash

…merge with squash. (Bonus)

Bonus section for all developers who want to have clean git history, but are afraid of using squash.

• Always remember about your parents! (parent branch)
• Merge to your branch ONLY parent one from where you started 
• For example if you created a branch from develop – you can merge develop
• You can squash your story or fix branches feature/, fix/, hotfix/sth
• Do NOT squash when merging protected branches release, develop, master, hotfix
• Don’t be afraid to ask! Too many questions are better than too few!