[Git]升级合并两个Git库

最新推荐文章于 2025-05-29 23:59:12 发布

古辛

最新推荐文章于 2025-05-29 23:59:12 发布

阅读量1.6k

点赞数

CC 4.0 BY-SA版权

分类专栏： Git 文章标签： Git Github NiFi Apache fork

本文链接：https://blog.youkuaiyun.com/weixin_42278016/article/details/82882247

Git 专栏收录该内容

3 篇文章

订阅专栏

本文详细介绍了如何在GitHub上将官方代码库的更新合并到个人fork的代码库中，以Apache NiFi项目为例，演示了从克隆仓库、添加远程源、拉取更新到解决合并冲突的全过程。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

对于Github上的开源代码，一般都采用fork方式到自己账户下，进行二次开发定制或增强修正一些功能，久而久之，你fork的代码已经与官方代码有了很大的差别，尤其是当官方升级版本后，也想升级自己fork库的代码，那么就需要涉及升级合并两个库。

以Apache 的NiFi项目为例说明，Github库为

https://github.com/apache/nifi.git

自己fork的库地址为

https://github.com/kemixkoo/nifi.git

自该文时，Apache已发布正式版1.7.1，假设自己fork的master是基于1.7.0-SNAPSHOT，现在需要将Apache官方发布版本的tag "rel/nifi-1.7.1"合并到自己开发分支的master上。

升级合并

为了达到升级合并release tag的目的，首先需要clone自己fork的库：

git clone https://github.com/kemixkoo/nifi.git

然后进入本地的nifi目录（即库工作目录），添加Apache官方NiFi库：

git remote add official https://github.com/apache/nifi.git

然后拉取最新的官方代码：

git fetch official

fetch之后，.git/config里的内容如下：

[core]
   repositoryformatversion = 0
   filemode = true
   bare = false
   logallrefupdates = true
   ignorecase = true
   precomposeunicode = true
[remote "origin"]
   url = https://github.com/kemixkoo/nifi.git
   fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
   remote = origin
   merge = refs/heads/master

[remote "offical"]
   url = https://github.com/apache/nifi.git
   fetch = +refs/heads/*:refs/remotes/offical/*

准备工作已经就绪了，现在就开始正式的代码升级合并，为了保证不破坏原master分支，可临时创建一基于master的升级分支upgrade。

git co -b upgrade origin/master

由于先clone的是自己的fork库，所以默认的origin/master是自己fork的master远程分支，而经过fetch之后official/master是官方的master远程分支。

由于官方的release Tag是以rel开头的，比如rel/nifi-1.7.1，合并升级执行：

git merge rel/nifi-1.7.1

如果有合并冲突，可能有“CONFLICT (content)”之类的信息。可通过执行git status查看具体的冲突文件，在“Unmerged paths”列表下有both开头的，均为冲突文件，具体说明见下表：

状态	操作	说明
both modified	手动解决冲突	文件冲突，需手动解决每一个文件的冲突
both deleted	不做操作	同时都删除，无需做任何操作，也许拉取了官方的单个提交导致
both added	不做操作	同时都添加而无冲突，无需做任何操作，也许拉取了官方的单个新功能提交导致
deleted by us	检查	被我们删除，可能无需做任何操作，需检查依赖
deleted by them	检查	被官方删除，需检查是否有依赖，如果也不需要，可不做任何操作
added by us	不做操作	由我们新添加，无需做任何操作
added by them	不做操作	由官方新添加，可能是新功能，无需做任何操作

因此主要关注“both modified”状态的文件，需要手动一个一个仔细的解决冲突，否则将导致比较严重的后果。

解决完冲突后，即可执行添加index操作，并提交

git add .
git ci -m "Upgrade to 1.7.1"

至此，升级合并操作已完成，实际上如果想合并最新的master，也是类似操作，只是将release tag “rel/nifi-1.7.1”替换为官方的master，即

git merge official/master

但是为了保证升级成功，可执行相应CI程序，比如打包，测试等等后继验证流程。

最后说明几点：

为何用merge而不用rebase？这是因为，rebase解决冲突是每个提交解决一次，如果有比较多的提交有冲突，那么需要解决n次，这是比较烦恼的，采用merge只需一次即可解决所有的冲突。
为何merge没有策略选项，这是因为需要保证所有文件状态都可见，而不采用策略而自动处理，势必导致后期查找问题比较困难。