Pull Request 允许包含 merge commit 吗

[xingheng]

在我职业生涯里这种情况很少见，不过在现在公司的工作流中居然很常见，各种奇葩的 merge ，但凡碰到我是 reviewer 应该就会毙掉了。 同事的解释基本是直接在 SourceTree 里操作拉取的，默认是 merge 操作，所以就这样了。我看了一下其实是支持 rebase 选项的，应该只是不会用而已。

纯吐槽了，反正我不是 reviewer 。

[weixind]

你觉得不合理的可以提出来，大家一起讨论如何优化。这就是你的绩效亮点之一。

回到这个事情上来看，你的想法没错。

[looplj]

GitHub 默认行为吧。所以绝大部分人 merge 的时候，都会包含 merge commit 。
只要少数对这方面有想法的人，才会使用 rebase 或者 squash

[Kaiv2]

正常情况下不应该包含 merge commit ，我记得高版本 git 命令强制你设置

[Tink]

默认是包含的吧，新新的 merge commit 会保留原分支的提交历史

[guanzhangzhang]

有技术细节追求的是少数，好多人都是用 ide 啥 GUI 操作合并后推送，没有或者不会 git pull --rebase 和 git rebase 习惯

[peasant]

我和同事说过好多次用 rebase ，但是没人愿意用

[freeman12]

特性 git merge git rebase
是否保留分支历史 ✅ 是（有合并节点） ❌ 否（会“平铺历史”，重写 commit ）
是否修改 commit hash ❌ 否 ✅ 是，commit 会重写
是否生成 merge commit ✅ 默认生成 ❌ 不会生成
是否易于理解协作历史 ✅ 是（真实历史） ❌ 否（历史被改写，适合单人开发）
是否容易冲突 🔁 重复合并可能冲突 ⚠️ 频繁 rebase 更容易遇到冲突
应用场景 分支合并（多人协作常用） 清理分支历史（个人分支、PR 前整理）

多人协作不是 merge 更好吗，保留了真实历史

[finab]

rebase 有个问题，一旦某个文件每个 commit 都有冲突，那 rebase 就需要多次解决冲突
我现在的办法是 合并这些 commit ，然后再 rebase ，但其实我是希望保留 commit 记录的，各位彦祖有啥好办法么？

[crysislinux]

可以 pr 合并的时候在 squash merge 吧，merge commit 经常是不好避免的，比如 review 已经开始了之后 pr 跟 main 有冲突，这时候 merge main 比 rebase main 更合适，rebase 就把 review 的历史搞乱了

[zed1018]

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

[flywanly990]

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

[finab]

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

[encounter2017]

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

[funcman]

好早之前曾经在一个有一点 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 的团队里上班 🤦‍

[sepit]

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

[672795574]

rebase 会丢失信息， -f 操作除非我很明确知道自己在做什么 不然一般不用

[kid1412621]

@freeman12 #7 问题就是有时候可能太过真实😀

[flywanly990]

@sepit 对的，溯源很重要，主要是分锅的时候更方便，嘿嘿……
另外，团队成员技术水平参差不齐，merge 可以减少的心智负担

[chimission]

其实我也不太清楚，rebase 除了让 log 好看一点之外还有其他高收益的优点吗，讨论一下

[54xavier]

我讨厌 merge commit ，但是我愿意保留，比较清晰明了