Git 提交：有效的样式指南

帖子封面图片由xkcd提供

Git 提交是 Git 中最被低估的功能之一。暂停片刻，思考一下；

1. 您上次将代码恢复到较早的时间点是什么时候？

2. 您是否很难找到弄乱您代码的提交？

3. 这是因为提交信息不清楚、混乱吗？

4. 当找到该提交时，您是否还意识到您在该特定提交中包含了几个文件更改，导致在尝试重新回到该提交时感到头疼？

恭喜，您刚刚禁用了 Git 最强大的功能之一：

代码版本控制和历史记录！

保持提交干净整洁的重要性

作为一名开发人员，你会遇到的最困难的任务之一就是沟通。不仅要与其他开发人员沟通，还要与客户沟通，与经理沟通，还要与未来的自己沟通。

拥有干净的 git 提交消息历史记录意味着您将来可以随时修改代码中所做的更改、删除的功能部分以及修复的错误。

通过运行，git log您将能够查看逻辑消息流，这些消息流本身就解释了应用程序的整个代码历史。
您还可以运行git log --pretty=oneline以查看更密集的版本git log。

如何组织提交信息

如果您使用Jira、Asana、Trello或其他项目管理工具，并遵循Scrum或Kanban等任务分解项目管理流程，您将把所有任务集中在一个地方，整洁有序。

你的目标应该是让每个提交都对应一个子任务。不要再使用git commit -m "Added code"、git commit -m "Added CSS"或 了git commit -m "bugfix"。
这些提交是不可追踪的，你将来也用不到它们。

那么，为什么首先要拥有它们呢？

当你更改了一堆类并准备提交代码时，请花点时间思考一下；

1. 你在每个文件中做了哪些修改？哪些类与你处理的子任务功能相关？

2. 您的应用程序受到了怎样的影响？您对代码进行了哪些重大更改？

遵循简洁的消息风格

通过选择一种风格并坚持下去，您可以将您的代码提升到另一个层次。

其他开发人员将能够像阅读小说一样阅读您的消息历史记录，并且他们可能永远不必查看实际代码（这将为他们节省大量时间）。

您还会强迫自己去做重要的事情，而不是当前方便的事情。

最后，风格指南

消息结构

干净的提交消息应由三个不同的部分组成，中间用空行分隔：标题（描述代码更改的类型）和描述性正文，其中包含有关后续任务或问题跟踪器 ID（页脚）的可选消息。

布局看起来应该是这样的：

commit type

body (changes, links, attributions, etc)

issue tracker id (for reference)

提交类型

它可以是实际提交内容的缩写。例如（摘自Udacity 的提交样式指南）：

1. feat：一项新功能
2. 修复：错误修复
3. docs：文档变更
4. 样式：格式化、缺少分号等；无需更改代码
5. 重构：重构生产代码
6. 测试：添加测试，重构测试；无需更改生产代码
7. 琐事：更新构建任务、包管理器配置等；无需更改生产代码

身体

提交对代码所做的任何更改。它可以是添加的功能的描述、已完成任务的描述，也可以是错误重现和解决方案的步骤。

撰写正文时，请尽量详细。想象一下，两年后你很有可能还会读到这条提交消息。你想和未来的自己分享什么？
你可以添加项目符号、列表、Stackoverflow 答案链接以及你的问题跟踪器链接。

结论

能够编写有意义的 Git 提交不仅会让你受到其他阅读你提交的开发人员的喜爱，
还能让你成为更好的写作者，并且更注重分析和代码的整洁。

想想未来的自己。今天就写下更好的承诺！

参考：
Udacity Git 提交消息样式指南