如何撰写让项目维护者欣赏的提交信息
你知道那句俗语“如果你一直盯着过去，就会错过未来”吗？但是在编码和Git工作的环境下，事情并非如此你的提交历史在你贡献给开源项目的未来中扮演着重要的角色，而不是限制你
你知道那句“如果你一直盯着过去，就会错过未来”的谚语吗？嗯，在编程和使用Git的上下文中，并非如此。
你的提交历史在你为开源项目做出贡献的未来中扮演了重要的角色，而提交信息是实现这一点的关键。
你可能会问，什么是提交信息？这些简要说明描述了你对代码库所做的更改，如果出现错误等情况，它们非常有用。
如果你很久没有为一个开源项目做出贡献，并且需要记住迄今为止所做的更改，那么提交信息也是非常好的检查点。
感到有些害怕？别担心。在这个快速指南中，你将学习如何编写有效的提交信息。
什么是糟糕的提交信息？
像生活中的大多数事情一样，在学习如何编写一个好的提交信息之前，我们必须了解什么是无用的提交信息。
让我们看一个例子：
mention information尽管这个提交信息描述了变化，但它并没有解释更改的原因，这可能让维护者感到困惑。
它也没有说明提到了什么样的信息。维护者可能会想：“是缺少的代码片段吗？还是一个特定部分的链接？”当编写提交信息时，你应该避免这些情况。
现在我们已经看到了不好的例子，让我们学习如何将这个提交信息转变为维护者能够理解的东西。
好的提交信息的特点
还记得我说过之前的提交信息有点模糊吗？那么，我们要怎么解决呢？
步骤1 – 提到类型
在这里，你要指明你对代码库所做的更改类型。这样可以让维护者和其他贡献者更好地了解你的贡献。
下面是使用示例提交的这一步骤的实例：
feat: mention information由于示例提交似乎侧重于添加一些文本，我决定选择feat，因为它通常用于描述向开源项目添加信息或新功能的贡献。
这里还有一些常用的缩写，用于对提交进行分类：
docs：常用于描述修订当前版本或更新开源项目文档。fix：通常用于修复项目代码库中的错误或项目文档中的小语法错误。chore：通常用于需要较长时间才能完成的贡献。
步骤2 – 总结更改
在这里，你需要概述更改及其实施方式。这有助于维护者了解你的贡献如何解决你要解决的问题。
现在需要注意的是，GitHub对提交信息有72个字符的限制，所以你需要将描述保持在这个范围内。让我们回顾一下我们的例子：
feat: mention information记得之前我说过它没有具体说明修复了哪个拼写错误吗？经过一些思考，我决定写成这样：
feat: 在课程介绍中提到Christine Peterson好多了！与之前不同，这个示例提交的版本提到了信息的种类，并指明了它在项目中的添加位置。这有助于维护者更好地理解为什么做出这个贡献。
可选步骤 – 添加描述
在这里，你可以更详细地描述更改，并说明为什么进行了更改。虽然这个步骤是可选的，但考虑在进行贡献时这样做，以便维护者可以了解你的贡献如何增强或解决他们项目中的问题。
下面是我们示例的描述：
我决定添加这些信息以便参与者获得准确的信息。在描述时，我决定保持描述简短而具体。这样可以帮助维护者理解为什么我进行了这个贡献以及它如何增强项目。
现在让我们把这些部分放在一起：
feat: 提及Christine Peterson在课程介绍中，我决定添加这个信息以便参与者可以得到准确的信息现在与原始示例相比，这个提交消息更有效，因为它做到了以下几点：
- 指明正在进行的提交类型
- 描述了贡献如何增强项目
- 总结了变化
看起来很棒，对吧？ 😉
总结
无论你是新手贡献者还是经验丰富的老手，有效地编写提交消息对于与项目维护者进行沟通非常重要。
如果你想了解更多提升提交消息写作技巧的方法，请查看Conventional Commits。此外，关注我在BioDrop上的动态，了解我的社交媒体和其他技术文章。
Leave a Reply