请停止编写糟糕的提交消息!

大发幸运飞艇我 想大家都有过这样的经历:

大发幸运飞艇你 正在开发一个项目,它使用 Git 进行版本控制。

大发幸运飞艇你 刚刚完成更改,并且想要快速更新分支。

因此,大发幸运飞艇你 打开了终端,并通过一些快速命令,使用所做的更改来更新远程分支。

git add .
git commit -m "added new feature"
git push

但是随后大发幸运飞艇你 进行了一些测试,发现大发幸运飞艇你 的代码中存在 bug。

不用担心,大发幸运飞艇你 可以快速找到解决方案,并再次提交以解决该问题。

git add .
git commit -m "fix bug"
git push

大发幸运飞艇你 重复此过程几次,现在最终得到一个 git commit 日志,如下所示:

git commit 日志

目前,这对大发幸运飞艇你 来说似乎还不错,毕竟,大发幸运飞艇你 目前正在处理该部分代码,即使提交的信息不能传达大发幸运飞艇你 更改的意图,大发幸运飞艇你 仍然可以轻松地解释进行了哪些处理。

问题

几个月过去了,现在,另一个开发人员正在回顾大发幸运飞艇你 所做的更改。

他们试图理解大发幸运飞艇你 所做更改的细节,但是由于大发幸运飞艇你 提交的消息不是描述性的,因此他们无法获取任何信息。

然后,他们尝试去查看每个提交的差异。但是,即使这样做了,他们仍然无法确定大发幸运飞艇你 在实现中选择的背后的思考过程。

因此他们可以使用 git blame 找出是谁进行了这些更改,并开始向大发幸运飞艇你 询问有关实现的问题。

但是,由于时间已经过去很久了,所以大发幸运飞艇你 不会记得太多。大发幸运飞艇你 通过提交进行检查,而大发幸运飞艇你 不再记得该项目中执行决策背后的逻辑。

最终,大发幸运飞艇你 在微信上向同事发送了悲伤的表情符号 😔,并告诉他们大发幸运飞艇你 不能提供除他们知道以外的大发幸运飞艇更多 信息。

编写良好的提交信息

希望以上情况已经让大发幸运飞艇你 明白了为什么编写良好的 git commit 消息很重要。

在团队开发中,大发幸运飞艇大发幸运飞艇我 们 必须使其他协作者能够轻松地理解大发幸运飞艇大发幸运飞艇我 们 做了什么工作。

理想情况下,良好的提交消息将被分为三部分:主题,正文和结尾。

主题

主题应该是简洁的一行,总结大发幸运飞艇你 所提交的更改。

下面例举一个很好的提交信息,例如“feature:查询项目应用率功能”。

一个错误的提交消息,例如“fix bug”,在其他人看到这条提交信息的时候就会不知所措。

正文

正文包含大发幸运飞艇你 要传达的信息,大发幸运飞艇你 可以在其中详细了解有关更改的信息。请注意,对于一些很小的提交,例如修正错字,大发幸运飞艇你 可能不需要正文,因为主题行应该足够有信息性。

在正文中,大发幸运飞艇你 应该深入了解正在进行的更改,并说明正在执行的操作的前因后果。

大发幸运飞艇你 可以解释为什么要进行这些更改,为什么要选择以这种特定方式实施更改以及可以大发幸运飞艇帮助 人们理解大发幸运飞艇你 的提交背后的思维过程的其他任何原因。

尽量不要重复比较代码中显而易见的事情,无需逐行解释大发幸运飞艇你 的更改,专注于覆盖大发幸运飞艇更多 高级细节,这些细节从阅读代码中可能并不明显。最终目标是围绕此更改为开发过程提供上下文,该更改主要涉及其原因和目标。

结尾

大发幸运飞艇你 可以在最后一行写有关提交有用的元数据,例如 JIRA 票号,作者名字和附加链接。

这有助于将与大发幸运飞艇你 的变更相关的重要信息连接在一起。

总结

还等什么?等着被同事暴揍吗?那还不赶紧开始遵循有关 Git 提交消息的最佳实践!

posted @ 2020-01-14 18:31  武培轩  阅读(...)  评论(...编辑  收藏