我目前正在考虑迁移到git，但似乎无法找到一个优雅的解决方案，我们目前使用svn标签的方式。在我目前的资料库我有检出所有的git标签
tags
tags/1
tags/1.1
tags/1.n
tags/live
tags/library
tags/library/1
tags/library/2
其中1-1.n是发布，我合并的最新版本为现场和库包含每个版本可以使用库。我明白如何在git中创建1.n标签，但我正在努力研究如何创建实时标签和库标签。
我应该有一个单独的回购，并从1-1.n作为子模块拉标签，或者可以直接做git？
在我看来，live应该是一个分支，而不是标签。以防万一您不知道：与svn不同，svn将分支和标签视为简单的树形复制操作（唯一区别是您使用它们处理的约定），git的分支和标签只是指向特定提交的指针，主要区别在于活动分支遵循提交，而标签始终停留在创建的提交上。
库目录不是分支或标签。它可能会被git子模块取代，但它们是棘手的小bugger，所以你可能想避开它们，直到你在git工作流程中提高了一点技能。别误会我的意思;子模块恰恰是管理第三方依赖关系的正确工具，但是它们确实需要一些习惯，并且如果您对基础git模型没有强烈的直觉，那么它将显得非常神秘和破碎。
从更一般的角度讲，从svn转到git时丢失的大事是预先建立的工作流的方便性。 Git可以让你遵循常见的svn工作流程以及更多，但是如果你对于如何使用git没有采取某种限制，你可以很容易地制作你的历史炒鸡蛋。你可以找到一个非常有效的工作流程here。它不是唯一可能的工作流程，它可能不是最适合您的情况，但它可以作为您创建自己的工作流程的起点。例如，在我们的商店，也从svn搬到了我们，我们坚持要求我们的大部分提交master，他们使用develop分支，我们在release分支上标记事物，而不是master。因此，我们的工作流程基本上与他们的工作流程相同，但长寿分行的名称选择不同。
谢谢，这真的很有帮助，也是一个很好的开始，但它听起来像git实际上不会让我们做我们想做的事情，因为我们希望同时在一个目录中使用所有这些标记。 – 2012-03-09 22:30:15
@JakeStride，在git中，tags不在任何目录中。你有你的仓库和标签是指向仓库中特定提交的指针。这在git中起作用，因为git中的提交不是线性的：一个提交可以有几个前辈和后继者。 – svick 2012-03-09 22:46:12
@JakeStride：你说得对，但你通常不需要有目录代表标签。标签只是一种用有意义的名称标记特定提交的方式。您可以像使用'git tag'一样轻松列出标签，并使用'git checkout
如果某件事情发生了变化，那么它不应该是标签。而图书馆不应该在他们的标签。它们应该是存储库正常结构的一部分，也可以是不同的存储库。换句话说，你的手上有一团糟，将它转换成合理的方式可能并不容易。 – svick 2012-03-09 22:05:37
在svn这个文件夹结构适用于我们的部署堆栈，并允许我们在同一台机器上运行不同的版本 - 我知道这不是最好的结构，但它适用于我们需要做的事情。 – 2012-03-09 22:31:49
@JakeStride问题在于，您在svn *中调用标签的内容不是标签*，并且不能用作实际知道标签是什么的VCS中的标签。这只是说svn是无知的，可以让你把任何旧东西称为标签。 – hobbs 2012-03-09 22:56:50