DEV Community

Cover image for Git flow and github flow
Fakorede Damilola
Fakorede Damilola

Posted on

Git flow and github flow

Recently I had the opportunity to learn a concept, that well, looked quite scary whenever I was asked in an interview.

The interviewer gives a very strong face with no smile at all and asks.. what is git flow.
Me: *sweating already :) *

So after going through git and GitHub flow, I want to share what I have learned, and help you realize why it is quite an important concept to be familiar with.

Git flow and GitHub flow are steps you take when building software or app. This is quite common in a company setting. Since in a company, you will be working with other developers, and you have a goal, a timeline, and more often than none, a project manager bugging you :):).

So in a situation where we have multiple developers working on a single product at different times of the day. There can be errors that can occur if this is not properly handled

So how does this flow help you?

As I said, I like to think of git and git flow as processes that define specific ways to work with other developers and make the process easy

The GitHub flow actually looks and feels quite simpler to use than the git flow but I am going to talk about the two and show you how it works


Here is how the git flow works.

  • There is always a branch by default called main(or master) where the live/production code stays (by convention). One file goes missing in that master branch, and the site might come crashing down. So due to the peculiarity and the sensitivity, you usually don't touch this branch

  • Another branch is created called the develop branch (by convention) which should contain all the code from main ( basically checked out from main), new changes are added to this branch from the feature branch

  • The feature branch contains the different features being worked on. This can be multiple branches with different names, a naming system for example will be feature/notification, feature/api, feature, etc
    This honestly can be different anyhow I just want to give you a feel of how the feature branch works

When a feature branch has been completed and/or tested, it is then merged to the develop branch, since this is where the code currently being worked on stays

After a few merges to the develop branch (from the feature branches) and the project manager thinks it is time to push this to the master branch for others to see the beautiful updates, a release branch is fork(Git fork operation will create a completely new copy of the target repository) from develop

  • A release branch will mean all the feature up to that point is ready to move to live and no new feature will be added to that release branch

Once the release branch has been tested (or whatever trick and hoops it is made to pass through), and it is ready to be released, the release branch gets merged into the main branch and
tagged with a version number.
In addition, it should be merged back to the develop branch in case there are any differences or critical changes made to the release branch. ( just to be safe)

  • Maintenance/hotfixes branches are used to patch production releases, and this is forked directly from the main branch. After which it is merged back to the main branch and the develop branch (to keep it in sync)

Now let's do a quick recap of what is needed for the git flow

1) main (master) branch: This holds the production code

2) develop branch: This is created from the main branch

3) feature branch: these are created from the develop branch (e.g feat/notification, feature/buy, etc)

4) release branch: The branch that will be sent off to the main branch. forked from develop

5) hotfix branch: crated from the main branch, used to fix production/ emergency error

honestly, that is a whole lot...let's talk about the GitHub flow

GitHub flow

The GitHub flow uses two branches

  • The main (or master) branch is where the live/ production code stays (similar to the git flow)

  • The feature branch which is every other branch, is where developers work from, which are pulled off from the main branch. Once a feature is completed, a pull request (PR) is opened to the main branch, and after proper testing, etc. It is merged with the main branch (production)

That is pretty simple and straight forward right :):)

Depending on the culture of the company, they can decide to use git or GitHub flow, but honestly, I prefer the latter.

Getting familiar with this concept might require working with it on your projects. Since quite many companies will want to use these flows, it is better that you familiarize yourself with them.

In this article, I hope you have been able to learn the difference between git flow and GitHub flow, and how they work.

Thank you

Top comments (6)

theaccordance profile image
Joe Mainwaring

I have worked in a highly-collaborative environment under both strategies, and I view it as picking the right tool for the job.

Git flow is something I view appropriate for manual deployment workflows, whereas Github flow is becomes a more rationale approach when you introduce automations with CI/CD - like a testing suite as part of pull requests, and auto-deploying your trunk to a unstable environment

fakorededamilola profile image
Fakorede Damilola

Thank you for this, I have done a little research and think this will be a good suggestion.
I will make a little change to the article. Thanks

naucode profile image
Al - Naucode

That was a good read, thank you, followed and bookmarked!

vinksz profile image

Git Flow - big companies / open-source projects
Github Flow - small companies or individuals it seems

what about CI/CD tho?

onibrother profile image

i'm totally new at this, so your post was a good introduction to this!

lengsovandara profile image
Sovandara LENG

Short and informative article. Appreciated