英文出處：Jake Benilov
譯文來(lái)自：伯樂(lè)在線
我的日常工作和開(kāi)源工作經(jīng)常要用到 git 和 GitHub ，所以我發(fā)現(xiàn)了有一些我經(jīng)常用到的實(shí)用模式。

下文中我會(huì)把 pull 請(qǐng)求（pull request）簡(jiǎn)寫(xiě)成PR。

1. 剝離的PR

我什么時(shí)候用？

• 工作在特性開(kāi)發(fā)分支
• 發(fā)現(xiàn)不好的代碼想要馬上就地修正，但是和我正在做的特性無(wú)關(guān)（例如一個(gè)小bug，或者哪里不一致，或者有違背代碼規(guī)范）

我該做什么？

• 暫停當(dāng)前的進(jìn)度（通過(guò)提交commit或者暫存stash）
• 檢出master分支
• 新建分支
• 修正代碼，提交
• 切換回特性開(kāi)發(fā)分支，繼續(xù)工作
• 等特性開(kāi)發(fā)分支合并（merge）到master分支后，再變基（rebase）到前面新建的分支上

這個(gè)既滿足想要快速修正無(wú)關(guān)問(wèn)題的愿望，又能保持特征開(kāi)發(fā)分支的清晰明了，讓評(píng)審變得更容易。
2. 樂(lè)觀的分支

我什么時(shí)候用？

• 有一個(gè)暫不能合并（例如持續(xù)集成構(gòu)建失敗，代碼評(píng)審者很忙等原因）的分支（分支A）
• 我需要基于分支A的代碼做另一個(gè)改動(dòng)

我該做什么？

• 在分支A上創(chuàng)建一個(gè)新的分支（分支B）
• 等分支A合并到master分支后，把分支B變基到master分支，并解決產(chǎn)生的任何沖突
• 這樣在分支A上對(duì)bug的修正都變基到分支B上了
• 這種處理有沖突的風(fēng)險(xiǎn)，如果在分支A上做的改動(dòng)特別大。但是這個(gè)樂(lè)觀的策略95%的情況都工作良好。

3. 機(jī)智的PR

我什么時(shí)候用？

• 假設(shè)我做的修改事實(shí)上不需要評(píng)審
• 我還是需要我的隊(duì)友知道這件事

我該做什么？

• 在分支上做修改
• 報(bào)一個(gè)PR
• 自己迅速合并這個(gè)PR

這個(gè)方法不會(huì)阻礙我的繼續(xù)，但是GitHub還是會(huì)通過(guò)郵件通知我的隊(duì)友這個(gè)PR。因此大家覺(jué)得有異議也都可以評(píng)論這個(gè)修改。

4. 偷偷摸摸的提交

我什么時(shí)候用？

• 代碼評(píng)審過(guò)了，并且合并到了master
• 我需要做一個(gè)小改動(dòng)（例如復(fù)制改動(dòng)，或者bug修正），但是沒(méi)必要通知?jiǎng)e人

我該做什么？

• 只要把新的提交push到master

5. the roger roger 評(píng)論

我什么時(shí)候用？

• 從分支的代碼評(píng)審那里收到了可操作的回饋
• 已經(jīng)基于回饋?zhàn)龊昧讼鄳?yīng)的修改

我該做什么？

• * 評(píng)論包含了該修改提交的引用的PR
• * GitHub會(huì)聰明地在差異鏈接處增加引用的次數(shù)，這樣我的同事：
• → 得到修改的郵件通知
• → 簡(jiǎn)單地點(diǎn)擊提交差異鏈接
• → 知道他們可以繼續(xù)代碼評(píng)審了

6. 慢慢爬的提交

我什么時(shí)候用？

• 發(fā)現(xiàn)自己引入了一個(gè)小小的格式化的bug（例如不必要的空格，文件最后沒(méi)有換行等），或者
• 某邏輯代碼修改實(shí)際上屬于前一個(gè)提交， 或者
• 代碼不可提交（例如某些測(cè)試未成功）但是我還是想要回退到這個(gè)狀態(tài)，這樣我可以安全地測(cè)試

我該怎么做？

• 前兩種情況，我會(huì)補(bǔ)救amend前一次提交
• 第三種情況，我有一個(gè)正在開(kāi)發(fā)的（爬行的）提交，我漸進(jìn)地進(jìn)行補(bǔ)救（或者如果實(shí)驗(yàn)失敗那就回退）直到我的代碼可以真正提交了。

7. 強(qiáng)制修改的分支

我什么時(shí)候用？

• 我需要補(bǔ)救一個(gè)遠(yuǎn)端功能開(kāi)發(fā)分支，例如提交信息里的說(shuō)明非常糟糕

我該做什么？

• 在本地補(bǔ)救提交
• 把該功能開(kāi)發(fā)分支強(qiáng)制推送到遠(yuǎn)端的版本庫(kù)
• 強(qiáng)制推送到遠(yuǎn)端分支應(yīng)該是 git 的一個(gè)禁忌，但是我的經(jīng)驗(yàn)是這樣處理很少有問(wèn)題（只要它是普通分支，不是master就行）。GitHub 能很好地處理強(qiáng)制推送到PR分支，例如不會(huì)丟失前一次的提交的評(píng)論。

8. 重新格式化剝離

我什么時(shí)候用？

• 我想修改同時(shí)格式化代碼

我該做什么？

• 在master上做一個(gè)僅包含重新格式化部分的提交
• 把我分支變基到master
• 這種方法，讓分支的差異在代碼評(píng)審者眼里變得更加清晰明了，因?yàn)樗话袷交?/li>

9. 原型PR
我什么時(shí)候用？

• 想要讓我的點(diǎn)子在寫(xiě)大量實(shí)現(xiàn)代碼前得到大家的反饋

我該做什么？

• 在某個(gè)分支上做點(diǎn)整理
• 為此報(bào)一個(gè)PR，目的不是要發(fā)布最終代碼，而是作為大家討論的出發(fā)點(diǎn)
• 當(dāng)達(dá)成一致開(kāi)始下一步時(shí)關(guān)閉該P(yáng)R（并且刪除分支）
• 新建另外一個(gè)分支和PR，這次好好寫(xiě)代碼

我以前習(xí)慣于當(dāng)代碼完成時(shí)應(yīng)該報(bào)一個(gè)PR。現(xiàn)在我真正領(lǐng)悟到了為什么“pull request是一個(gè)開(kāi)始討論的好辦法” —— GitHub的圍繞PR的功能（例如內(nèi)聯(lián)評(píng)論、回復(fù)、通知和比較差異）對(duì)于促進(jìn)代碼和設(shè)計(jì)討論堪稱卓越，還可以防止開(kāi)發(fā)者偏離正題太遠(yuǎn)，跑到死胡同。