为什么我们应该关心编写干净的提交消息？

提交是程序员技术的有形构建块。它们充当代码的锦上添花，如果编写正确，它们会带来巨大的价值。编写良好的提交消息变得不可或缺，因为它们提供了上下文——否则一开始就不需要提交消息。

良好的提交表明开发人员是否是良好的合作者 - Peter Hutterer，Linux。

开发人员中的一个常见错误是将 Git 存储库视为备份系统。随机承诺捕获代码的当前状态可能会妨碍您在将来检查代码库时理解过去更改的能力。提交诸如“WIP”、“吃午餐”、“今天代码结束”、“我累了 AF”、“团队周末快乐”和“首先提交”之类的消息只会让你的 Git 日志变得混乱，让你的工作变得困难。了解您所做的重要承诺，因为这些消息都不包含任何附加价值。

以下是尝试提交到远程存储库时要避免的一些关键错误

切勿分别对不同文件提交更改

在查看提交历史记录或与其他团队成员协作时，单独提交对不同文件的更改可能会导致出现问题。理解变化的完整背景及其相互关系变得具有挑战性。

例如，我正在建立一个网上商店。我不应该做的是：

# Committing changes to header.js separately
git add header.js
git commit -m "Improve header layout"

# Committing changes to footer.js separately
git add footer.js
git commit -m "Optimize footer design"

查看您的 Git 日志，这种提交结构可能会变得混乱，尤其是随着您的提交历史记录的增长。

提交应该清晰、简洁并组织成逻辑单元。例如，完成代码的布局部分并处理页眉和页脚部分后，在提交这些更改之前完成这些更改后，合并这些更改会更清晰：

# Staging changes to both header.js and footer.js
git add header.js footer.js

# Committing related changes together
git commit -m "Enhance UI: Header and Footer Improvements"

我知道这在理论上听起来可能比在实践中容易。这就是为什么在通过压缩将这些更改合并到主分支之前，维护一个专门用于提交的私有分支是一个很好的做法。

为私有提交创建专用分支

提交代码并不一定意味着它必须成为无尽的 git 日志中的永久固定装置。将私人分支机构视为您个人程序员的画板 - 您可以自由地进行实验，而不必担心其他人审查您的工作。

想象一下场景：您正在编码，需要暂时离开一下，或者您可能要去吃晚饭。对失去当前进度的恐惧促使您提交更改 - 私人分支机构的完美用例。无论您是要结束当天的编码会议还是只是想进行自发的提交，这些更改都可以在您的私人分支中找到它们的家。

commit [commit-hash]
Author: Your Name <your.email@example.com>
Date:   [Timestamp]
    WIP

commit [commit-hash]
Author: Your Name <your.email@example.com>
Date:   [Timestamp]

    commiting before i eventually lose my files

commit [commit-hash]
Author: Your Name <your.email@example.com>
Date:   [Timestamp]

    about to go for dinner

commit [commit-hash]
Author: Your Name <your.email@example.com>
Date:   [Timestamp]

    toilet time!

在协作环境中，使私有分支的命名显而易见非常重要。因为您不能让此类提交消息出现在您的公共分支中。

无论是通过明确的分支命名还是与队友直接沟通，都要明确表明该分支的内容并不旨在作为正在进行的工作的基础。私有分支的一个好命名可以是：“private/do-not-use-this”

成为公共分支一部分的每个提交都必须体现一个精心设计、独立、可逆且描述良好的工作单元。

案例研究：开发在线商店的购物车功能

让我们看一下我们一直在开发的在线商店项目。在这种情况下，您作为前端开发人员，负责向商店添加购物车功能。您的旅程将按如下方式展开：

您通过增强购物车部分的 CSS 呈现方式开始了努力，并做出了相应的提交。随着您的进步，您向购物车引入了 JavaScript 功能，从而导致了另一次提交。在追求完美的过程中，您注意到文本对齐问题并投入时间来完善 CSS，然后进行了额外的提交。

继续您的工作，您发现并解决了与将产品添加到购物车时计数器行为相关的错误。这个快速修复也在提交中得到了体现。最后，您试图通过在单击结帐按钮时合并加载动画来提升用户体验，并以结论性提交作为结束。

现在我们看一下git日志：

commit [commit-hash-1]
Author: Your Name <your.email@example.com>
Date:   [Timestamp]

    Enhance CSS presentation of cart section

commit [commit-hash-2]
Author: Your Name <your.email@example.com>
Date:   [Timestamp]

    Introduce Javascript functionality to cart

commit [commit-hash-3]
Author: Your Name <your.email@example.com>
Date:   [Timestamp]

    Refine CSS to resolve text alignment issue

commit [commit-hash-4]
Author: Your Name <your.email@example.com>
Date:   [Timestamp]

    Fix counter bug related to cart behavior

commit [commit-hash-5]
Author: Your Name <your.email@example.com>
Date:   [Timestamp]

    Incorporate loading animation for checkout button

如果这些更改需要与与在线商店相关的其他提交一起纳入主要功能分支，则审核过程可能会变得具有挑战性。

这是修复这些提交日志的方法

首先切换到您的功能分支：

# Checkout the feature branch named feature/cart-section
git checkout feature/cart-section

然后，将分支中的所有提交压缩private/do-not-use-this为feature/cart-section使用单个提交消息：

# Merge and squash all commits from the private branch to the feature branch using a single commit
git merge - squash private/do-not-use-this

合并和压缩后，您需要制作一条清晰且描述性的提交消息：

编写完美提交消息的 7 个标准规则

这些规则提供了指南和最佳实践，以确保您的提交消息格式正确并传达清晰的信息。虽然具体规则可能因不同来源而异，但总体目标是增强 Git 版本控制系统内提交消息的可读性和可理解性。

规则 1：限制为 50 个字符（最多）。

在设计提交消息的主题行时，建议保持简洁和重点突出。主题行用作提交目的的快速摘要，理想情况下应限制为最多 50 个字符。

难以满足 50 个字符的限制可能表明提交的意图不够明确。提交消息应该清晰、简洁并且能够独立存在。通过遵守此字符限制，您将被迫优先考虑最关键的信息，从而使您的团队和未来的您更容易一目了然地了解变更的性质。

规则 2：仅将主题行的第一个字母大写。

撰写提交消息时，请使用标题大小写，将主题行的第一个字母大写，就像编写简洁的句子一样。将消息的其余部分（包括任何其他详细信息）保留为小写。

规则 3：不要在主题行末尾添加句号

主题行不以句点结束的原因部分是历史原因，部分是为了保持一致的风格。惯例是将主题行视为标题或命令，这就是为什么它以祈使语气编写（例如，“添加功能”或“修复错误”而不是“添加功能”或“修复错误”）。省略末尾的句号有助于强化这一惯例并保持主题行简洁。

git commit -v -m "Create the Cart Feature with a Nice Animation"

规则 4：在主题行和正文之间放置一个空行

虽然该指南可能看起来不寻常，但它植根于实用性。许多开发人员使用 Git 命令行界面，但该界面通常缺乏自动换行功能。因此，引入了有意的格式化规则，以确保一致且清晰的提交消息。

git commit -v -m "Create the Cart Feature with a Nice Animation

Body...
"

规则 5：提交正文在 72 个字符处换行

需要澄清的是，遵守本指南并不涉及传统的自动换行；而是涉及传统的自动换行。相反，这种做法是因为考虑到命令行用户可能会遇到超过 72 个字符的截断提交正文。

大多数时候，您的消息长度会超过 72 个字符。在这种情况下，建议中断文本并在下一行继续您的句子，如下面的提交消息所示：

git commit -v -m "Create the Cart Feature with a Nice Animation

Enhanced the CSS layout of the cart section, addressing text
alignment issues and refining the layout for improved aesthetics
and readability."

总之，表示要点的标准做法是使用连字符或星号，后跟一个空格。此外，保持悬挂缩进以提高组织清晰度也很重要。

规则 6：使用祈使语气

一个有价值的实践涉及在编写提交消息时具有基本的理解，即提交在实施时将实现精确的操作。以逻辑上完成句子“如果应用，此提交将......”的方式构建提交消息。例如，不要git commit -m "Fixed the bug on the layout page"使用 ❌，而是使用这个git commit -m "Fix the bug on the layout page"✔

换句话说，如果应用此提交，确实可以修复布局页面上的错误。

规则 7：解释“什么”和“为什么”，但不解释“如何”。

将提交消息限制为“内容”和“原因”，可以为每个更改创建简洁而信息丰富的解释。寻求“如何”实现代码的开发人员可以直接参考代码库。相反，突出显示更改的内容以及更改的理由，包括受影响的组件或区域。

案例研究：Angular 的提交消息实践

Angular 是有效提交消息传递实践的一个突出例证。Angular 团队提倡在制作提交消息时使用特定的前缀。这些前缀包括“chore:”、“docs:”、“style:”、“feat:”、“fix:”、“refactor:”和“test:”。通过合并这些前缀，提交历史记录成为了解每次提交性质的宝贵资源。