Photo by Vlad Tchompalov on Unsplash
大部分与软件工程或程序开发有关的人都应该熟悉 Git 等版本控制系统。
通常，你会阶段性的作出改变、编写一段 commit message，然后将改变推送到仓库中。以下是一个例子：
git add . git commit -m "[#2313213] 修正了 tooltip 中的 XSS 安全性" git push # 向仓库中推送了 2 个改变过的文件
但是，你可能见到过包含了很多已改变文件的 commit，因为其包含了各种各样的主题：
git commit -m "[#3313212] 修正了 tooltip 中的 XSS 安全性 + 改善了 dropdown 的可访问性 + 为 user-dropdown.component 增加了单元测试 + 更新依赖项" # 向仓库中推送了 20 个改变过的文件
也有那种语焉不详的 commit：
git commit -m "改了点东西" # 向仓库中推送了 15 个改变过的文件
在使用了 Scrum 的敏捷环境或其它相关的敏捷方法论中，期望能快速而定期地交付用户价值。
受合作者的影响，我也尝试着采用其 小步提交并持续改善 的习惯。作为同时对其背后的商业和技术感兴趣的一员，这种方式引起了我的共鸣。
持续集成帮助我们及早发现问题
在本文中，我主要将概述为什么我喜欢这种方式。我们将看看在软件项目中小步提交的优势。
小步提交并持续改善的优势
- 尽早地从工具（如一台 CI 服务器上的单元测试）和其它人（开发者、测试人员、产品经理）那里得到反馈，既有利于持续改善，又能避免未来大的改动
- 当对一个 pull request 进行代码审查时，小的提交易于理解
- 有助于写出更好的 commit message。由于比起大的提交，小步提交更聚焦、范围更窄，所以通常更容易总结其目的
- 改善你的工作绩效（别当真）
也并非总要小步提交：
- 把代码改动过多地分散到小的 commit 中实际上也难以审查。如果分别在 12 个文件中重命名了一个变量，你可不能创建 12 次单独的 commit。这些改变是一回事，应该统一 commit。
- 如果小的 commit 过多，虽然其本身易于理解，但很可能就会因为数量太多而累积成为一个大的 pull request，这样还是难以审查。因此，应该避免造成会拖延过久的分支，这与持续改善的想法背道而驰
总结
如你所见，在软件项目中 commit 尽可能小有很多好处，也会有些问题。我认为，把握住最重要的方面，也就是尽快取得反馈且易于审查就够了。
