现有项目Git版本控制选型：单仓vs多仓及外部Submodules可行性

背景说明 #

现有项目目录结构固定如下：

/pipeline
  /project1
  /project2
  /project3
  /etc.
  /sharedcode1
  /sharedcode2
  /etc.

每个项目由1-3人的小团队负责，项目间基本独立，但都依赖/sharedcode下的代码。因团队和项目独立性强，倾向采用多仓策略，但遇到Git子模块的管理问题：想让project1引入sharedcode1和sharedcode2作为子模块，且克隆后形成如下本地结构，但不确定Git是否支持主项目目录外的子模块：

/local_dev_environment
  /project1
  /sharedcode1
  /sharedcode2

核心问题解答 #

Git原生不支持主项目目录外的子模块。因为Git子模块的.gitmodules配置文件中，子模块的路径是相对于主仓库根目录的相对路径，只能指向主仓库内部的子目录，无法指向同级或上级目录的外部路径。如果强行配置外部路径，克隆时会报错，也无法正常同步更新。

可行替代方案 #

1. 脚本化本地目录初始化（最贴合需求） #

• 远程仓库保持多仓独立：project1、sharedcode1、sharedcode2各自作为独立Git仓库
• 编写一个简单的初始化脚本（比如setup-dev-env.sh），一键创建预期的本地目录结构并克隆仓库：

  #!/bin/bash
  mkdir -p local_dev_environment
  cd local_dev_environment
  git clone <project1仓库地址>
  git clone <sharedcode1仓库地址>
  git clone <sharedcode2仓库地址>
  # 可选：添加项目依赖路径配置，比如给project1设置环境变量或修改配置文件
  

• 让开发者执行脚本即可完成环境搭建，同时在项目文档中说明依赖路径的配置方式（比如通过构建工具指定同级目录的sharedcode路径）

2. 使用Git Subtree替代Submodules #

• 把sharedcode的代码合并到project1的内部子目录（比如project1/shared-deps/），但保留sharedcode仓库的独立提交历史
• 拉取sharedcode的更新：

  git subtree pull --prefix=shared-deps/sharedcode1 <sharedcode1仓库地址> main
  

• 推送对sharedcode的修改到远程仓库：

  git subtree push --prefix=shared-deps/sharedcode1 <sharedcode1仓库地址> main
  

• 优势是不需要开发者处理子模块的复杂操作，本地可以通过构建工具把内部的shared-deps目录映射到预期的同级路径

3. 采用私有依赖包管理 #

• 把sharedcode打包成私有依赖包（比如npm包、PyPI包、Maven包等），上传到私有包仓库
• 每个项目通过对应的包管理工具（npm/pip/mvn）安装依赖，依赖会自动下载到项目的依赖目录（比如node_modules）
• 这种方式是现代项目依赖管理的标准方案，能清晰追踪依赖版本，避免Git子模块的各种坑，同时支持版本锁定、更新回滚等功能

内容的提问来源于stack exchange，提问作者masky007