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

Artur Latoszewski
Dev Genius
Published in
3 min readFeb 14, 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
  • 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.

…work on a bug on development.

Bugs found that can wait for the next release.

…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.

…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
  • Merge, but NOT squash

…release a new version with the hotfix.

  • git fetch
  • git checkout hotfix (or create a new hotfix branch, depending 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
  • 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!

Originally published at https://www.thecodeside.com.

--

--