问题标签 [branching-strategy]

We are using Visual Studio Team Services (VSTS) which have epics, features, stories and down to tasks. We will also follow git dmz flow in which development happens in feature branches. We want to use VSTS structure but not breaking the principles and benefits of git dmz flow.

I was thinking of having a feature branch that will be branched out to story branch and story branch that will be branch out to task branch (where the actual dev work happens). Is this not add too much overhead for the dev team? Can automation help in this?

我正在考虑使用特性分支之类的故事分支（在 git dmz 流上下文中），其中，当一个故事完成后，您可以将 PR 转到 dmz 分支（但它会破坏 VSTS/敏捷结构中的结构？）

我相信任务可以在一天内完成，所以任务分支应该是短暂的。我还假设功能需要几天才能完成。

简要概述

我们是产品公司，我们为 50 多个客户提供解决方案，他们每个月都在增长，我们有相当简单的分支模型，如果可能的话，我想升级它。

该模型

我们正在做敏捷，因此我们有冲刺和发布。每个月或两个月，我们都会从master开放新的发布分支，该分支将稳定下来，稍后将提供给对其功能感兴趣的客户。到目前为止，一切都很好。在开发过程中会创建新的客户端。假设我们开始在客户端A上工作，并且我们决定该客户端将使用某个版本，假设我们创建分支并在那里开始我们的开发，一旦完成，我们合并->并从分支部署到生产客户。release/1.0release/A_1.0release/A_1.0release/1.0release/1.0

在我继续解释问题出在哪里之前，我将制定一些我们遵守的规则：

• 一旦release分支打开master，就永远不会在那里合并。
• release/{client}_{version}分支偶尔会用release/{version}分支更新（版本号应该匹配）。
• 只有hotfix分支合并到release/{version}分支中。
• 在打开新release/{version}分支之前 2-3 个以前的版本release分支被合并到，master因此这些以前版本的所有修补程序也都在新版本中。
• release/{version}分支打开后，不允许使用以前版本的修补程序。

问题出在哪里？

Tbh 问题是糟糕的计划，但这种情况发生并且无法避免。假设我们与客户（B）进行了谈判，我们决定给他们 1.0 版本，这将打开一个分支，release/B_v1.0同时我们在这个分支中开发这个客户端，时间过去了，我们的产品团队 sprint 打开另一个release，例如 1.1 .有时客户的开发过程需要足够的时间来打开产品，如果不是一个，而是两个或三个新的release/{version}分支。因此，如果发生这种情况，管理层和客户可能会决定使用更新的版本（比如说 1.3 - 以前它是为 1.0 开发的）。现在必须做的是我们需要release/1.3为此客户端打开分支，然后合并以前打开的分支 - 这将进行合并 release/B_1.0 --> release/B_1.3，这可能会很痛苦要完成。为什么？

因为release/B_1.0偶尔会更新，release/1.0 这意味着 1.0 版的所有修补 程序都将包含在内release/B_1.0（这是无法避免的，因为某些修补程序对客户端的开发至关重要），当需要合并时， release/B_1.0 --> release/B_1.3这将包括 1.0 版的所有这些修补程序在引入合并release/B_1.3后，release/B_1.3 --> release/1.3它们将包含在 1.3 版中，这是被禁止的。

在这种情况下我该怎么办？

我会挑选所有提交/合并，这些提交/合并是来自 , 的，但release/B_1.0不是来自release/1.0, into的修补程序，release/B_1.3但这可能非常耗时，而且由于 git 历史的工作原理，也可能会犯错误。

我建议可以锁定这些客户端分支以进行提交，因此只有合并进入那里，当可以进行这种合并时，我可以轻松地只从相关分支中挑选合并（忽略来自的合并release/{version}），而不用担心留下尾随提交，但这意味着在这个分支中工作的每个人都必须创建自己的分支并将其合并到其中，在我看来这会减慢开发过程。

您还有其他可以简化此类合并的建议吗？

在过去的 2.5 年里，我一直在使用 TFS 和 RM 创建构建和发布（也使用 rm 13）。

最近，我尝试在我们公司的分支战略中嵌入“质量分支”模式。我们在开发过程中需要热修复合并、冲刺合并、错误修复合并。按质量模式分支这是一个小例子：

我们可以同意，在生产之前将热修复上传到测试环境会将质量检查当前正在测试的所有新功能与我们想要的小型紧急热修复混合在一起，因此代码很脏。和聪明的人坐下来，我们几乎想出了这个模式，所以当我偶然发现这个模式时，我认为它非常适合我们，并且对于我们的持续部署和集成，因为合并到每个分支（main\dev、test、 prod) 正在进入正确的环境，分支稳定且永久，并且我的部门 (devops) 没有进行任何维护工作。我们只在这些分支上为我们想要自动化的更多应用程序添加更多构建和发布。

一家为我们提供咨询并且也在推广 Scrum 的外部顾问公司考虑了另一件事。我还无法理解动机，所以也许有人可以协助或反驳我或顾问在我们的案例中提供的内容（不是竞争，只是试图将解决方案附加到我公司的现实生活中）。他发送了以下网址： 使用 TFVC 的分支策略

其次是另一个参考：

DevOps 的有效 TFVC 分支策略

简而言之-我们 v1.0在新分支上创建一个和我们的发布管道（ci cd）。这将始终改变，我们将在每个发布时更改管道（v2.0 , v50.0等等）。

我浏览了很多文章说特性分支策略不能很好地与持续集成一起工作——足够清楚，发布隔离建议每个发布都在一个新的分支上，有点类似于特性分支，我们应该希望一个发布能持续 2最多 -3 周将其合并到主分支。我只是看不出它是如何自动化的，它如何支持热修复自动化（热修复前一个分支将使我们更改所有构建以使用该分支），我将说明我的意思。

我正在使用带有发布管理的 TFS 2015 来执行持续集成构建和发布我们所有的代码都是 .Net ，在 windows 上。因此，我们有一个用于持续集成的分支，并且上面有触发器。我想提一下，在我的公司中，我们的服务有 30 多个（并且还在增加）构建和发布，我们有 200 多个应用程序，因此我们自动化了最紧急的应用程序，并且我们努力实现越来越多的自动化。

我在上面添加的链接中提供的解决方案（顾问共享它们）是每次有新版本时创建一个发布管道（每 2-3 周在 scrum 中工作）请注意，在 TFS Build 中，有对分支的特定引用应该构建（源和触发器），这意味着每个版本我们都必须将源和触发器中的所有分支名称以及 main sln \csproj 更改为发布分支的名称（例如 r12）。这会因项目而异，因为并非所有项目都具有相同的发布分支名称（例如，有些是 r5\r20），因此您不能自动覆盖每个不同应用程序构建的分支名称。

虽然它被写成好像这种类型的分支策略支持 tfvc 用于 devops 和持续交付，但这似乎是一项艰巨的冗余任务，为我们所有的自动化应用程序 EACH RELEASE 更改发布分支名称。这似乎是一个可怕的很多不必要的工作，没有明显的好处——当然对我来说。顾问确信他的解决方案更好更先进，Visual Studio 网站在同一篇文章中使用“连续”一词时展示了这个解决方案！另外，我们部门很小，手头有很多其他东西，谁能帮我看看我没看到的东西吗？

这是我们在每个版本中必须做的更改过程：

请注意，触发器在 tfs 2015 版本中不可克隆。

请注意，我想请求一个优雅的、非黑客的、可工作的证明（即使在理论上，这很好）解决方案，如果这意味着我们必须编写一个解决方法，则考虑根据我的经验增加了故障点和维护。

谢谢 ！

我正在将我的源代码从 TFVC 领域转移到 Git 中，我认为是时候清理并正确执行它了 - 目前有很多复制/粘贴正在进行。

我的项目有一个“主要”解决方案——如果你愿意的话，它被视为黄金标准。但是我的项目适用于不同的业务，两者之间存在内容差异，并且有些包含彼此不同的深奥业务逻辑（我认为这是一种相对松散耦合的方式）。

我不知道维护“主”版本和不同版本的最佳策略。

我是为每个版本创建一个包含多个分支的存储库，还是将它们拆分为不同的存储库（但显然我将无法合并新代码，所以这并不理想）。

我过去一直遵循“发布隔离”策略：

对不起，可怕的视觉效果，但 Master 是我部署的来源，F1/2 将是功能，v1.4/v2.0 是我们需要支持的版本，HF1 是支持该版本的修补程序，并且E1 是添加到该版本的增强功能。

任何修补程序都将合并回 Master，当 Master 充满了足够的新功能和经过测试的功能以上线时，我们将创建一个新版本 (v3.0)。

问题是，我不知道这个模型如何适应我的 WhiteLabel

我不知道这是否足够稳定。

如果我有一个贯穿所有构建的功能，我可以从 Master 的左侧开始，然后推送到每个版本的新版本，然后在那里协调任何合并问题。

如果我有一个错误（即 HF1），那么我将不得不将它合并到许多分支中（嗯，至少支持的版本和开发/主分支）

这是理想的还是我完全走错了路？

使用 Visual Studio，当我需要调用另一个项目中包含的类时，我正在努力解决如何最好地设置分支。假设我的项目结构如下：

当我分支我的项目时，它将如下所示：

从我的每个分支机构调用实用程序项目的最有效方法是什么？

我们几乎已经确定了一个分支模型，其中我们有一个master代表生产代码的release-x.x分支和一个代表未来版本的分支。

但是，有一些场景我们不确定如何有效解决：

实时错误修复与当前版本无关

1. 一个新feature的分支release-2.0并完全重写了模块A。

2. 新feature的完成并合并在release-2.0.

3. 发现并修复了当前直播模块 A 中的一个错误master。

在这一点上，我们认为有两种可能的情况：

1. 我们 rebaserelease-2.0以master带来错误修复和修复冲突（丢弃现在无关的错误修复代码）。最终release-2.0，master当版本准备好时，我们会合并。

2. 我们只挑选与发布相关的错误修复，当发布准备好时，我们用历史release-2.0覆盖整个历史。masterrelease-2.0

解决方案 #1 迫使我们用我们知道不需要的提交来解决合并冲突，但解决方案 #2 迫使我们擦除整个分支并在每次发布master时用分支的历史记录替换它。release-2.0这引入了丢失我们忘记挑选的错误修复的轻微可能性，release-2.0并且还可能破坏在发布之前分支的正在进行的错误修复master。

一个功能最终没有进入发行版

1. 我们创建一个新的feature，重新建立基础release-2.0并将其合并release-2.0到--no-ff.
2. 发现了一些错误，因此我们修复它们feature并重做上述合并过程。
3. 客户再次查看该功能并决定他们想要更改很多东西 - 没有这些东西，该功能没有任何价值，但我们无法进行这些更改，release-2.0并且必须等到release-3.0.

处理这种情况的正确方法是什么？我们是否应该恢复所有与功能相关的提交，这些提交release-2.0使用诸如“恢复功能 X - 推回 3.0”之类的消息完成，然后合并feature到release-3.0？

我无法理解如何处理以下情况：

1. 功能 A 承诺master为 commit A。
2. 我们已准备好发布v1.0.0，因此我们将提交标记A为v1.0.0，并从中创建一个发布分支rel-1.0.x用于 QA。
3. 功能 B 承诺master为 commit B。
4. QA 批准v1.0.0，我们部署和删除rel-1.0.x分支。
5. 我们已准备好发布v2.0.0，因此我们将提交标记B为并从中v2.0.0创建一个分支用于 QA。rel-2.0.x
6. 在生产中发现了一个错误 ( v1.0.0)，必须立即修复和部署。

在这一点上，我不确定我们应该如何处理。如果错误在主干中，我们可以从主干创建一个修补程序分支，修复错误并合并到主干中。然后，从创建一个rel-1.0.1分支v1.0.0，从主干中挑选修复，将其标记为v1.0.1并部署。

现在我觉得奇怪的是，v1.0.1提交不是原样的，master因为它是从分支中挑选出来并在分支master中标记的。rel-1.0.1此外，如果还需要修复，rel-2.0.x那么我们应该如何处理呢？我们是否应该再次从主干中挑选错误修复并将其标记为不同的版本，例如v2.0.1？

这是我将要执行上述操作的那种图表（请注意，v1.1 代表上述文本的 2.0 版本，并且它是Second feature A fix在准备v1.1发布时发生的。）：

我需要设置一个仅用于构建的分支。我有一个在 JS 上制作的项目，在另一个 repo 中有一个服务器。文件夹结构复杂，非生产文件较多。

我需要的是具有此文件夹结构的单独分支：

我该如何做到这一点？我不想将此分支与 合并master，也不想与 repo 中已经存在的其他分支和文件产生冲突

I am searching for better workflow to use with Git. I found git-flow very useful workflow which fits in enterprise product based solution.

The most useful functionality I like is of Cherry-Pick. Currently we are using SVN and it is bottleneck for us to release version timely, because all the development happens in single branch version and trying to release that version when all the features got completed. Using git-flow, we can simply avoid such bottleneck and have full control over release cycle.

However, The problem I face is CI. In CI, all your features got merged into single branch and follow appropriate workflow to give feedback. Second is, out Business Analyst want to test all the features and want to provide feedback based on that. In current scenario it is not feasible because we are not merging to develop branch until feature is completed.

Is there any solution to fill requirement of Cherry-pick with CI and BA in Git-flow?

Toggle is one solution, however I am not clear how toggling can work with major changes in relational database. Old functionality will be broken in that case.

Thanks in Advance.

我必须根据软件供应商的现有源代码设置 git 存储库以开发软件。源代码会定期更新，我正在寻找最有效的方法，我提出了 2 种工作模型，我很想听听您对哪一种（或另一种）最有效的意见情况。

总体而言，将有 3 个完全独立的团队，每个团队在各自独立的代码存储库中工作：A、B、C。

源代码存储库/团队 A 是基于供应商代码的退出位置。源代码存储库/团队 B 是基于供应商代码退出 + 第三方扩展的地方。我正在尝试设置的源代码存储库/团队 C，它应该基于 A + B 和我们自己的扩展。

每当存储库 A 发生变化时，B 团队的人都会将其拉入他们的存储库，集成并使其可供 C 团队使用。

团队 B 也可以自行发布独立版本（无需团队 A 的任何更改），他们将为团队 C 提供这些版本。

对于团队 C，我将设置存储库单独的分支：

分支 TeamA 和 TeamB 将由我们（团队 C）管理 - 每当我们收到来自团队 A 和 B 的代码并将它们合并到开发中时，我们都会自行更新它们。

目标是能够理解 TeamA 和 TeamB 之间的差异（开发）（以及 TeamA 和 TeamB 之间的差异），并且最容易地将团队 A 和 B 的更改集成到开发中。

我想知道如果我设置以下结构是否有任何区别：

1）基于master制作所有分支

或者，2）使分支的以下父子结构

我想知道它是否有任何实际区别。

过去有没有人遇到过类似的情况，您会推荐什么方法？