dll编写指南_编写良好的提交信息：实用指南-CSDN博客

dll编写指南

要创建有用的修订历史记录，团队应首先就使用的提交消息约定达成一致，这也适用于个人项目。

最近，我在Hashnode上问了一个问题，询问用户“ 他们在工作中使用哪种提交消息约定？ ”，当用户解释他们在工作中和用于个人项目的约定时，我得到了相当多的反响。

在本文中，我将介绍为什么您应该编写良好的提交消息以及如何编写良好的提交消息。

Git版本控制简介

版本控制软件是每天现代软件开发人员实践中必不可少的部分。

到目前为止， Git是当今世界上使用最广泛的现代版本控制系统。它是一个分布式且积极维护的开源项目，最初由Linux操作系统内核的著名创建者Linus Torvalds于2005年开发。

刚接触Git？查看我过去的演讲中的官方入门指南或这张幻灯片。

什么是提交消息？

在Git中暂存后，使用commit命令将更改保存到本地存储库。但是，在保存Git更改之前，您必须告诉Git您要保存哪些更改，因为您可能已经进行了大量更改。做到这一点的一种好方法是添加一个提交消息以标识您的更改。

提交选项

-m <消息>

此选项设置提交的消息。

gitadd  static/admin/config.yml
 git commit -m "Setup multiple roles for netlify-cms git gateway"

-a或--all

此选项自动提交所有（包括新的）跟踪，修改或删除的文件。

git commit -a -m "Add a new role for netlify-cms git gateway"

- 修改

此选项将使用任何当前暂存的更改或新的提交消息重写最后的提交，并且应仅对尚未推送到远程存储库的提交执行此操作。

gitadd  .
 git commit --amend -m "Update roles for netlify-cms git gateway"

为什么要编写良好的提交消息？

您可能会说，“这只是一个个人项目”，但是，是的，您现在一个人工作，但是当您与团队合作或为开源做出贡献时会发生什么？

精心设计的Git提交消息是与正在进行该项目的其他开发人员以及您未来的自我交流有关更改的上下文的最佳方法。您是否尝试过运行旧项目之一的`git log`来查看自创建以来一直使用的“怪异”提交消息？您很难解释过去为什么要进行一些更改，并且希望您现在之前已经阅读过本文：)。

提交消息可以充分告诉您进行更改的原因，并且了解进行更改的原因会使开发和协作更加高效。

如何使用Git编写提交消息

在此之前，我只在个人项目上使用了git commit -m "Fix X to allow Y to use Z" ，并且仅提供了一个主题，没有附加描述。这非常适合进行小而清晰的修复，例如git commit -m "Fix typo in README.md中的git commit -m "Fix typo in README.md但是在更广泛的更改的情况下，您需要添加一些额外的细节。

编辑器方法

运行没有消息或选项的git commit ，它将打开您的默认文本编辑器以编写提交消息。

>要配置“默认”编辑器：

git config  --global core.editor nano

这会将git配置为使用nano作为默认编辑器。将“ nano”替换为“ emacs”，“ vim”或您的偏好。

在打开的编辑器中，第一行是主题（简短描述），其后留空行，其他所有内容都是扩展描述（正文）。

< Summarize change ( s ) in around 50 characters or less >
< More detailed explanatory description of the change wrapped into about 72
characters >

命令行方式

git commit -m "Subject" -m "Description..."

第一个-m选项是主题（简短描述），第二个是扩展描述（正文）。

如何编写良好的提交消息

一些团队和开发人员使用多种约定来编写良好的提交消息。我仅概述一些用于编写提交消息的一般规则和技巧，您将必须决定要遵循的约定，并且如果您在公司工作或为开源做贡献，则必须适应它们的约定：）。

为了保持一致性，您可以在工作中使用一种约定，而在个人项目中使用另一种约定，因为您有时可能会更改工作，并且约定可能会更改。

确保检查此线程以了解一些惊人的提交消息约定，或添加您的帮助以帮助某人做出决定。

这是Tim Pope最初编写的良好提交消息的一个很好的模板

大写的简短（不超过50个字符）摘要

如有必要，提供更详细的说明文字。将其包装到大约72个字符左右。在某些情况下，第一行被视为电子邮件的主题，其余文本被视为正文。将摘要与正文分隔开的空白行很重要（除非您完全省略正文）；如果将两者一起运行，诸如rebase之类的工具可能会感到困惑。

请务必将提交消息写在“修复错误”而不是“修复错误”或“修复错误”中。该约定与git merge和git revert等命令生成的提交消息匹配。

空白段之后是其他段落。

-子弹点也可以

-通常在项目符号上使用连字符或星号，后跟一个空格，中间留有空白行，但约定在此处有所不同

-使用悬挂式缩进

如果您使用问题跟踪器，请在其底部添加一个引用，如下所示：解决：＃123

看起来不错吧？您也可以通过以下方法来使自己的表现出色：

1.指定提交类型：

壮举：您要添加到特定应用程序的新功能
fix ：一个错误修复
样式：与样式相关的功能和更新
重构：重构代码库的特定部分
测试：与测试相关的所有内容
docs ：与文档相关的所有内容
杂务：常规代码维护。

[您也可以使用表情符号来代表提交类型]

2.用空白行将主题与身体分开

3.您的提交消息不应包含任何空格错误

4.删除不必要的标点符号

5.不要以句号结尾主题行

6.大写主题行和每个段落

7.在主题行中使用祈使语气

8.用正文解释您进行了哪些更改以及为什么进行更改。

9.不要以为审阅者理解最初的问题是什么，请确保将其添加。

10.不要认为您的代码是不言自明的

11.遵循团队定义的提交约定