develop分支：最新的工作版本
master分支：即将发布的版本/已发布的版本
功能分支：开发中的功能
hotfix分支：已发布版本中的紧急错误修复
母版是只读的，可通过来自dev或hotfix分支的拉取请求进行更新。每次更新都会构建候选发布版本并将其部署到登台系统。手动批准后，候选发布版将部署到生产中。
功能分支是根据开发或从上一次合并到master中的提交创建的。构建了来自功能分支的要开发的拉取请求，并将其部署到免费的测试系统中，在该系统中执行集成测试和验收测试（自动和手动）。经过成功测试和审查后，PR被合并，因此它将成为下一个发行版的一部分（即从开发到母版合并）。
我的目标
我想简化一下并摆脱掉开发分支。 developer分支主要是出于历史原因，并且由于它始终是经过成功测试的版本，因此我认为不必将其与master分开。删除它还将简化发布过程，因为不再有其他合并。
我有以下限制：
发布是计划好的，并且在功能分支时不应完全自动化
通常是短命的，有些不合并数周（例如重新设计），但也需要进行测试（当前是针对开放拉取请求的开发）
有时应在常规发行版之外发布单个功能，从而有效地将其修复。使用当前策略，我可以重新建立要素分支的基础，然后将其直接合并到master
中，这也发生了，我们需要在对外部系统进行分阶段失败后进行测试之后保留要素，
在不确定转换的地方：
目前，我正在构建请求测试以合并发布的提交。我可以统一一下吗？
当母版领先于最新版本时，如何处理修补程序。我应该直接从修补程序分支构建和部署发行版吗？
是否有一种明智的方法来处理在合并后应该从发行版中排除的功能？在这些情况下，单独的开发部门真的是一个优势吗？大多数情况下，我最终还是要手动还原和还原提交。
#1 楼
恕我直言，您所面临的问题只是您采用的不良分支策略的副作用：您正在通过develop上的当前生产代码有效地耕作master上的新开发项目（即，向未来生产代码收敛的产品）。这就导致了矛盾的要求和问题，因为通常将来的代码与当前的代码有所不同：新的开发使生产不稳定-将
develop合并到master后看到的回归稳定生产会减慢未来的发展-您需要稳定
develop以使其足以整合到master中。问题，您只是将问题的develop特定部分转移到develop中。更好的方法是将生产移至当前/将来的开发之后，以防止对未来的开发造成干扰发布，如“什么是您的分支模型？”中的图片所示：
请注意，我仅指的是释放上图中的分支，而不是树干上的分支。
为您准备的ork：
master分支消失了，如您所愿，被吸收到develop中速度限制（从未合并到生产中）。生产是从master标签/标签拉出的一个或多个master分支被认为与生产质量足够接近（可以在该分支中解决剩余待办事项的简短列表）如果需要的话）。这些分支只能从release接收直接的热修复和/或精心挑选的修复，它们永远不会与master或其他分支合并。修补程序是直接提交到
master的分支如果此修补程序仅适用于生产版本而不适用于
master，则它将直接提交给release分支。如果同时适用于两者，则通常首先将其提交给master，也将其同时提交给release分支。现在查看进入
master的内容（已超出当前值release分支已关闭），您有2个选择：像今天一样继续使用功能分支，只是它们基于
master而不是release。仍然可以将它们转换为热修复程序-您只需将它们重新设置为相应的master分支，而不是develop 切换到持续集成并获得其收益（可以随时进行） ，包括以渐进的方式-逐渐拉动越来越少的功能分支。
如果您喜欢这种方法，那么这就是您今天所处的位置：
建立发布命名策略：
您不能有一个同名的正在进行的发布分支
您不能（实际上不应）变基或同步生产发布分支
立即从
release中拉出一个master分支，遵循该命名策略不再提交到
releaseX中，它们很快就会直接进入master。 />将develop合并到master中指示开发人员将工作空间基于
develop而不是master。打开
master进行提交根据需要删除
develop（或将其永久锁定/只读以供参考）评论
感谢您的详细建议。我不确定发布分支是否是产品开发之外的一个好主意，但我会重新考虑，这对于该项目可能有意义
–法比安·施蒙格勒（Fabian Schmengler）
17年3月31日在19:39
您还拥有持续部署的替代方案，该方案将开发与生产置于同一位置（而不是进行或进行之前），但为此您需要进行文化转变（因为这意味着放弃所有集成和功能分支）。
–丹·科尼莱斯库（Dan Cornilescu）
17年3月31日在20:04
我知道那个图:)
–paul_h
17年4月1日在23:10
我对先在master中提交修补程序，然后选择发布进行修复有疑问。示例-我的经理要求提供修补程序。如果我在master上实现它，然后将其放入发布分支，则它可能会（根据墨菲定律，master的代码更改会影响此修补程序）与发布分支的状态不兼容。所以，现在我必须花时间重写专门针对发行分支的修补程序，并向经理解释为什么我不能尽快在发行分支上解决此问题，以便尽快提供它，然后再处理以适应该修补程序。主。
– JustAMartin
20年5月6日在13:01
@JustAMartin：这两个命令同样有效，master和release分支是完全独立的。但是，如果您有不兼容的问题，则此修补程序不是同等适用的，因此请不要挑剔。
–丹·科尼莱斯库（Dan Cornilescu）
20年5月6日15:51
#2 楼
假设您取出了master分支（如果您以后喜欢，可以将development重命名为master，以使您的团队感到困惑），然后只需将标签用于developer或hotfix分支上的发布即可。您取出了一个分支，但区别只是语法上的更改。为了改变而进行更改。现在让我们说您实际上是通过保持锁定的master分支来进行开发的。将会发生的是，代码集成会变慢，它在功能分支中的寿命更长，尤其是在发布日期之前。这将增加每次合并的难度并减慢该过程的速度。
在您设定的约束范围内，我看不到进行此类更改的任何积极影响。这将需要放宽约束，尤其是第一个约束。
#3 楼
您已经在每个pull-request和hot-fix分支上构建和测试代码。这意味着总的来说，所有在请求请求上待处理的分支的总和就是您的虚拟develop分支。您可以在测试环境中将几个请求合并到一个分支中时创建一个系统。没有发布到主存储库的临时分支。该分支用于集成包括
master和几个其他请求请求的测试环境，但是一旦完成测试，该分支将不再在任何地方可用。从
master创建发行版时，您通常会在该版本上创建标签。以后的修补程序可以使用该标记创建一个新的修补程序分支，从该分支可以进行部署，即使master的边缘已经在前面。在此修补程序分支上，您可能还会标记一个次要发行版，并确保所做的更改已合并到master中。从git中很难删除发行版中的合并功能。最好的机制是在合并提交上使用
git revert。但这几乎使这些功能/更改无法恢复，历史变得一团糟。特征标记是处理代码部署和功能发布分离的更好方法。如果您的开发人员可以在代码本身的某些条件下隐藏其功能，则可以部署他们的代码，但请关闭该功能。这是一个单独的主题，但是存在许多与此有关的信息（包括对devops.SE的问答）。
评论
似乎您一方面说您不需要DEV分支，但接着继续解释为什么您确实需要它。生存了数周的功能分支在分散了这么长时间后将很难合并。您确定要删除DEV吗？@DaveSwersky好问题！我不确定，这就是为什么我要在这里问问题：)关于长期存在的功能分支：合并的困难是一个已经存在的问题，将被转移到另一个地方。通过从主分支返回常规合并，这是可行的。如果主分支是master会更困难吗？
长寿的分支机构始终是一个挑战，尽管合并到母版而不是DEV分支可能是更多的挑战。解决该问题的方法可能是更好地分解工作，以保持这些分支的生命周期短。如果您可以阻止主题/功能分支的寿命超过24-48小时，那么消除DEV可能会更好。
@FabianSchmengler您要删除dev分支的真正原因是什么？听起来确实像在事情未按计划进行的情况下需要它。
称它为master或develop或任何您想要的东西，如果您想拥有真正的CI，则将需要一个集成分支，或者如果将其委派给功能分支，则只能将它们与当前版本隔离进行外部集成。