请教一个开发流程中 GIT 解决冲突的问题

[sngxx]

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

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

[iMusic]

不理解

[lasuar]

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

[wu00]

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

[RightHand]

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

[Razio]

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

[JYii]

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

[liuguangxuan]

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

[inhzus]

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

[sagaxu]

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

[vcbal]

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

[zomco]

rebase 吧

[dxk611]

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

[leonshaw]

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

[nanrenlei]

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

[Ayanokouji]

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

[sfz97308]

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

[jamel]

说不理解的 都没开发过复杂的场景。比如：
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 怎么玩，还怎么发布上线？

[Felldeadbird]

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

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

[daimon1]

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

[whoosy]

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

[h1298841903]

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

[030]

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

[030]

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

[JLNR]

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

[gesse]

没有人说要用 squash merge 吗？

[JLNR]

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

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

[wwwz]

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

[whoosy]

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

[leonshaw]

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

[virusdefender]

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

[kapaseker]

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

[elron]

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

[xfmaa]

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

[sngxx]

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

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

[xfmaa]

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

[GeruzoniAnsasu]

两者不等价。见 https://v2ex.com/t/1101348#r_15733764

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

[SayHeya]

实际用方法一

[clovershell]

两种合并方式的本质区别在于合并方向和对历史记录的影响，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 规范：临时发布分支模式是标准持续交付实践

**技术实现差异对比：**
```bash
# 方式一
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 回答

[codingbody]

@leonshaw #13 feature rebase 就行了吧，而不要使用 merge

[unco020511]

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

[JohnSmith]

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

[ryougifujino]

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

[leonshaw]

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

[galenjiang]

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

[nekochyan]

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

[MingLovesLife]

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

[guanzhangzhang]

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

[galenjiang]

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

[clovershell]

@MingLovesLife #46 为啥, 违反论坛规则了?

[lc5900]

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

[inkmulberry]

@clovershell #38 是的，而且是死刑

[jqtmviyu]

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

[0o0o0o0]

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

[HB9527]

建议换个 LD

[Rickkkkkkk]

38 楼 @Livid

[nicholasxuu]

正常是第一种，第二种是多人多个更新，一起上公交车（中间 PR ），去坐火车（正式发布）的方式。
如果只有一个分支要更新发布，脱裤子放屁。。。

[gaeco]

@clovershell #49 一会号没了

[hfl1995]

还有个建议：

多关注提交通知，主分支有更新，就及时合并的你自己的分支，这样几乎遇不到冲突
不要在功能分支改别人写的基础代码，有修改需求，让代码的原作者自己改了提交，然后你再合过来

[gaeco]

直接开发分支变🐔（基），然后合并到 master

[qishua]

@xfmaa 我觉得你说的对+有道理

[Reficul]

方法 1 不讲究，但是比较简单，很多人都只会这样。
方法 2 的话，如果在后来 merge 到 master 的时候如果发生了 fast-forward merge 的话，本质上和 rebase 是一样的。而如果这个临时分支和 master 分支是一样的，即 remote master 还没新的提交的时候，我记得没错的话默认会发生 ff 合并。

总结下，最好本地 rebase 之后 force push 到 feature 分支，然后直接合并到 master 。方法 2 可能可以得到一样的效果，算次优吧。

不讲究随便弄就来回 merge 好了，又不是不能用，反正代码不会丢。

[Reficul]

不对，讲错了，更正下：即使 ff 合并也 rebase 后合并不一样，冲突解决的部分是发生在 merge commit 里的。
不过结论不变。

[aababc]

我们是两个都用，当没有冲突的时候直接提 pr ，当有冲突的时候从 master 创建一个新的分支然后把 feature 合并到新分支之后 使用新的分支再提 pr

[yx1989]

@JYii 是的。二就是这么用的，发布过没问题的版本才会被合入真正的 master 。

[ooops]

都不用，用 rebase

[KingHL]

二有个叫法叫做 release 分支，多分支合作开发的时候，通过 release 分支合并不同的 feature 分支代码发布，发布完成之后再合入 master 。

[chenqixinlife]

开发分支的 commit 比较少的情况下，可以使用 rebase （没把我别用），这样 git log 是一条直线美观。使用 merge 多了后 gitlog 看着比较乱

[mywjyw]

@Rickkkkkkk 喜欢打小报告的小哥哥一枚呀

[Rickkkkkkk]

@mywjyw 你也不喜欢看一堆 ai 回答吧

[EMMMMMMMMM]

一堆人说是一样的？？
feature 分支被污染了你说是一样的？ master 被回滚你的 feature 分支怎么上线？

[EMMMMMMMMM]

@jamel 一针见血

[Maboroshii]

回滚的话肯定用 tag 啊。第一种没什么问题，本地解决冲突再去 merge 到主 master ，不过有精力的话，rebase 肯定是最佳选择。

[yuankui]

github 的 squash 挺好用的。

将 main 合入 feaure 分支解决冲突不应该是常规操作了吗？

[jokechen]

在我看来，这两种思路本质上是把 master 合并到 feature 还是把 feature 合并到 master 的问题。
无论哪一种，只要你没有用到 no-ff ，都是会产生一个新的合并出来。
如果用到了 no-ff ，那我猜可能你 LD 的做法出来的图会好看些？（人在火车上，没有电脑没办法实践，你可以试试）

[jokechen]

@jokechen 写反了，如果用了 ff ，你 LD 的图可能好看些。

[zt5b79527]

学一下 rebase 吧，这才是你问题的最正确解法

[macha]

我感觉我周围很多人都很依赖 git 的合并算法，其实冲突比较多的时候，最好是拉着同事一起合代码，这样最保险。

[Lemonadeccc]

我们小公司习惯用 rebase ，然后 merge 。一般自己的提交在提交前都 stash ，更最新之后 stash apply 解决自己的冲突然后 push ，再在主分支 merge 新的 feat

[myderr]

哈哈，我们就是当 svn 用，直接 master 一把梭

[Wh1t3zZ]

我的习惯是将自己的 feature 分支频繁 rebase 到 master 分支，如果出现冲突，在自己的 feature 分支里该回滚就 reset ，该整理 commit 就 squash ，该强制推送就强推，保证合并回 master 分支时没有冲突，并且 git graph 是能清晰向前推进的。

[hnliuzesen]

感觉这两种都是在合入 master 时使用 rebase 的情况下有意义，可以保持 master 是一条线

[GaGaGood]

大厂方案：
1. 开发：基于 master 拉 feature
2. 上线：基于 master 拉 release ，合并 feature 到 release ，发布 release 上线
3. 上线后：合并 release 到 master

总结：
1. 开发：feature
2. 上线：release
3. 备份：master

[FrankAdler]

方案 1 就可以了，除了人情世故，上面那些洋洋洒洒一大堆的以为自己很有经验的，求求你们试试 squash merge 吧，所有问题都解决了

[cuizibo]

方案 2 类似 gitflow 的模式吧，master_1 等同于 develop

[Laobai]

你只需要嗯嗯嗯，好好好，然后自己用方法一就行了

[HangoX]

@RightHand 刚想说这个，就是当做 svn 用了
git local 的 master 和 remote 的 master 本来就是两个分支，合并到 master 上是合并到 local 的 master 上其实就是 master1 ，然后在 push 的时候其实是一个 fast forward 。

[korvin]

为什么不把 feature 直接全入 master ，然后解决冲突

[mnhkahn]

1 就行，diff 是关键

[zbowen66]

为什么不是 rebase ？为什么不是 squash merge ？

[demonzoo]

rebase 吧？在你的 feature branch 基于 master branch 操作 rebase

[wangyzj]

你的 dev 和 release 呢
如果非得二选一
应该选择 1
另外，1 是周期性的，并不是上线前

[UV]

我们是会基于 master 分支 checkout 一个带发版日期的版本分支 A 出来， 然后把多个 feature 合并到分支 A ，解决冲突后，发版时再把分支 A 合并到 master 。类似于你说的方法 2 。

[Nick66]

直接在 master 解决 测试没问题再提交代码

[rainbowhu]

feature 与 master 有冲突，说明 feature 版本落后了，要同步下 master 最新代码。
rebase 方式：
```sh
git checkout feature
git pull
git pull --rebase origin master # 更新本地分支，并解决冲突
git push -f # 确保 feature 只有自己使用或着没有别人推代码
#创建 mr ，如果已有 mr ，此时不会再显示冲突。如果过段时间又有冲突，重复此步骤
```

另外还有 merge commit 方式，如果没有 mr 等复杂流程：
```sh
git checkout master
git fetch
git pull
git merge origin/feature # 解决冲突，会产生 1 个 merge commit
git push
```

如果有 mr 流程(与 rebase 方式类似，只是会多 1 个 merge commit)
```sh
git checkout feature
git fetch
git pull
git merge oirgin/master # 解决冲突，会产生 1 个 merge commit
git push
#创建 mr ，如果已有 mr ，此时不会再显示冲突。如果过段时间又有冲突，重复此步骤
```

命令简单写的，不是很精简，理解意思即可

[rainbowhu]

当然还有一些简单的方式
```sh
git checkout feature
git pull --rebase origin master # 解决冲突
git push origin feature:master
```