想做一个 pull request 的工具，问问大家是不是伪需求？

最近发现 github ，gitfarm 或者 bitbucket 都没有 pull request 的版本。想问问大家的工作流程是怎样的。

我们使用内部工具，创建 pr 的流程和这些主流的 git 平台不太一样，所以描述一下，看看是不是可以作为一个增强体验的方式来实现一下。

这是 github 的流程

当一个 pr 被创建了，就会有人 review ，然后发布一些评论。那么我根据这个评论就回去修改的我的代码，然后再次提交。这时候 pr 就被更新了。然后我去问提意见的人重新 review ，但是这时候，reviewer 并不能看见我改了什么，而是整体和 master 的区别。所以这时候如果 pr 略微复杂，而修改意见也略微多一些，对于 reviewer 来说，就一些混乱，可能需要在看一遍整体代码。

上面的流程如果是在评论之后我又 commit 了一个新版本的话，还可以查看具体的 commit ，不过如果我用了 amend 来 commit ，则就没有办法看到了。

这是改进流程

改进流程呢就变成，当第一次创建 pr 之后，这个 pr 的版本号是 1 ，状态是 private 。然后 private 的 pr 只有创建者可以查看。然后创建者点击公开，这时把这个版本置成 public 。对于 pr 状态，private 只有创建者能看见，public 则是公开用来 review 的。然后有人在 1 这个版本上面留言（这还有个好处是，不会像 github 上有留言对应的代码不见了）。创建者修改代码，再次提交。提交时候有个逻辑，如果最高版本号是 public ，则创建一个更新的版本，状态为 private 。如果最高版本是 private ，则直接更新。这样当创建者修改好了代码，再公开这个版本。这时则有两个 public 的版本，可以分别产看 1 ，2 ，以及 1-2 区别。这样每次 reviewer 只需要看一下 1-2 的区别，就可以大概了解代码是否按照要求修改了。同理，可以有更多版本。

不知道大家听完觉得这个需求是不是伪需求？是不是已经有什么流程可以解决这个问题，只是我对 github 部熟悉？如果我做一个这样的插件，或者是服务。大家会不会有兴趣去用呢？当然部署便捷性，以及安全性也是要考虑的。不过我想就先从可行性的角度来咨询一下。

caixiangyu17

204 天前

@gitrebase 恩感觉有个规范可以解决大多数的问题，只是没那么清晰。比如 review 留言之后，我有提交了一个 commit ，然后发现有东西落下了，然后就有提交了若干个，这时对于 reviewer 来说，有多了若干个 commit ，则看起来又麻烦了，当然也有办法解决，把最新几个 commit 再 squash 一下，变成一个。不过整体来说略微麻烦，而且新手操作需要又一个标准流程。所以也是我考虑做这种一键快速的方式。