如何在主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 分支。
阅读全文