In the development process of large-scale software engineering projects, many problems related to git are often encountered, especially branch management and merging when multiple people collaborate, and code management chaos for testing and development. These problems often lead to extremely confusing commit records and even lost code. Git Flow came into being, providing a standardized branch management process.

This blog briefly summarizes the use posture of Git Flow, and also records a little bit of the problems and solutions encountered by tossing Git and Git Flow.

What problem Git Flow solved

• Different roles can be developed in parallel, keeping the isolation between roles as much as possible
• A stable source of code for the production environment
• Align with the DevOps development process

Branches in Git Flow

Feature Branches

• For the development of different features when multiple people collaborate, there can be more than one
• Based on the develop branch, merge directly back into the develop branch
• It can be deleted after the merge is complete

Develop Branch

• There is only one, which serves as a baseline branch for development
• Contains all the code you want to publish to release
• Bug fixes caused by merging the Feature branch and the Release branch
• CI/CD corresponding to the test environment
• Large-scale development is often a read-only branch and only accepts PRs from the Feature/Release Branch

Release Branch

• Corresponding to the pre-release environment CI/CD (sometimes called UAT (User Acceptance Test) environment in practice)
• Merge the develop branch, complete the test, fix the bug
• Contains all the code you want to publish to the master/main branch

Hotfix Branch

• Emergency bug fix branch after the feature goes live
• After the fix is complete, add the PR to the master/develop branch

Master Branch

• Master branch, read-only. Only accept PRs from other branches
• When pushing, you need to play git tag to do version tracking

Workflow

1. Git init initializes the project and checks out the first develop branch.
2. Multiple developers check out, forming multiple feature branches.
3. After the feature is developed, merge back into the develop branch.
4. After all functions are developed in the current stage, check out the release-x.x.x branch from the develop branch to start Release.
5. After completing testing, release configuration, and minor bug fixes, create tags and merge into the develop and master branches.
6. Release production code from the master branch
   1. If a bug is found, the hotfix branch is checked out based on the master branch to fix the bug.
   2. When hotfix finishes testing, merge back into the master/develop branch and type tag.

Precautions

• It is strictly forbidden to use git rebase to merge code on several public branches (master, release, develop). Git merge is used, and --no-ff is recommended to ensure that changes to each merge can be clearly tracked.
• On private branches, such as your own feature branch, you can use git rebase to synchronize the progress of the develop branch.