问题标签 [branching-strategy]

The company I work for is starting to have issues with their current branching model and I was wondering what different kinds of branching strategies the community has been exposed to?

Are there any good ones for different situations? What does your company use? What are the advantages and disadvantages of them??

我在理解 Git 团队工作原则方面遇到了一些麻烦。

考虑一个由两个程序员组成的团队：A和B. 他们正在研究一个Project. 此外，还有一个带有 repo 的远程服务器。A并且B正在远程协作。回购中已经有一些代码。

我想请你帮忙组织他们在 Git 上的分步工作流程。
1. 他们有没有建立自己的本地分支机构？
2. 他们如何在生产服务器上上传工作代码？rsync?

任何帮助将不胜感激。

我正在尝试为 Web 应用程序项目确定最佳分支策略。这是我到目前为止的想法，我将非常感谢任何评论和经验。

在我看来，有两种主要的分支策略：“按发布分支”和“按功能分支”。

“发布分支”：开发发生在主干上。当发布时间临近时，会为该发布创建一个分支。然后稳定/测试这个分支，最后发布一个版本。发布后，分支被合并回主干，同时保持发布分支处于活动状态以进行错误修复。是否应用了错误修复，然后将其合并到主干中（如果主干上的开发没有以其他方式使错误黯然失色）。新功能被添加到主干，不会影响发布分支。当新的发布时间临近时，也会创建一个新的发布分支

“按功能分支”：主干始终是“生产”主干（实时代码）。错误修正直接提交到主干。下一个版本的功能在功能分支中开发。错误修复不时合并到功能分支中。当发布时间到来时，特性分支被合并到主干中，生命周期继续。

现在我认为这两种策略之间最大的实际区别是“按发布”允许您维护软件的不同生产版本（当客户 A 有版本 1 和客户 B 版本 1.5 时，客户是付费客户）案子）。相比之下，使用“按功能”策略只能支持当前的生产版本（所有客户端都使用最新版本）。

由于在典型的Web 应用程序中，所有客户端都使用相同的“最新”版本（因为它们都访问相同的服务器），我认为“按功能”方法是最常用的。它消除了“跨层次结构”合并的需要，比如当一个错误修复必须应用于所有 3 个发布版本时。

所以我目前的状态是我应该使用“按功能分支”。如果重要的话，我的团队不是很熟练。

过去

我使用 subversion 作为 scm 开发了一个软件项目。到目前为止，开发总是发生在trunk. 现在，我们想重新考虑我们的分支策略，要求是：我们希望能够同时处理多个未来版本。

任务

这意味着：假设，我们正在开发的当前版本是 1.0。下一个计划的版本是2.0，之后的版本是3.0。现在我们已经发布了 1.0，我们想要

• 维护版本 1.0
• 为 2.0 开发功能
• 同时开发3.0的功能

当然，在其他两个版本中也需要在 1.0 中应用的修复。此外，来自 2.0 的功能也必须在 3.0 中。此外，可能会计划一个次要版本，例如 1.1，其中还包括新功能，并且必须单独维护。

一个可能的解决方案

我提出了以下分支策略：

• 后备箱将被遗弃
• 对于每个新的计划发布，都会创建一个源自上一个发布分支的分支
• 更改在版本时间线中“向上”传播

让我再详细说明一下：在给定的示例中，我们将从主干分支版本 1.0。此外，我们将从 1.0 版和 3.0 版从 2.0 版分支 2.0 版。当在 1.0 中进行更改时，它将被合并到 2.0 中，随后会合并到 3.0 中。

问题

这是一种有效的方法吗？它会在技术上起作用吗？是否存在组织缺陷？有最佳实践吗？（所有互联网都会想出的是：“在主干中开发，在发布分支中维护”）。放弃后备箱对我来说尤其奇怪——这是错的吗？

使用 TFS，我们有以下内容：

• 主要基线
• 每个开发工作的开发分支。这些被合并回基线。
• 随每个版本创建的版本分支。错误修复在这里进行、发布并合并回基线。
• 使用搁置集，如果需要，我们可以在开发分支之间共享代码，而不会污染基线。对代码审查很有用。
• 当我们将开发更改交付到基线时，我们有一个自动构建启动并自动将我们的更改放置在测试服务器上。

问题是业务分析师在测试服务器上之前无法看到我们的更改，目前在测试服务器上获取我们的更改的唯一方法是将它们检查到基线中。因此，如果 BA 发现有问题，不幸的是，该代码已经处于基线状态，我们将不得不费力将其取回。

有没有一种方法可以改变我们的分支策略或流程，让 BA 得到他们想要看到的东西，而不会污染我们的基线？

我想就具有以下要求的专业开发设置的外观提供一些意见。

• 几个 PHP 开发人员（比如 PHP）
• 每个开发人员属于一个组
• 每个小组都有一名负责委派任务的团队负责人
• 每个开发人员都在一台 Windows 7 机器上工作
• 并使用 NetBeans 或 Eclipse 进行开发
• 每个开发人员都“拥有”一个可以运行代码的虚拟测试服务器
• 使用的 VCS 是 SVN
• 有一个登台服务器，在产品发布/部署之前最终对其进行测试

我给出了一些具体的技术，不要太抽象和 b/c 我也会对插件等的具体建议感兴趣。

在该设置中，我想到了几个问题。

1）因此每个开发人员都将在个人分支上工作。

2) 此分支在工作副本中签出。

现在......这个工作副本在 PC 上使用开发人员的 IDE 进行本地编辑，并在服务器上执行/测试。

在这种情况下，最好/通常的方法是什么？我的意思是 - 你如何在服务器上获取你编辑的代码而不造成太多开销？

开发人员会在他的本地磁盘上保存代码吗？还是让 IDE 通过隧道或特定协议在远程虚拟服务器上写入会更好？

3）每天，开发人员都会将他的工作提交到位于中央存储库中的个人分支中。

关于存储库的位置是否有最佳实践？单独的服务器？

4）然后在开发人员完成他的任务后，他/她或团队负责人将新代码合并到各自的主分支或主干中。

最令人困惑的部分是关于我在 2) 和 3) 之间写的内容。因为到目前为止，我只使用本地服务器。例如，带有运行代码的服务器的 VM 位于共享文件夹中，因此我将能够直接对其进行编辑。当服务器现在实际上是远程的时，我不确定如何有效地弥合差距。例如，高效意味着不必通过 FTP 手动上传。

也欢迎外部资源或书籍推荐。

编辑

我的问题是/正在针对准标准/最佳实践。我认为这几乎是一个标准的开发方案，所以必须有一个“常规”的解决方案。

编辑 2

好的......让我们尝试一张图片：

V 是一个或多个开发人员的虚拟测试服务器 D。C 和 C' 是两个代码版本。它们应尽可能保持相同。

我想到了两个解决方案：

1：编辑C，然后上传到C'，然后执行C'，然后提交C。

2：不存在C。只是通过一些隧道技术编辑并执行和提交的 C'。

我的直觉告诉我，这两种解决方案都是半最优的。那么什么是“专业”/最高效/最快/最方便/最无摩擦/最不容易出错/最佳实践/行业标准？

任何问题？

我正在寻找以下情况的最佳实践：

我有一个 bll/dal 项目，以及使用 bll/dal 项目的树 UI 项目。一开始，我们将它们全部放在一个 SVN 存储库上的一个主干文件夹中。我们正在使用用户分支，所以每个用户分支都有所有源代码。

现在我们开始使用 TeamCity 作为构建服务器，我们希望每个项目都有自己的产品版本。所以我们在不同的 SVN 存储库上拆分了主干（每个项目在另一个 SVN 上），这样每个项目在其产品版本中都有自己的修订号。

我们对 teamcity 上的每个项目都有持续集成和持续部署。4 个项目提供 8 种配置

现在我们还希望为每个用户提供其分支的 CI。但是现在我们必须为每个项目创建一个用户分支，这样每个用户就有 4 个用户分支。这还涉及到我们需要为 TeamCity 上的每个用户配置 4 个 CI 配置...

现在我只是想知道，这是一个好方法，还是有更好的解决方案......？

提前致谢。

布鲁诺

在之前的工作中，我发现通过让每个开发人员在他/她自己的分支上工作，更容易管理和保持稳定的预发布分支（或主分支，取决于设置）。我们只有一个生产实例，因此无需支持同一应用程序的多个版本。

这个“预发布”分支之所以这样命名，是因为我们可以从另一个分支（主分支）进行登台和生产发布。分支的设置使得只有来自预发布分支的代码可以合并到发布分支中。这些合并是我们的代码审查检查点。CI 构建也是从这个预发布分支构建的，每个开发人员都可以在完成该工作主体的开发时从“预发布”合并到他们自己的分支以缓解复杂的合并问题。

如果开发人员需要将一个给定的功能配对并一起工作，那么除了他们自己的分支权限之外，没有什么可以阻止他们与其他人一起工作。这对于管理分布式团队非常有效，其中每个团队中的个人都在处理单独/多个功能。

在频繁（每周 1-2 次）30 分钟状态更新会议的帮助下，作为一个团队，我们将决定哪些内容将进入 QA，哪些内容不用于特定的 QA 版本。

该系统有效，但在搜索此主题时，我发现开发人员分支有很多不满。似乎对 git 的本地存储库功能有很多热情。然而，似乎它们只是解决相同问题的不同方式。不考虑本地存储库解决的跨网络问题，例如签入延迟等。

因此，我将 Subversion 用作我维护的经典 ASP webapp 的 SCM。我们使用功能分支来处理具有依赖关系或长期开发的更改。

我们为 Dev/QA 使用共享 Web 服务器，这就是我的问题所在。中央开发服务器是主干的工作副本，然后当我需要从功能分支查看 Dev 上的更改时，我将它们合并到 Dev工作副本。到目前为止一切都很好，但我是否正在为将来的坏事做好准备？

例如，今天一位分析师告诉我，我可以“删除”我对某个功能所做的更改，然后合并到 Dev 站点进行演示——不是因为该功能被杀死，只是因为他不需要查看它了。我意识到我不能轻易做到这一点。我现在合并的更改只是在 Dev 工作副本上显示为本地修改，我不能轻易地将它们剥离（我必须手动恢复对受影响文件的更改，因为完全恢复可能/会杀死与其它功能）。

我写得越多，我就越觉得我已经回答了自己的问题。我是否需要更改我的分支策略——每个环境的分支？或者我是否需要为每个分支（dev.mysite.com:4801、dev.mysite.com:4802）有一个单独的“共享开发”站点？或者这就是你处理这个的方式？

我计划通过让该团队在功能分支中为他们分配的所有工作工作来管理一个在我的代码库上工作的外包开发团队。他们将负责每周合并来自主干的更改。我自己的团队也将根据需要继续使用功能分支。

根据使用特定分支策略集成外包工作的经验，是否有人有任何提示？