如何摆脱开发分支以简化Git流

在一个持续开发的Web项目（不是产品）中，我们目前具有以下分支策略，大致基于git flow：

• 开发分支：最新工作版本
• 主分支：要发布的版本/已发布的版本
• 功能分支：开发中的功能
• 修补程序分支：已发布版本中的紧急错误修复

Master是只读的，可以通过来自develop或hotfix分支的拉取请求进行更新。每次更新都会构建候选发布版本并将其部署到登台系统。手动批准后，候选发布版将部署到生产中。

功能分支是基于develop或已合并到master的最后一次提交创建的。构建了来自功能分支以进行开发的拉取请求，并将其部署到免费的测试系统中，在该系统中执行集成测试和验收测试（自动和手动）。成功测试和审查后，PR就会合并，因此它将成为下一个版本的一部分（即从开发到母版合并）。

我的目标

我想简化此过程，并摆脱开发分支。developer分支主要是出于历史原因，并且由于它始终是经过成功测试的版本，因此我认为不必将其与master分开。删除它还将简化发布过程，因为不再有其他合并。

我有以下限制：

• 版本已排定，不应完全自动化
• 虽然功能分支通常寿命很短，但有些分支未合并数周（例如，重新设计），但也需要进行测试（当前是针对开放拉取请求的开发）
• 有时，应该在常规版本之外发布单个功能，从而有效地将其转变为修补程序。使用当前策略，我可以重新建立功能分支的基础并将其直接合并到主分支中
• 也有发生，我们需要在对外部系统进行暂存测试失败后保留功能

我不确定转换的地方：

• 目前，我正在构建请求测试以合并发布的提交。我可以统一一下吗？
• 当母版领先于最新版本时，如何处理修补程序。我应该直接从修补程序分支构建和部署发行版吗？
• 有没有明智的方法来处理在合并功能后就应从发行版中排除的功能？在这些情况下，单独的开发部门真的是一个优势吗？大多数情况下，无论如何我最终还是要手动还原和还原提交。

恕我直言，您所面临的问题只是开始时不良分支策略的一个副作用：您正在通过上的当前生产代码有效地耕作新的开发develop（即，向未来的生产代码收敛的东西）。由于通常将来的代码与当前的代码不同，所以这导致矛盾的要求和问题：master

• 新发展动摇了生产-合并develop为新产品后出现的衰退master
• 稳定生产会减慢未来的发展-您需要稳定develop以使其足以合并到master

删除develop无济于事-您并没有消除问题，只是将问题的develop特定部分转移到中master。

更好的方法是移动生产背后的电流/未来的发展，以防止发展为未来的版本中的干扰，从这个图片中所示什么是你的分支模型？：

请注意，我仅指上图中的发行分支，而不是指主干中发生的事情。

这将如何为您工作：

• 该develop分行自败，如你所愿，吸收到master
• 该master分支是你的箱子，这就是发展，没有速度的限制（它的发生从来没有合并到生产）。
• 生产是release从一个master标签/标签拉出的一个或多个分支，被认为与生产质量足够接近（如果需要，可以在该分支中解决剩余待办事项的简短列表）。这些分支只能从接收直接的热修复和/或精心挑选的修复master，它们永远不会与master或其他分支合并
• 修补程序是直接提交到release分支

如果修补程序仅适用于生产版本，而不适用于生产版本，则master它将直接提交给release分支。如果同时适用于这两种情况，则通常也将其master首先提交给release分支机构，并将其优先选择/双重提交给分支机构。

现在查看要执行的操作master（已超出当前release分支的断开点），您有两个选择：

• 像今天一样继续使用功能分支，只是它们将基于而master不是develop。仍然可以将它们转换为修补程序-您只需将它们重新设置为相应的release分支即可，而不是master
• 切换到持续集成并从中受益（可以随时进行），包括以渐进方式-逐渐减少越来越少的功能分支。

如果您喜欢这种方法，这里就是您今天所处的方式：

• 建立发布命名策略：
  • 您不能有一个同名的持续发行分支
  • 您不能（实际上不应）调整基准或同步生产版本分支
• 按照该命名策略立即releaseX从分支中撤出master
• 停止提交进入develop，他们将很快进入master。
• 合并develop成master
• 指示开发人员将工作空间master改用而不是develop。
• 公开master提交
• develop如果需要，请删除（或将其永久锁定/只读以供参考）

假设您取出了master分支（如果您以后喜欢，可以将development重命名为master，以使您的团队感到困惑），然后只需将标签用于developer或hotfix分支上的发行版即可。您取出了一个分支，但是区别只是语法上的变化。为了改变而改变。

现在，假设您实际上是在保留锁定的master分支的情况下进行开发的。将会发生的事情是，代码集成会变慢，在功能分支中的寿命更长，尤其是在发布日期之前。这将增加每次合并的难度并减慢该过程。

在您规定的限制范围内，我认为进行此类更改不会产生任何积极影响。这将需要放宽约束，尤其是第一个约束。

您已经在每个pull-request和hot-fix分支上构建和测试代码。这意味着总的来说，所有在请求请求中挂起的分支的总和就是您的虚拟develop分支。

您可以在测试环境中将几个拉取请求放入未发布到主存储库的临时分支中时创建系统。该分支用于集成包括master和多个其他请求请求的测试环境，但是一旦完成测试，该分支将不再在任何地方可用。

从中创建发行版时master，通常会在该发行版上创建标签。以后的修补程序可以使用该标记创建一个新的修补程序分支，从该分支可以进行部署，即使的边缘master已经在前面。在此修补程序分支上，您可能还会标记一个次要版本，并确保所做的更改已合并到中master。

使用git很难从发行版中删除合并的功能。最好的机制是git revert在合并提交上使用。但这几乎使这些功能/更改无法恢复，历史变得一团糟。

一种更好的处理代码部署和功能发布分离的方法是功能标志。如果您的开发人员可以在代码本身中的某些条件下隐藏其功能，则可以部署他们的代码，但请关闭该功能。这是一个单独的主题，但是存在许多与此有关的信息（包括对devops.SE的问答）。

@ dan-cornilescu很好地解决了您的特定问题，但是基于主干的开发的更一般情况（在持续交付，精益企业和DevOps手册中提到）在此处进行：https : //trunkbaseddevelopment.com/