[译] 为什么每次 Git Commit 要尽量小？

原文：medium.com/better-prog…

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 尽量小有不少好处，也会有些问题。我认为，把握住最重要的方面，也就是尽快取得反馈且易于审查就够了。

--End--

查看更多前端好文
请搜索 fewelife 关注公众号

转载请注明出处