基准分支是 master ，开发分支是 feature 。现在准备发布上线了，需要 feature 合入 master ，此时有冲突，我解决冲突有两种方式。

一是：直接把 master 合入 feature 解决冲突，再把 feature 合入 master ；
二是：先从 master 拉出分支 master_1 ，把 feature 合入 master_1 解决冲突，再把 master_1 合入 master ；
这 2 种有区别吗，LD 必须让第二种，不理解。

不理解

2 是脱裤子放 p 。但是想来是你 leader 长期以来的习惯了，也不要去纠正他，没必要。

不理解
master 合入 feature-x 解决冲突，此时 feature-x 不就是等于方案二中的 master_1 吗?

随便，毕竟大部分人把 git 当大号 svn 用

正常不是要 rebase 到最新的 master 么。哪种都行，只要没合并出 bug 。
你跟他争论只会让他对你印象变差，他说啥你都 [嗯] 就完了，逢场作戏的事，私下你该干嘛就干嘛，别理他

除非 master_1 是预生产、预发布，不然即便是回滚，分支线路都没看出什么优势来

从技术上来说，应该没什么区别。
从人情世故上来说，劝你按领导说得来，不要硬刚领导。
---来自过来人的忠告。

二是脱裤子放屁 +1
还有一种选择是 feature rebase 到 master 上

如果 feature 短期内被合入 master ，那我更习惯用 rebase ，并且把 feature 中间的 commit 都去掉，减少对 master 的扰乱

风险控制吧，是多此一举，但就是为了降低风险，建议听领导的

rebase 吧

迭代周期短，变更记录少，用 rebase ；否则，方式一。方式二脱裤子放屁

一 back merge 应该避免
二如果 “把 master_1 合入 master” 是 ff 那就是对的

1 、估计你们用的 git 不规范造成的，一般 feature 合并到 master 为什么会冲突呢，有冲突的话在 feature 应该就解决了
2 、为什么不在本地 master 解决呢，feature 合并到 master 发现有冲突难道还要回滚吗，然后在另起分支解决冲突，感觉有点脱裤子放屁

如果只有一个 feature 分支，方式一，就行。如果多个 feature 分支，推荐方式二。

核心问题在，你的 feature 分支从主分支拉出来之后，就再也不同步主分支的变更了，导致 feature 分支与主分支越走越远。
更好的做法是，在开发阶段频繁地把 feature 分支 rebase 最新的主分支，如果出现冲突及时解决。这样在最后将分支合并回主分支时，feature 分支也依然是 base 在最新的主分支上，则不会有冲突。

说不理解的 都没开发过复杂的场景。比如：
feature/A -> master 有冲突，如果直接 把 master 代码 合到 feature/A 中，这个时候 假如说 不想上线 合并了，你得操作回滚。

另外一个 master 不一定是要上线的代码，可能是 上线前的准备回归封板代码，如果这个时候 feature/B 也合并到了 master 出现了严重 bug ，这个时候 feature/A 同步 master 的代码 就会被污染。

新开一个分支 用来同步 最新的稳定版本的代码 以及 处理冲突，feature/A 要同步 也是 同步 已经上线后的稳定版本代码，而不是 直接 同步 最新的 master 代码。

feature 是 基于 某个时间点的 功能开发版本，不一定非要跟 最新 master 保持同步，feature 的目的 是为了完成 当时那个时间点的需求，开发完成了，就新开一个分支 去合并到 master ，这也可以在 feature 上 继续开发，编码 跟 环境部署测试 是两回事。

如果有很多的冲突 不兼容的问题 是需要团队提前沟通的，不可能说 feature/A 在迭代功能，feature/B 在重构，你这合到 master 怎么玩，还怎么发布上线？

用第二种是怕你把 master 搞乱，又不懂恢复，又或者为了省事，搞错不用回滚等操作。算是一种新手保护，或者团队有人搞乱过。

实际上第一种就最好了。可以的话，尽量 git rebase

第二个操作毫无意义啊，分出最新 master ，再合并回到最新 master ，和操作一 等价。

第一种方式叫循环回合，可能会带来 merge base 爆炸的问题，小项目无所谓随便搞，像远古银行的项目因为不规范导致某些仓库的 merge base 多达上百个，merge 一个小的改动都非常耗时。这种仓库使用 gitlab 、gitee 线上合并是会拒绝的，github 没试过

我都是用方法一，我们公司合入代码出现冲突时，会有提示教程，用的就是方法 1 ；

只要不是在 master 上操作就行，local branch 也算是 diff branch

第一种方式不会有这种问题，有问题的是人不会用，建议直接换人

你说得对，这两种方式就是等价的，楼上还有人搁那一本正经的分析呢，完全对 git 一无所知

没有人说要用 squash merge 吗？

方法 1 和 2 是基本等价的，区别就是方法二多创建了一个无用分支

p.s. 比较看不惯不管有没有冲突先把 master 往 feature 分支一顿 merge ，再发 merge request 到 master 的，没冲突的话不应该直接发 mr 嘛？所以还是 merge 前先 rebase 比较好，分支看起来清晰干净

有没有想过问 deepseek ，说的很清楚。
这是一个决策问题不是对错问题，over

＃23 不是搞 git 领域的确实不用关注这些，我们很长时间才找到的问题被你一句话给否定了

说等价的没有理解 commit parents 的顺序
看看 Linux 怎么处理
docs.kernel.org/maintainer/rebasing-and-merging.html＃merging-from-sibling-or-upstream-trees

你直接 git rebase master 不就相当于没有冲突了么，那就没有这个问题了

走 Merge Request 的话，都是要先解决完冲突才能和入，在 Master 上拉不拉新分支不影响什么

＃23 我们之前投产就是用第一种方法，用的是私有化 gitlab ，线上 pr 合不进去 master 分支，只能本地手动去合，很痛苦

你们 LD 的想法起点是让 master 一直保持正确可用的版本，git merge 后发现不对在 log 里就会发现错误。所以想先创建一个临时分支用于合并，合并确认无误后在 master 上保存版本。说白了他就是接受草稿本上犯错，卷子上一直整洁。你非要在 master 上搞个潜在的问题出来他不喜欢

是的，第一个是 feature 合过 master 后，提一个 feature->master 的 MR ；第二个是解决完冲突提一个 master_1->master 的 MR 。

理由是第二种 MR 的 diff 是以更新的 commit 为基准和 feature 对比，只包含了当前 feature 的改动记录

补充一下，你们 ld 肯定还要求你们确认无误 merge 之后把这个 master_1 分支删掉。这个其实无所谓，就是习惯问题，你的 ld 考虑的是所有人一起用的版本需要整洁，不想万一哪一个往上面抹了一坨然后说擦掉就没事。

两者不等价。见 hesudu.com/t/1101348＃r_15733764

不要交叉 merge ，会导致公共父节点难以判断，然后代码会「莫名其妙地在你正常操作情况下丢失」

实际用方法一

两种合并方式的本质区别在于合并方向和对历史记录的影响，LD 要求使用第二种方式的核心原因在于保持 master 分支的稳定性。以下是具体分析：

1. 第一种方式（ master→feature→master ）的潜在问题：

• 污染特性分支历史：feature 分支会引入 master 的合并提交，破坏特性分支的线性开发记录
• 隐藏风险：合并后若发现冲突解决错误，需要回滚会导致 master 和 feature 同时受影响
• 破坏权限模型：若 master 有保护规则，直接合并 feature 可能绕过 CI/CD 流程

2. 第二种方式（ feature→master_1→master ）的优势：

• 隔离风险：所有冲突解决在临时分支完成，不影响原始开发分支和主分支
• 强制代码最新：master_1 基于最新 master 创建，确保冲突解决是基于最新线上代码
• 审计清晰：master_1 的合并请求可独立进行 code review ，保留完整解决记录
• 符合 Git Flow 规范：临时发布分支模式是标准持续交付实践

技术实现差异对比：

＃ 方式一
git checkout feature
git merge master ＃ 污染 feature 分支
git checkout master
git merge feature ＃ 可能触发二次 CI

＃ 方式二
git checkout -b master_1 master
git merge feature ＃ 在隔离分支解决
git checkout master
git merge master_1 ＃ 快进合并（无冲突）

企业级开发的最佳实践建议：

1. 使用 --no-ff 合并保证历史可追溯
2. 通过 Merge Request 机制合并 master_1
3. 在 master_1 分支触发完整 CI 流水线
4. 合并后立即删除 master_1 分支

这种方式既能保证主分支稳定性，又符合审计要求，是大型项目协同开发的常规做法。理解这个设计需要跳出个人开发视角，从团队协作和交付安全的角度思考分支策略的价值。

来自 Deepseek 回答

＃13 feature rebase 就行了吧，而不要使用 merge

你每次合并前 rebase 一下 master 就可以了

merge queue 的需求啊 github 已经原生支持了 就是防止并行开发冲突的

如果 feature 分支是和其他人共享的，就不要用 rebase ，用 merge

rebase 可能需要多次解决冲突并且会改变/丢失历史，能接受就没问题。

唯一的区别是生成下个 commit 记录的 first parent commit 是 master 上的最后一个 commit 还是 feature 上的最后一个 commit.用了 fast forward merge 就是没有区别

我比较喜欢 feature 开发完成后，master rebase 到 feature ，然后 feature 再 merge 到 master ，冲突都在 feature 上解决了

建议撤回，等会有人举报你

feature 上和别人不共用就
git pull --rebase origin master
git push -f

假如用了 gitlab 或者 GitHub 冲突了，会有提示，按照提示操作就是最佳的方案。

＃46 为啥, 违反论坛规则了?

我选择 rebase 过来再提交，自己的功能分支随便玩，master 上的代码也是稳定的，问题不大

＃38 是的，而且是死刑

插眼. 我一直都是用的方法 1. 等大佬们讲下有啥更好的方法.

提示：v 站没有办法自己删除任何帖子和评论，只要发出来的就永远留存了
v2 禁止发任何 AI 输出的评论，注意是 禁止任何，发了就会被删号，除非本身是讨论 AI 输出相关的（不确定）
规则详情见： www.hesudu.com/about
具体例子见： fast.hesudu.com/t/1112516

建议换个 LD