GitFlow Process combing

Introduce a,

As a source code management system, Git inevitably involves the cooperation of many people.
Collaboration must have a standard work flow, let everyone effectively cooperate, make the project in good order to develop;
This article introduces one of the most widely used workflows, Git Flow;
‘flow’ means water flow, which means that the project flows smoothly and naturally forward like water flow, without impact, collision or even vortex.

Second, current issues

The process is too complex, with too many merge operations, and is not developer friendly;
The link of the submitted code is too long, it is too troublesome, the development students are not clear in which branch to modify the code, which branch to merge, feel very messy;
The more manual operations, the higher the error rate, are potential risks;
The new person does not know the team code submission specification, so it is necessary to output documentation;

Three, goals,

Improve r&d efficiency and code quality
Reduce production accidents
Successful Git branching model

Iv. Application

Fixed iteration cycles, say 2 to 3 weeks per release
Develop at a release pace, with a product release at the end of each iteration. Do not release the product during the iteration unless it is an emergency (hotfix)

Five, the characteristics of

1. There are two long-term branches of the project

Develop /dev develop/devCopy the code

The former holds releases. Any time you get a release in the branch, it’s a stable release. The latter is used for daily development and holds the latest development releases.

2. There are three short-term branches of the project

Pre-release branch (Release /test) FixBugCopy the code

Once development is complete, they are merged into Develop or master and then removed

Six, commonly used branches

Production branch (Master /prod) The master branch is the main branch of the repository and provides the official version for users to use. This branch contains the most recent Release of code to the production environment and the most recent Release(test). This branch can only be merged from other branches and cannot be modified directly in this branch
Develop branch (develop/dev)
- This branch is our main development branch and contains all the code to be released to the next Release(test). This branch is mainly merged from other branches such as Feature, Release(test), and Fixbug
- Git create Develop branch
```
git checkout -b develop master
Copy the code
```
Feature branch
- The feature branch is used to create a new feature. The feature branch is separated from the Develop branch and is incorporated into the Develop branch.
- The name of a function branch can be named with feature-*, for example (feature-v2.1.0)
- Create a function branch:
```
Git checkout -b feature-v2.1.0 developCopy the code
```
- Merge the functional branch into the Develop branch when development is complete:
```
Git checkout develop Git merge --no-ff feature-v2.1.0Copy the code
```
- Delete feature branch:
```
Git branch - d feature - v2.1.0Copy the code
```
- What does the –no-ff parameter mean
  - With the –no-ff parameter, the normal merge is performed and a new node is generated on the Develop branch.
  - By default, Git performs a “fast-farward merge” that points the Develop branch directly to the Feature branch.
Pre-release branch (Release /test)
- The pre-release branch is separated from the Develop branch and must be merged into the Develop and Master branches after the tests verify that it is OK.
- Create a pre-release branch
```
    git checkout -b test develop
Copy the code
```
- Once the test is validated, merge into the master branch
```
    git checkout master
    git merge --no-ff test
Copy the code
```
- Merge into the Develop branch
```
    git checkout develop
    git merge --no-ff test
Copy the code
```
- Finally, once online is ok, delete the pre-release branch
```
    git branch -d test
Copy the code
```
Fix bug branches online
- After the official release of the program, it is inevitable that there will be bugs, online accidents need to cause enough attention, then you need to create a branch, emergency repair
- The fixbug branch is separated from the master branch. When the fix is finished, the master and develop branches are merged and named fixbug-* (fixbug-20210724).
- Create a bug fix branch
```
    git checkout -b fixbug-20210724 master
Copy the code
```
- When the fix is complete, merge into the master branch
```
    git checkout master
    git merge --no-ff fixbug-20210724
Copy the code
```
- Then merge it into the Develop branch
```
    git checkout develop
    git merge --no-ff fixbug-20210724
Copy the code
```
- Finally, remove the fix bug branch
```
    git branch -d fixbug-20210724
Copy the code
```

7. Role

Good management practices can appropriately reduce production accidents and improve R&D efficiency. Personnel in the R&D department can be roughly divided into:

The development team leader
To develop students
Testing students
Ops students
- Develop the operations that students need to do
  1. When the requirements are started, switch to the corresponding feature branch development requirements, complete the coding, before and after the end of the joint debugging, the local agent background DEV environment interface joint debugging, after passing the self-test, submit the code;
  2. If you want to experience the effects of the development environment, submit the merge request and merge the code into Develop in advance. Otherwise, wait until all other code is merged into the Feature branch and the team leader merge the code into the Develop branch.
  3. Fix bugs, directly fix bugs in the test branch, submit code, you can not build, let the test students build themselves, or focus on a unified build at a certain point in time, avoid frequent build;
Summary: Develop new requirements in the feature branch before testing, and fix bugs in the test branch after testing.
- What the development lead needs to do
  1. Code, create new functional branches, handle merge request, code Review;
  2. Merge the feature branch into Develop and create the test branch.
  3. After the test validation is ok, gray level verification is carried out;
  4. After the gray level is ok, the official release will be launched, and the test will be merged into the Develop and master branch and tagged
  5. If there are many online problems after the release, such as dozens of bugs, the test branch will not be deleted temporarily, continue to change the bugs in the test branch, and continue to verify;
  6. Delete the test branch when the line is stable.
  7. If there is a problem online, create a FixBug branch, arrange for someone to fix it, and then merge the branch into the Develop and Master branches.
- When the commit code conflicts
  1. It is best to know the cause of conflict and resolve it yourself.
  2. When not sure, do not arbitrarily cover, find and conflict code development, collaborative solution;
  3. With the conflict of people do not know how to solve, ask the team leader to help deal with;
  4. Above still cannot solve, throw out the problem, everybody solves together;

Viii. Code submission specifications

Each Commit, the Commit Message format contains three fields: Type (required), Scope (optional), and Subject (required)

<type>(<scope>): <subject> // Example: fix(comfirmOrder): Fix virtual order input errorCopy the code

1. Type Type indicates the category of COMMIT. Only the following seven identifiers are allowed.

New feature (feat)
Fix: Fix a bug
Docs: Documentation
Style: format
Refactor: refactoring (that is, code changes that are not new functionality or bugs)
Test: Adds tests
Chore: Changes to the build process or ancillary tools

Scope is used to describe the scope of the commit impact, such as the data layer, control layer, view layer, and so on, which varies from project to project.

3. Subject A subject is a short description of the purpose of the commit. The subject contains no more than 50 characters.

Use git Stash

Application scenarios

This is used when you are working on a requirement in the Feature branch and you have a bug in your project that you need to fix urgently, but the development is only half finished and you don’t want to commitgit stashSave the changes to the stack, then switch to the FixBug branch to fix the bug, and then switch back to the Feature branchgit stash popRecovers from the stack what has just been saved
Due to negligence, the content that should have been developed in the feature branch has been developed on the master, so it needs to be switched back to the feature branch for development, which can be usedgit stashSave the content to the stack, and restore the content again after you cut back to the feature branch

Details of common commands

1. Git stash // Can save all uncommitted changes (workspace and staging area) to the stack for later recovery of the current working directory. 2. Git stash save // works the same as git stash, except you can add some comments like: 4. Git stash pop // Pops up the current stash contents and applies them to the working directory corresponding to the current branch. 5. Git Stash Clear // Clears all the contents of the stackCopy the code

10 and other

A branch of development that is built by the developers themselves during the alignment process
In the test branch, the development only needs to fix bugs, submit code, and let the test students deploy themselves to avoid frequent interruptions in the test process. All the deployments are one-click Jenkins deployment (unless the test actively asks the development to help it deploy).
Similarly, the small program branch specification is developed in the Feture branch before testing, and bugs are fixed in the Test branch after testing. The test branch is used to release the small program test version
To be continued…

Xi. Summary

This paper sorted out a timeline of the research and development stage, which mainly consisted of three key time nodes, namely, the launch of development, the launch of testing, and the launch of the line. It simply introduced what the development students needed to do in each stage.

Remark:

If there are any mistakes, please point them out
This article is a good introduction, have good ideas, welcome to share

The resources

Git branch management strategy – nguyen one: www.ruanyifeng.com/blog/2012/0…
A successful Git Isomodel: nvie.com/posts/a-suc…
Commit message – nguyen one: www.ruanyifeng.com/blog/2016/0…