Git flow

The "Git flow" is the Git workflow created by Vincent Driessen: A successful Git branching model

Main concept

The Git workflow is the set of rules follow by a group of developers to ensure good practice and minimize risks (git conflicts, bad merge...)

Let's analyse the following flow:

  • Git Flow
  • GitHub Flow
  • GitLab Flow
  • Trunk Based Flow

Requirements of a git flow

A proper Git Flow needs to fit those requirements:

  • The development of one developer must NOT impact and other developer work.
  • How to use Pull Request/ Merge Request, who review it...
  • The number of branches.
  • How to create a Feature/Release/HotFix/BugFix branch (From which branch...).
  • How merge are performed. Are cherry-pick used instead of merge ?

Git Flow

It was one of the first work flow to be fully documented. For that simple reason many compagnies used it. It concentrate around activ development and continuous/urgent maintenance.

  • Two permanent branches: master and develop.
  • New features or fix are new branches from develop.
  • To put it in production, a release branche is created from develop to be tested.
  • Once the production deployment is finished, the release branch is merged in master and in develop.
  • A tag is create on master to mark this new version.
  • For urgent fix, a branch is created form a master tag.

Pros and Cons

Pros:

  • Very good for project with planned deadlines.
  • Easy feature development without impacting other team member.
  • Delivery can be planned without impacting current development.

Cons:

  • Hard to understand at first.
  • Not easy to remove feature from delivery.
  • Merge in develop can generate many conflicts.
  • Incompatible with continuous deployment.

GitHub Flow

This flow is also called Forking Workflow has been popularized par GitHub using forks and pull-requests. Those concept didn't exist before GitHub and GitLab.

  • One central repo usually named upstream
  • One branch master and all feature are made in branch from master
  • Pull-request are use for feedback and merge

Pros and Cons

Pros:

  • Perfect for open-source development.
  • Easy to understand.
  • Compatible with continuous deployment.

Cons:

  • Incompatible with delivery deadlines.
  • Urgent fix are not considered.

GitLab Flow

This flow is like an in between of the previous two.

  • Two permanent branches: master and develop.
  • One branch per environment.
  • Every delivery has it's own stable master. Only major bug fix are committed to that branch.
  • One branch by feature. git cherry-pick if use with small branch to avoid merge of highly number of commits.

Pros and Cons

Pros:

  • Used for deployment project where all branches are stable.
  • Add good programming tips.
  • Strong CI/CD integration.

Cons:

  • Way to hard for simple development.
  • Many branches and merge request needed to update code.

Trunk Based Flow

  • All developers work on a single branch master.
  • New features are created in feature branches from master.
  • Feature branches are merge in master only when the branch compiles and passes all tests.

Pros and Cons

Pros:

  • Perfect for minimum viable product approach.
  • Fast development after first version.
  • Tends test coverage to reach 100%.

Cons:

  • Not viable for open-source project.
  • Hard to perform with junior developers.
  • Hard to perform with large teams.

Comparison

FlowTeam sizeCompatible with CI/CDType of projectsTest restriction
Git FlowNo restrictionFalseAny typesNo restrictions
GitHub FlowNo restrictionTrueMostly open-sourceIntegration test are mandatory
GitLab FlowMediumTrueMulti-environments projectUnit test are mandatory
Trunk Based FlowSmallTrueAny typesUnit test and integration test are mandatory

Sources

Jobs Testing guidelines