一些实用的GitHub模式_最新动态_新闻资讯_程序员俱乐部

　　英文原文：Useful GitHub patterns 译者：deepfish 译文：链接

　　我的本职工作和开源工作常涉及到使用 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 的功能（例如内联评论、回复、通知和比较差异）对于促进代码和设计讨论堪称卓越，还可以防止开发者偏离正题太远，跑到死胡同。