如何写好Git commit的信息

最新推荐文章于 2024-09-30 20:16:52 发布

Esther佳佳

最新推荐文章于 2024-09-30 20:16:52 发布

阅读量923

点赞数 1

分类专栏： git教程文章标签： git

本文链接：https://blog.csdn.net/Suejia/article/details/72783634

版权

本文介绍了编写Git commit信息的规范和实践，强调每个commit应专注一件事，遵循50字符标题、72字符正文换行等规则，并提供示例，以提高代码历史的可读性和追溯性。

摘要由CSDN通过智能技术生成

Git commit是代码提交时必经之路，commit虽然没有具体的规范，但也不能太过于随意，不然当你回头浏览git仓库的日志时，也可能会一脸懵逼（小编就曾经被点名，都怪小编当年过于放荡不羁￣□￣｜｜）

下面小编总结了一些Tips：

1、one thing one commit

在提交commit的时候尽量保证这个commit只做一件事情，比如实现某个功能或者修改了配置文件。

这样会有几个好处：

易读：阅读整个项目代码的时候有时候整个项目通读并不是一个好的方法。我们可以通过 issue 或者 commit 来一点一点分解整个 repo。如果一个 commit 只聚焦在一个点上，那么代码看起来也会比较舒服，顺着 commit 读下来就是当初的开发过程了。
cherry-pick：cherry-pick 是 git 中的一个非常有用的命令，可以将 commit 从一个分支“拷贝”到另一个分支。如果我的 commit 划分都很清楚，那么 cherry-pick 就会比较轻松。但是如果我的一个 commit 即实现了功能A，又实现了功能B，而我只想要功能A，这就很尴尬了。
code review : review 过别人代码的人都知道如果 commit 乱七八糟那将有多么痛苦。如果commit msg写得清晰就可以方便代码的阅读。

2、规范

# 50-character subject line
#
# 72-character wrapped longer description. This should answer:
#
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
#
# Include a link to the ticket, if any.

文章《5 Useful Tips For A Better Commit Message》中是这样规定：

第一行不超过50个字符；

第二行空一行

第三行开始是描述信息，每行长度不超过 72 个字符，超过了自己换行；

描述信息主要说明：

（1）这个改动为什么是必要的？

（2）这个改动解决了什么问题？

（3）会影响到哪些其他的代码？

最后最好有一个相应的ticket的链接

当Commit主题不超过50个字符，然后空一行，这样显示的下面的部分都会折叠起来，类似下面的样子。我们使用命令 git log --oneline的时候就只显示第一行。正文部分不超过 72 个字符，也主要是为了阅读方便。关于最后的一个 ticket 的说明。我们开发之前需要将所有的功能进行拆解，然后开发过程中需要通过一些工具来 track ，每个小功能就是一个 ticket。有些公司使用 jira，有些公司使用 wiki。以使用 jira 为例，前面把功能拆解之后分到每个人手上。这样我们进行提交的时候附上对于的 ticket 链接或者 ticket 号，之后再回溯的时候就会非常方便了。或者也可以给 jira 开发插件，通过抓取 git commit 信息进行分析就能将相应的改动代码直接展示在 jira 上了。这么做的好处不言而喻，需求-功能-开发-代码，整个都被串起来了，不管是对于新人了解系统还是5年或者10年之后回溯都是非常有帮助的。