我有几个库，libA、libB、libC。它们每个都是颠覆中的不同项目，结构如下：
libA 不依赖于任何人，libB 依赖于 libA，libC 依赖于 libB 和 libA。
我有一个项目 MyProject，它依赖于 3 个库。当我在 MyProject 中创建标签时，我希望将来能够签出该标签并编译并使用它。问题是，如果 MyProject 的标签版本针对 3 个库的主干进行编译，它们可能会发生变化，并且可能会发生当我签出标签时，它可能无法编译或工作不同。为了以与制作标签时相同的方式工作，我应该将库签出到正确的版本（我应该按存储库查找存储库的版本）。
我目前的解决方案是，为每个库制作一个标签，然后根据标签编译MyProject的标签。在 Subversion 中，标签只是一个副本，因此每当我签出 MyProject 标签时，它都会指向已经存在的标签。问题是，随着时间的推移，标签数量会增加，尽管存储库大小没有增加，但磁盘中的大小却增加了。
现在我想迁移到git。 Git 标签不是副本，所以我有原来的问题。如果我转到 MyProject 的标签版本，其他库可能已更改，因此我应该更改其他库的版本。
如何解决这个问题？
一种解决方案是指示您需要使用其他库的哪些标签进行编译。我建议的另一个解决方案是使用 git 子树合并，以便您可以将其他库的适当版本嵌入到您正在构建的版本中。在这种情况下，每个库都有自己的存储库。然后，您就拥有了一个将不同库集成在一起的附加存储库。
这实际上取决于您处理这些库的方式以及它们需要如何相互独立。
简而言之，不要针对其他库的“主干”进行编译，在编译时管理它们并用标签标记它们，以便稍后可以重新编译旧的组合版本。 （这对于回归测试通常很重要。）
说 git tag 不是“副本”而 true 也不完全是一个高级声明。 Git 标签就像分支一样，只是它们不会移动。它们是指向给定提交的指针。这正是他们非常适合做的事情。您在所有这些库上放置相同的标签，以便您可以检查用于生成给定构建的确切组合。
我看到的主要问题是你还没有完全理解 git 是如何工作的。主干/分支/标签的区别是没有用的，因为它们是在本地正确管理的，而不是 svn 操作它们的方式。
我真的强烈建议你阅读 git 的书来学习如何使用 git，而不是将其视为我需要采取什么步骤来执行 x 操作？ http://git-scm.com/book
最后，在 SVN 或 GIT 上标记或不标记它都不会增加文件大小，系统知道代码是常见且重复的。