当前位置:网站首页>Git specification

Git specification

2020-11-10 12:04:49 AlexZ33.

Code submission habits

Code ( Or something else ) It is forbidden to stay in the local area for a long time , It is recommended to ( Or shorter ) Save to server , To prevent the loss caused by computer failure . In addition, in order to communicate with the team in time ,
It is recommended to submit as soon as possible merge request( Incomplete can be marked as WIP state ), The general requirement is no more than 1 Zhou ( The shorter the time, the better ).

Basic development process

  1. fork Project to your own name , At the same time, configure this fork Project CI( Be careful , It needs to be configured correctly gitlab runner, You may need to runner Authorized by the owner )
  2. Add two locally remote: source item (origin) And my own name fork(${your-remote-name})

    git remote add ${your-remote-name} git@xyz.com:your-name/project-name.git
  3. Create a local development branch ( Every Commit Just do one thing )

    git checkout -b name_of_the_feature_branch
  4. Make code changes , Ensure that necessary inspections and tests are passed locally
  5. Complete the modification ,commit To local (commit message To meet the specifications , Refer to the corresponding content )
  6. git push commit To your own fork, And initiate merge request

    git push ${your-remote-name} name_of_the_feature_branch
  7. Fill in merge request Information , And focus on the corresponding CI Running results
  8. advance reviewer Conduct code review And according to review Comments modify code
  9. If passed review There are many commits, Recommended by git rebase -i Conduct squash Submit after , Guarantee commit log It's simple, clear and up to standard
  10. In the end by the reviewer Merge code

Other matters needing attention

  1. Merger conflict , In general, you should use rebase Instead of merge
  2. gitlab The project is recommended to be set to Fast-forward merge
  3. gitlab The project is recommended to be set to Pipelines must succeed and All discussions must be resolved
  4. One merge request, If someone else review too , Unless it's permanently closed , Otherwise, you should not shut down and send new ones merge request, This will lose review

Commit message standard

effect

A standardized commit message, It has the following functions :

  1. So that other collaborators can clearly and accurately infer this commit The content of
  2. It can easily and even automatically generate beautiful Release Notes or CHANGELOG

Rules and regulations

  1. In English ( Except for business related projects )
  2. Start with a capital letter ( Except in special cases ), A concise but specific description

Case in point :

  • Support LeakyReLU conversion from TensorFlow
  • Add Gather and Scatter ops for DenseTensor

A bad example :

  • Fixing broken links
  • Some fix
  • Fix compatibility bug
  1. Add category tag prefix ( Optional , Depending on the project , For example, projects need to be formal Release management ), Format reference git-chglog or AngularJS Git Commit Message Conventions
type explain
feat Function development
fix bug fix
perf performance optimization
docs Add the document
style Code style changes
refactor Refactoring with constant functionality
test Supplementary tests
chore Maintenance work

for example :

  • feat: Add Gather and Scatter ops for DenseTensor

Version number specification

Project version number naming rules follow Semantic version SemVer standard :

Version format : The major version number . Sub version number . Revision number , The rules for increasing version number are as follows :

 The major version number : When you do incompatible  API  modify ,
 Sub version number : When you do a downward compatible feature add ,
 Revision number : When you do downward compatible bugfix

Branch 、tag management

type Naming rules Created from explain
master Branch master - Main development branch
feature Branch feature Function point name master For complex long period independence feature Development of , Not good for Agile Development , Generally not used
release Branch r+ First two digits of version number ( Such as r1.0) master Used to guarantee release quality , Update code code review
release tag v+ Version number ( Such as v2.0.3) release Branch issue tag edition
release hotfix It only exists locally release tag release bug Repair , After repairing, type a new one tag,PATCH Number +1( Such as v2.0.3 -> v2.0.4)

Reference material : A successful Git branching model

版权声明
本文为[AlexZ33.]所创,转载请带上原文链接,感谢

随机推荐