@finab 有的兄弟，你先合并成一个 commit 然后 rebase ，完了通过 reset --soft 退回到未提交状态，然后你自己再做一遍多个 commit

没感觉到 rebase 在多人协作中的优点，除了 commit 看起来纯净，还有啥好处呢？ merge commit 可以看到所有的操作记录，不是更好吗

@zed1018 这样这个文件会是最新状态，修改记录就已经丢失了

pull request 里面包含 merge request 不是很正常的吗，github 上很多开源社区的做法是，在提交到主分支前，由 bot 或者人手工 rebase 成单条记录然后合并。在 pr 阶段保留 merge request 信息可以方便 review 人员查看变更历史，之前 resolve 的评论就可以往后面的 commits 看。 一个特殊的例子，openjdk 仓库里面 pull request 合并后都是 close 状态的，主分支保持干净 https://github.com/openjdk/jdk

好早之前曾经在一个有一点 Google 脉络的组上班，其中 CodeReview 用的是 Gerrit 。也就是说这种提交模式（ pre-commit ）会导致我们一个提交会因为等待打分，导致做好多次 rebase 。rebase 的结果导致提交线直直一根很漂亮。可能会丢失实际开发信息，但是从成果角度看，丢失的信息也无所谓，丢失也是一种整理过程。 当然如前面有人说的，这种模式一旦遇到冲突，可能要多次反复解决冲突。比较麻烦。 至于 Merge Request 这种 post-commit ，几乎是非 Gerrit 管理的项目的实际上的唯一可靠的模式。Gerrit 需要组里有足够的熟手。而 MR 只需要一个老手加若干新手就能转起来。所以别纠结。 术语 Merge Request 和 Pull Request 实质几乎是一样的，主要是 Gitlab 用前者，Github 用后者。所以 IDE/Tools 在生成 commit log 时，用词可能比较随意。（回想当时用 Gerrit 之前，我们的库就是托管在 Github 上，但是不使用 PR ，所有人都有权限直接往库里 push 。有的人会 rebase 一下，有的人直接来。） 后来再也没有在有 CR 的团队里上班 🤦‍

@flywanly990 我也是同感，感觉 merge 明显更自然一些，分锅甩锅追溯问题都更清晰