什么应该是“主干”开发，还是发布？
我有一个不幸的机会，通过Borland的StarTeam来控制源代码。不幸的是，它做得很少，其中一个最大的弱点就是它的观点管理。我喜欢SVN，来自SVN的心态。我们的问题是后期生产发布，我们花费了无数个小时将变化合并到一个“生产支持”环境中。
请不要打扰我--这不是我的行为，我继承了它，并试图提出一种更好的方法来管理存储库。切换到不同的SCM工具并不是一种选择。
电流设置
- 产品1.0(主干，当前的生产代码，在这个级别上是挂起的bug修复)
- 2.0(真正的主干--任何签入的东西都会被测试，然后发布下一个生产周期，这个视图中会发生很多变化)
我的建议是交换它们，让所有的开发都在主干(生产)上完成，在发行版上标记，并根据需要创建子视图来表示生产支持bug修复。
- 生产
- Production.2.0.SP.1
我找不到任何文件来支持上述建议，因此，我试图获得反馈意见，是否改变是一个好主意，如果有什么，你会建议采取不同的做法。
回答 2
Stack Overflow用户
发布于 2010-04-12 18:39:52
以下是构造构建流的一般建议：
+HEAD - master -> current development
+ tags
+ version1
+ version1.sp1
+ version1.sp2
+ version2
+ branches
+ version1.sp2.fixes <- at some point, this will get promoted to version1.sp3
+ version2.fixes <- at some point, this will get promoted to version2.sp1
+ version2.nix.feature1 <- this is your (nix's) private version2.feature branch
+ master.nix.feature2 <- this is your (nix's) private new development feature branch.基本上，您从不直接提交到.fixes或主分支--只有集成过程才能做到这一点。
无论如何，几乎所有的源代码管理工具都会支持这个模型。
Stack Overflow用户
发布于 2010-04-14 02:19:32
我同意你和克里斯·卡明斯基的做法。我们使用StarTeam，这就是我们使用它的方式。每个项目中的提示或主视图是当前的开发行(用StarTeam术语来说，这是与项目名称相同的默认视图)。每当我们在这个视图上构建时，我们的构建服务器就会创建一个构建标签。发布是根据特定的构建标签完成的。
然后，我们将创建一个新的视图作为生产发布分支，然后将发布中的任何bug修复应用到该视图( bug修复是在Tip视图中完成，还是合并到分支，反之亦然，只要它们合并到主Development视图中)。
此外，如果我们有一个特定的项目将是长期运行，将不会完成之前，下一个正常的生产发行版，我们将做一个分支的提示视图与分支的更改设置。这肯定不太理想，因为一旦完成，就必须进行大量的合并，但它确实将代码排除在主开发线之外，并确保它不会意外地在生产版本中结束。我们确实试图限制这些类型的项目，但有时是由业务人员决定的。
这个设置对我们来说非常有效，而且对于新手来说似乎很容易理解和使用。
https://stackoverflow.com/questions/2624280
复制相似问题
腾讯云开发者
