Original address: juejin.cn/post/684490…

In collaborative team development, members need to work together to complete the development, testing, and release of features. However, people have different habits, and each person has a different understanding of how to collaborate. Therefore, a collaboration model is needed to regulate how people from different functions and the same functions of the team cooperate.

The workflow level analysis will be carried out based on Git.

Traditional Git flow

A more traditional Git flow is shared by Vincent Driessen as follows:

A successful Git branching model.

In this model, there are two main branches and other functional branches. The main branches include:

  • Master: Holds production-level code.
  • Development: Code that houses newly developed, integrable functions.

Other functional branches include:

  • Feature branches: Branches based on development, used for the development of new features.
  • Release Branches: Branches created based on development, used to Release new features, which have been stable for a period of time before being merged into the Master branch for final Release.
  • Hotfix Branches: Branches based on master used to fix bugs.

Application Scenario Analysis

This model applies to the following scenarios:

  • The functionality of each phase of development is clear: because a release creates a new release branch directly from development, any unfinished (developed or tested) functionality in development will affect the release.
  • High volume and low frequency releases: Since there may be multiple features in development, they need to be tested before they are released. Such as desktop application, mobile application development.

Not applicable scenarios:

  • Small and frequent releases.
  • Multi-environment deployment (e.g., development, test, and production). Development of Restful apis, etc.

Improved Git Flow

Aiming at the problems of traditional Git flow, the improved model is shown as follows:

The model consists of three main branches and other functional branches, including:

  • Development: Development-side testing (as the developers themselves) and integration (such as front-end API integration) for new features.
  • Staging: Test branch, where development-side testing and integration of functional branches can be consolidated and tested by testers.
  • Production: The production branch where the production level code is stored; The functional branch is merged into the branch after it passes testing by the tester in the staging environment.

The initialization of the Development and staging branches is based on the Production branch.

Other functional branches include:

  • Feature branches: Branches based on production, used for the development of new functions; The naming format is feature/feature-name, such as feature/payment.
  • Bugfix branches: Branches created based on production, repair of common bugs of users, merge process with feature branches; The name format is bugfix/bug-name.
  • Hotfix Branches: Used for urgent bug fixes. Hotfix Branches can be merged directly into the Production branch, and then into the Development and staging branches respectively. The name format is Hotfix /bug-name.

All functional branches are local to the developer and cannot be uploaded to a remote repository.

The running process of this model is as follows:

  1. Get a functional requirement such as payment, create a new functional branch feature/payment based on production branch;
  2. Switch to the functional branch feature/ Payment for development;
  3. At the end of local development, the feature/payment branch is merged into the development branch for development-side testing and integration.
  4. If any problem is found in the test and integration of the development side, switch back to the feature/ Payment branch to fix the problem, and perform Step 3 after the repair.
  5. If there are no problems with development-side testing and integration, merge the feature/payment branch into the staging branch and let testers test it.
  6. If the tester finds a problem with this feature in staging, switch back to the feature/ Payment branch and perform Step 3 after the repair.
  7. If the tester at Staging believes that the feature has been tested, merge the feature/ Payment branch into the Production branch.

The rules

To ensure smooth implementation of the model, team members should also follow the following rules:

  1. All functional branches need to be created based on the latest Production branch;
  2. All functional branches exist only in the developer’s local, can not be uploaded to the remote warehouse, remote warehouse only main branch;
  3. The main branches (development, staging, and production) cannot merge with each other.
  4. The main branch can only merge feature branches (such as feature, Bugfix, and Hotfix branches);
  5. Functional branches are eventually merged into all main branches.
  6. Keep a record of each merge (merge command belt--no-ff);

With the above improvements, the model can support multi-environment deployment and guarantee independence of function merging.

Of course, business scenarios vary from team to team, and models need to be adjusted accordingly;

In short, no model is absolutely perfect, and the scenario determines the model that applies.

reference

  • A successful Git branching model.