A Review of Git Workflow Management

4 min readApr 6, 2018

This is a summary for git workflow management, which is an important part when having a team working together with git. There are several approaches to manage the workflow:

All in master branch
Feature branch
GitFlow
GitHub flow
GitLab flow

All in master branch

Simple. Everything is a single master branch.

# git pull [remote repository] [branch]
$ git pull origin master
$ git commit
$ git push origin master

git pull is a shorthand of git fetch and git merge FETCH_HEAD. git merge to merge the retrieved branch heads into the current branch.

     A---B---C master on origin
    /
D---E---F---G master
    ^
    origin/master in your repository

To merge these two branches, there are two ways to do that, git pull and git pull --rebase. However, we should note that there is a big difference between them. After git pull,

D---E---F---G---A---B---C---H master
                            ^
                            fix merge issue

After git pull --rebase,

D---E---A---B---C---F---G master

If there is a conflict between C and F, you need to resolve it and use git add to mark them as resolved. Then, run git rebase --continue to continue to apply G.

This is an important difference between git merge and git rebase. I didn’t really understand it until I made some experiments to verify it today.

Feature branch

This is the workflow in my current company.

$ git checkout -b feature/new-branch
$ git add .
$ git commit
# create a remote branch in repository
$ git push --set-upstream origin feature/new-branch

When you want to add a feature or fix a bug, you first checkout a local branch. You make changes locally and push them to a remote branch, not master branch. When you feel it’s ready, you can make a pull request to merge your branch into master branch. After the code review, your code will be merged and deployed.

This approach is simple and works well with small teams. One thing is that we try to keep changes small and iterate fast, instead of having many changes in once.

GitFlow

GitFlow is a famous one. It looks like the following:

Basically, you have to maintain 5 types of branches:

Master: Stable, direct to production.
Develop: Unstable, all feature changes will be pushed here.
Feature: Check out from Develop branch, and push changes back to it.
Hotfix: Check out from Master, push changes to Master and Develop.
Release: Semi-stable, ready to release, following with a few bugfixes. Checkout from Develop and push to both Master and Develop.

The drawbacks are obvious because you have to maintain a Develop branch in long-term. Also, changes in Hotfix and Release need to push to both Master and Develop for sync. The git history would look very messy and hard to follow.

GitHub flow

This is also called Forking Workflow, which is largely used in open source projects. Instead of having a central codebase, every developer can have their own server-side repository. This is the way how we contribute to open source projects in GitHub.

Create a fork of the project under your account
Pull the code to your local dev via git clone
Create a feature branch
Save and push changes to your remote forked repo
Open up a pull request for your feature branch to the original repo

To me, this looks like a distributed version of feature branch workflow. The good thing is that only project maintainers have the write permissions to the official codebase. The contributions can be from any developer, but merging with the approval from the project maintainer.

GitLab flow

This is a version used by GitLab with an improvement from GitHub flow, setting up environment branches, such as pre-production and production, or release branches, such as 2.3.stable and 2.4.stable.

Summary

No matter which one you are using, find one that suits your team best. I believe instead of spending too much time on choosing right git workflow, it’s more worthing to spend time on adjusting team size, split into small repositories, developing CI/CD, and etc. This makes iteration faster and easy to cooperate.