我目前正在考虑迁移到git，但似乎无法找到我们目前使用svn标签的方式的优雅解决方案。在我目前的存储库中，我有
tags
tags/1
tags/1.1
tags/1.n
tags/live
tags/library
tags/library/1
tags/library/2
其中1-1.n是发行版，我将最新版本合并到live中，库包含每个版本可能使用的库。我理解如何在git中创建1.n标签，但我很难看到如何创建实时和库标签。
我是否应该为此单独设置一个repo并将1-1.n中的标签作为子模块拉入，或者可以直接执行此操作？
答案 0 :(得分：1)
在我看来，live应该是分支，而不是标记。以防你不知道：与svn不同，svn将分支和标签视为简单的树复制操作（唯一的区别是你使用它们时使用的约定），git的分支和标签只是指向特定提交的指针，主要区别在于活动分支遵循提交，而标记始终保留在它们创建的提交上。
库目录不是分支或标记。它可能会被git子模块取代，但它们是一个棘手的小bug工具，所以你可能想要避开它们，直到你在一般的git工作流程中提高你的技能。别误会我的意思;子模块正是用于管理第三方依赖关系的正确工具，但它们确实需要一些人习惯，如果你对底层git模型没有强烈的直觉，那么它们看起来会非常神秘和破碎。
用更一般的术语来说，从svn转到git时丢失的大事是预先建立的工作流程的便利性。 Git让你可以遵循常见的svn工作流程以及更多，但是如果你不对git的使用方式采取某种限制，你就可以轻松地制作你历史的炒鸡蛋。您可以找到非常有效的工作流here。它不是唯一可行的工作流程，它甚至可能不是最适合您的情况，但它可以作为您构建自己的工作流程的起点。例如，在我们的商店，也是从svn转移，我们坚持在master进行大部分提交，他们使用develop分支，我们在release上标记内容分支而不是他们的master。因此，我们的工作流程基本上与他们的工作流程相同，但是对于长寿分支的名称选择不同。