GIT code warehouse management specifications

Why do we need code management standards?

Let me tell you a little story. You have played Honor of Kings or League of Legends. We want to gank (one or several game characters in the game act to sneak attack, outflank, and kill the opponent's game characters) the opposing mid laner, so the agreed strategy is

  1. Our mid laner is responsible for seducing and dragging the opponent's mid laner
  2. Our jungler is lying in ambush in the grass, waiting for help to come
  3. Support players rush over from the bottom lane to support

If the players follow the strategy, they will kill the enemy in a good wave. However, because the jungler cannot calm down, during the ambush process, he went to the opponent's jungle area and reversed the wave of wild monsters where they were seen. The opponent's players came and counterattacked. The other players on our side did not know this and decided to start a fight. As you can imagine, they were killed by the local counterattack.
Code management is also a multi-person collaboration to achieve mutual benefit and symbiosis, which requires an agreed strategy to ensure that the project can proceed smoothly.

1. Commit specifications

Standardized commit logs allow people to scan key information at a glance. Bad logs make people confused and confused, especially when code rollback is required. There once was a team member who kept submitting in the following way. Later, her code needed to be rolled back. In this log situation, the correct node was not found after rolling back three or four times. After trying to persuade her many times to no avail, this colleague has now been contacted by the company about her employment contract.

Commit message submission specifications, including type (required) + subject (required), provide more historical information for quick browsing. Can filter certain information (such as building installation packages);

#1 type

#主要type

feat:新功能
fix: 修补bug

#特殊type
docs:文档(document)
style:格式(不影响代码运行的变动)
refactor:重构(既不是新功能,也不是修改bug的代码变动)
test:增加测试
build:构造工具的或者外部依赖的改动,例如webpack,npm
chore: 不修改src或者test的其余修改,例如构建过程或辅助工具的变动

#2 subject

subject是 commit 目的的简短描述,不超过50个字符。

Examples are as follows:

  1. new features

  2. Benefits of fixing bugs :
    • Good readability and clarity. You can understand the role of the current commit without looking deeply into the code.
    • Prepare for Code Reviewing
    • Facilitate tracking of project history
    • Make it clear to other developers when running git blame
    • Improve the overall quality of the project and improve personal engineering quality

2. Branch management specifications

Branch management specifications.

  1. The development branch of the current task is the develop branch, and develop is used as the development branch and the test branch. If there is new online, you need to manually merge the master branch code into the develop branch.
  2. The develop branch test is passed. Switch from develop to the current version branch such as v2.0 (v2.0 is used as an example below), and use v2.0 as the pre-release branch and the online branch.
  3. After v2.0 passes the pre-release environment test, it can be directly launched as an online branch.
  4. After the v2.0 branch is successfully launched, it needs to be merged into the master branch.
  5. Online bug modification, fix the online bug of v2.0, you can cut the new branch v2.1, accumulate in sequence, etc.

The git branch management flow chart is as follows:
Insert image description here

3. Summary

Good Git management methods can greatly improve team work efficiency and avoid confusion in submissions.

Reference: https://www.processon.com/diagrams/new#template

If you have any questions, please contact me~

Welcome to join QQ group:
Insert image description here

Guess you like

Origin blog.csdn.net/qq_37617413/article/details/109471092