开发者学堂课程【Git 从入门到进阶：Git 的十年变化（八）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1194/detail/18122
Git 的十年变化（八）
内容介绍：
一、作为开发者的困惑
二、什么是”好“的提交
三、如何写好提交
四、提交做小的注意事项
五、修复错误提交的技巧
六、写好提交说明
一、作为开发者的困惑及代码提交
对于开发者来说，写好 git 提交，对于提交个人开发效率和促进团队合作都是大有裨益的，那作为一个开发者，我们可能都有过这样的困惑，那就是当你阅读同事的代码，或者自己以前写的代码时，很难理清头绪，搞不清这段代码到底做了什么改动？
以及为什么要这么改？这背后当然可能有代码的原因，比如：变量命名不规范和逻辑混乱等，但除此之外也可能是你的 git 提交没写好。
写好git 提交能够帮助我们快速理清代码逻辑及其背后的设计思路，比如我们使用 Vscode 阅读上面一段git代码的时候直接看代码可能一头雾水，但是先找到这段代码的提交，然后查看他的提交说明，就可以很清楚的看到这段代码产生的背景，要解决的问题，以及他的大致实现逻辑，这样我们再去看代码，就很容易的看懂它的逻辑。某种程度上讲写好代码与写好提交同等重要。
二、什么是”好“的提交
我们认为好的提交就一个标准 Do one thing and do it well ,即一个提交中只做一件完整的小事，但是把它一次性做好。这是因为一个提交中做了太多的事情的话可能会有以下问题：
①提交太大会增加评审这的评审难度
②提交缺乏原子化
③包含太多改动
三、如何写好提交
我们首先介绍一些技巧，教你如何把干了多件事情的一个大提交拆分为多个小提交。
①如何拆分分支当前指向的提交如图（3.1）
Master 分支当前只想的提交c中做了三件事情①删除文件 setup.c ②新增文件 log.c ③修复已知缺陷
我们接下来将展示如何将提交c拆分为三个小提交c1，c2和c3每个提交中分别完成上述三件事之一
如图（3.2）
我们的整体思路是如图3.3，先将 master 分支回退到提交C之前，然后重新提交，将提交C的改动分散提交到三个小提交中，具体来说，我们先执行 git reset 命令，此时 master 分支将会回退到提交B，同时提交C的改动仍然保留在工作区中接着我们执行 git add-p 命令，按照提示选择“修复已知缺陷”。这个事情涉及的改动，然后执行 git commit 生成新的提交c1，那我们使用同样的方法，可以将新增文件 log.c 和删除文件 setup.c ，这两个事情涉及的改动分别写在提交C2和C3中，
那接下来看一下如何拆分分支的历史提交，如图3.4
图3.4
历史提交B中做了上述三件事情，我们将展示如何将历史提交B中做的三件事情分别拆分到三个小提交，B1,B2和B3中，首先我们执行 git rebase 命令来将 master 分支回退到B前，此时 git 会自动打开一个编辑器，将参与 rebase 的提交写到一个动作文件中。编辑器中显示的内容是 Pick b 换行 pick c ，我们将带拆分的提交B之前的 pick 改为 edit ，然后保存退出，此时B成了 master 分支当前指向的提交，那这时候我们就可以使用上一小节的方法将提交B分别拆分为三个小提交B1，B2和B3，最后我们执行 git rebase-continue 命令，此时， git 会自动将提交B后面的提交C重新 rebase 到提交B3上去生成一个新提交C’，这样我们就完成了历史提交B的拆分。
四、提交做小的注意事项:
①错误提交 ②修正提交 ③修正修正提交
原因：一方面会增加评审负担，另一方面，也不利于后期使用 git bisect 快速定位问题，所以，接下来我们将给大家介绍一些修复错误提交的技巧。
五、修复错误提交的技巧
（1）修改当前提交
首先我们还是来看一下如何修复分支，当前指向的提交，如图所示，master 分支指向的当前提交C中包含一个可能会导致应用 panic 的缺陷，那么我们可以直接在工作区中修复这个缺陷，然后执行 git commit-amend 命令来生成新的没有 panic 缺陷的提交C1.
（2）修改历史提交
如果历史提交中存在问题，我们应该如何修复呢？如图，master 分支的历史提交a中包含一个会导致应用 panic 的缺陷，同样的，我们也可以直接在当前工作区中修复该缺陷，然后执行 git commit时添加 fix up 参数，并且将待修复提交a的提交ID作为参数传入，此时git会生成一个新提交F，并且为F自动生成提交说明，该提交说明由a的提交说明，加上fix up！前缀构成，接着我们在执行上述 git rebase 命令，git 就会自动将提交a和提交F合并生成一个新提交A’，然后自动将后面的提交B和提交C到提交A’上去.
六、写好提交说明
1.提交说明结构：
一般包含四部分，首先第一行是提交标题，接下来接一个空行，然后是提交说明主题，最后是一个签名区如图，
2.提交标题
下面我们分别来看一下提交说明的这四部分都写些什么内容，有哪些注意事项，我们先来看一下提交标题，那提交标题中需要简明扼要地说明，提交设及的改动内容长度一般不要超过50个字符，因为很多开源代码库都是用邮件列表来做，代码评审，提交标题会作为邮件的标题，而邮件标题本身有长度上的限制，此外，提交标题应该使用英文，不要使用中文，这是因为 git format-patch 的命令，在将提交转化为补丁的时候，可能会将中文转化为空白字符，导致提交说明丢失，最后，建议大家在提交标题中增加前缀，以区分当前提交的改动范围。比如通过上面的示例，我们可以很容易看到这个提交改了代码库的 upload 命令模块，而改动内容是给 upload 命令增加一个新的叫做 rerun 的参数，提交标题后的空行是为了区分提交标题和提交说明主体的，如果不加这个空行，这客户可能会将连续几行的提交说明都当成提交标题处理，这会导致 git log-oneline 命令对 commit 提交说明展示会变得非常混乱。
3.提交说明主体
提交说明主体中可以较为详细的说明本次提交解决了什么问题，如何解决的以及为什么这么做是合理的等，为了便于阅读和展示，每行最好不要过长，此外，也可以使用马当语法来进一步增强提交说明的可读性，目前已经有很多代码托管平台支持在提交说明中使用 markdown 语法了。
4. 签名区
git commit 命令有一个-s参数，使用该参数时，Git会自动在提交说明的最后给提交者添加一个 signed-off-by 签名，那该签名的作用是给提交添加背书，通常由作者和提交者添加签名，此外，我们还可以添加其他签名，比如签名 reported-by 说明提交中涉及的相关问题的报告者 reported-by 说明提交的评审者 helped-by 说明提交撰写过程中提供帮助的人，通过这一系列签名可以让我们清晰的看到一段代码的诞生过程，具体可以参考图示例。
那我们在前面讲了如何修改存在错误的提交内容，假如我们的提交内容没有错误，只提交说明写的有问题，这时候应该怎么修复呢？例如图的场景中提交a的提交说明写的有问题，为了修复这个提交说明我们可以使用 git2.23中引入的 reword 提交说明特性如图，我们执行 get commit 命令的时候添加 -fixup=reword 参数，此时，Git 会自动弹出一个编辑框，用于编辑提交，说明我们在编辑框的第二行中修复有问题的提交说明，此时 git 会生成一个新提交，该提交的提交说明由“amend!”前缀和提交a的提交说明拼接而成，第二行是我们修改过的提交说明，这是我们在执行 git rebase 命令，git 就会自动将提交a提交说明替换为我们修改过的提交说明，生成新的提交a’，然后自动将提交B和C rebase 到a’上去，这样我们就完成了提交说明的修改。
