In this standard, we suggest you multiple implementations of Git Flow. Each flow is different. Some is better when you're developing, some is better when your project was already go live. This standard will help you pick the right one for your project.

Before we start, one thing that's constant is we will use only one branch as a standard.

TL;DR

Flows

There are three flows we suggested you in this standard:

  1. Feature Branching: have main branch and feature branch(es).
  2. Gitflow Workflow: have two branches such as main branch and development branch
  3. Trunk-based Development: it is like Feature Branching but feature branch is very short-lived and will be merged into main branch as fast as possible. Project should also implement feature flags to turn on/off feature as well.

Flow Selection

Here's how you choose a Git Flow for your project:

Flow Selection
Flow Selection

Comparison

Topic Feature Branching Gitflow Workflow Trunk-based Development
Development
Number of branch(es) 1 2 2
Branching By feature By feature By feature and release
Feature branch live Long-lived N/A Short-lived
When to merge? When feature is done When feature is done Depends but every often
(everyday, every 2 days, etc.)
Code review Possible Possible Recommended
Deployment
Development Server On pushed to main branch On pushed to development branch On pushed to main branch
Staging Server (if any) Manually deploy from main branch On pushed to main branch On pushed to release branch
Production Server On tag pushed from main branch On tag pushed from main branch On tag pushed from release branch

Feature Branching
Feature Branching

Concepts

  • A single main branch (usually named main)
  • Branching is required to develop a new feature, enhancements, bug fixes, and etc.
  • Frequently merge main branch to feature branch
  • When it is finished, code review (including pipelines) is required before merging into main branch.
  • Delete feature branch immediately after it has been merged

Deployment

  • Development: Deploy when pushed into main branch
  • Staging (if any): Manually deploy from main branch
  • Production: Manually deploy by creating a tag from main branch

When do you want?

  • Project is in development phase or support phase
  • Team has senior developers enough to review the code for every other developers
  • There are many features or tasks to do and they need to be implemented at the same time

References

Gitflow Workflow
Gitflow Workflow

Concepts

Similar as Feature Branching but

  • There is a development branch (usually called dev). It is an active branch which replaced the main branch. Developers usually work on this branch by create a new feature branch from this branch.
  • Feature branch should frequently merges development branch into its branch
  • The main branch will be the branch to prepare for release
  • Hotfix will be merged in the main branch and it needs to be merged back into development branch
  • When everything is ready, merge development branch to main branch for release preparation.

Deployment

  • Development: Deploy when pushed into development branch
  • Staging (if any): Deploy when pushed into main branch
  • Production: Deploy when pushed tag created from main branch

When do you want?

  • Your project is SaaS or product development such as standard project
  • Features are implementing along side with bug fixes
  • Team has senior developers enough to review the code for every other developers

References

Trunk-based Development (with Feature Flag)

Trunk-based Development
Trunk-based Development

Concepts

Similar as Feature Branching but

  • There is a separated branch called release to freeze the development in a certain time, preparing to deploy to staging (if any) or production.
  • Feature branches are short-lived
  • Every point in main branch should be production-ready. Here comes the Feature Flag.

Feature Flag

Feature Flag[1] (aka. Feature Toggle) is the ability to turn on or turn off every particular feature without re-deploying which is a time-consumed task.

Feature Flag also helps us to turn off a feature that we don't want to release as well. This will allow us to merge our code as fast as possible to main branch without considering that it will be released on production or not.

Deployment

  • Development: Deploy when pushed into main branch
  • Staging (if any): Deploy when pushed into release branch
  • Production: Deploy when pushed tag created from release branch

When do you want?

  • Project is in go-live phase but there are features left to be implemented as well as fixing bugs in production server
  • Release schedule is strictly
  • Has enough senior developers to review everyone's code
  • Already set-up CI/CD

References