Version control 分支模式/策略

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

我想看看其他人是如何分支的，并成功地做到这一点，而不是我读到的所有头痛问题

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

---

谢谢。

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

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

对我们来说，我们是一家网络商店，所以我们没有任何编号的“发布”。我们保持trunk作为“生产”的价值，只直接进行小的更改

当我们有一个大型项目时，我们创建一个分支，并将其工作到生产就绪状态，同时将主干更改同步到其中

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

同样，如果您正在创建需要维护不同版本的打包软件，那么这几乎不起作用

---

为了记录在案，我们使用。

这是我们的工作方式，它对我们很有效

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开发/Relase1.0和02集成/Relase1.0之间， 02集成/发布版1.0和03登台/发布版1.0， 03阶段/版本1.0和04生产/版本1.0

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

这为我们提供了4个独立的环境：开发、集成（alpha服务器）、登台（beta服务器）、生产

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

功能/更改被收集并分组到每几个月发布一次的版本中

但是假设您正在为Release2.0开发，您在Release1.0上遇到了一个生产问题。。。我可以很容易地获得最新版本的Release1.0，修复问题并升级它，而不会影响我为Release2.0所做的任何工作

---

不是说这在任何情况下对每个人都有效，但这对我们非常有效。

考虑分支时有三件事

第一：分支是可以的，只要您打算稍后再合并。当然，对于有特定问题的客户，您可以始终为其分支机构提供特定补丁。但最终您希望将大部分补丁合并回主干

第二：坚持你的需求。我见过根据部门规模、客户数量等不同而有不同大小的树

---

第三：检查您的源代码管理在分支和合并方面有多好。例如，众所周知，CVS对于这种操作非常差。SVN，他们声称的“CVS做得对”，稍微好一些。但是创建Git的Linus Torvalds（这对于这种操作特别好）会告诉你CVS做得不对（他在Git上的一个非常有趣的演示中说）。因此，如果您确实需要分支和合并，至少要获得SVN而不是CVS。

看看分支模式：

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

• 稳定的接收线-所有开发都在分支中完成，只有在需要时才合并到主干中。这意味着您总是有一个稳定的释放点

• 主要开发线-所有工作均在主干道中进行。当涉及到释放时，你需要一个释放标签并使用它。如果需要进行重大的实验性返工，则在分支中进行，并在稳定后合并回主干中

---

我们是一家网络商店，所以我认为这样的模式非常好。