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

sngxx · 2025-03-05T03:21:27Z

基准分支是 master ，开发分支是 feature 。现在准备发布上线了，需要 feature 合入 master ，此时有冲突，我解决冲突有两种方式。一是：直接把 master 合入 feature 解决冲突，再把 feature 合入 master ；二是：先从 master 拉出分支 master_1 ，把 feature 合入 master_1 解决冲突，再把 master_1 合入 master ；这 2 种有区别吗，LD 必须让第二种，不理解。

git

冲突解决

开发流程

121 replies • 2025-03-08 08:29:27 +08:00

1 2

❮

❯

MzM2ODkx

Mar 5, 2025

1

不理解

freemoon

Mar 5, 2025

1

2

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

wu00

Mar 5, 2025

3

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

RightHand

Mar 5, 2025 via Android

4

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

Razio

Mar 5, 2025

5

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

JYii

Mar 5, 2025

6

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

liuguangxuan

Mar 5, 2025

7

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

inhzus

Mar 5, 2025

8

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

sagaxu

Mar 5, 2025

9

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

vcbal

Mar 5, 2025

10

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

zomco

Mar 5, 2025

11

rebase 吧

dxk611

Mar 5, 2025 via iPhone

12

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

leonshaw

Mar 5, 2025

1

13

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

nanrenlei

Mar 5, 2025

14

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

Ayanokouji

Mar 5, 2025

15

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

sfz97308

Mar 5, 2025

7

16

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

jamel

Mar 5, 2025

7

17

说不理解的都没开发过复杂的场景。比如：
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

Mar 5, 2025

18

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

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

daimon1

Mar 5, 2025

19

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

whoosy

Mar 5, 2025

2

20

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

h1298841903

Mar 5, 2025

21

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

030

Mar 5, 2025

22

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

030

Mar 5, 2025

23

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

JLNR

Mar 5, 2025

24

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

gesse

Mar 5, 2025

25

没有人说要用 squash merge 吗？

JLNR

Mar 5, 2025

26

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

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

wwwz

Mar 5, 2025

27

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

whoosy

Mar 5, 2025

28

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

leonshaw

Mar 5, 2025

5

29

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

virusdefender

Mar 5, 2025

30

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

kapaseker

Mar 5, 2025

31

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

elron

Mar 5, 2025

32

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

xfmaa

Mar 5, 2025

1

33

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

sngxx

OP

Mar 5, 2025

34

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

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

xfmaa

Mar 5, 2025

35

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

GeruzoniAnsasu

Mar 5, 2025

1

36

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

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

SayHeya

Mar 5, 2025

37

实际用方法一

clovershell

Mar 5, 2025

38

两种合并方式的本质区别在于合并方向和对历史记录的影响，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 回答

Reminders

Mar 5, 2025

39

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

unco020511

Mar 5, 2025

40

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

JohnSmith

Mar 5, 2025 via Android

41

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

ryougifujino

Mar 5, 2025

1

42

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

leonshaw

Mar 5, 2025

43

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

galenjiang

Mar 5, 2025

44

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

nekochyan

Mar 5, 2025

45

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

MingLovesLife

Mar 5, 2025

46

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

guanzhangzhang

Mar 5, 2025

47

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

galenjiang

Mar 5, 2025

48

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

clovershell

Mar 5, 2025

49

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

lc5900

Mar 5, 2025

50

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

inkmulberry

Mar 5, 2025

51

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

jqtmviyu

Mar 5, 2025

52

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

0o0o0o0

Mar 5, 2025

53

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

HB9527

Mar 5, 2025

54

建议换个 LD

Rickkkkkkk

Mar 5, 2025

1

55

38 楼 @Livid

nicholasxuu

Mar 5, 2025

56

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

gaeco

Mar 5, 2025

57

@clovershell #49 一会号没了

FringJX

Mar 5, 2025

58

还有个建议：

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

gaeco

Mar 5, 2025

59

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

qishua

Mar 5, 2025

60

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

Reficul

Mar 5, 2025

61

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

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

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

Reficul

Mar 5, 2025

62

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

aababc

Mar 5, 2025

63

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

yx1989

Mar 5, 2025

64

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

ooops

Mar 5, 2025

2

65

都不用，用 rebase

KingHL

Mar 5, 2025

66

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

CoderChan

Mar 5, 2025

67

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

mywjyw

Mar 5, 2025

68

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

Rickkkkkkk

Mar 5, 2025

4

69

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

EMMMMMMMMM

Mar 6, 2025 via Android

70

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

EMMMMMMMMM

Mar 6, 2025 via Android

71

@jamel 一针见血

Maboroshii

Mar 6, 2025

72

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

yuankui

Mar 6, 2025

73

github 的 squash 挺好用的。

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

jokechen

Mar 6, 2025 via Android

74

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

jokechen

Mar 6, 2025 via Android

75

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

zt5b79527

Mar 6, 2025

76

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

macha

Mar 6, 2025

77

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

Lemonadeccc

Mar 6, 2025

78

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

myderr

Mar 6, 2025

79

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

Wh1t3zZ

Mar 6, 2025

80

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

hnliuzesen

Mar 6, 2025

81

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

GaGaGood

Mar 6, 2025

1

82

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

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

FrankAdler

Mar 6, 2025 via Android

83

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

Boben

Mar 6, 2025

84

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

Laobai

Mar 6, 2025

85

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

HangoX

Mar 6, 2025

86

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

korvin

Mar 6, 2025

87

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

mnhkahn

Mar 6, 2025

88

1 就行，diff 是关键

zbowen66

Mar 6, 2025

89

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

demonzoo

Mar 6, 2025

90

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

wangyzj

Mar 6, 2025

91

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

OnePunchMan100

Mar 6, 2025

92

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

Nick66

Mar 6, 2025

93

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

rainbowhu

Mar 6, 2025

94

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

Mar 6, 2025

95

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

sir283

Mar 6, 2025 via Android

96

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

Livid

MOD

PRO

Mar 6, 2025

97

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

zthxxx

Mar 6, 2025

98

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

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

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

mark2025

Mar 6, 2025

99

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

seanzxx

Mar 6, 2025

100

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

1 2

❮

❯