Overview

I am Cui from the Global Development Group at KINTO Technologies. I am currently the project manager of the Global KINTO App team, and previously the project manager for the back-office system developed by the Global Development Group.
In this article, I will talk about Gitflow, a branch management method implemented within our back-office system development team to manage our source code. I think it can be applied to other products as well, so I hope this article serves you as a reference.

Gitflow

Note: In this article, I will only talk about Gitflow, which was adopted by our development team. In the following explanation, the branch name is written as "master," but when using GitHub, master is an old name, so the default branch is now "main." The roles are exactly the same.
The overall diagram is as follows:

Role of Each Branch

master:
A branch that manages released source code and has the same source version as the application running in production environment. Each release is tagged.

develop:
A branch that brings together the developed source code. It includes features that have not yet been released to the production environment and will always have the latest functionality. Typically, regression tests are deployed and performed on this branch.

feature:
A branch for development of new or modified features. It branches from the develop, and merges back into the develop branch after completion of integration testing. Generally, one feature branch can be created per user story, but the development team is free to decide.

hotfix:
A branch for bug fixes after release. It branches from the master branch, deploys to production environment on this branch after fixing bugs and passing tests. After production is completed, the branch is merged with both the master and develop branches. It merges in some release and feature branches as needed.

release:
A branch for product release.
It branches from the develop branch with the feature to be released reflected.
This branch is used to the production environment. When production is complete, merge in the master and develop branches and delete the branches.

support:
This branch is required for projects that must continue to support older versions. The support branch maintains and releases older versions. It is derived from the commit of the master branch of the version that needs support and independently bugfixes and releases until support is terminated.

bugfix:
In addition to the above five standard branch types, a branch type called bugfix is also defined.
Details are described later, but if a bug is found prior to release, a bugfix branch is branched off from the release branch to deal with the fix.

Development Flow

(1) Initialization

Create a develop branch from the master branch. Note: The master and develop branches will always exist as the main Gitflow branches, and once created, they cannot be deleted. (Set up on GitHub)

(2) Development of new and modified features

1． Create a feature branch from the develop branch and start developing new and modified features.

2． Feature branch naming convention: feature/xxxx
The "xxxx" can be decided by the development team. 　Example: feature/GKLP-001, feature/refactoring, feature/sprint15
It is also recommended to create an additional working branch from the main feature branch in order to make pull requests and perform source reviews before integration testing. Specific patterns will be described later.

3． Commit source code revisions in the working branch, and when finished, submit a PR for review by others.

4． Once the source review is complete, merge it into the main functional branch and perform integration testing.

5． Once the integration test is complete, submit a PR to be merged into the develop branch and merge it.

Note: Please always check the merge timing, as there are times when development must not be merged into the develop branch even if development is completed, depending on the release plan.

6． Delete the feature branch after merging into the develop branch.

Pattern No. 1: Functional branch and working branch

In this pattern, all working branches off the functional branch are merged before the integration testing is performed. This pattern is appropriate when the development of a single feature is large and is expected to span multiple sprints.

Pattern No. 2: Branch per sprint and working branch

In this pattern, you are not limited to performing integration tests after all work branches have been merged, but you can also perform integration tests for a single feature in a sprint once the necessary development has been merged. This pattern is appropriate when the feature to be developed is small in scale and is expected to be completed within one sprint.

Pattern No. 3 (Not recommended): Equating the functional branch with the working branch

In this pattern, the timing of PR submission and integration test would not be clear, and the frequency of merges into develop would also be high, so it would be very cumbersome to make QA and release plans. We do not recommend such an approach that lacks planning. Instead, it is recommended to properly plan your releases during system development and operation and decide how to cut feature branches accordingly!

(3) Release & Deployment

1. Create a release branch from the develop branch.
2. Tag the release branch. (See Tag naming convention below for naming convention.)
3. When deploying to production environment is finished, merge the release branch into the master branch.
4. Delete the release branch after the merge is complete.

Release Plan

For development that you plan to release into production environment, create a release plan as soon as possible.
The operational rules of the feature branches and the timing of merging feature branches into develop are determined according to the release plan.
The simplest release plan is to release all features that have been developed in the develop branch, which only requires the creation of a release branch.

However, if multiple development teams are developing different features at the same time and plan to release them multiple times, you should create a release branch first and merge the targeted features one by one. For example, if features 1, 2, and 3 are developed simultaneously, but features 1 and 2 are released first and feature 3 is released a few weeks later:

Once release branches such as release 1.0 and 2.0 above are created by branching off from the develop branch, the rule is that, in principle, modified source code from the develop branch should never be merged in again.
The reason is that if there are multiple release plans, after the release branch is created, another feature may be merged into the develop branch, and if the feature is further merged from the develop branch, the feature will be mistakenly released even though it has not been tested. As shown in the figure below:
Also, feature branches are not merged into develop immediately after development is completed. Once merged into develop, it will be included in the next release, so make sure to check the timing of merging feature branches into develop according to your release plan.

If a bug is found prior to release

Create a bugfix branch by branching off from the release branch. Then fix the bug, submit a PR and merge it into the release branch. Fixed bugs are reflected after release work when the release branch is merged into master and develop. As shown in the figure below:

(4) Bug fix in production environment

If a bug occurs in the production environment, follow the steps below to fix it.

1. First, create a hotfix branch from the master branch.
2. Tag the hotfix branch when you are done fixing it. (See Tag naming convention below for naming convention.)
3. When deploying to production environment is complete, merge the hotfix branch into the master and develop branches.
4. Delete the hotfix branch after the merge is complete.

Maintenance branch

The product's version-up policy ensures that it is versioned in units of microservices, and each major version has a certain maintenance period. Therefore, it is necessary to create a maintenance branch for each major version in the GitHub repository of the microservice. For example, the microservice "Automotive" has had three major versions released so far, V.1, 2, and 3, the maintenance branch would look like this:
To make minor changes or fix bugs in an old major version, it is advisable to branch from the corresponding maintenance branch, but you can also make an appropriate release plan depending on the scale of development and decide on development and release branches.

Branch Commit Rule

There are two ways to merge a modified source code into a Git branch:

• to commit directly
• to submit a pull request and have a reviewer approve it before merging
  In principle, it is advisable to opt for the method of making a pull request and then merging.
  However, you may commit directly to the following branches:
  1． Working feature branches for developing new and modified features
  2． Bugfix branches for fixing bugs just before release
  3． Hotfix branches for post-release bug fixes

Tag Naming Convention

Development environment

1.1 On GitHub, manually at release time (not recommended)
　→ Tag the git branch
　Naming convention: x.x.x-SNAPSHOT
　Example: 1.0.0-SNAPSHOT
　→ When registering to ECR, the image is automatically tagged according to tags and time. 　 　Image tag name: x.x.x-SNAPSHOT_yyyyMMdd-hhmmss
　Example: 1.0.0-SNAPSHOT-20210728-154024
1.2 Use JIRA tickets and automatically at release time (recommended)
　→ Do not tag the git branch.
　→ When registering to ECR, the image is automatically tagged according to current branch and time.
　Image tag name: Branch name_yyyyMMdd-hhmmss
　Example: develop-20210728-154024

Staging & Production Environment

Manually tag the release or hotfix branch.
Naming convention: release.x.x.x
Example: release.1.0.0

Challenges solved by this Git branch strategy

Our development team was launched a year ago. At the beginning, we encountered confusion regarding source code management, due to the diverse development experiences and backgrounds of our team members. There was also a "core" team of developers at our headquarters and a "star" team of developers offshore for our project. Although both teams work on the development of different functions, it is inevitable that the same source files are modified at the same time.
Thus, the following problems occurred:

1. Source code conflicts occurred when other people's updates were accidentally deleted
2. Features were developed based on old source code
3. Phased releases were not feasible
   We value teamwork in system development. Rules that are acknowledged and enforced by everyone are essential.
   This is exactly what Gitflow is all about.
   Each team member responsible for developing different features can create different feature branches and modify the sources without impacting on each other's work.
   Also, by keeping the latest source code in the develop branch according to the sprint development cycle, everyone will be able to deploy their own work based on the latest source code at the start of the next development cycle.
   In addition, by creating a release branch for each "release plan," the developed features can be released gradually, thus reducing the burden on developers and the risk of the project itself!
   With this Git branch strategy in place, the back-office system development team I previously led was able to overcome the chaos and stably develop and have features released! In the future, as I take on the role of project manager on the app development project, I aim to draw upon my experiences when encountering similar challenges in the future. Why not use it as a reference for your own product development?