将含多Git仓库的文件夹设为不同远程的Git仓库是否可行？

可行性结论 #

Git完全支持这种操作。你可以在本地repos文件夹根目录初始化一个Git仓库，将所有子仓库（包括各自的.git目录）作为普通文件添加到追踪范围，然后在移动硬盘上创建一个裸仓库作为远程，实现工作电脑与家用电脑之间的推送、拉取流程。Git会将内层仓库的所有文件（包括其Git元数据）当作普通文件处理，不会阻止这类嵌套操作。

冲突风险说明 #

外层repos仓库与内层RepoA/RepoB仓库不会产生原生数据冲突，原因是两者的Git环境完全独立：

• 外层仓库的.git目录位于repos根目录，仅管理该目录下的所有文件内容
• 内层仓库的.git目录位于各自子文件夹内，仅负责对应仓库的版本控制

只要在正确的目录执行Git命令（比如在repos根目录操作外层同步，在RepoA内操作内层仓库的提交/推送），两者的操作互不干扰。唯一的“冲突”可能是人为操作失误（比如在子仓库目录误执行外层仓库的命令），但这不属于Git本身的冲突问题。

潜在的实际问题 #

这种方案存在诸多使用痛点，不推荐作为长期解决方案：

• 存储空间冗余：每个子仓库的.git目录包含完整的本地历史，同步时会重复传输这些数据，导致移动硬盘占用大量额外空间，仓库数量越多、历史越久，问题越严重。
• 操作易混淆：需要时刻区分外层（跨设备同步）和内层（同步到共享网络远程）的Git命令，极易出现操作失误，比如误将内层仓库的变更推送到移动硬盘，或者将外层仓库推送到共享网络。
• 本地状态混乱：如果工作电脑上的子仓库存在未提交/未暂存的变更，外层仓库提交的是当前文件状态，家用电脑拉取后需要手动处理这些未完成的变更，容易遗漏或导致本地状态不一致。
• 路径适配繁琐：不同电脑对移动硬盘的挂载路径不同（如Windows的D:和macOS的/Volumes/xxx），每次连接移动硬盘后可能需要重新配置外层仓库的远程地址。
• 同步性能低下：由于需要处理大量小文件（尤其是内层.git中的Git对象），推送/拉取整个repos文件夹的速度会非常缓慢，远不如单独同步每个子仓库高效。

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