•  06-07-2019
  •  | 
  •  

题

目前，我正在改造我们的店并版本控制。我们将要使用的一个服务器为中心的版本控制的解决方案。

我想看看其他人的分支，这样做成功，没有所有的头疼，我阅读有关。

什么是一些实地测试分支的模式，你已经看到生产环境中工作以及即支每释放。什么样的政策已经到位，以确保分支的顺利进行。

感谢

有帮助吗？

解决方案

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

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

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

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

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

为了记录，我们使用 Subversion 。

其他提示

颠覆书描述了一些常用的分支模式（例如发布分支，特征分支等）。

考虑分支时有3件事。

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

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

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

看看在分支的模式：

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

它描述了一些模式对于工作模式。我一般工作在两个方面：

  • 稳定的收线-所有的发展是做了在分支机构和合并为继，只有当需要。这意味着你总是有一个单一的稳定释放点。

  • 主要发展行的所有工作中进行的干线。当涉及到释放你把释放的标签和使用。如果主要的实验返工被要求它进行的分支机构和合并回到主干当稳定。

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

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工作

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

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top