根据 Git Commit Best Practices 翻译整理。

Git 提交最佳实践

基本规则

提交相关的更改

一次提交应该是相关更改的包装。例如，修复两个不同的错误应该产生两个单独的提交。小的提交使得其他开发人员更容易理解这些更改，并在出现问题时回滚它们。

经常提交

经常提交可以使您的提交变得更小，并且再次帮助您仅提交相关更改。此外，它允许您更频繁地与他人共享代码。这样，每个人都可以更容易地定期集成更改并避免合并冲突。相比之下，拥有大的提交并且不经常共享它们会使解决冲突变得困难。

不要提交未完成的工作

你应该只在完成逻辑组件时才提交代码。 将功能的实现拆分为可以快速完成的逻辑块，以便您可以经常提交。如果你想提交只是因为你需要一个干净的工作副本（检出一个分支，拉取更改等），请考虑使用Git的“Stash”功能。

在提交之前测试您的代码

抵抗提交你“认为”完成的东西的诱惑。彻底测试它，以确保它确实已经完成并且没有副作用（就我们所知）。当在本地存储库中提交半烤的东西时，只需要原谅自己，但是在将代码推送/共享给其他人时，对代码进行测试更加重要。

编写良好的提交消息

以一个简短的更改摘要开始您的消息（最多50个字符作为指南）。通过包含空行将其与以下正文分开。您的消息正文应提供对以下问题的详细答案：

• 更改的动机是什么？
• 它与以前的实现有何不同？ 使用祈使语气，现在时态（“change”，而不是“changed”或“changes”）与诸如git merge之类的命令生成的消息保持一致。

使用分支

分支是Git最强大的功能之一，这不是偶然的：快速简便的分支是从第一天开始的一个核心要求。分支是帮助您避免混淆不同开发线的完美工具。您应该在开发工作流程中广泛使用分支：用于新功能，错误修复，想法…

同意工作流程

Git允许您从许多不同的工作流中进行选择：长期运行的分支，主题分支，合并或rebase，git-flow…您选择哪个取决于几个因素：您的项目，您的整体开发和部署工作流以及（也许最重要的是）您和您的队友的个人偏好。无论您选择哪种工作方式，只要确保达成共识，每个人都会遵循共同的工作流程。

下面的文档基于使用GIT的一些项目（包括libvirt，QEMU和OpenStack Nova）进行代码开发，故障排除和代码审查的经验。对其他开源项目（如Kernel，CoreUtils，GNULIB等）的研究表明，它们都遵循着相当普遍的做法。它的动机是希望提高Nova GIT历史的质量。质量是一个很难定义的计算术语;一个人的“美丽之物”是另一个人的“邪恶黑客”。然而，我们可以提出一些一般性的指导方针，用于发布与项目合并的GIT提交，本例中为OpenStack，或者反过来，不要这样做。

这个主题可以分为两个关注领域

• 代码更改的结构化集/分割
• 提供的提交消息中的信息

格式化规则

• 大写，简短（50个字符或更少）的摘要
• 合并的更详细的解释性文本（如果需要）。将其包装到大约72个字符。在某些情况下，第一行被视为电子邮件的主题，其余文本被视为正文。分隔摘要和正文的空行至关重要（除非您完全省略正文）;如果您将两者结合在一起，rebase等工具可能会混淆。
• 总是留下第二行空白。
• 用祈使语气写你的提交消息：“修复错误”而不是“修复错误”或“修复错误”。这个约定与git merge和git revert等命令生成的提交消息相匹配。
• 进一步的段落在空行之后。
  • 项目符号也可以
  • 通常使用连字符或星号作为项目符号，前面有一个空格，在两者之间有空行，但是约定在这里有所不同
  • 使用悬挂缩进

良好实践的例子

例子1（没有描述，只有摘要）

  commit 5c6bce2d0d1c1e0c0b8d9e4e8b8f6e0b1e7e4b1e
  Author: [removed]
  Date:   Mon Jun 11 17:16:10 2012 +0100

    Update default policies for KVM guest PIT & RTC timers

例子2（描述为项目符号）

  commit ae878fc8b9761d099a4145617e4a48cbeb390623
  Author: [removed]
  Date:   Fri Jun 1 01:44:02 2012 +0000

    Refactor libvirt create calls

     - Minimize duplicated code for create

     - Make wait_for_destroy happen on shutdown instead of undefine

     - Allow for destruction of an instance while leaving the domain

例子3（描述为纯文本）

  commit 31336b35b4604f70150d0073d77dbf63b9bf7598
  Author: [removed]
  Date:   Wed Jun 6 22:45:25 2012 -0400

    Add CPU arch filter scheduler support

    In a mixed environment of running different CPU architectures,
    one would not want to run an ARM instance on a X86_64 host and
    vice versa.

    This scheduler filter option will prevent instances running
    on a host that it is not intended for.

    The libvirt driver queries the guest capabilities of the
    host and stores the guest arches in the permitted_instances_types
    list in the cpu_info dict of the host.

    The Xen equivalent will be done later in another commit.

    The arch filter will compare the instance arch against
    the permitted_instances_types of a host
    and filter out invalid hosts.

    Also adds ARM as a valid arch to the filter.

    The ArchFilter is not turned on by default.