做一个有品位的程序员

“能够写出漂亮代码的程序员就是有品味的程序员么？”

“还不够。品味来自于每一个细节，有品位的程序员会把每一次提交做小、做对、做好，尽量做到整个开发的过程的无可挑剔，这样才够逼格，才可以称为有品位。”

$ git log --no-merges --pretty="" --shortstat
2 files changed, 25 insertions(+), 4 deletions(-) 1 file changed, 4 insertions(+), 12 deletions(-) 2 files changed, 30 insertions(+), 1 deletion(-) 3 files changed, 15 insertions(+), 5 deletions(-) ... ...

那么如何将提交拆分为若干个小提交呢？

拆分当前提交（松耦合）

先以拆分最新提交为例，可以如下操作： 将当前提交撤销，重置到上一次提交。撤销提交的改动保留在工作区中。

$ git reset HEAD^

通过补丁块拣选方式选择要提交的修改。Git 会逐一显示工作区更改，如果确认此处改动要提交，输入“y”。

$ git add -p 

此处显示补丁块（hunk），用户根据提示信息，输入自己的选择：输入 y，此块儿补丁要提交； 输入 n，此块儿补丁不提交；输入 s，尝试将此块儿补丁细分； 输入 e，打开编辑器对此块儿补丁进行再次编辑。（注：HEAD@{1} 是上一步 git reset 操作前的HEAD提交，具体含义查看 git reflog 帮助）

$ git commit -e -C HEAD@{1}

对于工作区其余的修改进行提交，完成一个提交拆分为两个的操作。 （注：git add -u 是将已经建立跟踪的文件的修改添加到提交队列/index中。如果要把工作区中所有文件添加到index，执行git add -A）

$ git add -u
$ git commit 

拆分当前提交（紧耦合）

如果要拆分的提交，不同的实现逻辑耦合在一起，难以通过补丁块拣选（git add -p）的方式修改提交，怎么办？这时可以 直接编辑文件，删除要剥离出此次提交的修改，然后执行下面命令更新当前提交：

 $ git commit --amend 

接下来执行下面的命令，还原出原有的文件修改，然后再次提交。如下：

 $ git checkout HEAD@{1} 
 $ git commit

同样完成了一个提交拆分为两个提交的操作。 拆分历史某个提交

如果要拆分的是历史提交（如提交 54321），而非当前提交，则可以执行交互式变基（git rebase -i），如下：

$ git rebase -i 54321^ 

Git 会自动将参与变基的提交写在一个动作文件中，还会自动打开编辑器（比如 vi 编辑器）。

将要拆分的提交 54321 前面的关键字 pick 修改为 edit，保存并退出。变基操作随即开始执行。 首先会在提交 54321 处停下来，这时要拆分的提交成为了当前提交，参照前面“拆分当前提交”的方法对提交 54321 进行拆分。拆分结束再执行 :

$ git rebase --continue

完成整个变基操作。 提交做对 “好的文章不是写出来的，而是改出来的。” 代码提交也是如此。 程序员写完代码，往往迫不及待地敲下：git commit，然后发现提交中少了一个文件，或者提交了多余的文件，或者发现提交中包含错误无法编译，或者提交说明中出现了错别字等等。 Git 提供了一个修改当前提交的快捷命令：git commit –amend，相信很多人都用过，不再赘述。

如果你发现错误出现在上一个提交或其他历史提交中怎么办呢？我有一个小窍门，在《Git权威指南》里我没有写到哦。 比如发现历史提交 54321 中包含错误，直接在当前工作区中针对这个错误进行修改，然后执行下面命令:

$ git commit --fixup 54321 

你会发现使用了 –fixup 参数的提交命令，不再询问你提交说明怎么写，而是直接把错误提交 54321 的提交说明的第一行拿来，在前面增加一个前缀“fixup!”，如下：

fixup! 原提交说明 

如果一次没有改对，还可以再接着改，甚至你还可以针对这个修正提交进行 fixup，产生如下格式的提交说明：

fixup! fixup! 原提交说明 

当开发工作完成后，待推送/评审的提交中出现大量的包含“fixup!”前缀的提交该如何处理呢？ 如果你执行过一次下面的命令，即针对错误提交 54321 及其后面所有提交执行交互式变基（注意其中的 –autosquash 参数），你就会惊叹 Git 设计的是这么巧妙：

$ git rebase -i --autosquash 54321^

交互式变基弹出的编辑器内自动对提交进行排序，将提交 54321 连同它的所有修正提交压缩为一个提交。 对于“提交做对”，很多开源项目还通过单元测试用例提供保障。对于这样的项目，在提交代码时往往要求提供相应的测试用例。

Git 项目本身就对测试用例有着很高的要求，其测试框架也非常有意思。我曾经针对Git的单元测试框架写过博客，参见： 复用 git.git 测试框架。 提交做好 仅仅做到提交做小、提交做对，往往还不够，还要通过撰写详细的提交说明让项目维护者（maintainer）信服，这样才能够让提交尽快通过评审合入项目仓库中。

Git 对于提交说明的格式有着如下约定俗成的规定，不遵守这个约定的提交说明都不合格：

提交主题

提交说明第一行是提交主题，是整个提交的概要性描述。 提交主题要用英文，不能出现中文，因为某些命令（如 git format-patch）会出现问题。

提交主题中可以添加前缀（例如本例中的 receive-pack 是此次修改的模块名称）。

提交主题（即提交说明的第一行）尽量保持在50字节以内（Gerrit 的commit_log检查插件似乎有着稍微宽泛一些的要求）。 这是因为对于像 Linux、Git 这样的开源项目，是以邮件列表作为代码评审的平台，提交主题要作为邮件的标题，而邮件标题本身有长度上的限制。 既然提到提交主题作为邮件标题，还要提及一点，你见过在邮件标题的结尾写句号么？所以提说明的第一句结尾不要加标点符号。

提交主题后的空行 必须要在提交说明的第一行和后续的提交说明中间留一个空行！如果没有这个空行，很多 Git 客户端会将连续几行的提交说明合在一起作为提交描述。这样显然太糟了。

提交说明主体

要让评审者对提交信服，要为将来的代码维护者留下线索，提交说明要回答如下问题：What——要解决什么问题？什么情况下会发生？ How——怎么样解决这个问题。Why——为什么这样解决是合理的，比其他解决方法更好。

50/72原则

前面说过提交主题50个字符为限，提交说明的主体的每一行则以72字符为限，超过则断行。 因为 GitHub 在显示提交说明时支持 Markdown 语法， 所以作为一个有品位的程序员学些 Markdown 的语法，让你的提交说明的可读性变得更强吧。我总结过一个 Markdown 和其他文本标记语言的语法说明，可供参考：轻量级标记语言语法参考。

签名区

在提交说明最后是签名区。签名区可以看出这个提交的参与者、评审记录等等。