因此，我们正在缓慢但坚定地将我们的开发从 SVN 转移到 Git（大约是时候了）。我们的团队对 Git 非常熟悉，但 SVN 存储库非常庞大，并且随之而来的是许多其他团队和版本，这增加了我们 Git 方法的复杂性。我尝试过搜索类似的场景，但所有 SO 帖子都相当旧，我想确保我们没有实施一些“旧”的东西，而不是最新的可用实践。
目前（仍在 SVN 上），我们正在同时开发三个版本。一个即将发布，我们称之为版本 1.9，一个是该版本 (1.1) 的更新，我们已经在进行 2.0 版本的工作。这在 SVN 中工作正常，因为每个团队都有自己的开发分支，我们将其合并到 Trunk，然后从那里继续合并到release_1.0。这最终意味着所有 1.1 版和 2.0 版开发现在都将合并到 Trunk 中。当版本 1.0 发布时，我们将分支 version_1.0 -> version_1.1，并简单地从 Trunk -> version_1.1 合并 1.1 所需的特定提交。此外，最终在 1.1 版本发布后，我们将直接创建 Trunk 的 version_2.0 分支，如此继续。这在 SVN 中没有问题，尽管这在 Git 中行不通。
我正在寻找在 Git 中实现类似但“Gitified”的最佳实践。我当前的“最佳计划”如下（在提议的开发分支之前显然是特定开发分支的功能分支或“每个团队”分支。为了简单起见，我在这里不提及这些）：
通过这种方式，我们希望尽可能避免采摘樱桃。不过，我不确定这是否是最好的方法。我们考虑的另一种选择是跳过 1.1 分支，并在 1.0 发布后最终创建 1.1 分支后，简单地从 2.0 中挑选 1.1 内容。这会减少分支工作，但当然会引入樱桃采摘，我对自己不太熟悉，但我意识到可能会比建议的方法引入更多冲突。
任何有使用此类模型经验的人都可以评论一下可以改进的地方吗？这是一个好的解决方案还是有任何明显的改进？当然，即使您没有直接经历过这种情况，所有评论也值得赞赏。
谢谢！
我很想知道更多关于为什么你认为你当前的方法在 Git 中“……行不通”。你所描述的内容对我来说听起来并不矛盾。
如果您还没有遇到过它，我建议您看一下Gitflow。这种在 Git 中管理发布的方法非常接近/正是您所提出的。通读一遍可能会让您确信 Git 将如何为您工作。
如果你的旧 Subversion 存储库只是主干、分支和合并，我认为这将很容易映射到 Git。
向 Git 的过渡更多的是调整单个开发人员的工作流程以适应新的 Git 中心范例。对我来说，这是一个分布式 VCS，其中提交只是一个大图，您的存储库副本和我的存储库副本将有很多共同的节点和边，但您或我可能有一些节点我们还没有共享，在某些时候我们必须协调和合并我们的图表（通常这是通过拥有一个我们都认为是规范回购的“中心”回购的形式来完成的）。另外，与 svn 不同，分支（大部分）只是图中节点的名称。