多年来我们一直使用TFS（TFVC）作为我们的版本控制系统 . 无论如何我们可能会迁移到git，但我想弄明白
1）是否有比我们目前使用的更合理的分支策略/模型，特别是维护多个 生产环境 版本（通常针对几个不同的客户）？
2）关于1），git对TFVC有特定的好处吗？
我们今天所做的事实上很简单：
Mainline ----------------------------------------------------
| | | | |
Release 3 Release 4 Release 5 Release 6 "Release" 7
所有版本在主线上都有自己的分支，即使是未来版本的开发工作也是一个“未来”版本分支 . 在上文中，“Release 7”正在进行中，尚未发布 .
在每个分支下面可能是更多的子分支，例如功能分支，以隔离工作并保持发布分支稳定，但我不认为这对于这个讨论很重要 .
每当其中一个发布分支发生变化时，它必须最终合并到主线，并从那里合并到所有未来版本，以避免客户从第3版到第5版的回归 .
在实践中，对这些“旧”分支的更改不仅是小错误修正，而且可能是第3版客户请求的更大功能，它是在第3版中开发的，客户收到第3版的新版本 . 最终，该功能将合并到主线，并从那里合并到所有未来版本 .
由于合并总是从主线上的每个分支到每个较新的分支发生，这实际上意味着主线与最新的发布分支大部分相同 .
这是第一个令人头疼的事情：有一些不自然的东西（实际上它会不时引起问题）关于从旧版本3到主线的合并，这是非常新的，然后是从主线到旧的版本5.可能有大的和例如，在将版本3与版本6进行比较时，会发生更改 . 直接从第3版合并到第5版会更自然，但TFVC不支持这一点 . 您只能合并到您的直接父母（或孩子） . git有同样的限制吗？
另一个问题是，如果TFVC中的变更集不在历史中的一个连续的，不间断的块中，那么在TFVC中不可能对整个特征进行合并 . 如果来自某些其他要素的变更集是交错的，则您必须将每个连续的子块合并到要素更改集中，或者必须合并从源分支到目标分支的所有内容 . 并不总是可以进行多次樱桃选择合并，因为 Build 或单元测试甚至可能需要所有变更集 . 我可以看到为什么TFVC具有此限制，因为该功能的较新变更集可能基于来自另一个功能的较旧的交错变更集 . 因此，仅合并最初来自此功能的变更集可能甚至没有意义 . 在实践中，我们倾向于合并所有准备合并的东西，它必须在某些时候合并 . 在这方面git如何比较？
对于我们的案例，什么是合理的分支策略/模型，迁移到git会对我们有帮助吗？
1 回答
TFVC（CVCS）和git（DVCS）之间存在很大差异 . git的简单工作流程通常如下：
feature分支通常是从develop分支创建的，用于开发新功能或修复错误 . 他们通常会缩短生活分支 . 功能或错误完成后，它应合并到develop分支 .develop分支用于所有开发人员合并其作品（功能和错误） .master作为管理项目稳定代码的主要分支 . QA团队可以测试合并develop分支到master分支 .所以分支结构看起来像：