Git Flow vs GitHub Flow

Git Flow vs GitHub Flow

by | 8 min read

Losing code that you have spent hours writing can be painful, which is why we use version control (or source control) to store our code and manage changes.

Version control is even more important if you are working in a team, without it code, changes can get messy quickly.

Version control has been around for a while in various forms but it seems most of the development community has settled on Git as the defacto way of managing code changes.

What are Git and GitHub?

Git has been around since 2005 and has become the predominant version control used amongst developers.

Git works on branches. You have your working deployable code in the main branch (sometimes called master branch) and then you can branch off copies of the code to allow you to make changes.

This allows multiple developers to work on the same codebase without treading on each other’s toes.

All the work you are doing stays on this separate branch until you are happy with the changes, it has been reviewed if you are working in a team, it has been tested and then it can be merged back into the main branch.

There are a lot of different commands for git but the mains ones are:

  • git clone https://….git used for cloning a repository onto your local machine
  • git branch <branch> used to create a new branch on your local machine
  • git checkout <branch> used to switch to the new branch.
  • git add <file> add a file to the staging area ready to commit.
  • git commit -m “commit comment goes here" commit your changes to the branch.
  • git push -u origin <branch> used to push your changes to the remote server.
  • git pull used to pull down other people’s changes from that branch.

When you are working with other people on an application you need a shared location to store all the code.

🚀 Are you looking to level up your engineering career?

You might like my free weekly newsletter, The Curious Engineer, where I give career advice and tackle complex engineering topics.

📨 Don't miss out on this week's issue

A lot of developers now use GitHub to host their code. Hosting code on GitHub is completely free for both public and private repositories.

It is also a great resource for developers. If you have spent any time in software development I am sure you are already familiar with GitHub already.

GitHub isn’t the only option for hosting code you can also use BitBucket as well as host your own repository using GitLab.

When working in a team there are 2 main branching strategies that are used, Git Flow and GitHub Flow.

What is Git Flow?

Git Flow is the most commonly used branching strategy. Git Flow is particularly useful when your development cycle resolves around releases.

If you work using Scrum and expect to do a single release at the end of the sprint then you will want to use Git Flow. Also if you rely on QA to do manual testing of your code before it goes to production, then this could be another reason why you might want to use Git Flow.

Git Flow

Git Flow works around several branches that need to be set up.

  • main (or master) - stores the currently released version of code and should match the code that is in production.
  • develop - stores a copy of the main branch with all additional changes that have been added since the last release.
  • feature - developers branch off of develop and create feature branches for any new features they are working on. There isn’t a single branch called feature unlike main and develop. Branch names will generally be named based on the change that is being made bug/StackOverflowFixInService. If you are using JIRA and have the GitHub or Bitbucket integration set up then you might see the JIRA issue number in the branch as well so that the branch gets shown on the JIRA ticket task/PRJ-1234-AddCardPage.
  • release - once the developers are done with the changes a new branch is merged from develop to create the release. The branch will generally be named after the release number release/1.2.3.
  • hotfix - if there is an urgent production issue that requires a code fix then a hotfix branch is created. This is branched directly off of main and will usually be named after the incident hotfix/INC1234-InvalidPageMatch.

When using GitFlow this is the general flow of how the branches are used:

  1. For new projects, a main branch is created first and left empty, maybe apart from a file.
  2. A develop branch is immediately branched off of main. No changes are ever made directly to main or develop unless you are a cowboy.
  3. Developers will branch off of develop into a feature branch to make their changes. Changes from develop will occasionally need to be merged into the feature branch depending on how long it takes to develop the feature.
  4. Once a change is done a pull request (PR) is created so that the team can review the change before it is merged into develop. Any conflicting changes that have happened on develop will need to be resolved before the feature can be merged.
  5. Once all the work for the release has been done a release branch is branched off of develop. Normally a QA team will run their tests on this release before it is ready for production. In the meantime, the developers can continue working on the develop branch on features for the next release.
  6. If an issue is found with the release then a branch is usually created off of the release branch to work on the fix. This is then applied to the release branch once it has been reviewed.
  7. When it comes to releasing, releases are usually either created from the release branch or from the main branch after the release is merged. If you release from main there is a risk that what you are releasing is different from what has been tested by QA. Although, this shouldn’t happen if you follow the process correctly. Either way, the release should be tagged with the release number so you know exactly what has been released and when.
  8. After release, the main branch will be merged into develop so any changes made during testing are accounted for.
  9. If there is a production issue after a release then a hotfix branch will usually be created off of the main branch in order to apply the fix.

Pros of Git Flow

  • Allows you to work on multiple releases in parallel
  • Provides clear version control as each release is tagged and individually tested and is easy to trace.
  • Allows multiple developers to work on the same feature. Either by committing incomplete parts to develop or by branching again off of a feature branch.
  • Allows for jumping between work for current and future releases as they live on separate paths.

Cons of Git Flow

  • Not suitable for continuous delivery or continuous deployment.
  • Many branches to maintain. You need to remember to merge branches back into others to maintain consistency.
  • Due to the overhead required to release, it can lead to a technical debt build-up.

What is GitHub Flow?

GitHub flow, as the name suggests is the branching strategy used by GitHub. You don’t have to be using GitHub though in order to use this branching strategy.

GitHub Flow

With the GitHub flow, you only ever have 2 branches:

  • main (or master) - similar to GitFlow the main branch contains all the deployable code for the project.
  • feature - developers branch directly off of main to work on new features.

For GitHub flow, the general process is as follows:

  1. As with Git Flow, an empty main branch is created at the start of a new project.
  2. Every change that is worked on is branched directly off of main into a feature branch.
  3. Once a feature is ready it is tested on the feature branch and the code is reviewed before being merged to main.
  4. Once the feature has been merged to main it should be released to production immediately.

Unlike Git Flow there is no concept of a release branch. Every feature makes up its own release and therefore everything merged should be in a deployable state.

Similarly, with GitHub Flow, hotfixes are treated the same as feature branches as they branch off of main already.

Generally, teams using Git Flow have a large number of automated tests that run against each feature before it is merged in.

Handling features and releases in this way allow teams to release multiple times a day instead of at end of a sprint.

In order to be able to release quickly you need to have a solid automated test suite and hands-off automated deployments.

Pros of GitHub Flow

  • Allows for continuous delivery and deployments.
  • Hardly any branch management is needed other than clearing up feature branches once released.
  • Encourages teams to release quickly and get feedback on the work they have done.
  • Less chance for technical debt to build up as it can be tackled without as much overhead.

Cons of GitHub Flow

  • Requires a solid automated testing framework and automated release process.
  • Doesn’t lend itself well to large features that multiple developers need to work on in parallel.
  • Extra diligence is needed as any bug merged into main will go straight into production.

Which Git branching strategy is best for you?

Git branching strategies are a matter of preference. If you don’t have a solid automation suite and completely hands-off automated deployments then GitHub Flow isn’t going to work for you.

Git Flow is generally the preferred branching strategy for companies that need a lot of quality control in place before features are released to production.

For example, financial institutions, where large amounts of money are at risk if a bug is released, are unlikely to use GitHub Flow. Although all teams can benefit from solid automated testing and automated deployments.

GitHub flow is great if you want to move fast and get things into production quickly.

It reminds me of Mark Zuckerberg’s old motto “Move fast and break things”. If breaking things isn’t going to cost you millions of dollars in damages then GitHub flow could be a simpler approach for your team.

If you found this article useful please let me know and feel free to share it with your friends.

🙏 Was this helpful? If you want to say thanks, I love coffee ☕️ , any support is appreciated.


SOLID Principles: Do You Really Understand Them?

SOLID Principles: Do You Really Understand Them?

  • 16 June 2023
SOLID Principles are one of those things that every developer has heard of but few fully understand. If you use an object-oriented language…
Recursion explained with the help from Inception

Recursion explained with the help from Inception

  • 12 May 2023
People love to joke about recursion. As the saying goes: “In order to understand recursion, one must first understand recursion.” You will…
Python List Comprehension: With Examples

Python List Comprehension: With Examples

  • 20 February 2023
Working with arrays can be a bit of a pain in most languages. If you want to make changes to an array you need to use a FOR loop, a bit like…
Finally Understand Regular Expressions: Regex isn't as hard as it looks

Finally Understand Regular Expressions: Regex isn't as hard as it looks

  • 10 January 2023
There’s nothing like a regular expression to strike fear in the heart of a developer. Regular expressions (regex) are used for a lot of…
How I would learn to code (if I could start over)

How I would learn to code (if I could start over)

  • 06 January 2023
When I was 8 years old I learnt how to code. I learnt to code from an old BASIC book that my Dad had lying around from his ZX Spectrum. I…
Understanding Big-O Notation

Understanding Big-O Notation

  • 03 January 2023
It’s important when you’re writing applications especially, those that are going to be processing a large amount of data that you understand…
Stack vs Heap Memory - What are the differences?

Stack vs Heap Memory - What are the differences?

  • 30 November 2022
In modern programming languages such as C# or Java, we tend to take memory management for granted. Gone are the days when we need to call…
Bitwise Operators and WHY we use them

Bitwise Operators and WHY we use them

  • 26 October 2022
Bitwise operators are one of those concepts that a lot of programmers don’t understand. These are not used a great deal anymore so you can…