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.*

在gitlab上，一般步骤是
1、按comments修改，产生新的commit
2、reviewer approve
3、能fast-forward的，直接merge，不能的先rebase再merge，还可以squash

没理解为啥要push -f

【 在 dpblue 的大作中提到: 】
: code review过了几天，给了一些comments，这时候我的branch已经落后develop branch很多了
: 我一般的做法是：
: 1. 把本地branch rebase到最新的 (git rebase develop)
: ...................
--
FROM 124.126.3.*

gerrit code review 的玩法是服务端自己开一个新的 ref，不可能推进主分支，贡献者在本地 rebase 和 amend 再推就行了。
我个人在 GitHub/GitLab 上一般的做法是 rebase, amend, force push. 系统的 merge request 会自动更新。

【 在 dpblue 的大作中提到: 】
: code review过了几天，给了一些comments，这时候我的branch已经落后develop branch很多了
: 我一般的做法是：
: 1. 把本地branch rebase到最新的 (git rebase develop)
: ...................
--
FROM 103.90.178.*

其实我还蛮常 amend 的，有时候发现个 typo，实在不愿意敲 commit message（我们有要求必须带 jira number，最少是“JIRA-123 typo”），于是就直接改了……

【 在 cybereagle 的大作中提到: 】
: PR之前自己的分支随便rebase
: 知
: 说的就是这个问题
: ...................
--
FROM 203.211.104.*

这倒是一个办法，不然每次取新代码以后，之前approve过的人还得喊人家approve一遍

【 在 jimmycmh 的大作中提到: 】
: 除非明确知道某些改动会影响到自己吧
: 一般就偷懒，最后merge时看下diff
:
--
FROM 120.21.135.*