经验:停止 cherry-pick,请开始 merge!

简介: cherry-pick 是一个比较常用的 git 操作,可以将一个分支上的 commit “精选”到另一个分支上。然而在最近的开发过程中,却时不时的遇到 merge 冲突。在下文中,我将会详细的分析 cherry-pick 造成冲突的原因,以及 cherry-pick 可能造成的其他更严重问题。

cherry-pick 是一个比较常用的 git 操作,可以将一个分支上的 commit “精选”到另一个分支上。然而在最近的开发过程中,却时不时的遇到 merge 冲突。在下文中,我将会详细的分析 cherry-pick 造成冲突的原因,以及 cherry-pick 可能造成的其他更严重问题。


我们以一个简单的例子来进行分析:


微信图片_20220414205658.png

如上图:我们有一个 master 分支,以及一个 feature 分支。这个例子中我们只关注其中的一行代码,其初始值(commit A)为 apple。在此基础上我们进行了如下操作:从 master 分支 checkout 出来了 feature 分支。


在 feature 分支进行了 F1 提交,在 master 分支进行了 M1 提交,这些提交都与 apple 这行代码无关。


在 feature 分支进行了 F2 提交,将 apple 修改为 berry。


我们将 F2 提交 cherry-pick 到 master 分支(以虚线表示一次 cherry-pick)。


现在 feature 和 master 分支上这一行代码都是 berry。当最后我们将 feature 分支正式往 master 合并的时候,可能出现三种情况:


这一行代码在两个分支上都没有再修改过,顺利合并。


这一行代码之后在两个分支上又有了修改,结果出现了冲突(解决冲突很麻烦)。


这一行代码之后在两个分支上又有了修改,没有冲突,顺利合并(但是可能导致更严重的错误)。


1. 这一行代码在两个分支上都没有在修改过,顺利合并。

这是最理想的情况,不做分析。


2. 这一行代码之后在两个分支上又有了修改,结果出现了冲突。

微信图片_20220414205923.png


如上图所示,在 cherry-pick 之后,我们又进行了如下操作:在 master 分支进行了 M3 提交,该提交并未修改 berry 这行代码。


在 feature 分支进行了 F3 提交,将 berry 修改为了 cherry。


尝试将 feature 分支往 master 合并:冲突发生。


分析:


合并时,M3 和 F3 的最近公共祖先(merge base)是 commit A,这行代码为 apple,然后对比发现,master 分支上这行代码由 apple 变成了 berry,feature 分支上这行代码由 apple 变成了 cherry,所以冲突出现了。如果我们使用的是 merge 呢?那 M2 到 F2 将是一条实线,M3 和 F3的最近公共祖先(merge base)会是 F2,master 上:


berry -> berry,feature 上 berry -> cherry,因为 master 分支相对 F2没有修改,所以就没有冲突。这只是两个分支的简单情况,随着分支增多,冲突会越来越难以处理。而且这是有冲突的情况,还有一种情况是没有冲突,却可能引发更严重的问题。


3. 这一行代码之后在两个分支上又有了修改,没有冲突,顺利合并。


为了更直观,我们将这一行代码视为一个功能的开关配置:apple 代表这个功能是上线状态,berry 代表这个功能是下线状态。


微信图片_20220414210105.png


如上图,最开始(A),我们这一行代码是 apple,代表功能为上线状态。然后我们发现了一些 bug,需要将该功能紧急下线,我们:在 feature 分支上下线该功能(F2):apple -> berry。


然后将该操作 cherry-pick 到 master(M2),现在 master 上该功能也下线了。


然后我们在 feature 分支上进行了 bug 修复,最终解决了 bug,我们在 feature 分支上将该功能上线(F3):berry -> apple。


然后我们决定将 bug 修复 merge 到 master。


merge 顺利完成,没有冲突。但是:这行代码仍然是berry,下线状态。


merge 分析:

M3(berry) 和 F3(apple) 的最近公共祖先是 A(apple),因此 git 认为 feature 分支并未修改 apple 的值,结果合并后 master 分支上这行代码还是 berry,我们的功能在 master 上还是下线状态。


结论


在开发中,不要使用 cherry-pick 来进行不同分支之间代码的同步,这很可能会造成最终合并时出现冲突,而且可能产生比冲突更严重的问题:该有冲突却没有冲突。ps: 何时使用 cherry-pick


当我们需要在不同分支之间移动提交时,可以使用 cherry-pick。本文主要参考了 Raymond Chen 的系列文章Stop cherry-picking, start merging。作者作为 Windows 开发团队的一员,因为项目需要有很多分支相互 merge,所以 cherry-pick 很容易造成问题。但是如果你的两个分支是两个单独的分支,永远不会相互 merge,那么就可以使用 cherry-pick 而不用担心上述问题。

目录
相关文章
|
C++ Windows
【Debug】VS EXE运行“应用程序无法正常启动(0xc000007b)”
今天在VS2013发布应用程序后,本地电脑可以正常打开exe,但放到其他电脑无法正常启动,打印“应用无法正常启动(0xc000007b)。请单击“确定”关闭应用程序”。
1603 0
【Debug】VS EXE运行“应用程序无法正常启动(0xc000007b)”
|
安全 开发工具 git
合并代码时,你选 Merge 还是 Rebase?
【8月更文挑战第13天】在团队协作开发过程中,代码合并是日常工作中不可或缺的一环。每当多个开发者在同一个项目上工作时,如何将各自的更改整合到主分支上,成为了一个需要仔细考虑的问题。Git 提供了两种主要的合并策略:Merge 和 Rebase,它们各有利弊,适用于不同的场景和需求。
382 0
|
开发工具 git 开发者
关于git 解决分支冲突问题(具体操作,包含截图,教你一步一步解决冲突问题)
本文通过具体操作和截图,详细讲解了如何在Git中解决分支冲突问题,包括如何识别冲突、手动解决冲突代码、提交合并后的代码,以及推送到远程分支。
3710 3
关于git 解决分支冲突问题(具体操作,包含截图,教你一步一步解决冲突问题)
|
安全 开发工具 git
git合并错了,我想回退到之前的版本
git合并错了,我想回退到之前的版本
|
开发工具 git 索引
$ git revert -m v1.0.21 6003eb5f5b455f0a3dfb74f48f63878e7 error: option `mainline' expect
$ git revert -m v1.0.21 6003eb5f5b455f0a3dfb74f48f63878e7 error: option `mainline' expect
|
开发工具 git
|
Web App开发 JavaScript 前端开发
解决Vue.js Devtools未检测到Vue实例的问题
解决Vue.js Devtools未检测到Vue实例的问题
1632 1
|
消息中间件 测试技术 领域建模
DDD - 一文读懂DDD领域驱动设计
DDD - 一文读懂DDD领域驱动设计
46436 6
mybatis-plus防止全表更新与删除
mybatis-plus防止全表更新与删除
343 0
mybatis-plus防止全表更新与删除

热门文章

最新文章