Question

我目前正在改进我们的商店进行版本控制的方式。我们将使用以服务器为中心的版本控制解决方案。

我希望看到其他人如何分支，并成功地做到这一点，没有我读到的所有令人头疼的问题。

您在生产环境中看到的一些经过现场测试的分支模式是什么，这些模式运行良好，即每个版本的分支。制定了哪些政策来确保分支顺利进行。

由于

Answer 1

这取决于您正在开发的软件类型。

对我们来说，我们是一家网店，所以我们没有任何编号的'发布'。我们保留主干作为“生产”的价值，只是直接进行小的改动。

当我们有一个大型项目时，我们会创建一个分支并准备好生产，同时将主干同步更改为它。

如果项目涉及代码库的大量重组，我们通常会在合并分支更改之前在最后一个修订版上创建一个标记。

同样，如果您要创建需要维护不同版本的打包软件，这种方法几乎不会起作用。

为了记录，我们使用Subversion。

Answer 2

subversion book描述了一些常用的分支模式（例如发布分支，功能分支等）。

Answer 3

考虑分支时有3件事。

首先：分支很好，只要你打算稍后合并回来。当然，您可以随时为具有特定问题的客户提供具有特定补丁的分支。但最终你想将大部分补丁合并回主干

第二：断言您的需求。我见过各种尺寸的树，取决于部门的规模，客户的数量等......

第三：检查源控件对分支和合并的好处。例如，CVS对于这种操作而言是非常差的。 SVN，正如他们声称的那样，“CVS做得对”，有点好。但是创建Git的Linus Torvalds（这种操作特别有用）会告诉你CVS不能正确完成（他在一篇关于Git的非常有趣的演讲中说过）。因此，如果你真的需要分支和合并，至少得到SVN而不是CVS。

Answer 4

查看分支模式：

http://www.cmcrossroads.com/bradapp/acme/branching/

它描述了许多处理模式的模式。我通常以两种方式工作：

稳定的接收线 - 所有开发都在分支中完成，并且仅在需要时合并到主干中。这意味着您始终只有一个稳定的释放点。
主要开发线 - 所有工作都在干线进行。在发布时，您需要使用发布标签并使用它。如果需要进行重大的实验性返工，则在分支中进行，并在稳定时合并回主干。

Answer 5

这就是我们的方式，它对我们很有用......

Project
   |
   +--01-Development
   |  |
   |  +--Release1.0
   |  |  |
   |  |  +--Solution Files
   |  |   
   |  +--Release2.0
   |     |
   |     +--Solution Files
   |
   +--02-Integration
   |  |
   |  +--Release1.0
   |  |  |
   |  |  +--Solution Files
   |  |   
   |  +--Release2.0
   |     |
   |     +--Solution Files
   |
   +--03-Staging
   |
   +--04-Production

嗯，你明白了......

注意：这是Team Foundation Server中的目录结构分支仅存在于01-Development / Release1.0和02-Integration / Release1.0之间， 02-Integration / Release1.0和03-Staging / Release1.0， 03-Staging / Release1.0和04-Production / Release1.0

换句话说，你将无法将03-Staging / Release1.0合并到04-Production / Release2.0等......

这对我们有什么影响我们有4个单独的环境开发，集成（alpha服务器），分段（测试服务器），生产。

开发中的代码从开发开始，然后在QA（集成/ alpha）和用户（Staging / beta）测试时进行升级，最后到生产。

收集功能/更改并将其分组到每隔几个月发布的版本中。

但是，让我们说你正在开发Release2.0并且你在Release1.0上遇到了一个生产问题...我很容易就能获得Release1.0的最新版本并修复问题并在不影响我的任何事情的情况下进行推广一直在为Release2.0工作

并不是说这对每个人都适用，但对我们来说效果非常好。

分支模式/政策

5 个答案: