这是一个专门讨论 idea 的地方。
每个人的时间，资源是有限的，有的时候你或许能够想到很多 idea，但是由于现实的限制，却并不是所有的 idea 都能够成为现实。
那这个时候，不妨可以把那些 idea 分享出来，启发别人。
每个人的时间，资源是有限的，有的时候你或许能够想到很多 idea，但是由于现实的限制，却并不是所有的 idea 都能够成为现实。
那这个时候，不妨可以把那些 idea 分享出来，启发别人。
这是一个创建于 428 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近发现 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 部熟悉？如果我做一个这样的插件，或者是服务。大家会不会有兴趣去用呢？ 当然部署便捷性，以及安全性也是要考虑的。不过我想就先从可行性的角度来咨询一下。
 |
1
gitrebase 2023-10-18 08:17:09 +08:00
看了描述，要解决的问题就是 [当使用 git commit --amend 时，没法查看两次 commit 之间的差异] 吧
那感觉像是伪需求，一般没必要使用 --amend ，就正常 commit 就行，如果最后感觉 commit 次数太多了，就在被 merge 之前自己 rebase 一下就行，或者直接 squash merge 就行 |
 |
2
robinshen 2023-10-18 08:50:08 +08:00
这个也是当初做 OneDev ( https://github.com/theonedev/onedev) 的考虑之一，可以显示自上次 review 以来的所有改动，对 amend/rebase 也正常工作。
后来 github 也加入了 “show changes since last review” 功能， 不过对于 amend/rebase 不支持。 |
 |
3
assassins1234567 2023-10-18 09:51:30 +08:00 via iPhone
gerrit 是不是可以满足你的需求。
|
 |
4
wu00 2023-10-18 10:11:37 +08:00
1# 说得对
感觉更多的是规范问题，已推到远端的 commit 都能被--amend ，那各种--force 你又如何应对 |
|
5
robinshen 2023-10-18 10:41:42 +08:00
如果是个人开发分枝，不与他人共享的话，amend/rebase 不会带来什么负面影响。对于公共分枝可依设置规则来拒绝 force push
|
 |
6
caixiangyu17 OP @gitrebase 恩感觉有个规范可以解决大多数的问题，只是没那么清晰。比如 review 留言之后，我有提交了一个 commit ，然后发现有东西落下了，然后就有提交了若干个，这时对于 reviewer 来说，有多了若干个 commit ，则看起来又麻烦了，当然也有办法解决，把最新几个 commit 再 squash 一下，变成一个。不过整体来说略微麻烦，而且新手操作需要又一个标准流程。所以也是我考虑做这种一键快速的方式。
|
|
7
caixiangyu17 OP @robinshen
#2 哇这个项目看着真不错。很高级 #5 我觉得所有人都不应该有 master 权限，只能靠 pr 合并，其他 branch ，每个人都是自己的，想怎么折腾随意。最后 pr 之前，搞好了就行。而且 pr 也应该有很多 review 才能被允许 merge ，包括 reviewer approve ，dry run ，unit test 等。 |
|
8
caixiangyu17 OP @wu00 如上条回复所说哈~
|
|
9
caixiangyu17 OP @assassins1234567 这个看起来和我想做的有点像呢，不知道具体的操作流程是什么，不过感觉类似。
|
Select Language