Git 提交消息模板 如何编写有用的提交消息(我的提交消息模板)

2025-05-25

Git 提交消息模板如何编写有用的提交消息(我的提交消息模板)

我们都曾在某个时候经历过有关 git 提交消息的 XKCD。

XKCD - 随着项目的拖延,我的 git 提交信息变得越来越缺乏信息量

我也不例外。我的博客提交信息如下:

fixxxx stuff
post
post
post
post
posts
mmm
posts
front maddy
Add chris oliver
add syntax
article
add git patch article
fix video
video
arty art art
Fix links
oops
Enter fullscreen mode Exit fullscreen mode

因为我博客的 git 历史记录只有我自己能看到,所以没关系。我已经接受了我永远无法在我的博客中充分利用 git 的事实,我完全接受这一点。

不幸的是,有些人对待多贡献者的真实项目就像我对待我的博客一样。我发现这种做法是出于无知,而不是懒惰。因此,我将分享一些关于如何在实际项目中使用提交消息的技巧。

你为什么要关心?

😤我不在乎,直接跳到模板! 🚀

Git 是一个强大的工具,即使您仅使用它来保存代码更改的历史记录,而不利用其最强大的功能。

然而,你会发现,你越深入研究,git 就越强大。你还会发现,git 的许多实用功能都是建立在提交信息有用的前提上的。

回想一下你上次使用 的时候git blame。如果你发现一条提交信息是 ,这会有帮助吗fixed a bad bug?可能不会,你可能只是想找到更多关于你正在处理的代码的上下文;你需要一个关于它是什么以及为什么的解释。

Git 提交消息必须包含每个更改背后的原因和内容,以便未来勇敢的 Git 探索者能够深入了解提交作者的内心世界。如果提交消息不包含这些信息,那还有什么意义呢?提交消息只有在帮助未来某个时间点理解更改内容的人时才有意义。

为了创建一个好的提交消息的模板,我将把提交消息分成几个部分。

首先,主题行

在提交信息中,第一行(有时称为主题行)应该与正文分开。理想情况下,这一行应该概括提交中所做的更改。

当我写主题行时,我会尝试完成这个句子,“这个提交将......”

例如,我可能会写一个类似这样的主题行Remove unused, commented code。这将完美地完成我的句子:“此提交将删除未使用的、已注释的代码。”

在设置主题行的格式时,需要记住一两个规则。

首先,主题行的首字母应该大写;这只是一个常见的惯例。根据我的经验,这也使得一行行的提交列表更容易阅读。

其次,你的提交信息不应超过 50 个字符。这是因为像 GitHub 这样的工具会在 50 个字符处截断一行。因此,为了让其他人能够有效地浏览和理解你的主题行,你应该尽量在 50 个字符内概括整个更改。

我的提交消息模板的第一行如下所示:
Summarize the change in less than 50 characters

接下来是第一个正文“段落”

在某些提交中,主题行足以传达整个想法。例如,如果你的提交是Add a comma to the README,你可能不需要解释。

然而,在大多数提交中,您的更改可能需要一些额外的上下文信息。我们不希望未来的开发者在尝试理解更改背后的原因时缺少上下文信息。

这时,邮件正文就派上用场了。我把正文分成“段落”,这些段落其实就是一些定义模糊的文本串,中间用空格隔开。段落可以是项目符号、句子或其他形式;重要的是,它们从一开始就易于阅读和理解。

过去,我通常会在提交信息正文的第一段解释我做了什么。现在,我已经不再使用“what”了,而是开始记录“why”

Ben Orenstein 最近改变了我对提交消息格式的看法

因此,在这种情况下,我们要先解释清楚我们为什么要做出改变。

以下是一个例子:

Refactor the coupon UI

Because:
- The old UI code is fairly slow
- There were a few unused dependencies
- The old UI has aged poorly
Enter fullscreen mode Exit fullscreen mode

这些“段落”的妙处在于,它只有一条格式规则:在 72 个字符处换行。这与其说是实质性的,不如说是传统做法。然而,主要原因是这给 Git 留出了一定的缩进空间(假设最大字符数限制为 80)。我建议遵循这条规则,尽管它并非总是必要的。

这是迄今为止的提交消息模板:

Summarize the change in less than 50 characters

Because:
- Explain the reasons you made this change
- Make a new bullet for each reason
- Each line should be under 72 characters
Enter fullscreen mode Exit fullscreen mode

现在第二个主体“段落”

现在我们已经总结了这一变化并分享了我们做出这一变化的原因,用更长的形式准确解释我们所做的事情可能是明智的。

我使用第二个“段落”来更详细地解释我在更改中所做的工作,例如:

Refactor the coupon UI

Because:
- The old UI code is fairly slow
- There were a few unused dependencies
- The old UI has aged poorly

I thought it was necessary to remove some of the old coupon UI code.
Unfortunately, it has aged pretty poorly, and I think this refactor makes
the code much easier to support in the long-run. Primarily, this commit
improves the performance of the coupon component. It also removes some
unused dependencies.
Enter fullscreen mode Exit fullscreen mode

提交主体的这一部分应该比 50 个字符的摘要更深入地解释所做的工作。格式由您决定(只要您在 72 个字符处换行即可)。

这是更新后的模板:

Summarize the change in less than 50 characters

Because:
- Explain the reasons you made this change
- Make a new bullet for each reason
- Each line should be under 72 characters

Explain exactly what was done in this commit with more depth than the
50 character subject line. Remember to wrap at 72 characters!
Enter fullscreen mode Exit fullscreen mode

其他部分:附加说明和合著者

至此,我们已经能够编写有效且连贯的提交信息了。然而,有时提交信息需要一些额外的注释。这可以在最后一节中完成。

例如:

Refactor the coupon UI

Because:
- The old UI code is fairly slow
- There were a few unused dependencies
- The old UI has aged poorly

I thought it was necessary to remove some of the old coupon UI code.
Unfortunately, it has aged pretty poorly, and I think this refactor makes
the code much easier to support in the long-run. Primarily, this commit
improves the performance of the coupon component. It also removes some
unused dependencies.

These changes should resolve issue #1337.

This commit removed the left-pad dependency, so please stop using it!

Co-authored-by: nspinazz89 <nick@example.com>
Enter fullscreen mode Exit fullscreen mode

在这个例子中,我能够:

  • 参考相关问题
  • 添加一行警告我删除了一个依赖项
  • 包含与我一起提交的人员的参考

此时,任何查看此提交消息的人都会知道:

  1. 一目了然
  2. 为什么需要进行这项改变
  3. 有关所做事情的详细信息
  4. 有关变更的任何有用细节

这使得我们的提交信息对于我们未来的自己以及任何需要了解我们代码的其他开发人员来说更加有用。

即使您不同意我编写提交消息的方法,也很难否认我们必须编写提交消息,以便其他开发人员在阅读我们的代码时能够进入我们的思维空间。

我认为大多数人都同意“好”代码的标志是可维护性,您可以通过编写提交消息来增强代码的可维护性,以帮助其他人在将来理解甚至更改您的代码。

最终模板

Summarize the change in less than 50 characters

Because:
- Explain the reasons you made this change
- Make a new bullet for each reason
- Each line should be under 72 characters

Explain exactly what was done in this commit with more depth than the
50 character subject line. Remember to wrap at 72 characters!

Include any additional notes, relevant links, or co-authors.
Enter fullscreen mode Exit fullscreen mode

还有更多...

这些天我写了很多文章,我运营着一个播客,并且我已经开始发送一份关于我听到的所有精彩故事的新闻通讯摘要。

您还可以在Twitter上关注我,在那里我会制作一些有趣的表情包并谈论作为一名开发人员的感受。

文章来源:https://dev.to/jacobherrington/how-to-write-useful-commit-messages-my-commit-message-template-20n9
PREV
专访 Kent C. Dodds:打造职业生涯的 8 个技巧 JavaScript 专家和内容创作者 Kent C. Dodds
NEXT
如何寻找导师、拓展人脉、结交朋友 开源维护者 Steve Klabnik 美食 Ruby 厨师 Avdi Grimm 用户体验工程师和编码教练 创始人 Emma Wedekind JavaScript 专家和内容创作者 Kent C. Dodds