Pull Request 允许包含 merge commit 吗

[xingheng]

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

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

[jeesk]

讨论了不知道多少次了， 还是参考 chromium 项目的方法比较稳妥。 我不觉得你的项目比 chromium 还复杂。

[kneep]

取决于 merge commit 是不是反映必要的客观现实吧。如果你带进来的 merge commit 真就是因为多个人合作而产生的，或者有些 pipeline 有一些自动的处理，那就带进去。如果仅仅是因为你自己没用好工具造成的，比如改完后 git pull 一下在本地生成的 merge commit ，那是完全不应该的。

总体来说，我认为 PR 里面带进来必要的 merge commit ，是不多见的。我以往的工作经验中，绝大部分都是因为本地的 git pull 生成的 merge commit ，这种我都会打回去。

[sparkle2015]

分支间有冲突时，merge 只需要解一次冲突，rebase 可能要解 n 次冲突。而且使用 rebase 不利于多人修改同一个分支 (极少情况但确实有时候会发生)。所以 rebase 只是看似美好。
github 上用 squash merge 个人感觉是最优解。


> https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%8F%98%E5%9F%BA
> 呃，奇妙的变基也并非完美无缺，要用它得遵守一条准则：
> 如果提交存在于你的仓库之外，而别人可能基于这些提交进行开发，那么不要执行变基。
> 如果你遵循这条金科玉律，就不会出差错。 否则，人民群众会仇恨你，你的朋友和家人也会嘲笑你，唾弃你。

[unused]

可以包含 merge ，但是你说的这种无意义的 merge 肯定不行

[greycell]

没看懂，pr squash merge 就行了，你管人家自己 branch 上喜欢用啥呢

[unused]

@finab 看看 git rerere

[yunyuyuan]

小需求，直接 rebase master
大需求，如果是模块化的，一步到位的，squash 后再 rebase master 。如果不是模块化的，冲突很多的，直接 merge master ，这样也保留原始提交信息。

[RedisMasterNode]

> 我看了一下其实是支持 rebase 选项的，应该只是不会用而已。

哈哈，rebase 操作过程中不知道有多少事情要处理，也是个纸面上好用实际用起来一大堆问题的方案。到时候会有很多人跟你争论 PR 整体大小不合适不方便 rebase->为什么要把这么多内容放一个 PR -> 为什么需求/流程/排期如何如何...

squash 之后一个 PR 就只有一个 commit ，为什么要关心人家中间操作了什么呢？

[iyaozhen]

很多人推荐 rebase ，但其实操作难度比 merge 高多了，需要理解很多概念，很容易冲突，合出问题
当然你可以说这是基本功，但实际工作中你遇到的都是“跨域报错了是前端改还是后端改都能吵半天的水平”，就释然了，爱啥啥，只要不把我的代码给合丢了就行

[wenrouxiaozhu]

我一般这样
git rebase origin/master --committer-date-is-author-date
git switch master
git merge feat/xx --no-ff

[kakki]

别一天吹 rebase 了,本来就是两种不同的对待历史的态度,没有谁更牛比的说法 ok?
你尊重提交历史,那就 merge.

[kaedea]

当有不止一个主干的时候就别当什么 rebase 警察了。

[aragakiyuii]

自己本地的 merge commit 推到远程除了污染环境还有什么用？

[WorseIsBetter]

每当遇到这种老生常谈的问题，就不得不提 fossil 了，从设计理念上就不支持 rebase 功能： https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md

不过我自己还是挺喜欢用 rebase 的，主要是在提交 review 之前 rebase -i 整理一下自己的开发分支（不过按照 fossil 的说法，这不仅是「不诚实」，还是一种「不谦虚」的行为，我认了，哈哈）

而且在我遇到的大部分协作场景下，一个分支「在什么时候从主线分叉，中途什么时候再次同步过主线」这样的信息并不是很重要（尤其是当那个开发分支只有一个人在用的时候）。

个人观点是，既不要一味追求「诚实」（记得以前有人写博客怼 fossil 作者：既然那么想要诚实，为什么不把你在编辑器里做过的每一个操作都分别提交上去呢），也不要盲目追求「干净」（如果某些被改写的提交历史会影响后续的问题追溯的话）。要制定好团队协作规范，分情况讨论。

[siweipancc]

我跟同事开发的代码, 他喜欢 rebase, 容易吐槽说怎么提交的代码不见了

[Yuesh1]

@funcman 经历完全相同呀，我当时毕业去的第一家公司，后来出来后，后来再也没有人知道 gerrit ，也没人再做 CR ，面试的时候说 gerrit ，别人也不知道我在说什么

[Nich0la5]

感觉 merge vs rebase 都快成了月经贴了

[clue]

@flywanly990 #11 merge commit 看似你能看到所有提交细节，但实际上的改动只有 merge 的那一次，分支上的提交只是个参考引用。
所以如果 merge 出了问题，定位都难，再碰到喜欢弄一个私人分支一直 merge main 再 merge 回去的，提交记录没法看了。

rebase 不只是好看，分支的每个提交 rebase 到主干后都是真实有效的，唯一的缺点是对开发者要求比较高。

[Binwalker]

@finab #8 git rerere 了解下

[htxy1985]

理论上我是同意 22 楼的说法，要不要 merge 是看情况的，自己 merge 自己，又没有冲突，属于是自己没操作好导致的好多条 log 是可以干掉的。
但实际操作上，我是很懒的，全 merge 也没有问题，但总会有一些自我感觉 rebase 是最优雅的人来说服我，就有点反感。