Best practices for git workflow in large development projects

Gitflow Workflow is a Git workflow that facilitates continuous software development and implementation of DevOps practices. It was first published in nvie by Vincent Driessen and it was very popular. The Gitflow workflow defines a strict branching model designed around project releases. This provides a powerful framework for managing large projects.

Gitflow is very suitable for projects with scheduled release cycles and DevOps best practices for continuous delivery. Except for the content required by the functional branch workflow, this workflow does not add any new concepts or commands. Instead, it assigns very specific roles to different branches and defines how and when they should interact. In addition to feature branches, it also uses separate branches to prepare, maintain, and record releases. Of course, you can also take advantage of all the advantages of Feature Branch Workflow: pull requests, independent experiments, and more efficient collaboration.

Getting Started

Gitflow is actually just an abstract concept of Git workflow. This means that it determines what branches to set up and how to merge them together. We will touch on the purpose of the following branches. The git-flow tool set is an actual command line tool with an installation process. The installation process of git-flow is very simple. The git-flow package can be used on multiple operating systems. On OSX systems, you can execute brew install git-flow. On Windows, you need to download and install git-flow. After installing git-flow, you can use it in your project by executing git flow init. Git-flow is a wrapper for Git. The git flow init command is an extension of the default git init command. It will not change anything in the repository except for creating a branch for you.

How it works

Develop and Main Branches

This workflow uses two branches to record the history of the project instead of a single main branch. Main stores the official release history, and the development branch serves as the integrated branch of the function. It is also convenient to mark all commits in the master branch with a version number.

The first step is to supplement the default master branch with a develop branch. An easy way is to ask the developer to create an empty develop branch locally and push it to the server:

git branch develop
git push -u origin develop

This branch will contain the complete history of the project, while main will contain an abridged version. Other developers should now clone the central repository and create a tracking branch for the develop branch.

Feature Branches

Each new feature should reside in its own branch, which can be pushed to the central repository for backup/collaboration. However, the feature branch does not branch from main, but uses develop as their parent branch. When a function is completed, it will be merged back into the develop branch. Functions should not directly interact with the main branch.

Please note that the combination of feature branch and develop branch is a feature branch workflow for all intents and purposes. However, the Gitflow workflow does not stop there.

The feature branch is usually created based on the latest development branch.

Creating a feature branch

git checkout develop
git checkout -b feature_branch

Finishing a feature branch

When you have completed the development of this feature, the next step is to merge feature_branch into develop.

git checkout develop
git merge feature_branch

Release Branches

Once develop has gained enough release features (or the scheduled release date is coming soon), you can branch out a release branch from develop. Creating this branch will start the next release cycle, so no new features can be added after that-only bug fixes, documentation generation, and other release-oriented tasks should be performed in this branch.

Once ready to release, the release branch will be merged into the main branch and marked with a version number. In addition, it should be merged back into the develop branch, which may have made progress since the start of the release.

Using a dedicated branch to prepare for release allows one team to improve the current version while another team continues to develop features for the next version. It also creates a clearly defined development phase (for example, it is easy to say "this week we are preparing for version 4.0" and actually see it in the structure of the repository).

Making a release branch is another simple branch operation. Like feature branches, release branches are based on develop branches. You can use the following methods to create a new release branch.

git checkout develop
git checkout -b release/0.1.0

Once the release is ready to be released, it will be merged into main and develop, and then the Release branch will be deleted. Merging back to develop is important because critical updates may have been added to the Release branch and new features are needed to access them. If your organization emphasizes code reviews, this will be the ideal place for pull requests.

To complete the release branch, use the following method:

git checkout main
git merge release/0.1.0

Hotfix Branches

The Maintenance or "hotfix" branch is used to quickly patch the production version. Hotfix branches are very similar to release branches and feature branches, except that they are based on main instead of develop. This is the only branch that should be branched directly from main. After the repair is complete, it should be merged into main and develop (or the current release branch), and main should be marked with the updated version number.

With a dedicated bug fix development line, your team can solve problems without interrupting the rest of the workflow or waiting for the next release cycle. You can think of the Maintenance branch as a temporary release branch that works directly with main. You can use the following methods to create a patch branch:

git checkout main
git checkout -b hotfix_branch

Similar to completing the release branch, the patch branch is merged into the main branch and the development branch.

git checkout main
git merge hotfix_branch
git checkout develop
git merge hotfix_branch
git branch -D hotfix_branch

Summarize

• The develop branch is created from the main branch
• Create a Release branch from develop
• The feature branch is created from develop
• When a feature is completed, it will be merged into the develop branch
• After the release branch is completed, it will be merged into develop and main
• If a problem is detected in main, create a hotfix program branch from main
• After the patch is completed, it will be merged into develop and main branches

More original articles by Jerry, all in: "Wang Zixi":