这是一个创建于 216 天前的主题，其中的信息可能已经有所发展或是发生改变。
在我职业生涯里这种情况很少见，不过在现在公司的工作流中居然很常见，各种奇葩的 merge ，但凡碰到我是 reviewer 应该就会毙掉了。 同事的解释基本是直接在 SourceTree 里操作拉取的，默认是 merge 操作，所以就这样了。我看了一下其实是支持 rebase 选项的，应该只是不会用而已。
纯吐槽了，反正我不是 reviewer 。
第 1 条附言 2025 年 7 月 2 日
我并不是完全反对 git merge ，比如在一个 feature 分支完成后准备合并发版的的时候，feature 分支 merge 到 develop 再到 master 是完全可以接受的。除此之外都是不可理喻的。
49 条回复 2025-07-04 15:16:13 +08:00
 | 1 weixind 2025 年 7 月 2 日 你觉得不合理的可以提出来，大家一起讨论如何优化。这就是你的绩效亮点之一。 回到这个事情上来看，你的想法没错。 |
 | 2 looplj 2025 年 7 月 2 日 GitHub 默认行为吧。所以绝大部分人 merge 的时候，都会包含 merge commit 。 只要少数对这方面有想法的人，才会使用 rebase 或者 squash |
 | 3 Kaiv2 2025 年 7 月 2 日 正常情况下不应该包含 merge commit ，我记得高版本 git 命令强制你设置 |
 | 4 Tink PRO 默认是包含的吧，新新的 merge commit 会保留原分支的提交历史 |
 | 5 guanzhangzhang 2025 年 7 月 2 日 有技术细节追求的是少数，好多人都是用 ide 啥 GUI 操作合并后推送，没有或者不会 git pull --rebase 和 git rebase 习惯 |
 | 6 peasant 2025 年 7 月 2 日 我和同事说过好多次用 rebase ，但是没人愿意用  |
7
freeman12 2025 年 7 月 2 日 
3 特性 git merge git rebase
是否保留分支历史 是（有合并节点） 否（会“平铺历史”，重写 commit ）
是否修改 commit hash 否 是，commit 会重写
是否生成 merge commit 默认生成 不会生成
是否易于理解协作历史 是（真实历史） 否（历史被改写，适合单人开发）
是否容易冲突 重复合并可能冲突 频繁 rebase 更容易遇到冲突
应用场景 分支合并（多人协作常用） 清理分支历史（个人分支、PR 前整理）
多人协作不是 merge 更好吗，保留了真实历史
是否保留分支历史 是（有合并节点） 否（会“平铺历史”，重写 commit ）
是否修改 commit hash 否 是，commit 会重写
是否生成 merge commit 默认生成 不会生成
是否易于理解协作历史 是（真实历史） 否（历史被改写，适合单人开发）
是否容易冲突 重复合并可能冲突 频繁 rebase 更容易遇到冲突
应用场景 分支合并（多人协作常用） 清理分支历史（个人分支、PR 前整理）
多人协作不是 merge 更好吗，保留了真实历史
 | 8 finab 2025 年 7 月 2 日 rebase 有个问题，一旦某个文件每个 commit 都有冲突，那 rebase 就需要多次解决冲突 我现在的办法是 合并这些 commit ，然后再 rebase ，但其实我是希望保留 commit 记录的，各位彦祖有啥好办法么？ |
 | 9 crysislinux 2025 年 7 月 2 日 via Android 可以 pr 合并的时候在 squash merge 吧，merge commit 经常是不好避免的，比如 review 已经开始了之后 pr 跟 main 有冲突，这时候 merge main 比 rebase main 更合适，rebase 就把 review 的历史搞乱了 |
 | 10 zed1018 2025 年 7 月 2 日 @finab 有的兄弟，你先合并成一个 commit 然后 rebase ，完了通过 reset --soft 退回到未提交状态，然后你自己再做一遍多个 commit |
 | 11 flywanly990 2025 年 7 月 2 日 没感觉到 rebase 在多人协作中的优点，除了 commit 看起来纯净，还有啥好处呢？ merge commit 可以看到所有的操作记录，不是更好吗 |
 | 13 encounter2017 2025 年 7 月 2 日 pull request 里面包含 merge request 不是很正常的吗，github 上很多开源社区的做法是，在提交到主分支前，由 bot 或者人手工 rebase 成单条记录然后合并。在 pr 阶段保留 merge request 信息可以方便 review 人员查看变更历史，之前 resolve 的评论就可以往后面的 commits 看。 一个特殊的例子，openjdk 仓库里面 pull request 合并后都是 close 状态的，主分支保持干净 https://github.com/penjdk/jdk |
 | 14 funcman 2025 年 7 月 2 日 3 好早之前曾经在一个有一点 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 的团队里上班 |
 | 15 sepit 2025 年 7 月 2 日 @flywanly990 我也是同感，感觉 merge 明显更自然一些，分锅甩锅追溯问题都更清晰 |
 | 16 672795574 2025 年 7 月 2 日 rebase 会丢失信息， -f 操作除非我很明确知道自己在做什么 不然一般不用 |
 | 17 kid1412621 2025 年 7 月 2 日 @freeman12 #7 问题就是有时候可能太过真实 |
| 18 flywanly990 2025 年 7 月 2 日 @sepit 对的，溯源很重要，主要是分锅的时候更方便，嘿嘿…… 另外，团队成员技术水平参差不齐，merge 可以减少的心智负担 |
 | 19 chimission 2025 年 7 月 2 日 其实我也不太清楚，rebase 除了让 log 好看一点之外还有其他高收益的优点吗，讨论一下 |
 | 20 54xavier 2025 年 7 月 2 日 我讨厌 merge commit ，但是我愿意保留，比较清晰明了 |
 | 21 jeesk 2025 年 7 月 2 日 讨论了不知道多少次了， 还是参考 chromium 项目的方法比较稳妥。 我不觉得你的项目比 chromium 还复杂。 |
 | 22 kneep 2025 年 7 月 2 日 1 取决于 merge commit 是不是反映必要的客观现实吧。如果你带进来的 merge commit 真就是因为多个人合作而产生的，或者有些 pipeline 有一些自动的处理，那就带进去。如果仅仅是因为你自己没用好工具造成的，比如改完后 git pull 一下在本地生成的 merge commit ，那是完全不应该的。 总体来说，我认为 PR 里面带进来必要的 merge commit ，是不多见的。我以往的工作经验中，绝大部分都是因为本地的 git pull 生成的 merge commit ，这种我都会打回去。 |
 | 23 sparkle2015 2025 年 7 月 2 日 1 分支间有冲突时，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 > 呃，奇妙的变基也并非完美无缺，要用它得遵守一条准则： > 如果提交存在于你的仓库之外，而别人可能基于这些提交进行开发，那么不要执行变基。 > 如果你遵循这条金科玉律，就不会出差错。 否则，人民群众会仇恨你，你的朋友和家人也会嘲笑你，唾弃你。 |
 | 24 unused 2025 年 7 月 2 日 可以包含 merge ，但是你说的这种无意义的 merge 肯定不行 |
 | 25 greycell 2025 年 7 月 2 日 没看懂，pr squash merge 就行了，你管人家自己 branch 上喜欢用啥呢 |
 | 27 yunyuyuan 2025 年 7 月 2 日 小需求，直接 rebase master 大需求，如果是模块化的，一步到位的，squash 后再 rebase master 。如果不是模块化的，冲突很多的，直接 merge master ，这样也保留原始提交信息。 |
 | 28 RedisMasterNode 2025 年 7 月 2 日 > 我看了一下其实是支持 rebase 选项的，应该只是不会用而已。 哈哈，rebase 操作过程中不知道有多少事情要处理，也是个纸面上好用实际用起来一大堆问题的方案。到时候会有很多人跟你争论 PR 整体大小不合适不方便 rebase->为什么要把这么多内容放一个 PR -> 为什么需求/流程/排期如何如何... squash 之后一个 PR 就只有一个 commit ，为什么要关心人家中间操作了什么呢？ |
 | 29 iyaozhen 2025 年 7 月 2 日 很多人推荐 rebase ，但其实操作难度比 merge 高多了，需要理解很多概念，很容易冲突，合出问题 当然你可以说这是基本功，但实际工作中你遇到的都是“跨域报错了是前端改还是后端改都能吵半天的水平”，就释然了，爱啥啥，只要不把我的代码给合丢了就行 |
 | 30 wenrouxiaozhu 2025 年 7 月 2 日 我一般这样 git rebase origin/master --committer-date-is-author-date git switch master git merge feat/xx --no-ff |
 | 31 kakki 2025 年 7 月 2 日 别一天吹 rebase 了,本来就是两种不同的对待历史的态度,没有谁更牛比的说法 ok? 你尊重提交历史,那就 merge. |
 | 32 kaedea 2025 年 7 月 2 日 via Android 当有不止一个主干的时候就别当什么 rebase 警察了。 |
 | 33 aragakiyuii 2025 年 7 月 2 日 via Android 自己本地的 merge commit 推到远程除了污染环境还有什么用？ |
 | 34 WorseIsBetter 2025 年 7 月 2 日 1 每当遇到这种老生常谈的问题，就不得不提 fossil 了，从设计理念上就不支持 rebase 功能： https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md 不过我自己还是挺喜欢用 rebase 的，主要是在提交 review 之前 rebase -i 整理一下自己的开发分支（不过按照 fossil 的说法，这不仅是「不诚实」，还是一种「不谦虚」的行为，我认了，哈哈） 而且在我遇到的大部分协作场景下，一个分支「在什么时候从主线分叉，中途什么时候再次同步过主线」这样的信息并不是很重要（尤其是当那个开发分支只有一个人在用的时候）。 个人观点是，既不要一味追求「诚实」（记得以前有人写博客怼 fossil 作者：既然那么想要诚实，为什么不把你在编辑器里做过的每一个操作都分别提交上去呢），也不要盲目追求「干净」（如果某些被改写的提交历史会影响后续的问题追溯的话）。要制定好团队协作规范，分情况讨论。 |
 | 35 siweipancc 2025 年 7 月 2 日 我跟同事开发的代码, 他喜欢 rebase, 容易吐槽说怎么提交的代码不见了  |
 | 36 Yuesh1 2025 年 7 月 2 日 @funcman 经历完全相同呀，我当时毕业去的第一家公司，后来出来后，后来再也没有人知道 gerrit ，也没人再做 CR ，面试的时候说 gerrit ，别人也不知道我在说什么 |
 | 37 Nich0la5 2025 年 7 月 2 日 2 感觉 merge vs rebase 都快成了月经贴了 |
 | 38 clue 2025 年 7 月 2 日 @flywanly990 #11 merge commit 看似你能看到所有提交细节，但实际上的改动只有 merge 的那一次，分支上的提交只是个参考引用。 所以如果 merge 出了问题，定位都难，再碰到喜欢弄一个私人分支一直 merge main 再 merge 回去的，提交记录没法看了。 rebase 不只是好看，分支的每个提交 rebase 到主干后都是真实有效的，唯一的缺点是对开发者要求比较高。 |
 | 40 htxy1985 2025 年 7 月 2 日 理论上我是同意 22 楼的说法，要不要 merge 是看情况的，自己 merge 自己，又没有冲突，属于是自己没操作好导致的好多条 log 是可以干掉的。 但实际操作上，我是很懒的，全 merge 也没有问题，但总会有一些自我感觉 rebase 是最优雅的人来说服我，就有点反感。 |
 | 41 94 2025 年 7 月 2 日 我看别人会不会用 git ，或者操作的 git 的熟练度，就是看一个人对于 rebase 的理解。 PR 要不要保留最后的 merge commit ，是看仓库作者的想法。这个在仓库里面是可以设置的。不是贡献 PR 的人该考虑的问题。 ----- 如果是日常工作中的出现的 `Merge remote-tracking branch 'origin/master'` 或者 `Merge branch 'master' of 'http://xxxxx'` ，恕我直言：不是菜，就是懒。 |
| 42 greycell 2025 年 7 月 2 日 @dfkjgklfdjg 本来 repo 设置的问题，被搞成 merge 和 rebase 的矛盾我是没看懂。设成 pr 必须没有 conflict ，必须 squash merge 是不会吗。 |
 | 43 thulof 2025 年 7 月 2 日 好多人说 rebase 模式下多 Commit 解决冲突很麻烦云云。那既然都 rebase 了，就小步 Merge Request 、频繁提交呗。 为啥非得自己搞个大分支，和主干分叉很久之后再 rebase 主干解冲突，然后提个超大 MR ？恶心自己也恶心别人 |
| 44 94 2025 年 7 月 2 日 |
 | 45 xingheng OP  感受一下 merge history 的恐惧吧，这是我在 SourceTree 里把 Graph 列拉到最大的效果，有些还没显示出来。 |
 | 46 BruceXu 2025 年 7 月 2 日 develop 向 master 这种的,分支之间用 merge. develop 或者 feture 分支内部的,多人开发用 rebase. |
 | 47 weiwenhao 2025 年 7 月 2 日 正确的做法是什么呀？ 公司现在协作的方式是基于 master 创建 feature 分支(根据测试情况包括多次 commit ，持续几天)，然后会在合并到 master 之前，会 merge master 中最新的代码到 feature 分支，处理一下冲突，然后再提交 pr 到 master 。 |
 | 48 suiyun39 2025 年 7 月 2 日 我的做法是：其他分支怎么玩都无所谓，爱怎么折腾怎么折腾，但 master 必须保持线性提交（这个是有分支保护规则的）。当最终合并到 master 的时候，只允许使用 Squash Merge 把提交压缩成一条。特殊情况允许 Rebase Merge 来保留一定的提交历史（但必须提前 rebase 一次剔除掉杂音）。 |
| 49 wenrouxiaozhu 2025 年 7 月 4 日 @suiyun39 "只允许使用 Squash Merge 把提交压缩成一条" rebase 后再 merge -no-ff 更好一点？这样主分支上只有线性的 merge commit+可以保留 feat 分支历史记录 https://zhuanlan.zhihu.com/p/616897004 |
Select Language