- 主题:git大家一般都是怎么改code review给的意见的？
rebase了只能 -f
【 在 PaoloMaldini 的大作中提到: 】
: 你不写-f一样能push上去啊
--
FROM 220.200.25.*
github review 这个过程其实是不大喜欢 force push 的
因为不容易看到上次 review 之后干了啥
必须自己手工去选 commit
【 在 eGust 的大作中提到: 】
: 我个人倾向 rebase，这样 branch 没有 merge commit 比较干净。不过一般情况下，就算是落后了很多，但只要 PR 没有 conflicts，我一般是不会麻烦的
: 另外，自己的 branch 没啥不礼貌的，我又没跑过去把别人的 force 掉。不过 -f 的确有些危险，我就干过把 commit 搞丢了的情况，后来还是找别人 push -f 找回来的
--
FROM 220.200.25.*
PR之前自己的分支随便rebase
【 在 eGust 的大作中提到: 】
: 还是分干嘛，我一般情况下是用 rebase 解决 conflicts，少了一个 merge commit 完成同样的功能。逻辑上，因为代码逻辑和功能并没有实质的变化，每个 commit message 描述的变化还是相同的，所以别人并不需要知道干了啥。如果是用 merge 解决 conflicts，同样其他人也还是不知
: 道具体干嘛了，本来 merge commits 也都是次要的。
: 如果是根据 code review 更新代码，那肯定还是要有新的 commit 的，因为代码的逻辑和功能已经发生了改变。如果 commit --amend 然后 push -f，那的确不太好
说的就是这个问题
给 reviewer 带来了不方便
rebase 完加新 commit 这种还能忍，至少可以手工指定看新 commit
解决 comment 的时候在原来的 commit 直接 amend 这就太过分了……
--
FROM 220.200.25.*