Pull Request 允许包含 merge commit 吗

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

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

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

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

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

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

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

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

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

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

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

@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 明显更自然一些，分锅甩锅追溯问题都更清晰

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

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

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

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

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