- 主题:git大家一般都是怎么改code review给的意见的？
code review过了几天，给了一些comments，这时候我的branch已经落后develop branch很多了
我一般的做法是：
1. 把本地branch rebase到最新的 (git rebase develop)
2. 加一个新的commit把要改的都改好
3. git push -f origin my-branch
第三步有个问题：force push。这个是比较危险的做法，而且据说不太礼貌？
你们一般怎么搞？
--
FROM 120.21.135.*
gitlab 上面弄
每个人提交分支，code review之后再创建merge request, ci cd 一套流程
【 在 dpblue 的大作中提到: 】
: code review过了几天，给了一些comments，这时候我的branch已经落后develop
: branch很多了
: 我一般的做法是：
: 1. 把本地branch rebase到最新的 (git rebase develop)
: ...................
--
FROM 27.19.16.*
为什么需要-f?
--
FROM 121.200.253.*
你不写-f一样能push上去啊
【 在 dpblue 的大作中提到: 】
: code review过了几天，给了一些comments，这时候我的branch已经落后develop branch很多了
: 我一般的做法是：
: 1. 把本地branch rebase到最新的 (git rebase develop)
: ...................
--
FROM 103.107.216.231
所以有些地方说：你可以 PULL + MERGE
【 在 dpblue 的大作中提到: 】
: code review过了几天，给了一些comments，这时候我的branch已经落后develop branch很多了
: 我一般的做法是：
: 1. 把本地branch rebase到最新的 (git rebase develop)
: ...................
--
FROM 13.56.31.*
rebase了只能 -f
【 在 PaoloMaldini 的大作中提到: 】
: 你不写-f一样能push上去啊
--
FROM 220.200.25.*
我个人倾向 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。有问题再让review 一次。最后push -f
【 在 dpblue 的大作中提到: 】
: code review过了几天，给了一些comments，这时候我的branch已经落后develop branch很多了
:
: 我一般的做法是：
: 1\. 把本地branch rebase到最新的 (git rebase develop)
: 2\. 加一个新的commit把要
: ..................
发自「今日水木 on 辽宁舰」
--
FROM 73.93.166.*
github review 这个过程其实是不大喜欢 force push 的
因为不容易看到上次 review 之后干了啥
必须自己手工去选 commit
【 在 eGust 的大作中提到: 】
: 我个人倾向 rebase，这样 branch 没有 merge commit 比较干净。不过一般情况下，就算是落后了很多，但只要 PR 没有 conflicts，我一般是不会麻烦的
: 另外，自己的 branch 没啥不礼貌的，我又没跑过去把别人的 force 掉。不过 -f 的确有些危险，我就干过把 commit 搞丢了的情况，后来还是找别人 push -f 找回来的
--
FROM 220.200.25.*
还是分干嘛，我一般情况下是用 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.*