一个用于提升
github pull request & code review的 chrome 插件
特性
关于创建pull request
当你给某个 github 仓库 push 了一个新分支之后，应该会在该仓库的首页看见下面这种页面：
然后点击"Compare & pull request"，就会跳转到创建pull request的页面，并且你刚 push 的这个分支会直接和master分支比较。
酷😝。但如果你并不想合并到master分支呢？假设我们从master创建了一个staging分支，它被用于测试环境。而日常的开发和测试都是在基于staging所创建的分支 -- 即master作为生产环境的分支🤔。
既然我们的分支基于staging创建，那它或许和master有很大的差别。既然如此，如果点击"Compare & pull request"之后直接和master毕竟的话，那简直太糟糕了 -- 你的页面可能会卡死、耗费很长很长的时间来加载资源🙄。而且只有在加载完资源之后才可以切换base分支，然后再比较一次😞。
而利用这个插件，我会偷偷改变你要比较的分支。当你点击"Compare & pull request"按钮之后，会跳转到一个仅仅和自身比较的页面，那样的话几乎可以在瞬间完成页面加载。
我觉得吧，与其初始化的时候加载了错误的compare，还不如不提供默认选择，让我自己来选择pull request的base分支。
关于code review的用户体验
假设你被指定参与一个code review，而那个code review又碰巧很长。直接merge了呗？别开玩笑了，那怎么可能。
所以当你认认真真的看完了pull request file compare，想要发表点评论，或者合并分支的时候，不得不再将页面滚动到最顶部，点击navbar上的按钮。
这个差距可以为这一步提供一点便利。针对pull request页面，它会生成一个位于页面右下角的action button浮动按钮，并提供"回到顶部"、"链接到 conversation 页面"、"链接到 commits 页面"、"链接到 files 页面"几个功能😝。
那几个按钮和navbar的作用一毛一样：
其实吧，我上面的那些都仅仅是"治标不治本"而已。因为对一个正确、健康的开发流程而言，本身就不提倡太长的code review -- 有那么多改变的代码要看，难以保障 review 质量。而对于插件"改变 pull request 比较的分支"这个功能，本身 github 的git flow所提倡的就是：使用master分支作为base分支，开发分支应该基于master分支创建。不过因为自己习惯的原因（公司开发流程的git flow和gitlab work flow），才会去创建这个 chrome 插件，也希望能帮助到大家吧。
author
License
MIT
