git merge 出现冲突时， incoming change 和 current change 都不完全是自己想要的，如何解决？

[Ghrhrrv146]

场景：

现有 master 、dev 分支，假设 master 分支中有一文件 a.txt ，内容为

featureA 1.0
featureB 1.0

而 dev 分支已经迭代了好几个版本，假设该分支下 a.txt 内容为

featureA 1.0
featureB 2.0

现在，a.txt 有一个紧急 bug 需要修复，常规做法是基于 master 分支 checkout 一条 hotfix 分支，在 hotfix 分支中修复 bug ，假设修复后 a.txt 的内容为：

featureA 1.1
featureB 1.0

然后把 hotfix 分支 merge 到 master 分支即可，到这一步我都没有疑问，我的疑惑是，当我在 dev 分支执行

git merge hotfix

冲突信息是这样的:

<<<<<<< HEAD
featureA 1.0
featureB 2.0
=======
featureA 1.1
featureB 1.0
>>>>>>> hotfix

而我实际想要的是

featureA 1.1
featureB 2.0

目前我的解决方式是，手动修改冲突信息为自己想要的内容，请问各位有更好的解决办法吗

[Rache1]

这就是合并冲突的意义所在了，冲突的情况并不只有 apply ours 和 apply theirs 。

[unco020511]

如果只是 hotfix ,一般改动都很小,我可能会选择 pick 到 dev.
另外如果 featureA 1.0 和 featureB 1.0 在不同的行.理论上 git 是不会产生冲突的,既然冲突了,你手动修改一下吧

[iyyy]

手动解决冲突

[CEBBCAT]

提出我的一些浅薄见解：
1. 冲突是可以理解的
2. 别的工具我不太了解，IntellIJ 系列工具 Merge 工具左上角有一个小刷子按钮，可以尝试用它解决简单冲突
3. 我听别人说过一种说法，大概是“冲突意味分工不明确”。就这个例子而言，可以把这个文件分拆为三个文件：
3.1 list.txt ，内含一个列表，代表拼接顺序
3.2 A.txt 存放 “featureA 1.0” 这一行
3.3 B.txt 存放 “featureB 1.0” 这一行
3.4 发布时，使用自动化工具根据 list.txt 记载的顺序拼接出 finnal.txt

[fzzf230]

手动解决冲突+1

[9a09e]

这种情况就需要手动合并解决冲突了哦，Accept both 然后手动解决冲突，然后 commit 。

[lovelylain]

我以为会 checkout -2 -3 的是少数，很多人是手动解决冲突的，结果你竟然没手动改过？

[liuidetmks]

我总是不知道 ours theirs 到底哪个是我的

[arvinsilm]

不是所有的冲突都能完美自动合并，或许可以考虑接入 AI 来做这个事

[KnightYui]

在做大型项目的时候，很容易碰到冲突，而且很有可能是别人修改之后这个地方实现逻辑跟原来完全不同了，这时候不就是要手动修改，解决冲突么？
不是简单的合并代码到一块，连逻辑都需要重新考虑。

[FrankAdler]

前面的所有回答甚至都没理解楼主的意思

[nightwitch]

关键词 3-way merge ，搜一搜吧，你这种需求在实际的开发场景下太常见了

[karott7]

如果是我，我不会在 dev 分支上 merge hotfix 分支，我认为 hotfix 只能被 master merge ，其他分支（比如 dev ）应该执行 rebase master ，如果有冲突就手动解决冲突；
另外手动解决冲突很常见，开发中同事之间应尽量避免开发同一个模块