[译] 为何每次 Git Commit 要尽可能小?
2020/2/13 9:20:53
本文主要是介绍[译] 为何每次 Git Commit 要尽可能小?,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
大部分与软件工程或程序开发有关的人都应该熟悉 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 关注公众号
转载请注明出处
这篇关于[译] 为何每次 Git Commit 要尽可能小?的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!
- 2024-09-19uniapp 如何实现点赞后全局更新数据-icode9专业技术文章分享
- 2024-09-19云函数怎么运行wx-server-sdk-icode9专业技术文章分享
- 2024-09-19"dependencies": { "wx-server-sdk": "latest" },是什么意思-icode9专业技术文章分享
- 2024-09-16优化批处理流程:自定义BatchProcessorUtils的设计与应用
- 2024-09-15laravel collect游标批量插入的方法示例-icode9专业技术文章分享
- 2024-09-15怎么修改laravel的中间件 把获取IP改成X-Real-IP-icode9专业技术文章分享
- 2024-09-15laravel默认分页返回样式是什么-icode9专业技术文章分享
- 2024-09-15服务类中 怎么调用模型基类的函数-icode9专业技术文章分享
- 2024-09-15依赖注入比静态方法有什么好处-icode9专业技术文章分享
- 2024-09-15不使用静态方法控制器调用服务类有什么方法-icode9专业技术文章分享