C/C++教程

[译] 为何每次 Git Commit 要尽可能小?

本文主要是介绍[译] 为何每次 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 的敏捷环境或其它相关的敏捷方法论中,期望能快速而定期地交付用户价值。

受合作者的影响,我也尝试着采用其 小步提交并持续改善 的习惯。作为同时对其背后的商业和技术感兴趣的一员,这种方式引起了我的共鸣。

GitHub checks passed
持续集成帮助我们及早发现问题

在本文中,我主要将概述为什么我喜欢这种方式。我们将看看在软件项目中小步提交的优势。

小步提交并持续改善的优势

  • 尽早地从工具(如一台 CI 服务器上的单元测试)和其它人(开发者、测试人员、产品经理)那里得到反馈,既有利于持续改善,又能避免未来大的改动
  • 当对一个 pull request 进行代码审查时,小的提交易于理解
  • 有助于写出更好的 commit message。由于比起大的提交,小步提交更聚焦、范围更窄,所以通常更容易总结其目的
  • 改善你的工作绩效(别当真)

也并非总要小步提交:

  • 把代码改动过多地分散到小的 commit 中实际上也难以审查。如果分别在 12 个文件中重命名了一个变量,你可不能创建 12 次单独的 commit。这些改变是一回事,应该统一 commit。
  • 如果小的 commit 过多,虽然其本身易于理解,但很可能就会因为数量太多而累积成为一个大的 pull request,这样还是难以审查。因此,应该避免造成会拖延过久的分支,这与持续改善的想法背道而驰

总结

如你所见,在软件项目中 commit 尽可能小有很多好处,也会有些问题。我认为,把握住最重要的方面,也就是尽快取得反馈且易于审查就够了。



--End--

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

转载请注明出处

这篇关于[译] 为何每次 Git Commit 要尽可能小?的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!