一些實用的GitHub模式
我的本職工作和開源工作常涉及到使用 git 和 GitHub 。我發現有一些實用的模式我會固定使用。
下文中我會把 pull 請求（pull request）簡寫成 PR。
1. 剝離的 PR
我什么時候用？
- 工作在特性開發分支
- 發現不好的代碼想要馬上就地修正，但是和我正在做的特性無關（例如一個小 bug，或者哪里不一致，或者有違背代碼規范） </ul>
- 暫停當前的進度（通過提交 commit 或者暫存 stash）
- 檢出 master 分支
- 新建分支
- 修正代碼，提交
- 切換回特性開發分支，繼續工作
- 等特性開發分支合并（merge）到 master 分支后，再變基（rebase）到前面新建的分支上 </ul>
- 有一個暫不能合并（例如持續集成構建失敗，代碼評審者很忙等原因）的分支（分支A）
- 我需要基于分支A的代碼做另一個改動 </ul>
- 在分支A上創建一個新的分支（分支B）
- 等分支A合并到 master 分支后，把分支B變基到 master 分支，并解決產生的任何沖突
- 這樣在分支A上對 bug 的修正都變基到分支B上了 </ul>
- 假設我做的修改事實上不需要評審
- 我還是需要我的隊友知道這件事 </ul>
- 在分支上做修改
- 報一個 PR
- 自己迅速合并這個 PR </ul>
- 代碼評審過了，并且合并到了 master
- 我需要做一個小改動（例如復制改動，或者 bug 修正），但是沒必要通知別人 </ul>
- 只要把新的提交 push 到 master </ul>
- 從分支的代碼評審那里收到了可操作的回饋
- 已經基于回饋做好了相應的修改 </ul>
- 發現自己引入了一個小小的格式化的 bug（例如不必要的空格，文件最后沒有換行等），或者
- 某邏輯代碼修改實際上屬于前一個提交， 或者
- 代碼不可提交（例如某些測試未成功）但是我還是想要回退到這個狀態，這樣我可以安全地測試 </ul>
- 前兩種情況，我會補救 amend 前一次提交
- 第三種情況，我有一個正在開發的（爬行的）提交，我漸進地進行補救（或者如果實驗失敗那就回退）直到我的代碼可以真正提交了。 </ul>
- 我需要補救一個遠端功能開發分支，例如提交信息里的說明非常糟糕 </ul>
- 在本地補救提交
- 把該功能開發分支強制推送到遠端的版本庫 </ul>
- 我想修改同時格式化代碼 </ul>
- 在 master 上做一個僅包含重新格式化部分的提交
- 把我分支變基到 master </ul>
- 想要讓我的點子在寫大量實現代碼前得到大家的反饋 </ul>
- 在某個分支上做點整理
- 為此報一個 PR，目的不是要發布最終代碼，而是作為大家討論的出發點
- 當達成一致開始下一步時關閉該 PR（并且刪除分支）
- 新建另外一個分支和 PR，這次好好寫代碼 </ul>
我該做什么？
這個既滿足想要快速修正無關問題的愿望，又能保持特征開發分支的清晰明了，讓評審變得更容易。
2. 樂觀的分支
我什么時候用？
我該做什么？
這種處理有沖突的風險，如果在分支A上做的改動特別大。但是這個樂觀的策略 95% 的情況都工作良好。
3. 機智的 PR
我什么時候用？
我該做什么？
這個方法不會阻礙我的繼續，但是 GitHub 還是會通過郵件通知我的隊友這個 PR。因此大家覺得有異議也都可以評論這個修改。
4. 偷偷摸摸的提交
我什么時候用？
我該做什么？
5. the roger roger 評論
我什么時候用？
我該做什么？
* 評論包含了該修改提交的引用的 PR
* GitHub 會聰明地在差異鏈接處增加引用的次數，這樣我的同事：
→ 得到修改的郵件通知
→ 簡單地點擊提交差異鏈接
→ 知道他們可以繼續代碼評審了
6. 慢慢爬的提交
我什么時候用？
我該怎么做？
7. 強制修改的分支
我什么時候用？
我該做什么？
強制推送到遠端分支應該是 git 的一個禁忌，但是我的經驗是這樣處理很少有問題（只要它是普通分支，不是 master 就行）。GitHub 能很好地處理強制推送到 PR 分支，例如不會丟失前一次的提交的評論。
8. 重新格式化剝離
我什么時候用？
我該做什么？
這種方法，讓分支的差異在代碼評審者眼里變得更加清晰明了，因為它不包含格式化
9. 原型 PR
我什么時候用？
我該做什么？
我以前習慣于當代碼完成時應該報一個 PR。現在我真正領悟到了為什么“pull request 是一個開始討論的好辦法” —— GitHub 的圍繞 PR 的功能（例如內聯評論、回復、通知和比較差異）對于促進代碼和設計討論堪稱卓越，還可以防止開發者偏離正題太遠，跑到死胡同。