场景:
现有 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
目前我的解决方式是,手动修改冲突信息为自己想要的内容,请问各位有更好的解决办法吗
1
Rache1 2023-05-11 16:20:29 +08:00
这就是合并冲突的意义所在了,冲突的情况并不只有 apply ours 和 apply theirs 。
|
2
unco020511 2023-05-11 16:38:09 +08:00
如果只是 hotfix ,一般改动都很小,我可能会选择 pick 到 dev.
另外如果 featureA 1.0 和 featureB 1.0 在不同的行.理论上 git 是不会产生冲突的,既然冲突了,你手动修改一下吧 |
3
iyyy 2023-05-11 16:40:21 +08:00
手动解决冲突
|
4
CEBBCAT 2023-05-11 17:23:35 +08:00
提出我的一些浅薄见解:
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 |
5
fzzf230 2023-05-11 18:05:26 +08:00
手动解决冲突+1
|
6
9a09e 2023-05-11 18:13:39 +08:00
这种情况就需要手动合并解决冲突了哦,Accept both 然后手动解决冲突,然后 commit 。
|
7
lovelylain 2023-05-11 18:22:54 +08:00 via Android
我以为会 checkout -2 -3 的是少数,很多人是手动解决冲突的,结果你竟然没手动改过?
|
8
liuidetmks 2023-05-11 18:27:19 +08:00
我总是不知道 ours theirs 到底哪个是我的
|
9
arvinsilm 2023-05-11 18:31:36 +08:00
不是所有的冲突都能完美自动合并,或许可以考虑接入 AI 来做这个事
|
10
KnightYui 2023-05-11 20:07:21 +08:00
在做大型项目的时候,很容易碰到冲突,而且很有可能是别人修改之后这个地方实现逻辑跟原来完全不同了,这时候不就是要手动修改,解决冲突么?
不是简单的合并代码到一块,连逻辑都需要重新考虑。 |
11
FrankAdler 2023-05-11 20:32:01 +08:00 via iPhone
前面的所有回答甚至都没理解楼主的意思
|
12
nightwitch 2023-05-11 21:01:25 +08:00 via Android
关键词 3-way merge ,搜一搜吧,你这种需求在实际的开发场景下太常见了
|
13
karott7 2023-05-12 13:46:05 +08:00 1
如果是我,我不会在 dev 分支上 merge hotfix 分支,我认为 hotfix 只能被 master merge ,其他分支(比如 dev )应该执行 rebase master ,如果有冲突就手动解决冲突;
另外手动解决冲突很常见,开发中同事之间应尽量避免开发同一个模块 |