我们使用内部工具，创建 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 部熟悉？如果我做一个这样的插件，或者是服务。大家会不会有兴趣去用呢？
当然部署便捷性，以及安全性也是要考虑的。不过我想就先从可行性的角度来咨询一下。
