如何写Git提交消息?

项目的长期成功(除其他因素外)取决于它的可维护性,而且维护者所拥有的工具很少比其项目日志更强大。值得花时间学习如何正确地照顾一个人。一开始可能会引起麻烦的习惯逐渐成为习惯,最终使所有相关人员感到自豪和提高生产力。

团队处理提交日志的方法应该没有什么不同。为了创建有用的修订历史记录,团队应该首先就提交消息约定达成一致,该约定至少定义以下三件事:

Style: 标记语法,自动换行边距,语法,大写字母,标点符号。讲清楚这些内容,消除猜测,并使其尽可能简单。最终结果将是非常一致的日志,这不仅使我很高兴阅读,而且实际上确实会定期阅读。
Content: 提交消息的正文(如果有)应包含哪些信息?它不应该包含什么?
Metadata: 应该如何引用发布跟踪ID,请求请求编号等?

幸运的是,关于什么构成了惯用的Git提交消息,已有许多公认的约定。确实,其中许多假设是以某些Git命令起作用的方式进行的。您无需重新发明。只需遵循以下七个规则,您就可以像专业人士一样进行承诺。

Git提交消息的七个规则

  1. 用空行将主题与内容分开
  2. 将主题行限制为50个字符
  3. 大写主题行首字母
  4. 不要以句号结尾主题行
  5. 在主题行中使用命令式心情
  6. 将内容包裹在72个字符处
  7. 用内容来解释什么以及为什么与如何

举个例子:

Summarize changes in around 50 characters or less

More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.

Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequences of this
change? Here's the place to explain them.

Further paragraphs come after blank lines.

 - Bullet points are okay, too

 - Typically a hyphen or asterisk is used for the bullet, preceded
   by a single space, with blank lines in between, but conventions
   vary here

If you use an issue tracker, put references to them at the bottom,
like this:

Resolves: #123
See also: #456, #789

看一看完整的差异,然后花些时间在这里和现在提供时间,想一想作者节省了多少时间来节省同伴和将来的提交者。如果他不这样做,它可能会永远丢失。

在大多数情况下,您可以忽略有关更改方式的详细信息。在这方面,代码通常是不言自明的(并且如果代码太复杂以至于需要在散文中进行解释,这就是源注释的目的)。只需专注于清楚说明为什么要进行更改的原因-更改之前的工作方式(以及问题出在哪里),现在的工作方式以及为什么决定以自己的方式解决它。

未来的维护者,谢谢您可能就是您自己!

shell命令大全
git: detached head问题