Git branching policy for team with scheduled releases (GitFlow)

In this post I'd like to share with you how to organize branches in a team with scheduled releases and what flow worked perfectly fine for our team setup.

Spoiler - GitFlow.

Teams configuration and release schedule

Let's talk about our teams configuration, release schedule and some business requirements to the development and release processes first.

At the time of this post this flow was successfully tested on 2 Scrum teams both working on the same codebase/project.

Teams have 2 weeks Sprint duration where first 2-3 days of the Sprint are dedicated to regression testing and release to production process. Not all members of the teams are booked for regression testing and bugfixes in the beginning of the Sprint, so it was required to have ability to start working on next version while previous version is being tested and deployed.

Before different flows and branching policies where researched and approved - The Business required to provide an ability to make some king of hot-fixes or urgent code changes in the middle of the Sprints. This requirement is based on possible unpredicted laws or regulations changes that our project is depending on.

Important to say that the project does not require to support multiple versions in the same time. Not like packages for example (v1.5.0, v2.0.0, etc.) - we have 1 version of product in production only.

What is GitFlow and how we use it

Having strict releases schedule, some specific business requirements and release process - we found that GitFlow covers all the requirements that we have.

GitFlow is branching policy that introduces 2 long living branches (main/master and develop), organizes parallel work on features for developers, documents release and hotfix branches flows.

Let's review it in more details.

*Images below are based on GitFlow cheat sheet

Branches types

GitFlow has 2 long-living branches – develop and master.

GitFlow has 3 types of short-living branches - feature, release, hotfix:

• master – reflects code in production,
• develop – ongoing tasks,
• feature/feature_name – temporary branch for developing feature,
• release/vX.X.X – branch reflecting set of new features preparing for production (release candidate),
• hotfix/hotfix_name – temporary branch for urgent code changes in the middle of the Sprint.

Flow description

The flow will be described below in reflection to Sprint activities.

Sprint started

New sprint started - developers are starting to work on new features (Regression testing flow will be covered below).

New feature flow

Direct pushes and merges to develop and master branches are restricted for developers. To start new feature – developer must create new branch from develop branch.

Name convention – feature/feature_name.

• Example – feature/999_add_new_button.
• Where 999_ - is ID of task in bug-tracking system.

Developer can do everything in feature branch to keep it up-to-date in relation to develop branch (including rebasing and force pushing).

Developer finishes feature in branch and makes push. It’s time for integrating to develop.

Integrating changes to develop branch

Developers can merge feature into develop only via pull request.

PR policy:

• All developers will get notifications about new PRs
• There is group of Mandatory reviewers, at least one from this group (except PR author) should approve PR

After approving – branch is squash-rebased on develop.

Feature branch is deleting after merge. It is not needed anymore.

As a result – git history is clean.

develop branch is constantly deploying to QA server for functional testing/bugs verification of sprint tasks.

Sprint end

Release flow start (regression started)

Sprint is finished – developers are starting new release cycle by creating release branch. After this point - new sprint development can be started in develop branch.

Name convention – release/vX.X.X

• Example – release/v1.0.3
• Where v1.0.3 - is new version number.

Release branch is building and deploying to Stage environment for regression testing. Regression bug fixes for this release must be committed only once to current release branch. Direct pushes and merges to release branches are restricted for developers. To start new bugfix – developer must create new branch from release branch and then submit a PR into release branch.

Closing release (regression finished)

Regression is finished - release is ready for Production deploy.

Release is closed with next actions:

• release branch merged to develop and master.
• master tagged with version number vX.X.X.
• release branch now can be deleted.

Hot fix flow

In case of hotfix required – hotfix branch is created from master.

Name convention – hotfix/hotfix_name

• Example – hotfix/716470_regulations_update
• Where 716470_ - is task ID in bug tracking system.

Hotfix branch is deploying to Stage for testing. After testing – hotfix is closed in git.

• Hotfix branch merged to master and develop.
• master branch has new tag with hotfix name.

New build from master with latest hotfix is deploying to production. This flow can be done anytime in the middle of the Sprint if needed.

Summary

This post described a successful case of using GitFlow in real teams. Let's talk about some pros and cons

Advantages of GitFlow

• GitFlow encourages to use Pull requests before merging feature into development.
  • This leads to code reviews.
  • Potential bugs decreasing.
  • Knowledge sharing.
• Regression Bugfixes are committed only once, there is no need to fix same bugs twice both in long-lived release branch and the cherry-picking it into develop branch.
• Branches are organized in folders feature/, release/, hotfix/ - better readability in git clients.
• Git history is much cleaner due to using rebase where possible.
• Any standardization is good at growing team, no chaos.
• The flow is quite popular – easy onboarding for new people.

Disadvantages

• From experience - this flow is quite hard to understand for people just starting working with git or in teams.
• GitFlow does not fit for projects required to support multiple releases in the same time.
• Overcomplicated for small teams. Probably GitHub flow or Gitlab flow will fit better.