在第二个工作副本中使用子树

Question

假设我们有两个开发人员。一位开发人员在foo / bar / path的“main”git存储库中添加了一个子树（foo /是一个普通目录，foo / bar / now作为子树连接到一个单独的“子树”存储库）。第二个开发人员取消了变化并获得了foo / bar /。但是在他的工作副本中，foo / bar /不是git的子树，它只是主存储库中的一个目录。

现在，第二个开发人员完成了将子树切换到子树存储库中的较新标记的任务。他认为他可以使用git subtree pull从子树存储库中提取，但他需要先添加一个子树。但是他的工作副本中的git subtree add不起作用，因为该目录已经存在。在他的工作副本中，这个目录看起来不像git的子树。

问题：

• 第二个开发人员如何告诉git foo / bar /实际上是一个子树？
• 他如何签出此子树的标签？

Answer 1

我不相信子树有任何内置方法让第二个开发人员知道子目录实际上是一个git子树。指示可能是子树根目录中的文件的最佳方式（我不承认这是不理想的。）

您示例中的第二个开发人员不应该执行git subtree add。他们应该只需要拉动然后推动（再次，他们需要一些其他方式来了解它们的来源）。

要更新子树，第二个开发人员会： （注意：我是子树的新手，所以请把它当作它的价值）

1. 照常进行更改
2. 将他们的更改提交到“主要”存储库
3. 将他们的更改推送到'主'存储库
4. 从子树中提取：git subtree pull --prefix=bar ../bar.git master
5. 推动在子树中进行更改：git subtree push --prefix=bar ../bar.git master

Answer 2

子树的整个要点（与子模块相反）是它们看起来不像存储库而且不需要任何配置文件。 git-subtree使用＆＃34; git-subtree - ＆＃34;编码初始合并提交中后续合并所需的所有信息。前缀，所以两个开发者之间确实没有区别。您的示例中的工作副本。两者同样能够git subtree pull ...。

如果您想拥有可以从上游轻松更新的显式（即可识别的）子存储库，请使用git submodule。