Question

假设我有一个可以独立使用的库Common，并由项目P1和P2使用，因此我想要的树看起来像

/Common/.git
        ...
/P1/.git
    .gitmodules  # points to remote server
    Common/
    ...
/P2/.git
    .gitmodules  # points to remote server
    Common/
    ...

当我在/Common进行更改时，我希望能够在提交之前使用P1和P2对其进行测试。使用通常的git submodule命令集，我必须从/Common提交，推送到远程，然后从/P1/Common和/P2/Common提取。如果提交中断了某些内容，则无法修改，因为已经发布了错误的更改。或者，我可以git remote add quicktest /Common从/P?/Common能够在不触及远程服务器的情况下进行拉取。但是这有很多不一致的机会，从/P?/Common剥离失败的提交是很脏的，因此可以在/Common中修改它们。

我希望在开发过程中，/Common和P1使用来自P2的工作树，但我无法使/P1/Common成为/Common的符号链接{1}}因为git submodule将符号链接识别为与目录不同。大多数文件系统不允许使用硬链接目录。我可以使用

硬链接所有文件

rm -rf /P1/Common
cp -rl /Common /P1/Common

在将新文件添加到/Common之前效果很好，在这种情况下需要重复此过程。

是否有一种优雅的方式

让git clone --recursive git://remote/P1.git为最终用户工作，
允许我轻松测试/Common中P1和P2的变化情况吗？

Answer 1

我宁愿建立一个中间的裸仓库：

推送Common新提交
来自P1/Common和P2/Common

至少，如果稍后修改/删除了提交，那么该中间仓库从未在外部发布，您仍然可以将P1/Common和P2/Common子模块重置为该中间仓库内容。

Answer 2

从git 2.5开始尝试git worktree功能。

删除/P1/Common
cd /Common
为即将到来的P1工作树

/P1/Common

运行git worktree add ../P1/Common P1

在/P2上做同样的事情。

然后，/P1/Common，/P2/Common and / Common working trees share the same repository / Common / .git`。

您可以轻松地检查在另一个工作树中提交的任何提交。

P.S。你仍然可以使用git submodule命令进行日常工作，使用这个git worktree功能。

与git子模块共享一个工作树

2 个答案: