问题标签 [branching-strategy]

没有项目 Y 的更改，如何发布项目 X（合并到主控）？

展望未来，解决方案 A、B 和 C 是否应该都是单独的存储库（尽管它们在业务级别相关）？

设想

我们有一个单一的存储库，其中包含：

• 解决方案 A
• 解决方案 B
• 解决方案 C（共享组件）

解决方案 A 和 B 都“插入”到我们的整个系统，通过通用组件将它们连接在一起。解决方案 A 和 B 依赖于解决方案 C 中的共享组件。

项目 X 需要对解决方案 A 和 C 进行更改。这些更改在功能分支中完成，合并回 dev 并持续部署到我们的暂存环境中。

项目 Y 只需要对解决方案 B 进行更改。再次在功能分支中，合并回 dev 并持续部署到 Staging。

Git 历史

此时，我们的 Git 历史看起来像这样（从最早到最新）：

--> 项目X --> 项目Y

业务需求

企业不再希望项目 X 投入生产，因为项目 Y 现在是“优先级 1”。不能发布来自 Project X 的任何更改。

分支策略

我们遵循以下策略：

发布策略

我们部署完整的产品包，而不是差异化。

在合并到 Dev 时，Team Foundation Server 会部署到 Staging。

在合并到 Master 时，Team Foundation Server 为每个构建定义提供一个格式化的部署包。

我一直在研究并试图找出满足以下要求的最佳分支和部署策略。也许我错过了一些东西，但它比看起来更复杂。理想情况下，我们只有一个永久分支“master”，它可以标记特定的提交以将发布标记为生产。

我们当前的策略是基于 Git Flow 并拥有永久分支“master”（只有发布到生产）和“develop”。使用多个永久分支模型复杂化的主要问题是从暂存环境“提升”相同构建到生产环境的概念。目前，这需要在单独的源代码分支中完成（部署到 staging 来自“develop”，部署到 prod 来自“master”）。

工具： Git (VSTS)、TeamCity、Octopus Deploy

要求（功能和修补程序生命周期）：

• 所有代码都通过拉取请求进行审查（通过分支策略强制执行）
• 所有代码都部署到暂存环境进行测试
• 我们可以快速返回到之前部署的任何代码快照
• 如果测试成功，那么相同的构建可以从我们的暂存环境“提升”到生产环境（无需再次构建）

在作为单个版本推出生产之前，功能会随着时间的推移而积累。修补程序必须能够通过，而不会陷入“全有或全无”的下一个常规版本。

我喜欢拥有一个带有标签的永久分支的想法（re: master/develop 拆分是多余的，http ://endoflineblog.com/gitflow-considered-harmful ），但是拥有额外的永久分支可能更好地促进部署到不同的生命周期/八达通的版本（功能和修补程序）。

我一直在努力解决如何最好地解决这个问题，我可能会把事情复杂化。任何反馈表示赞赏。

因此，几天来我一直在摸索，试图想出一种有效的方法来管理 TFS 分支的发布/迭代。

情况如下：

我们有一个项目，我们有发布，并且对于每个发布，我们都有迭代。发布是我们投入生产的新版本，而迭代只是需要在 QA 中测试的开发阶段。

迭代有点像特征。假设您要开发一个网站来展示商品（迭代 1），然后出售它们（迭代 2）并在第一个版本中将其全部打包。对于 QA 修复，它在迭代分支中完成并在 QA 中合并。由于我们不在 QA 中提交，因此在合并时没有需要解决的冲突。

所以工作流程看起来是这样的（由于时间紧迫，需要做很多并行工作）：

• 对于第 1 版
  1. 开始迭代 1 的开发
  2. 开始迭代 2 的开发
  3. 迭代 1 进入 QA
  4. 开始迭代 3 的开发
  5. 迭代 1 QA 已完成
  6. 迭代 2 进入 QA
• 第 2 版开始...

在简历中，大量并行开发，一次在 QA 中进行一次迭代，当所有版本的迭代都通过 QA 时，它会进入生产阶段。

所以我们需要提出一个分支解决方案，允许在开发分支之间轻松合并，然后进入一个 QA 分支。到目前为止，我们想出了这个分支结构

有了这个，我们可以很容易地在 dev 分支之间合并。但是在迭代 1 QA 结束的某个时刻，我们禁用了分支（通过删除它，或者拒绝访问签出/签入）。当那个时候到来时，策略是重新设置DEV_Iteration_2to QA_Release_1。

为此，我们需要进行毫无根据的合并，这会产生很多冲突。如果我理解正确，毫无根据的合并只是一个文件夹比较，没有考虑之前发生的变更集合并。

所以我想第一个问题是我们这样做会给自己带来多少合并麻烦（如果有的话）？是否可以忽略巨大的合并并在重新调整时解决大量冲突？

其次是：有没有更有效的方法来实现这个目标？

编辑：我想念git ...

我们继续寻找解决方案，一位同事给我发了这个链接：

Gitflow 工作流程

也就是说，如果你把与 git 直接相关的东西拿出来，这正是我们需要做的。在 TFS 中它可能看起来像这样：

问题是，TFS 不喜欢跳过分支。只要您不合并父级或子级，就将其视为毫无根据的合并。因此，由于QA_Release_1是在 下创建的Develop，它不会轻易合并到Main. 这让我回到我的第一个问题：毫无根据的合并是一个陷阱吗？

我们正在尝试遵循gitflow分支模型，但有所不同。

我们有四个可以部署产品的服务器环境，每个服务器都有一个用途：开发、内部测试、外部测试和生产。

• DevServer，开发人员在开发时测试他们的不同功能。开发人员无法在他们的机器上进行本地测试，他们必须在 DevServer 上进行更改才能进行测试
• TestServer，一旦开发人员完成，QA 测试人员会在其中测试多个功能
• ReleaseServer，在将发布版本转移到生产环境之前对其进行隔离测试
• 生产服务器。生产服务器

我们正在努力使合并/冲突解决尽可能简单，因此我们创建了两个额外的分支，它们不是 gitflow 模型的一部分。

正常的 gitflow 分支

• 开发
• 主（匹配“生产服务器”）
• 特征XXX
• releaseXXX（每周发布部署到“ReleaseServer”）

但是这两个分支不是标准的，可能需要改变......

• dev-release（DevServer 的副本）
• 测试发布（TestServer 的副本）

那么流程如下：

• 开发人员从“develop”创建他们的“featureXXX”
• 多个开发人员将他们不同的“功能”合并到“dev-release”分支中，“dev-release”分支被发布到“DevServer”，然后所有开发人员都可以在其中测试他们的不同功能。并非所有这些功能都将在下一个版本中
• 一旦开发人员对上面的开发测试感到满意，他们就会将他们的“featureXXX”合并到分​​支“test-release”中，并将其部署到“TestServer”。并非此处的所有功能都将成为下一个版本的一部分。
• 一旦在“TestServer”上对 featureXXX 进行了测试，开发人员就可以将他们的 featureXXX 关闭为“develop”。
• 然后开发人员要么创建一个新的“releaseXXX”，要么将他们的“featureXXX”合并到现有的“releaseXXX”中。
• 'releaseXXX' 分支被部署到'ReleaseServer' 并经过测试。
• 一旦'releaseXXX'测试被签署，'releaseXXX'被合并到develop和master，并部署到'ProductionServer'

我们是否搞砸了整个 gitflow 模型？

这是我们的分支过程：

我目前正在为我的公司规划一个新的 Git 流程，其新想法是迁移到分叉和拉取请求以及添加一个暂存分支进行测试。

提议的分支规范

• master（开发）- 包含来自开发人员功能/错误分支的前沿代码
• staging- 将自动部署到登台服务器的预生产代码库。由最终客户测试。
• production- 自动部署到生产服务器的经过全面测试的生产就绪代码。

所以最终它会是这样的：master-> staging->production

建议的设置流程

• 有一个官方upstream仓库，每个开发人员都可以从中分叉他们自己的origin仓库
• 他们将其克隆到本地开发中

提议的开发流程

• 创建一个功能/错误分支master
• 咖啡代码魔术
• 完成后，他们upstream/master从他们的分支创建一个拉取请求

在这种状态下，其他同事会查看该 PR 并提供建议或最终将其合并到upstream/master该功能最终应最终用于 QA 的地方，然后如果测试通过，则将其合并到生产中。

现在具有挑战性的部分是将测试的东西转移到staging最终客户进行测试以接受更改。

我考虑过的可能方法：

• master将更改从to合并staging- 虽然这似乎是最简单的方法，但由于某种原因，它感觉最危险以及未完成的代码最终可能会进入暂存状态，这可能会导致最终客户的测试失败。

• master从到采摘樱桃staging- 比上述方法更安全，但在某些时候可能会变得乏味（？）

• 将特性分支合并到upstream/staging- 这很可能不起作用，因为特性分支在上游不可用

• upstream/staging直接发出拉取请求- 虽然这很方便，但缺少对master分支的使用（如果 PR 用于暂存，则必须从暂存中重新设置主节点。可能不是一个好主意？）。

在这种情况下，以一种干净的方式将特性从上游主节点转移到 QA 阶段的最佳或理想做法是什么？或者我只是在这一点上过于复杂了？

git-flow我们正在使用分支模型开发几个由 Web 工件组成的项目。

参考：Vincent Driessen 的 git 流分支模型

我们正在使用develop分支并jenkins自动构建和部署SNAPSHOTWeb 工件以测试环境。

我们手动运行git flow release start并git flow release finish构建部署到我们的工件并最终部署在产品中的非快照工件。

（如何运行git flow xxx命令？这是备忘单）

我的问题：QA 的工作流程应该如何工作？

鉴于：

1. 我们不想将快照部署到 QA
2. 如果我们在 QA 中测试的相同工件部署在 PROD 中，那就太好了
3. 我们可以git flow尽可能地使用脚本和分支模型

看分支模型，我自己最好的理解是：

1. 创建一个发布分支（例如release/1.1）。
2. 从发布分支构建工件并在QA.
3. 在分支中进行更改release/1.1并根据需要返回步骤 2
4. 测试完成后，finish发布（合并到master）
5. 在产品中部署工件。

有没有人有这方面的经验，尤其是 step 2？应该如何唯一标识发布分支的工件？

我们正在考虑使用发布候选版本控制，其中 maven 版本1.1.RC1表示release-candidate1，之后是1.1.RC2，最后是1.1（最终版本）。

我目前正在使用功能分支工作流程实施 CD。我不清楚什么时候增加版本号。

创建新功能时是否应增加？

假设我们有 1.1 版，我将实现一个新功能 FB-123。

创建FB时我应该增加版本吗？

并使用 Jenkins 内部版本号进行后续提交？

我们正在采用新的分支策略来与敏捷合作，并使我们能够逐个特性地发布，因此我们有一个master分支和一个QA永久分支。每晚构建将基于QA和发布将来自master. 开发人员将为每个故事创建一个功能分支。所有功能分支都将被分支出来master，然后合并到QA测试中，然后将功能分支合并到master后续发布中。这很好，直到出现以下情况：

• 开发人员 A（“Rod”）已经创建feature/RodsFeature、执行了一些工作并合并到QA（但还没有master）
• 开发人员 B (“Jane”) 已经创建feature/JanesFeature、执行了一些工作，现在正试图合并到QA
• Jane 的合并冲突现在正在发生，这是QA由 Rod 合并feature/RodsFeature

如果 Jane 绕过 QA 并合并feature/JanesFeature到master中，则不会出现冲突，因为feature/RodsFeature尚未在master. QA然而，出于显而易见的原因，简必须融入其中。为了解决冲突，她可以将 Rod 的更改拉入并将其集成到她的特性分支中，解决冲突然后执行合并 - 不良后果是，一旦她将她的特性分支合并到master其中，也会引入 Rod 的更改，这些更改是仍在等待质量检查测试。

所以 - 一种解决方法是直接在QA分支上解决冲突，让 Jane 的功能分支完好无损，以便以后合并到master. 但是，这违反了代码审查政策，因为合并应该得到同行的批准——通过这样做，她已经在本地合并QA并推送到远程，而没有任何拉取请求或同行审查。

在这种情况下，什么被认为是“最佳实践”？

我们正在将源代码控制从 subversion 迁移到 TFS 2015。我们的开发工作将分为两个团队：一个只执行新的开发/增强功能，另一个团队只进行缺陷修复。

任何人都可以提出一个分支策略来合并这两种不同的努力吗？一个分支（开发）的代码更改总是比另一个仅执行缺陷修复的团队使用的分支更新。

在进行了几年的功能分支并在许多分支和合并噩梦中苦苦挣扎之后，我正在寻找有关分支策略的良好资源。功能分支确实为我们提供了一个很好的隔离，以一种非常精细的方式管理发布，以确定哪些功能应该发布。然而，他们带来的问题（许多分支、合并冲突）远远超过了他们带来的好处。

我们在后端使用 Oracle 数据库（有 5000 个对象）。我们还有多个团队致力于同一产品的不同领域。我们正在使用带有 TFS（无 DVCS）的 Visual Studio。

我们创建的分支越多，我们需要的数据库实例就越多，以便在这些分支（每个分支 - 一个数据库实例）的功能测试中提供适当的隔离，这是另一组问题。

我们正在采用 Scrum 并正在寻找适合我们的发布周期（一年 4 次）和 CI 构建的分支模型。我们计划为每个版本进行 5 次常规冲刺和 1 次强化冲刺。

从一个特征分支模型，我们将我们的分支模型重新设计为一个非常简单的分支，如下所示 -

开发分支作为我们的“主干”（基于主干的开发）工作，所有开发人员（所有团队）都致力于这个分支（季度发布），测试人员正在这个分支中进行测试，CI 服务器（Jenkins）每天都在构建这个分支. 为了安全起见，我们随时都需要一个干净的 MAIN 作为“最后一次发布的单一事实来源”，我们经常使用它有几个原因。

维护分支是我们的 bug 修复分支（hotfix），一年内发布多次（不考虑季度发布）。我们不希望直接在主分支上工作，因为希望有一个“干净的”主分支。我们不希望在没有完成“手动”/功能测试的情况下让代码进入 Main。一旦错误修复发布完成，代码将从维护 -> 主 -> 开发合并，以将错误修复集成到开发中。

我们通常不需要 TBD 中建议的“发布分支”，因为我们将不断地在维护分支中进行错误修复，从维护中发布，然后将更改合并到 Main（然后是 Development）。我们只维护“最后一个版本”，如果需要以前的版本修复，我们会从 Main 中的标签创建一个旧版本分支。

我们是否对基于主干的开发进行了修改，以至于将来会出现问题？你有什么建议？

参考：

http://paulhammant.com/2013/12/04/what_is_your_branching_model

http://paulhammant.com/2013/04/05/what-is-trunk-based-development/#comment-2765204723