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

不理解

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 ，和操作一 等价。

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

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

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

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

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

没有人说要用 squash merge 吗？

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

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

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

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

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

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

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

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

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

两者不等价。见 https://v2ex.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 规范：临时发布分支模式是标准持续交付实践

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

建议换个 LD

38 楼 @Livid

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

@clovershell #49 一会号没了

还有个建议：

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

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

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

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

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

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

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

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

都不用，用 rebase

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

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

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

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

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

@jamel 一针见血

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

github 的 squash 挺好用的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1 就行，diff 是关键

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

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

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

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

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

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 ，此时不会再显示冲突。如果过段时间又有冲突，重复此步骤
```

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

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

直接 git push -f ，管它什么冲突，是 lead 叫我 push 的，我只管 push ，出了问题找 lead 。

@Rickkkkkkk 谢谢，38 楼的账号已经被彻底 ban 。

月经贴。。。 说等价的是真没理解 parent / diff 方向的问题

在不用 rebase 的情况下，最好的做法都是「不要把 master/dev 等公共分支合到自己的 feat 分支，始终保持 开发分支->公共分支 单向合并」

这个问题在 v2 上已经讨论过好几次了

尽量避免“直接把 master 合入 feature 解决冲突”

在 feature 分支 rebase 呀，然后再 merge 到 master