代码版本管理和提交规范（二）代码提交_软件开发过程中代码提交规范

好的提交记录VS不好的提交记录

好的代码提交，应该具有原子性、清晰可读等特点，有助于提升代码可读性、问题排查和代码审核效率。而不好的提交记录对代码维护几乎起不了任何作用。可以从提高代码提交原子性、提高代码提交说明质量、提升Git使用技能三方面提升代码提交质量。

提高代码提交原子性

代码提交的原子性，是指一个提交包含一个不可分割的特性、修复或者优化，同时这个提交要尽可能小。原子性提交的优点是，结构清晰，容易定位问题。一般来说，代码提交的原子性做得越好，代码质量越好。同时，原子性提交因为小而聚焦，也是做好代码审查的基础。尽快发起代码评审，一个commit只做一件事。在Facebook，代码提交的原子性是代码审查非常重要的指标，如果提交的原子性不好，常常会被直接打回。审查中首先看原子性。如果一个提交做了几件事，不看细节直接打回。

提高代码提交说明质量

提交说明是提高代码审查的利器，好的格式应该包含以下几个方面：

标题，简明扼要地描述这个提交。这部分最好在 50 个字符之内，以确保在单行显示的时候能够显示完整。比如，在命令行常用的 git log --oneline 输出结果要能显示完全。

详细描述，包括提交的目的、选择这个方法的原因，以及实现细节的总结性描述。这三个方面的内容最能帮助审查者阅读代码。

测试情况，描述的是你对这个提交做了什么样的测试验证，具体包括正常情况的输出、错误情况的输出，以及性能、安全等方面的专项测试结果。这部分内容，可以增加审查者对提交代码的了解程度以及信心。

与其他工具和系统相关的信息，这些信息对代码审查和后续阅读代码提供基础信息，非常重要。

Task、Feature、Bug的Overmind ID和链接设计文档链接其中第1和第4点必须填写，2和4点按照具体需求选填，代码审查阶段进行质量把关。

可以在Git内设置统一的提交模版

> git commit 
# feat - A new feature
# fix - A bug fix
# docs - Documentation only changes
# style - Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
# refactor - A code change that neither fixes a bug nor adds a feature
# perf - A code change that improves performance
# test - Adding missing tests or correcting existing tests
# build - Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
# ci - Changes to our Cl configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)chore - Other changes that don't modify src or test files
# revert - Reverts a previous commit
 
feat:
 
Summary:
    
Test:
 
Overmind Link:

参考文档：谷歌工程实践-小change list 谷歌工程实践-编写良好的change list 描述

系列文章：

代码版本管理和提交规范（一）分支管理

代码版本管理和提交规范（二）代码提交

代码版本管理和提交规范（三）代码审查

 代码版本管理和提交规范（四）实践方案