Git仓库本地用软链接，如何实现克隆主仓库时自动拉取公共子仓库？

当然可以实现啦！你本地用软链接指向独立Common仓库的操作完全不影响远程仓库的配置，咱们可以借助Git的官方功能，让其他人克隆Project One或Two时，自动把Common仓库拉取到指定的common目录（作为子仓库），同时你自己本地依然能保留软链接的使用方式。下面给你两种最实用的方案：

方法一：Git Submodules（最推荐，官方原生子仓库方案） #

这是Git专门为多仓库依赖场景设计的功能，完美匹配你的需求：

1. 先处理你的本地主仓库
   先移除现有的@common软链接（记得先确认Common仓库的本地路径没问题，避免丢失关联）：

   rm @common
   

   然后把Common仓库作为子模块添加到主仓库的common目录（这个目录就是其他人克隆后会看到的子仓库目录）：

   git submodule add <你的Common仓库Git地址> common
   

   执行完后，Git会生成两个关键文件：.gitmodules（记录子模块的配置信息）和common（指向子仓库的版本指针），把这两个文件提交并推送到远程：

   git add .gitmodules common
   git commit -m "添加Common仓库作为子模块"
   git push
   

2. 恢复你本地的软链接用法
   现在你可以删除刚创建的common目录，重新创建软链接指向你原来的独立Common仓库：

   rm -rf common
   ln -s /path/to/你的本地Common仓库路径 common
   

   这样你本地依然能直接操作自己的Common仓库，完全不影响远程的子模块配置。

3. 其他人克隆时的操作
   克隆主仓库时加上--recurse-submodules参数，就能自动拉取Common子仓库：

   git clone --recurse-submodules <Project One/Two的Git地址>
   

   如果已经克隆了主仓库，也可以手动初始化并拉取子模块：

   git submodule init
   git submodule update
   

方法二：Git Subtree（更友好的备选方案） #

如果团队成员觉得子模块的操作有点繁琐，Git Subtree是另一种选择——它会把Common仓库的内容合并到主仓库的common目录，但保持两边的提交历史独立：

1. 在主仓库中配置Subtree
   先添加Common仓库作为远程源：

   git remote add -f common-repo <你的Common仓库Git地址>
   

   把Common仓库的内容合并到本地的common目录（这里的main是Common仓库的主分支，根据实际分支名修改）：

   git subtree add --prefix=common common-repo main --squash
   

   提交并推送到远程：

   git commit -m "通过subtree引入Common仓库"
   git push
   

2. 你本地的软链接设置
   和子模块方案一样，删除自动生成的common目录，创建软链接指向你原来的Common仓库即可，完全不影响远程的内容。

3. 其他人的克隆体验
   其他人直接克隆主仓库后，就能看到完整的common目录内容，不需要额外的初始化操作，后续更新Common内容时，只需要执行：

   git subtree pull --prefix=common common-repo main --squash
   

关键注意事项 #

• 你本地的软链接仅在自己的机器上生效，远程仓库不会存储软链接的目标信息——其他人克隆后得到的是实际的common子仓库目录，和你的本地软链接用法互不干扰。
• 子模块方案的优势是保持仓库完全独立，适合需要单独维护Common仓库版本的场景；Subtree方案对新手更友好，不需要额外学习子模块的操作逻辑。

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