问题标签 [branching-strategy]

我很好奇其他人会在 Java 项目（Web 应用程序）上应用什么源版本控制策略，该项目很可能为多个客户进行定制。

该项目将有一个标准版本，但对于它的一些客户来说，需要进行一些定制（在不同的分支上）。

通过阅读此主题： 在 Web 应用程序的开发/维护期间我应该使用什么分支策略？ 我想“发布分支”将适合项目标准版本的开发。

现在，在客户分支上工作时，对其他客户/标准版本将受益的代码进行了一些改进/错误修复，这意味着对于每个分支都将执行合并和测试以保留所有内容最新。

作为一个约束，对于这个项目，我们坚持使用 CVS 作为源版本控制系统。

对于构建的工件的版本控制，我们将使用 maven（依赖：artifactId、groupId、版本、分类器 - 客户名称 - 以便清楚地区分工件）。

我们有三个运行我们的 ASP.NET 应用程序版本的环境或网站（开发、登台和生产）。我们使用 SVN 和持续集成 (Teamcity) 来帮助将应用程序自动部署到每个 Web 服务器。

我们当前的开发工作流程基于任务（或工作订单）系统。给开发人员一个他必须完成的任务。许多开发人员可以同时在项目上工作，但在应用程序的不同部分。

我当前的解决方案使开发人员为每个任务创建单独的分支。当用户提交时，主干源代码被编译并部署到我们的开发 Web 服务器。

开发人员 1 开始一个新任务并从主干源代码创建一个新分支，比如说“任务 1”。

他将代码提交到他的分支，然后将分支与主干合并。

他的更改与其余代码一起编译并部署到开发 Web 服务器。

开发人员 2 开始一个新任务并从主干创建一个分支（使用开发人员 1 的更改）。

然后他进行更改，将他的代码提交给“任务 2”并将分支与主干合并。

代码再次编译并部署到开发 Web 服务器。

开发人员 1 尚未完成，但开发人员 2 所做的更改已准备好部署到生产环境。

Dev 2 然后将“Task 2”与“Production”分支合并。

这就是问题所在。Dev 1 所做的部分更改正在生产中，这是一件坏事。

我需要找到一个分支策略，使我们能够继续开发并逐个执行每个任务。

你有什么建议吗？SVN 是适合这项工作的工具吗？

更新

我现在正在考虑创建一个“开发”分支来部署到我们的开发服务器并保持主干清洁并与我们的“生产”分支同步。这个特殊问题似乎以这种方式消失了，因为每个开发人员都会从一个干净的主干创建他的分支，而不是一个经过一些开发人员修改的分支。

我目前正在研究 git-flow，并试图弄清楚如何将它用于我参与的项目。

我看过各种 git-flow 教程，我对 git 相当熟悉。因此，我不需要任何关于 git 的提示，而是直接使用 git-flow 的工作流程。

情况如下：

当我发布一个版本（我们称之为 1.0）时，这个 get 是开发的分支，这很好。假设现在我开始研究 2.0，添加新功能。当然，一旦完成，我想将它们合并回开发中。现在在 1.0 上修复就可以了，所以假设我生产了几个版本 1.0.1、1.0.2 等。所有这些也会更新开发分支，这也很好。到目前为止，现在很麻烦，我可以独立开发 2.0 的功能和 1.0.x 的修补程序。

但是，假设有人要求 1.1 版本的新功能。现在我有一个问题。如果我创建一个特性分支，这将基于开发分支，它可能已经包含 2.0 的东西，我可能不希望在这个 1.1 版本中。

有没有一种简单的方法来独立处理这些 2.0 和 1.1 的更改？

我已经看到了几种可能性：

• 在开发的最后一个发布位置创建一个新分支。将开发重新定位到此位置并重命名另一个开发分支。但是，此分支将不包含来自 1.0.1 等的任何修补程序。

• 在 2.0 完成之前不要合并 2.0 的功能。但是，我将不得不保留许多未合并的更改，直到最后一刻。这也无济于事，如果 2.0 get 发布并且随后请求更改为 1.0.x。

这对 git flow 有可能吗？即，一旦新版本的工作已经开始甚至完成，就基于早期版本发布？

这不是我没有任何想法的问题，而是我想展示一个模型，看看它是否获得批准，或者任何人都可以看到它的问题或有更好的建议。他们说最好仔细选择你的分支模型，以避免未来的头痛。

所以我们有一个内部应用程序，只有一个版本（最新）发布给客户，基本上有两种开发活动：主要活动是为下一个版本工作，通常包括新功能和纠正性修复，它是计划中，第二个是未计划的，是关于维护的，包括生产中当前版本的修补程序。

经过长时间的研究，我们决定使用主干，从中分出 2 个子分支：开发和维护（或修补程序）。正如指南中介绍的那样，每次我们为下一个版本准备好功能时，日常开发都将在开发分支中进行，我们从那里进行反向集成 (RI)。在发布之前，反向集成将停止，代码将稳定在主分支中。从Main发布后，将从Main到Development和Maintenance进行前向集成 (FI) 。

任何修补程序都只会在Maintenance中发生，并且取决于修补程序（例如，如果我们想将其保留在代码库中），我们将在Main中执行 RI，然后在Development中执行 FI 。

现在一切看起来都很好，至少在纸面上，所以我想听听其他人对这个模型的看法。

例如，我们还会考虑创建另一个分支Release，其中代码的稳定发生在发布到生产之前（而不是直接在Main中工作），当然我们将从这里发布到生产并在Main中执行 RI，然后开发和维护的 FI ，但我们不确定这是否会带来任何好处或只会增加复杂性？

假设开发中的某些功能在下一个版本中还没有准备好或不需要，这意味着我们将不得不对与所需功能相关的变更集进行一些“樱桃采摘”，但这并不是太好根据文档。有什么建议么？

我再次知道这不是一个简单直接的问题，而是一个开放的问题，我仍然希望听到任何有类似经历的人的意见。提前感谢您的关注。

我注意到一些 关于分支名称的问题的答案引用了 Mercurial wiki，以表明每个功能的分支或每个错误的分支命名约定可能会导致性能问题。

在提交时使用标志将分支标记为已关闭的能力是否--close-branch对此性能声明有任何影响？

我正在尝试为一个四人小团队提出一个可靠的 SVN 存储库结构和分支策略。我们在任何时候都有四个主要项目和几个次要项目在开发中，并且项目之间经常存在一些重叠。我们当前的策略是完全低效的，包括将这些文件夹中的每一个（大约 15 个左右）放在一个版本化的“主干”文件夹下。这意味着每当我们进行分支时，我们都会对所有 15 个项目进行分支（更新工作副本并拉下一个分支大约需要 20 分钟，以透视这一点）。

主要问题是一些项目重叠，并且一个特性或任务需要在项目 A 和项目 B 中更改某些内容并不少见（所有这些项目都与同一个数据库通信并使用相同的数据库表；此外它们共享一个业务层，因此在一个项目中更改一个类会影响另一个），因为这些项目本质上都是一个“伞形”应用程序的相关部分。例如，对于主要项目，基本上有：

• 项目A：前端电商网站
• 项目 B：后端执行/管理系统
• 项目 C：前端站点的无品牌副本（相同的东西减去 CSS 样式并且功能较少）
• 项目 D：Web 服务 API

A 和 B 交织在一起，但 B 是一个软件即服务应用程序（我们充当我们自己的客户端），而 C 作为客户的前端（A 充当我们自己公司的前端，因为 C 本质上是A 具有较少的功能且没有公司特定的详细信息）。D 只能由客户访问，但我的最终目标是让 A、B 和 C 都通过 Web 服务使用 D 的功能（基本上是吃我们自己的狗粮）。

我们刚刚决定采用三周部署策略（这意味着我们每三周进行一次生产部署），而我们当前的 SVN 策略很麻烦，并且使得分支非常痛苦。

由于多个项目有重叠，将它们全部放在一个具有分支/标签/主干格式的项目文件夹下是否有意义，或者我们应该将它们视为单独的项目？也许结合一些，例如将 SaaS 前端/后端结合在一起，我们自己的网站和 Web 服务是分开的？

参与类似项目的人的任何建议或建议都会很棒。

就我而言，超级项目足够大，因此它包含多个工件。假设项目 A、B、C、D、E。它们是不同的 git 项目。现在我们需要处理两个不同的版本，那么问题就在于我们想要如何进行分支。我最初来自颠覆世界，如果是 SVN，我可能会考虑创建一个超级项目并包含所有子项目 A、B、C、D、E，然后我只是分支出超级项目。

但是在分支方面，从概念上来说，git 和 SVN 还是有一些区别的。只是想知道在 git 世界中，通常为不同版本分支多个 git 项目的最佳实践是什么？我知道子模块已经讨论了很多，单独分支项目有意义吗？

另一个问题是，如果完成了分支，我们如何在不同的分支中对工件进行版本控制？如果你有两个分支，这意味着你将在两个不同的分支中为所有子项目拥有不同的版本，那么你就会开始闻到失败的味道。

（关于这个有很多类似的问题，我也阅读了各种文档，但我找不到任何回答这个特定问题的东西。）

给定一个没有远程和分支的存储库，在 master 上有 20 次提交。

目的是最终得到一个空的主人，所有的提交都在发展，但没有混乱的历史。

有没有区别：

和：

?

第一个选项似乎是执行此操作的最简单方法，但我在任何地方都没有看到它建议 - 我一直在阅读的所有各种内容都倾向于使用第二个选项的变体（或变基，我认为这里不适用）。

第一个选项是否像我认为的那样做，与第二个选项相比，它有什么好处/缺点吗？

有没有更好的方法来实现这一目标？

我已经阅读了@nvie 的Git 分支模型和gitflow，我认为这是一个很好的模型，可用于我目前正在开发的项目（Web 应用程序）。

我是该项目的首席开发人员，我在本地环境（类似 MAMP）上进行开发。每当我做了一些东西给客户看时，我都会提交我的工作并将其推送到中央 Git 主机。从那里我将它部署到连接到互联网的服务器上。然后我的客户可以看到更改。

第二个开发人员刚刚开始从事该项目。他一次开发单个功能，并在它们准备好时将它们推送到中央 Git 主机。我在部署之前回顾了他的工作。

目前所有提交都在master分支中完成并部署到单一托管环境。将来我想拥有一个生产环境（用于实际使用）、测试环境（在应用程序的新版本发布之前测试它们）和一个开发环境（我可以在其中展示已完成的功能或仍在进行中给客户）。我认为生产环境将从中部署master，而开发环境将从中部署develop。

我的问题如下：

1. 我经常同时处理多项任务。当某个功能的一部分准备就绪时，有时我想在继续开发该功能之前将其展示给我的客户。但是，据我了解，一个功能（分支）只会develop在它完成并计划发布时才被合并。如何向我的客户（在开发环境中）显示正在进行（或尚未计划发布）的功能？

2. 我应该从哪个分支部署到测试环境？我应该手动选择那个时候的发布分支，还是有一个专门的测试分支？

我是一名网页设计师，他将 HTML/CSS/JS 组合在一起用于前端 Web 应用程序设计。我与另一位开发人员合作，他采用我的设计并利用 ASP.net 从这些设计中开发功能性 Web 应用程序。

在我看来，Web 应用程序有三个版本——我最初的 HTML/CSS/JS 设计、其他开发人员的 ASP.net 版本以及实时网站上的版本。

关于如何在 Git 中进行设置的任何建议？我计划使用两个存储库，一个用于我的前端设计，另一个用于 ASP.net 开发和网站的实时版本（对于我计划使用这个 git 分支模型的分支（http://nvie. com/posts/a-successful-git-branching-model/）。

让它们在同一个仓库中成为不同的分支有什么好处吗？我主要关心的是确保我们拥有与 HTML/CSS/JS 原始设计分离的网站的 ASP.net 版本，同时确保两者处于相同的状态（除了功能）。