——問：“能夠?qū)懗稣_代碼的程序員就是有品味的程序員么？”

——答：“還不夠。品味來自于每一個(gè)細(xì)節(jié)，有品位的程序員會(huì)把每一次提交做小、做對(duì)、做好，讓人看懂，且無可挑剔，這樣才夠逼格，才可以稱為有品位。”參加百湖培訓(xùn)之前，華為的一個(gè)小伙伴發(fā)現(xiàn)了Git實(shí)現(xiàn)的一個(gè) Bug，給我發(fā)了一個(gè) Pull Request，讓我審核以及代發(fā)到 Git 社區(qū)。不用看代碼，只看 Pull Request 的說明，我相信大家就可以聞到這是一個(gè)好代碼，寫代碼的人有品味。

參見：
https://github.com/jiangxin/git/pull/25

熟練使用 Git，會(huì)讓程序員更有品味。

提交做小

寫小提交就是將問題解耦：“Do one thing and do it well”。

開源項(xiàng)目的提交通常都很小，每個(gè)提交只修改一個(gè)到幾個(gè)文件，每次只修改幾行到幾十行。找一個(gè)你熟悉的開源項(xiàng)目，在倉庫中執(zhí)行下面的命令，可以很容易地統(tǒng)計(jì)出來每個(gè)提交的修改量。

$ 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(-)

然而事實(shí)上，我看到的很多項(xiàng)目都沒有做到“提交做小”。一個(gè)提交動(dòng)輒修改成百上千的文件，涉及成千上萬行的源代碼。試問：這樣的提交能 Show 出來給人看么？可能在開發(fā)過程中，程序員一旦進(jìn)入狀態(tài)，往往才思如泉涌，不經(jīng)意間就寫出一個(gè)大提交。比如，我有一次向 Git 貢獻(xiàn)代碼時(shí)，提交還不算太大，就被 Git 的維護(hù)者 Junio 吐槽，要我拆分提交，便于評(píng)審：

TODO(鏈接尋找中。。。)

那么，如何將提交拆分為若干個(gè)小提交呢？

拆分當(dāng)前提交（松耦合）

先以拆分最新的提交為例，可以如下操作：1. 將當(dāng)前提交撤銷，重置到上一次提交。撤銷提交的改動(dòng)保留在工作區(qū)中。

    $ git reset HEAD^

2. 通過補(bǔ)丁塊揀選方式選擇要提交的修改。Git 會(huì)逐一顯示工作區(qū)更改，如果確認(rèn)此處改動(dòng)要提交，輸入“y“。

    $ git add -p

3. 以撤銷提交的提交說明為藍(lán)本，撰寫新的提交。

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

4. 對(duì)于工作區(qū)其余的修改進(jìn)行提交，完成一個(gè)提交拆分為兩個(gè)的操作。

    $ git add -u
    $ git commit

拆分當(dāng)前提交（緊耦合）

如果要拆分的提交，不同的實(shí)現(xiàn)邏輯耦合在一起，難以通過補(bǔ)丁塊揀選（git add -p）的方式修改提交，怎么辦？這時(shí)可以直接編輯文件，刪除要?jiǎng)冸x出此次提交的修改，然后執(zhí)行：

$ git commit --amend

然后執(zhí)行下面的命令，還原原有的文件修改，然后再提交。如下：

$ git checkout HEAD@{1} -- .
$ git commit

同樣完成了一個(gè)提交拆分為兩個(gè)提交的操作。

拆分歷史某個(gè)提交

如果要拆分的是歷史提交（如提交 54321），而非當(dāng)前提交，則可以執(zhí)行交互式變基（git rebase -i），如下：

$ git rebase -i 54321^

Git 會(huì)自動(dòng)將參與變基的提交寫在一個(gè)動(dòng)作文件中，還會(huì)自動(dòng)打開編輯器（比如 vi 編輯器）。在編輯器中顯示內(nèi)容示例如下：

pick 54321 要拆分的提交
pick ...   其他參與變基的提交

將要拆分的提交 54321 前面的關(guān)鍵字 pick 修改為 edit，保存并退出。變基操作隨即開始執(zhí)行。

首先會(huì)在提交 54321 處停下來，這時(shí)要拆分的提交成為了當(dāng)前提交，參照前面“拆分當(dāng)前提交”的方法對(duì)提交 54321 進(jìn)行拆分。拆分結(jié)束再執(zhí)行g(shù)it rebase --continue 完成整個(gè)變基操作。

提交做對(duì)

“好的文章不是寫出來的，而是改出來的。”代碼提交也是如此。程序員寫完代碼，往往迫不及待地敲下：git commit，然后發(fā)現(xiàn)提交中少了一個(gè)文件，或者提交了多余的文件，或者發(fā)現(xiàn)提交中包含錯(cuò)誤無法編譯，或者提交說明中出現(xiàn)了錯(cuò)別字。Git 提供了一個(gè)修改當(dāng)前提交的快捷命令：git commit --amend，相信很多人都用過，不再贅述。如果你發(fā)現(xiàn)錯(cuò)誤出現(xiàn)在上一個(gè)提交或其他歷史提交中怎么辦呢？我有一個(gè)小竅門：比如發(fā)現(xiàn)歷史提交 54321 中包含錯(cuò)誤，直接在當(dāng)前工作區(qū)中針對(duì)這個(gè)錯(cuò)誤進(jìn)行修改，然后執(zhí)行下面命令。

git commit --fixup 54321

你會(huì)發(fā)現(xiàn)使用了 --fixup 參數(shù)的提交命令，不再詢問你提交說明怎么寫，而是直接把錯(cuò)誤提交 54321的提交說明的第一行拿來，在前面增加一個(gè)前綴“fixup!”，如下：

fixup! 原提交說明

如果一次沒有改對(duì)，還可以再接著改，甚至你還可以針對(duì)這個(gè)修正提交進(jìn)行 fixup，產(chǎn)生如下格式的提交說明：

fixup! fixup! 原提交說明

當(dāng)開發(fā)工作完成后，待推送/評(píng)審的提交中出現(xiàn)大量的包含“fixup!”前綴的提交該如何處理呢？如果你執(zhí)行過一次下面的命令，即針對(duì)錯(cuò)誤提交 54321 及其后面所有提交執(zhí)行交互式變基（注意其中的 --autosquash 參數(shù)），你就會(huì)驚嘆 Git 設(shè)計(jì)的是這么巧妙：

$ git rebase -i --autosquash 54321^

交互式變基彈出的編輯器內(nèi)自動(dòng)對(duì)提交進(jìn)行排序，將提交 54321 連同它的所有修正提交壓縮為一個(gè)提交。Tips：執(zhí)行 git config --global rebase.autoSquash true 命令設(shè)置配置變量 rebase.autosquash，執(zhí)行 git rebase -i 命令會(huì)自動(dòng)帶上 --autosquash 參數(shù)。對(duì)于“提交做對(duì)”，很多開源項(xiàng)目還通過單元測試用例提供保障。對(duì)于這樣的項(xiàng)目，在提交代碼時(shí)往往要求提供相應(yīng)的測試用例。Git 項(xiàng)目本身就對(duì)測試用例有著很高的要求，其測試框架也非常有意思。我曾經(jīng)針對(duì)Git的單元測試框架寫過博客，參見：復(fù)用 git.git 測試框架。Tips：Git 的測試框架代碼經(jīng)過重構(gòu)，已經(jīng)成為一個(gè)單獨(dú)的項(xiàng)目：Sharness，更加方便重用了。我曾經(jīng)的幾個(gè)項(xiàng)目都使用了這個(gè)框架寫用例，后面有時(shí)間專題介紹。

提交做好

僅僅做到提交做小、提交做對(duì)，往往還不夠，還要通過撰寫詳細(xì)的提交說明讓評(píng)審者信服，這樣才能夠讓提交盡快通過評(píng)審合入項(xiàng)目倉庫中。例如今年7月份在華為公司內(nèi)部的 Git 服務(wù)器上發(fā)現(xiàn)一個(gè)異常，最終將問題定位到 Git 工具本身。整個(gè)代碼改動(dòng)只有區(qū)區(qū)一行：

提交：receive-pack: crash when checking with non-exist HEAD

你能猜到提交說明寫了多少么？寫了20多行！

receive-pack: crash when checking with non-exist HEAD

If HEAD of a repository points to a conflict reference, such as:

* There exist a reference named 'refs/heads/jx/feature1', but HEAD
  points to 'refs/heads/jx', or

* There exist a reference named 'refs/heads/feature', but HEAD points
  to 'refs/heads/feature/bad'.

When we push to delete a reference for this repo, such as:

        git push /path/to/bad-head-repo.git :some/good/reference

The git-receive-pack process will crash.

This is because if HEAD points to a conflict reference, the function
`resolve_refdup("HEAD", ...)` does not return a valid reference name,
but a null buffer.  Later matching the delete reference against the null
buffer will cause git-receive-pack crash.

Signed-off-by: Jiang Xin <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

Git 對(duì)于提交說明的格式有著如下約定俗成的規(guī)定

提交主題

提交說明第一行是提交主題，是整個(gè)提交的概要性描述。可以在提交主題中添加所更改的模塊名稱作為前綴（如：receive-pack:）。提交主題（即提交說明的第一行）盡量保持在50字節(jié)以內(nèi)（Gerrit 的commit_log檢查插件似乎有著稍微寬泛一些的要求）。這是因?yàn)閷?duì)于像 linux、Git 這樣的開源項(xiàng)目，是以郵件列表作為代碼評(píng)審的平臺(tái)，提交主題要作為郵件的標(biāo)題，而郵件標(biāo)題本身有長度上的限制。

提交主題后的空行

必須要在提交說明的第一行和后續(xù)的提交說明中間留一個(gè)空行！如果沒有這個(gè)空行，很多 Git 客戶端會(huì)將連續(xù)幾行的提交說明合在一起作為提交描述。這樣顯然太糟了。

提交說明主體

提交主題之外的提交說明也有長度的限制，最好以72字節(jié)為限，超過則斷行。因?yàn)?GitHub 在顯示提交說明時(shí)支持 Markdown 語法，所以作為一個(gè)有品位的程序員學(xué)些 Markdown 的語法，讓你的提交說明的可讀性變得更強(qiáng)吧。我總結(jié)過一個(gè) Markdown 和其他文本標(biāo)記語言的語法說明，可供參考：· 輕量級(jí)標(biāo)記語言語法參考· 簽名區(qū)

在提交說明最后是簽名區(qū)，簽名區(qū)可以看出這個(gè)提交的參與者、評(píng)審記錄等等。

正確的代碼評(píng)審方式

代碼評(píng)審要關(guān)注過程，要由遠(yuǎn)及近地看每一個(gè)提交，不能只看前后兩個(gè)版本之間的差異。

有人認(rèn)為這樣的代碼評(píng)審多此一舉，認(rèn)為這樣可能是浪費(fèi)時(shí)間。有的時(shí)候，給一個(gè)提交不規(guī)范的開發(fā)者做代碼評(píng)審，的確頭疼又浪費(fèi)時(shí)間：看到一個(gè)提交中的代碼問題，花了幾分鐘寫評(píng)論，然后發(fā)現(xiàn)下一個(gè)提交中這個(gè)問題被修正（fixup）了。這樣的神操作，讓人無奈。如果評(píng)審的代碼來自提交規(guī)范的開發(fā)者，逐提交評(píng)審可能是一件賞心悅目的事情：

一些重構(gòu)操作（修改方法名、變量名；代碼塊在文件之間移動(dòng)；文件改名），單獨(dú)作為一個(gè)提交，評(píng)審起來工作量很小，對(duì)后續(xù)提交評(píng)審的干擾也小。
一個(gè)提交干一件事，由遠(yuǎn)及近的評(píng)審的過程，能夠看到開發(fā)者工作的邏輯性和思路。
因?yàn)橛?nbsp;git rebase --interactive 等神器，不會(huì)出現(xiàn)后一個(gè)提交修改前一個(gè)提交中錯(cuò)誤的實(shí)現(xiàn)，讓每個(gè)提交把事情一次做對(duì)。
因?yàn)槊總€(gè)提交能夠把事情一次做對(duì)，在代碼調(diào)試過程中 git bisect 神器就可以派上用場。
提交 cherry-pick 或者 rebase 到新的基線（如定制開發(fā)型項(xiàng)目中，遷移到上游新的版本），工作量小。

最后，讓我們一起學(xué)習(xí)成為一名有品位的程序員吧。依靠你對(duì)代碼的品味，高質(zhì)量嚴(yán)要求，守護(hù)好你的項(xiàng)目。

出品：凌云時(shí)刻作者：知憂