In this article, we’ll discuss some of the branch workflows that are most popular with Git users, and you can choose which works best for you.

Git Flow

Git workflows are the most widely known. Invented by Vincent Driessen in 2010, this workflow is based on two branches with a permanent life cycle:

  • Master branch – online code for the production environment. All development code is merged into the Master branch at some point.
  • Develop branch – corresponds to pre-produced code. When functional branches are developed, they are merged into the Develop branch.

In parallel, other types of branches are used to support the development process during the development cycle:

  • Feature -* (* indicates wildcard, same below) branch – Feature branch is used to develop new features included in the next release. These branches should all be derived from develop, and should eventually be merged back into develop as well.
  • Hotfix -* branches – When there is a condition in the master branch that should not occur, it is necessary to derive hotfix branches to make emergency fixes to the master branch. These branches should be derived from the Master branch and should eventually be merged back into both the Master and Develop branches.
  • Release -* branch – The release branch is used to prepare a new production environment release update. Create the Release -* branch to fix minor bugs not found in the test environment and update the original information for this release. It should derive from the Develop branch and eventually merge back into both the Master and Develop branches.

advantage

  • This workflow ensures that both major branches are in a clean state at all times during the project lifecycle
  • Branch naming is easy to understand because it follows a systematic pattern
  • Most Git tools support extensions to this workflow
  • This workflow pattern is ideal when multiple production releases need to be maintained simultaneously in a project

defects

  • Git’s history will be very messy and unreadable
  • The split of the Master/Develop branch makes the CI/CD process more difficult
  • This workflow is not applicable when a project is maintaining a single production release

GitHub Flow

GitHub Workflow is a lightweight workflow created by GitHub in 2011 that follows six principles:

  1. The master branch code can be deployed at any time
  2. Any new changes need to be derived from a branch of Master and given a name that describes the new changes: new-oAuth2-scopes, for example
  3. Commit the new branch changes locally and push changes to the server side with the same name on a regular basis
  4. Create a pull Request whenever you need help, feedback, or think new branches can be merged
  5. New branches are allowed to merge into only after review has been approved by othersmasterbranch
  6. Once the new branch is merged and pushed tomasterBranch, master Branch should be deployed immediately

advantage

  • This workflow is CI/ CD-friendly
  • Git workflow is a simple replacement for Git workflow
  • This workflow is applicable when a project is maintaining a single production environment release

defects

  • The code corresponding to the production environment can easily be in an unstable state
  • There is insufficient support for projects that rely on release schedules
  • This workflow does not address solutions to deployment, environment, release, and issues
  • This workflow is not applicable when a project is maintaining multiple production releases

GitLab Flow

GitLab Workflow was created by GitLab in 2014. This workflow combines a feature-driven development pattern with problem tracking. The main difference with GitHub workflow is that GitLab workflow creates new environment-specific branches (e.g., staging branches and production branches) for projects that do not need to be deployed to production immediately after each merging of functional branches (e.g., SaaS software, mobile software projects, etc.).

GitLab workflows follow the following 11 principles:

  1. Use functional branches for development, rather than directly inmasterCommit code on the branch (if your main development branch ismasterIf so, the same as below)
  2. Test every commit, not just onmasterBranch test
  3. Run automated tests on all commits (if your test scripts took more than 5 minutes to run, have them in parallel)
  4. Do code review before merging code, not after
  5. Automate deployment by branch name or TAG
  6. A tag is set by a person, not a CI
  7. The release should be built on a tag
  8. Pushed commits should never rebase
  9. All the people frommasterSpawn new branches and eventually merge back into ‘master’
  10. Bug fixes should be prioritizedmasterBranch code, then cherry-pick to the online branch after repair
  11. Commit messages should be meaningful

advantage

  • In contrast to the first two workflows, GitLab workflows define how to integrate CI and CD processes
  • The commit history will be very clean and the history information will look more readable (see: Why Developers should use Squash and Merge, not just Merge)
  • This workflow is applicable when a project is maintaining a single production environment release

defects

  • More complex than the GitHub workflow
  • When a project maintains multiple production releases, it can become as complex as Git Flow

One Flow

The One Flow is a proposed alternative in article GitFlow considered harmful by Adam Ruka, written in 2015. The main condition that needs to be satisfied in order to use OneFlow is that every new production release is based on the previous release. The most difference between One Flow and Git Flow that it not has develop branch.

One Flow was first proposed in the article GitFlow Considered Harmful By Adam Ruka, 2015, as another option of GitFlow. The most important condition to meet with One Flow is that every update to the production release is based on the previous production release. The biggest difference with Git Flow is that there is no develop branch.

advantage

  • The commit history will be very clean and the history information will look more readable (see: Why Developers should use Squash and Merge, not just Merge)
  • Flexible team work mechanism
  • This workflow is applicable when a project is maintaining a single production environment release

defects

  • Automate CI/CD capability projects with caution
  • The functional branching is not clear and is not suitable for continuous integration
  • This workflow is not applicable when a project is maintaining multiple production releases

reference

  • “A Good Git branching model” by Vincent Driessen
  • GitHub FlowGit by Scott Chacon
  • “GitFlow is Harmful” by Adam Ruka
  • “A good Git branching model is considered harmful” by Jussi Judin
  • Introduction to GitLab Flow by GitLab
  • OneFlow — A Git branch model and Workflow “by Adam Ruka
  • “11 Rules to Follow for GitLab Workflows” by GitLab

Translated from:medium.com/@patrickpor…