- 主题:git大家一般都是怎么改code review给的意见的？
我个人倾向 rebase，这样 branch 没有 merge commit 比较干净。不过一般情况下，就算是落后了很多，但只要 PR 没有 conflicts，我一般是不会麻烦的
另外，自己的 branch 没啥不礼貌的，我又没跑过去把别人的 force 掉。不过 -f 的确有些危险，我就干过把 commit 搞丢了的情况，后来还是找别人 push -f 找回来的
【 在 dpblue 的大作中提到: 】
: code review过了几天，给了一些comments，这时候我的branch已经落后develop branch很多了
: 我一般的做法是：
: 1. 把本地branch rebase到最新的 (git rebase develop)
: ...................
--
FROM 203.211.104.*
还是分干嘛，我一般情况下是用 rebase 解决 conflicts，少了一个 merge commit 完成同样的功能。逻辑上，因为代码逻辑和功能并没有实质的变化，每个 commit message 描述的变化还是相同的，所以别人并不需要知道干了啥。如果是用 merge 解决 conflicts，同样其他人也还是不知道具体干嘛了，本来 merge commits 也都是次要的。
如果是根据 code review 更新代码，那肯定还是要有新的 commit 的，因为代码的逻辑和功能已经发生了改变。如果 commit --amend 然后 push -f，那的确不太好
【 在 cybereagle 的大作中提到: 】
: github review 这个过程其实是不大喜欢 force push 的
: 因为不容易看到上次 review 之后干了啥
: 必须自己手工去选 commit
: ...................
--
修改:eGust FROM 203.211.104.*
FROM 203.211.104.*
我们用 bitbucket，comment 是基于文件的，只要文件还在，就还是能看到评论。如果文件不在了的话，就只能点到每一个 commit 里面去看了。如果 comment 在一个新文件里，之后改代码把文件干掉了，那 -f 就看不到了……如果 comment 该行的代码变了，那就会跑到 outdated comments 里面去，这点跟 -f 没关系。
不确定 github 逻辑啥样
PR 的大小也是一个需要控制的点，一个 PR 如果改了超过50行复杂代码，我个人感觉就已经超过能通过 review 检查出问题的上限了。不 pull 下来整个 branch 跑一下的话，能做的就只有检查一下代码风格，功能在大方向有没有问题了。换句话说，如果一个 review 一个 PR 搞出了20条 comments，那回头代码变了，再检查20个点有没有都改到也是很浪费时间的
【 在 dpblue 的大作中提到: 】
: -f 会不会把别人之前的review comments给冲掉？
--
FROM 203.211.104.*
其实我还蛮常 amend 的，有时候发现个 typo，实在不愿意敲 commit message（我们有要求必须带 jira number，最少是“JIRA-123 typo”），于是就直接改了……
【 在 cybereagle 的大作中提到: 】
: PR之前自己的分支随便rebase
: 知
: 说的就是这个问题
: ...................
--
FROM 203.211.104.*