Git workflow specification reference



It was thought that the workflow specification using git was very popular, but it was not. Looking for some data, combined with the actual work situation, try to sort out a standard.

  • Origin
  • My GitHub


Git workflow is a suggestion on how to use git to accomplish work in a consistent and efficient way. When working with teams on git managed projects, it is important to ensure that the team agrees on how to apply the workflow. As you look at what follows, keep in mind that these workflows are guidelines, not specific rules. It can be adjusted according to the actual situation.

What is a successful git workflow

When evaluating a team’s workflow, it is important to consider the team’s culture. You want the workflow to improve the team’s efficiency, not become a burden on productivity. Things to consider when evaluating:

  • Does this workflow scale with team size?
  • Can errors and errors be easily undone by this workflow?
  • Does this workflow introduce any new and unnecessary cognitive overhead to the team?

Let’s compare common git workflows.

Git workflow

See git branching model for details.


  • It has been proposed for a long time that many people know something about this process.
  • The branch function is clear and independent of each other, which reduces the accidental release to the online situation.
  • There is always a branch that can be posted online immediately.


  • The cost of acceptance is relatively high.
  • When the scale of project development is expanded and complex, there may be overlapping situations of development, to be released, hot repair, and release at the same time, which may restrain each other and be easily confused.
  • There are too many branches, and the whole construction cycle is relatively long.

GitHub workflow

See GitHub flow for details.


  • There are mainlyfeatureBranching andmasterIt’s easier to publish online.
  • Fix the problem directly in thefeatureThis method can reduce the cost of merge submission.
  • There is always a branch that can be posted online immediately.


  • stayfeaturemerge tomasterBefore,featureBranches need to be published to an online environment for validation, which means that there may be multiple online environments at the same time, which may require additional overhead.
  • When many functions are developed, they are merged intomasterThe possibility of conflict is higher.

Gitlab workflow

See gitlab flow for details.


  • It is relatively flexible and can be released online immediately, and the steps before release can be increased or reduced.
  • Focus on useissueThe way of tracking reduces the work of project management, so that every developer can consciously manage himself.
  • The description in the document is relatively comprehensive.
  • There is always a branch that can be posted online immediately.


  • Due to the relative flexibility, without some uniform and rigid regulations, the management of branches and environments will be relatively complex.
  • It emphasizes the combination with gitlab platform. If other platforms are changed, some conversion costs may be required.
  • We hope to adapt to more situations, and give examples of various situations. Too many choices lead to the need to consider again, but there will be no general sense of compliance with the specification.

Specification reference

According to the above several kinds of workflow, as well as the situation encountered in the actual work, there are some ideas for the specification.

Let’s start with the environment function as a starting point.

Environmental Division

Generally, there are development environment, test environment and production environment. The characteristics of each environment are described below.

development environment

It is mainly used for development, such as interface debugging. The code changes most frequently in this environment. It may take the following forms:

  • The computer used by developers themselves is a development environment.
  • There is a separate server deployment, and generally there is a corresponding continuous build.

testing environment

It is mainly used for testing. The code in this environment is relatively stable, and there is usually a separate server deployment. Testing and development will occur in parallel, so code that does not run normally is not allowed to enter this environment, so as not to affect the test. The types of tests may be:

  • Manual test after new function development.
  • Provide a third party for docking or acceptance.

production environment

For online external access, this is the real user environment. Only specific people will have access to the code.

Branching strategy

On the whole, it is similar to the branching strategy in Git workflow. The principle is that each branch corresponds to a specific environment.


  • The branch exists from the beginning of the project and always exists, corresponding todevelopment environment
  • Each new function is created based on this branchfeatureBranch, name, uniform prefixfeature/。 After the development is completed, it will be released after confirmationfeatureTo merge to this branch. Delete after mergefeatureBranch.
  • Whenever a new commit to this branch, scripts can be used to automatically build and deploy to the corresponding environment.
  • You can commit changes directly on this branch.

To be confirmeddevelopOnce the branches are working properly, they can be merged into thereleaseBranch, or create adevelopOfreleaseBranch. Enter the testing phase.


  • It doesn’t always exist, but it can also exist for a long timetesting environment
  • The original Branch source isdevelopBranch.
  • Whenever there is a new commit for this branch, scripts can be used to automatically build and deploy to the corresponding environment.
  • Modification commit directly on this branch is not allowed.

After the relevant tests have passed, start to merge into themasterBranch, merge todevelopBranch, because there may be bug fixes during this period. Then we go to the release phase.


  • The branch exists from the beginning of the project and always exists, corresponding toproduction environment
  • The code of this branch is always in the release ready state. Each time the code is released, a new version number is added according to the project version management rulestag
  • Whenever there is a new commit for this branch, scripts can be used to automatically build and deploy to the corresponding environment.
  • Modification commit directly on this branch is not allowed.

Branch merging

  • mergeMandatory use of instructions--no-ffParameter to generate corresponding merge records for easy backtracking.
  • developandreleaseThe general developers of branches have merge permission,masterOnly specific personnel can have branch merge permission.

Bug fixing strategy

According to the environment corresponding to the above branch, the bugs are distinguished.

Bugs in test environment

  • be based onreleaseBranch create repair branch, name unified prefixbugfix/
  • After fixing the bug, merge thereleaseBranch.
  • The branch continues until the merge tomasterBefore,releasemerge tomasterThen delete the branch.

Bugs in production environment

  • be based onmasterBranch create repair branch, name unified prefixhotfix/
  • After fixing the bug, merge thereleaseThe branch is verified in the test environment. After the verification is passed, the branch is merged into themasteranddevelop
  • Delete the branch after merging.

Handling of other situations

The above is a normal process, but it is not so ideal in practice. The following may happen.

Multi version testing

releaseThe corresponding test environment is a version of the function branch developed in advance due to time problemsfeature/functionIt has been completed and needs to be tested immediately.

At this time, it can be directly based onfeature/functionBranches build a separate test environment. This requires a certain cost in the continuous construction of the system. stayreleaseAfter publishing, merge according to the original process.

Environment synchronization

Generally, the data and configuration of the test environment and the production environment are independent of each other. Sometimes the production problems cannot be reproduced in the test environment

  • Import the data and configuration of the production environment into the test environment.
  • Deploy the code of the test environment to a separate environment, which directly uses the data and configuration of the production environment, but only allows access to relevant personnel.

Grayscale Publishing

There are two sets of environments in the production of grayscale publishing, and different users are in different environments. At this time, you can do this:

  • be based onmasterCreate a pre release branch.
  • releaseMerge to the pre release branch. After graying, merge the pre release branch into themaster
  • The production bugs during grayscale can be combined into the gray level branch for verification. After verification, the repair branches are merged into themasteranddevelop

Another way of thinking

The above principle follows that one branch corresponds to one environment, or one branch corresponds to multiple environments. for exampledevelopAfter the branch is built, it can be deployed to two different servers. Testers can use it in one environment and developers can use it in another environment, which does not affect each other. This needs to be configured in the continuous build tool.

Specification reference simplification

According to the above process, it can be found that once branches are added, the operations of creating and merging are indispensable. Sometimes the team development is just two or three people. At this time, the steps that can be simplified are as follows:

  • No need to createfeatureBranch, directly indevelopOn the development.
  • No need to create a test environment to fix the bug branchreleaseIt was revised on.
  • For the bugs in the production environment, you only need to merge them into themaster。 Merge to in next versionreleaseBefore, unifymastermerge todeveloponce.

Specification reference enhancement

With the expansion of team size, more detailed rules become more necessary. The strengthening steps are as follows:

  • Each requirement is developed with aissueAt the beginning, describe the content and implementation of the development, and give it to the relevant personnel for review. The following progress status is in thisissueIn China.
  • Be sure to go through relevant reviews when merging branches.
  • Add automatic test link.
  • Separate the build and deployment, the test environment deployment authority is given to the test department, and the production environment deployment authority is given to the relevant person in charge.
  • Before submitting to the test and production environment, it is necessary to inform relevant functions, code base, configuration changes, script changes, etc. by email. Deployment can only be carried out after the review and approval. This step can be done with the help of relevant automation tools.

reference material

  • A successful Git branching model
  • GitHub flow
  • GitLab Flow
  • Comparing Workflows