在 Git 中编写清晰提交历史的技巧

---

引言

Git 是最重要的工具之一。Git 不仅保留项目的版本历史，还简化了团队间的协作。尽管它是一个非常有价值的工具，但它经常被忽视或未得到充分利用。

清晰的 Git 历史记录讲述了一个项目的故事，并且易于理解。添加和实现功能的过程一目了然。在项目中，我非常重视清晰的 Git 历史记录。好消息是，保持清晰的历史记录并不困难。

以下是一些在 Git 中实现清晰历史记录的技巧

什么是 Git 历史记录？

Git 表示历史记录的方式与 Team Foundation Version Control、Perforce 和 Subversion 等集中式版本控制系统 (CVCS) 表示历史记录的方式根本不同。在集中式系统中，存储库中的每个文件都有其自己的历史记录。Git 将历史记录存储为对存储库在任何给定时间的每个部分的快照的图表。在 Git 中，这些快照可以有多个父级，从而创建类似图表的而非线性的历史记录。Git 的历史记录与 CVCS 截然不同，这是用户发现它令人困惑的主要原因之一。

有意义的 Git 历史记录的重要性

提交消息是你留在代码片段上的指纹。如果你一年后查看相同的更改，你会感谢你编写的清晰、有意义的提交消息，它也会让你的同事受益。通过上下文隔离提交可以更容易地找到由特定提交引入的错误，从而更容易回滚引入错误的提交。编写清晰的提交历史记录让我了解到以下几点。

它促进了拉取请求的审查过程。组织良好的提交可以更好地理解主题。

如果代码被组织成小的提交，审查者就不会感到压力。

审查者用它来发现拉取请求中的错误或缺陷。

你将代码组织成有意义的提交的方式反映了你对特定问题的理解和方法。

维护清晰 Git 历史记录的技巧

以下五个技巧可以帮助你维护清晰的 Git 历史记录

始终在分支上工作

使用分支的好处很多。首先，通过在分支而不是主分支上工作，开发人员避免了使用进行中的提交污染主分支。分支还可以使多个人同时处理一组功能变得更容易。分支的使用有助于将一项功能的工作压缩成几个逻辑提交。

遵守并遵循样式指南

以清晰、描述性的方式描述你的更改将产生的影响。编写提交消息时要保持一致（使用祈使句或过去时）。通常，你未来的自己也会阅读你的提交，因此需要简要说明其目的。与其写“修复标题”，不如写“修复加载 Python DLL 的错误”。保持提交消息少于 50 个字符，因为有人会阅读你的提交日志以快速了解更改摘要。每个提交都包含你的姓名和日期，因此你无需自己添加它们。它促进了拉取请求的审查过程。组织良好的提交可以更好地理解主题。

练习合并和压缩

在一个项目中，主分支应该包含高级摘要。应该很容易找到何时以及如何实现功能。为了使功能完全整合，在使用 `git merge --squash` 与主分支合并时，需要再次压缩它。在合并之前，所有提交都将合并到一个提交中。这很方便，因为所有提交消息都包含在一个消息中。

从其他人的角度看待它

对于仅对应用程序有大致了解的人来说，理解这组经过良好压缩的提交应该很容易。在大多数情况下，很难用 50 个字符概括你的工作。只要有可能，根据样式指南在提交消息中包含项目符号或段落。将你的写作视为广告牌，而不是论文。在将你的代码审查功能合并到“master”之前，请征求他人对你的提交消息的意见。如果他们能够快速轻松地阅读和理解你的更改，则表示你成功了。

根据需要删除分支

分支保留的时间越长，混乱就越多。该分支是否已经合并？是否还有待完成的工作？它是否可能是一个不应该合并的突发事件？

一旦分支完成了它的目的，就删除它以避免混淆。借助出色的 Git 扩展项目，可以本地和远程删除分支。该过程与运行 `git delete-branch ` 一样简单。

结论

保持清晰的 Git 历史记录需要纪律。如果遵循这些步骤，阅读项目的历史记录就很容易了。你如何维护项目的清晰历史记录？