好的提交记录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 描述
系列文章: