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

git

请教一个诡异的 git 问题 - V2EX 有一个 git 仓库合并问题，不知道怎么办才好分析一个技巧让同事不知道我使用了 ai ： git 忽略本地改动文件，实现不提交 Rebased, 一个 git 客户端发现一个邪修快速清理 Git 项目里面空文件夹的方法🤡 不知道有没有什么其他标准做法. - V2EX zig 写的 100kb 的 wasm 可以 http 读写任意 git 仓库 - V2EX 有人把 IDEA 的 git 客户端做出来了问个关于 rebase 和 github pr 的奇怪的问题 - V2EX idea 同款 git 客户端求推荐 - V2EX 有没有类似 JB 家的 Git 管理工具 - V2EX 大家自己的代码都是放在哪儿 - V2EX 分享一个在 Linux 上编译静态 Git 二进制的项目 - V2EX 上亿的 git 仓库如何做冷热存储分离呢 - V2EX 发现了一个极度臃肿的项目 - V2EX 有什么支持直接连接远程主机 git 仓库的 GUI 工具吗 - V2EX KFCode 官网上线，做好用、靠谱、有趣的 Git 托管平台 - V2EX git 工作流，大家现在用的什么样的？ - V2EX 很奇怪的一个现象，有没人知道是怎么回事，所有 LLM 都说 100%不会出现 - V2EX 我宣布，最好的 git 客户端是腾讯家的 ugit - V2EX Fork 付费版有什么不同？ - V2EX 一位高级工程师的 GIT 需要熟悉到什么程度？ - V2EX 已经 push 到远程仓库的提交，如何修改某个用户的所有提交的邮箱啊 - V2EX [求助下] 关于代码同步问题 - V2EX 一直不理解 Windows 下 git 的这个逻辑，我自己 clone 的仓库还不能删了？ rm -force 也不行 - V2EX 分享一个 Git 存储库治理利器 - hot - V2EX 代码有没有必要备份到多个远程仓库？比如 github 和 codeup。有必要的话最好怎么备份？ - V2EX 请教 git 里怎么删除记录 - V2EX git 中如何将子分支的多个提交作为一个提交合并到主分支？ - V2EX git 切换分支问题 - V2EX git 各种命令执行很慢是什么原因导致的？ - V2EX 有没有大佬指导一下 git 问题 - V2EX git remotes 分支克隆 - V2EX 两处修改需要分开提交吗？ - V2EX 问个 Git 基操：怎么样复制一个文件，能保持历史记录？ - V2EX Linux 的 Ubuntu 系统有类似 Sourcetree 或者 fork 这种 git 图形化操作的客户端工具吗 - V2EX 关于刚刚 git 的问题描述的不清楚，不能编辑主题了，重新发下问题： git 如何对比服务器上最新的代码和本地的区别？ git diff 对比和我预想不一样 - V2EX git 新手求教： git 如何对比服务器上最新的代码和本地的区别？不是本地远端和本地 working。 svn 可以使用 show log，直接对比，调用 beyond compare 很方便。 - V2EX 对上游提 pr，上游的管理员觉得 pr 里面的功能他不需要或者不满意 - V2EX gitee fork 时继承推送规则是否合理？ - V2EX 请教各位关于 Git 合并的问题 - V2EX 请教大家一个测试环境代码合并的问题 - V2EX 推送远程仓库导致本地提交记录消失，如何找回 - V2EX 给上游 pr，自己应该先 pr 到自己的 main 分支吗？ - V2EX 求教：在 fork 的仓库上添加不太可能被 upstream 接受的修改，是不是应该在新开的 branch 上开发？ - V2EX 有哪个 git 的 gui 软件。可以像 idea 的 git 管理那样查看文件历史和代码冲突？现在换到了 cursor，但是这边的代码管理个人用的太不习惯了。 - V2EX git clean 还能找回吗 - V2EX 求助 git 自动 merge 丢代码 - V2EX 码云代码自动同步到 github - V2EX 请教大家这样的项目应该要怎么做 git 管理 - V2EX 从本地提交代码到 gitlab 后， diff 异常问题，求大佬解惑 - V2EX 在 Git 中，已知某一个分支的某个 Commit 引入了一个 bug，如何快速确定这个 bug 是经过哪些分支流转到 master 分支的？ git rebase 那么重要么??? 如何在 git 提交前将生产版本和开发版本的配置进行区分开源了个新的版本控制系统 HugeSCM，请 V 友们指导 Git Permission denied 问题求助

sngxx · 2025-03-05 · via git

这是一个创建于 466 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

freemoon 2025 年 3 月 5 日

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

wu00 2025 年 3 月 5 日

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

RightHand 2025 年 3 月 5 日 via Android

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

Razio 2025 年 3 月 5 日

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

JYii 2025 年 3 月 5 日

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

liuguangxuan 2025 年 3 月 5 日

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

inhzus 2025 年 3 月 5 日

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

sagaxu 2025 年 3 月 5 日

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

vcbal 2025 年 3 月 5 日

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

zomco 2025 年 3 月 5 日

rebase 吧

dxk611 2025 年 3 月 5 日 via iPhone

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

leonshaw 2025 年 3 月 5 日

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

nanrenlei 2025 年 3 月 5 日

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

Ayanokouji 2025 年 3 月 5 日

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

sfz97308 2025 年 3 月 5 日

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

jamel 2025 年 3 月 5 日

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

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

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

daimon1 2025 年 3 月 5 日

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

whoosy 2025 年 3 月 5 日

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

h1298841903 2025 年 3 月 5 日

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

030 2025 年 3 月 5 日

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

030 2025 年 3 月 5 日

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

JLNR 2025 年 3 月 5 日

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

gesse 2025 年 3 月 5 日

没有人说要用 squash merge 吗？

JLNR 2025 年 3 月 5 日

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

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

wwwz 2025 年 3 月 5 日

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

whoosy 2025 年 3 月 5 日

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

virusdefender 2025 年 3 月 5 日

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

kapaseker 2025 年 3 月 5 日

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

elron 2025 年 3 月 5 日

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

xfmaa 2025 年 3 月 5 日

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

sngxx 2025 年 3 月 5 日

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

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

xfmaa 2025 年 3 月 5 日

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

SayHeya 2025 年 3 月 5 日

实际用方法一

clovershell 2025 年 3 月 5 日

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

unco020511 2025 年 3 月 5 日

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

JohnSmith 2025 年 3 月 5 日 via Android

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

ryougifujino 2025 年 3 月 5 日

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

galenjiang 2025 年 3 月 5 日

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

nekochyan 2025 年 3 月 5 日

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

guanzhangzhang 2025 年 3 月 5 日

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

galenjiang 2025 年 3 月 5 日

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

lc5900 2025 年 3 月 5 日

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

jqtmviyu 2025 年 3 月 5 日

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

HB9527 2025 年 3 月 5 日

建议换个 LD

nicholasxuu 2025 年 3 月 5 日

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

FringJX 2025 年 3 月 5 日

还有个建议：

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

gaeco 2025 年 3 月 5 日

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

Reficul 2025 年 3 月 5 日

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

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

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

Reficul 2025 年 3 月 5 日

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

aababc 2025 年 3 月 5 日

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

yx1989 2025 年 3 月 5 日

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

ooops 2025 年 3 月 5 日

都不用，用 rebase

KingHL 2025 年 3 月 5 日

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

CoderChan 2025 年 3 月 5 日

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

EMMMMMMMMM 2025 年 3 月 6 日 via Android

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

Maboroshii 2025 年 3 月 6 日

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

yuankui 2025 年 3 月 6 日

github 的 squash 挺好用的。

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

jokechen 2025 年 3 月 6 日 via Android

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

jokechen 2025 年 3 月 6 日 via Android

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

zt5b79527 2025 年 3 月 6 日

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

macha 2025 年 3 月 6 日

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

Lemonadeccc 2025 年 3 月 6 日

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

myderr 2025 年 3 月 6 日

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

Wh1t3zZ 2025 年 3 月 6 日

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

hnliuzesen 2025 年 3 月 6 日

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

GaGaGood 2025 年 3 月 6 日

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

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

FrankAdler 2025 年 3 月 6 日 via Android

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

Boben 2025 年 3 月 6 日

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

Laobai 2025 年 3 月 6 日

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

HangoX 2025 年 3 月 6 日

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

korvin 2025 年 3 月 6 日

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

mnhkahn 2025 年 3 月 6 日

1 就行，diff 是关键

zbowen66 2025 年 3 月 6 日

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

demonzoo 2025 年 3 月 6 日

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

wangyzj 2025 年 3 月 6 日

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

OnePunchMan100 2025 年 3 月 6 日

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

Nick66 2025 年 3 月 6 日

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

rainbowhu 2025 年 3 月 6 日

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 2025 年 3 月 6 日

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