Git 中的提交可以是以下两种情况之一：
- 它可以是来自各种主题的混乱的变化集合：用于修复错误的几行代码、重写旧模块的尝试以及用于全新功能的几个新文件。
- 或者，只要稍加注意，它就可以帮助我们掌握最新情况。它可以是属于一个且仅属于一个主题的相关更改的容器，从而让我们更容易了解发生了什么。
在这篇文章中，我们将讨论如何产生后一种类型的提交，或者换句话说：“完美”的提交。
Git高级系列：
- 第1部分： 在 Git 中创建完美的提交（您在这里！）
- 第二部分： Git 中的分支策略
- 第 3 部分： 通过 Pull 请求实现更好的协作
- 第 4 部分： 合并冲突
- 第五部分： Rebase 与 Merge
- 第六部分： 交互式 Rebase
- 第 7 部分： 在 Git 中挑选提交
- 第 8 部分： 使用 Reflog 恢复丢失的提交
为什么干净且细致的提交很重要
真的有必要以谨慎、周到的方式编写提交吗？我们不能将 Git 视为一个无聊的备份系统吗？让我们再一次回顾一下上面的例子。
如果我们遵循第一种方式——只要发生更改，我们就将其塞进提交中——提交将失去其大部分价值。一个提交与下一个提交之间的分离变得任意：似乎没有理由将更改放入一个提交而不是另一个提交。稍后查看这些提交，例如当您的同事试图弄清楚该修订中发生了什么时，就像翻看每个家庭都有的“万能抽屉”：这里有所有其他地方找不到的东西，从蜡笔到图钉和现金单。在这些抽屉里找到东西真是太难了！
按照第二种方法，我们只将属于同一类的事物（即更改）放入同一次提交中，这需要更多的规划和纪律。但最终，您和您的团队将获得非常有价值的东西：干净的提交历史记录！这些提交可帮助您了解发生了什么。它们有助于以易于理解的方式解释所做的复杂更改。
我们如何才能做出更好的承诺？
编写更好的提交
一个概念对于在 Git 中编写更好的提交至关重要：暂存区 (Staging Area)。
暂存区正是为此目的而设计的：允许开发人员以非常精细的方式选择应成为下一次提交一部分的更改。而且，与其他版本控制系统不同，Git 强制您使用此暂存区。
然而不幸的是，我们仍然很容易忽略暂存区的整理效果：一个简单的暂存区git add .就会收集我们当前的所有本地更改并将它们标记为下一次提交。
确实，有时这种方法非常有用且有效。但很多时候，我们最好停下来思考一下，看看我们的所有更改是否真的都与同一主题有关。或者，两三个单独的提交可能是更好的选择。
在大多数情况下，保持提交较小比保持提交较大更有意义。专注于单个主题（而不是两个、三个或四个），它们往往更具可读性。
暂存区允许我们仔细挑选应该进入下一次提交的每个更改：
$ git add file1.ext file2.ext这只会将这两个文件标记为下一次提交，并将其他更改留待将来提交或进一步编辑。
这种简单的暂停和精心选择应该进入下一次提交的内容的行为大有裨益。但我们可以做得更精确。因为有时，即使是单个文件中的更改也属于多个主题。
让我们看一个真实的例子，看看我们的“index.html”文件中的具体变化。我们可以使用“git diff”命令或像Tower这样的 Git 桌面 GUI ：
现在，我们可以添加-p选项git add：
$ git add -p index.html我们指示 Git 在“补丁”级别上检查此文件：Git 会手把手地引导我们检查此文件中的所有更改。并且，对于每个块，它会询问我们是否要将其添加到暂存区：
[Y]通过在第一个块中输入（“是”）并[N]在第二个块中输入（“否”），我们可以在下一次提交中包含此文件中更改的第一部分，但将其他更改留待以后或更多次编辑。
结果如何？更细致、更精确的提交，专注于单一主题。
测试代码
既然我们在这里谈论的是“完美提交”，我们就不能忽略测试这个话题。你“测试”代码的具体方式当然会有所不同，但测试很重要这个概念并不新鲜。事实上，如果一段代码没有经过适当的测试，许多团队都拒绝认为它已经完成。
如果你仍然犹豫是否应该测试你的代码，让我们来揭穿几个有关测试的误区：
- “测试被高估了”：事实上，测试可以帮助你更快地发现错误。最重要的是，它们可以帮助你在产品投入生产之前发现错误——而生产过程中的错误才是最严重的。毫不夸张地说，尽早发现错误是无价的！
- “测试耗费宝贵的时间”：一段时间后，你会发现编写良好的测试可以让你更快地编写代码。你花在寻找错误上的时间更少，而且更常见的是，结构良好的测试也能让你为实际实施做好准备。
- “测试很复杂”：虽然几年前这可能是一个论点，但现在已不复存在。大多数专业编程框架和语言都对设置、编写和管理测试提供了广泛的支持。
总而言之，在你的开发习惯中添加测试几乎可以保证你的代码库更加健壮。同时，它们还能帮助你成为一名更好的程序员。
有价值的提交信息
使用 Git 进行版本控制并不是备份代码的绝妙方式。而且，正如我们已经讨论过的，提交并不是任意更改的转储。提交的存在是为了帮助您和您的队友了解项目中发生的事情。而良好的提交消息对于确保这一点大有帮助。
但是什么才是好的提交信息呢？
- 简洁明了的主题行，总结了变化
- 描述性的消息主体，解释最重要的事实（尽可能简洁）
让我们从主题行开始：目标是简要概述发生的事情。当然，简洁是一个相对术语；但一般的经验法则是（理想情况下）将主题保持在 50 个字符以下。顺便说一句，如果你发现自己很难想出一个简短的主题，这可能表明提交涉及的主题太多了！再看一看是否值得将其拆分成多个单独的主题。
如果您用换行符和额外的空行结束主题，Git 会理解以下文本是消息的“正文”。在这里，您有更多空间来描述发生的事情。它有助于记住以下问题，您的正文应该旨在回答这些问题：
- 这次提交给你的项目带来了什么改变？
- 做出这一改变的原因是什么？
- 有什么需要特别注意的吗？其他人应该了解这些变化吗？
如果你在编写提交消息正文时牢记这些问题，你很可能写出对所发生事情有用的描述。这最终会使你的同事（以及一段时间后你）在尝试理解此提交时受益。
除了我刚才描述的有关提交消息内容的规则之外，许多团队还关心格式：同意字符限制、软或硬换行等，都有助于在团队中产生更好的提交。
为了更容易遵守这些规则，我们最近为我们制作的Git 桌面 GUI Tower添加了一些功能：例如，您现在可以根据需要配置字符数或自动换行。
优秀的代码库由优秀的提交组成
任何开发人员都会承认他们想要一个很棒的代码库。但只有一种方法可以实现这个崇高的目标：不断做出出色的提交！我希望我能够证明 (a) 追求这个目标绝对值得，并且 (b)实现它并不难。
如果您想深入了解高级 Git 工具，请随时查看我的（免费！）“高级 Git Kit”：它是关于分支策略、交互式 Rebase、Reflog、子模块等主题的短视频集合。
享受创建出色提交的乐趣！
