一些实用的GitHub模式
我的本职工作和开源工作常涉及到使用 git 和 GitHub 。我发现有一些实用的模式我会固定使用。
下文中我会把 pull 请求（pull request）简写成 PR。
1. 剥离的 PR
我什么时候用？
- 工作在特性开发分支
- 发现不好的代码想要马上就地修正，但是和我正在做的特性无关（例如一个小 bug，或者哪里不一致，或者有违背代码规范）
我该做什么？
- 暂停当前的进度（通过提交 commit 或者暂存 stash）
- 检出 master 分支
- 新建分支
- 修正代码，提交
- 切换回特性开发分支，继续工作
- 等特性开发分支合并（merge）到 master 分支后，再变基（rebase）到前面新建的分支上
这个既满足想要快速修正无关问题的愿望，又能保持特征开发分支的清晰明了，让评审变得更容易。
2. 乐观的分支
我什么时候用？
- 有一个暂不能合并（例如持续集成构建失败，代码评审者很忙等原因）的分支（分支A）
- 我需要基于分支A的代码做另一个改动
我该做什么？
- 在分支A上创建一个新的分支（分支B）
- 等分支A合并到 master 分支后，把分支B变基到 master 分支，并解决产生的任何冲突
- 这样在分支A上对 bug 的修正都变基到分支B上了
这种处理有冲突的风险，如果在分支A上做的改动特别大。但是这个乐观的策略 95% 的情况都工作良好。
3. 机智的 PR
我什么时候用？
- 假设我做的修改事实上不需要评审
- 我还是需要我的队友知道这件事
我该做什么？
- 在分支上做修改
- 报一个 PR
- 自己迅速合并这个 PR
这个方法不会阻碍我的继续，但是 GitHub 还是会通过邮件通知我的队友这个 PR。因此大家觉得有异议也都可以评论这个修改。
4. 偷偷摸摸的提交
我什么时候用？
- 代码评审过了，并且合并到了 master
- 我需要做一个小改动（例如复制改动，或者 bug 修正），但是没必要通知别人
我该做什么？
- 只要把新的提交 push 到 master
5. the roger roger 评论
我什么时候用？
- 从分支的代码评审那里收到了可操作的回馈
- 已经基于回馈做好了相应的修改
我该做什么？
* 评论包含了该修改提交的引用的 PR
* GitHub 会聪明地在差异链接处增加引用的次数，这样我的同事：
→ 得到修改的邮件通知
→ 简单地点击提交差异链接
→ 知道他们可以继续代码评审了
6. 慢慢爬的提交
我什么时候用？
- 发现自己引入了一个小小的格式化的 bug（例如不必要的空格，文件最后没有换行等），或者
- 某逻辑代码修改实际上属于前一个提交， 或者
- 代码不可提交（例如某些测试未成功）但是我还是想要回退到这个状态，这样我可以安全地测试
我该怎么做？
- 前两种情况，我会补救 amend 前一次提交
- 第三种情况，我有一个正在开发的（爬行的）提交，我渐进地进行补救（或者如果实验失败那就回退）直到我的代码可以真正提交了。
7. 强制修改的分支
我什么时候用？
- 我需要补救一个远端功能开发分支，例如提交信息里的说明非常糟糕
我该做什么？
- 在本地补救提交
- 把该功能开发分支强制推送到远端的版本库
强制推送到远端分支应该是 git 的一个禁忌，但是我的经验是这样处理很少有问题（只要它是普通分支，不是 master 就行）。GitHub 能很好地处理强制推送到 PR 分支，例如不会丢失前一次的提交的评论。
8. 重新格式化剥离
我什么时候用？
- 我想修改同时格式化代码
我该做什么？
- 在 master 上做一个仅包含重新格式化部分的提交
- 把我分支变基到 master
这种方法，让分支的差异在代码评审者眼里变得更加清晰明了，因为它不包含格式化
9. 原型 PR
我什么时候用？
- 想要让我的点子在写大量实现代码前得到大家的反馈
我该做什么？
- 在某个分支上做点整理
- 为此报一个 PR，目的不是要发布最终代码，而是作为大家讨论的出发点
- 当达成一致开始下一步时关闭该 PR（并且删除分支）
- 新建另外一个分支和 PR，这次好好写代码
我以前习惯于当代码完成时应该报一个 PR。现在我真正领悟到了为什么“pull request 是一个开始讨论的好办法” —— GitHub 的围绕 PR 的功能（例如内联评论、回复、通知和比较差异）对于促进代码和设计讨论堪称卓越，还可以防止开发者偏离正题太远，跑到死胡同。