如何在主Git仓库中新增子Git仓库?
摘要:一、前言 目前在开发一个QT项目,需要搭配师兄的一个仓库代码进行使用。考虑到后续可能需要对这个子仓库代码进行更新,所以最好是让主仓库也可以跟踪这个子仓库的代码。 二、实现方法比较 实现子仓库Git跟踪的方式、优缺点介绍如下: Git子模块(
一、前言
目前在开发一个QT项目,需要搭配师兄的一个仓库代码进行使用。考虑到后续可能需要对这个子仓库代码进行更新,所以最好是让主仓库也可以跟踪这个子仓库的代码。
二、实现方法比较
实现子仓库Git跟踪的方式、优缺点介绍如下:
Git子模块(Submodule)
优点
明确的仓库分离:子模块保持独立的版本控制,清晰显示为外部依赖
版本精确锁定:主仓库引用子模块的特定提交,确保所有人使用完全相同的版本
存储效率:主仓库只存储子模块的引用和路径,不包含子模块的实际内容
独立更新:子模块可以单独进行更新和版本控制,不会影响主仓库
权限分离:适合团队分工,不同人负责不同模块的场景
缺点
使用复杂性:需要学习额外的Git命令,操作流程较复杂
克隆步骤增加:其他人克隆项目时需要额外的步骤初始化子模块 (--recursive 选项)
更新不自动:子模块不会自动更新到最新版本,需要手动更新
历史追踪困难:难以查看包含子模块变更的完整项目历史
Git子树(Subtree)
优点
单一仓库体验:对于使用者来说,就像在操作单一仓库
完整性:克隆主仓库时自动包含所有子树内容,不需要额外步骤
历史完整:可以在主仓库中查看包含子树的完整历史
简单使用:对大多数团队成员来说,不需要了解子树的存在
向后兼容:可以与不了解子树的开发者协作
缺点
仓库体积增大:主仓库包含子树的全部内容,增加了仓库大小
双向同步复杂:向原始子仓库贡献更改的流程较复杂
合并冲突风险:当子树和主仓库同时修改时,可能产生复杂的合并冲突
历史混合:子树的提交历史会混入主仓库的历史
三、Git子模块(Submodule)的使用方式
我目前选择Git子模块(Submodule)来进行子仓库的更新,Git子树(Subtree)的使用方式后续会编写博客进行记录。
1. 移除当前嵌入式仓库并添加为子模块
已知子仓库位于主仓库根目录的 lib/AIEngine/proj_ai_engine
步骤1:移除缓存中的嵌入式仓库(不会删除代码,只是删除缓存)
# 确保在主仓库根目录下
git rm --cached lib/AIEngine/proj_ai_engine
步骤2:添加子模块
# 使用子仓库的远程URL添加子模块
git submodule add <子仓库URL> lib/AIEngine/proj_ai_engine
步骤3:提交更改
git add .gitmodules lib/AIEngine/proj_ai_engine
git commit -m "Add proj_ai_engine as a submodule"
此时在主仓库的根目录下面就会有一个.gitmodules存在了。
2. 跟踪子仓库的分支,以“remotes/origin/feature/windows-support”分支为例子
步骤1:进入子模块目录
# 确保在主仓库根目录下
cd lib/AIEngine/proj_ai_engine
步骤2:拉取远程分支(如果本地没有)
首先,我们需要确认本地是否存在 feature/windows-support 分支。 如果不存在,我们需要从远程拉取。
git fetch origin
现在你可以看到 origin/feature/windows-support 分支。
