[HL-27] A Review of Git Workflow Management
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
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
Developbranch, and push changes back to it. - Hotfix: Check out from
Master, push changes toMasterandDevelop. - Release: Semi-stable, ready to release, following with a few bugfixes.
Checkout from
Developand push to bothMasterandDevelop.
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.