我习惯于源控制分支方案，其中为产品的每个主要版本创建分支。我可能会忽略这个模型的一些潜在好处，但我认为主要的好处是它允许在带外修补版本。
对于那些除了最新版本（例如网站和内部应用程序）之外永远不会拥有补丁的产品，这个模型似乎过于复杂。
我正在考虑将内部应用程序移动到两个分支模型：development和production。 development分支用于下一版本的产品，production分支用于修补产品的当前版本。
我是否过度简化，或者缺少版本化分支结构的其他好处？其他人成功用于内部应用程序和网站的是什么？
答案 0 :(得分：1)
我的开发团队使用类似的策略，除了我们还使用第三个分支进行测试。我们有一个小团队，它运作良好，因为我们不会浪费太多时间处理合并，工作副本和其他浪费时间的麻烦。如果我们突然将团队规模扩大一倍或三倍，我认为它不会很好地扩展，但在这种情况下我们会担心比颠覆分支更多。
我不认为你真的不会错过修剪你的分支机构的许多重大好处。如果您的团队很小并且/或者每个人都有明确定义的任务不会干扰其他人的工作，那么请省去维护膨胀的存储库的麻烦。但是，你工作的人越多，就越有可能解决合并冲突。