没有开发分支的功能分支模型的Git分支策略

Question

我的团队有一个问题需要解决我们案例的最佳策略。

我们的方案

1. 每个功能都有一个单独的分支
2. 我们从release创建了master分支，以准备下一个版本。下一版本中的功能将合并到此分支中。但是，正如我所说，在最后一刻，某些功能可能会脱离版本。
3. 在最后一刻，每个功能都可以退出版本（release分支）。我们不确定下一版本中的功能是什么。因此，我们不能使用类似develop分支的东西（如Git Flow中所述）。
4. DBA团队在生产中执行一些独立于版本的脚本。这些脚本是在master上提交的，因为它们已经在生产中。

我的消化

我们正在考虑从release分支为测试团队生成版本。如果一切正常，我们正在考虑将release分支合并到master，在master上放置一个版本标记（如1.0），并从{{1}生成版本使用此版本标记的分支。

master中唯一不是版本提交的提交是来自DBA团队的SQL提交。因此，master生成的版本等于release。

但整个团队未获批准。

恐惧

他们担心我们将使用哪个分支来生成EAR。 master分支中生成的EAR文件与测试的EAR文件不完全相同，因为它是从master（另一个分支）生成的。

我的团队的另一个担心是有人直接（或合并一个功能）直接进入release，并且在master上生成的版本有这个意外的提交。他们肯定会在某个时候发生。

部分恐惧发生是因为DBA承诺＆＃34;混乱＆＃34;主历史。 master必须只是提交版本，但我不知道如何组织DBA团队中独立于版本的SQL脚本。这些SQL脚本与下一个版本一起发布是没有意义的，因为这些脚本已经在生产数据库中执行。

解决方案（临时？）

目前，解决方案是从master分支生成版本，并在生产中使用release分支中的相同EAR。之后，release分支将合并到release，并将创建一个新的master分支。 DBA SQL脚本将继续在release中提交。

我的意见

我不喜欢这种方法，因为：

1. 我们失去了在master中使用仅包含版本提交的版本标记的稳定历史记录的机会。我想为此提供一个解决方案，但我不知道如何解决有关DBA SQL脚本的问题。
2. 恐惧也是基于过去的合并错误，他们使用（复杂的）Subversion作为版本控制。
3. 版本标记将分布在不同master分支机构的存储库中。
4. 基于对某些开发人员直接在release上做错事的恐惧。
5. 此解决方案与几乎所有现有分支模型相反，因为它不会从主服务器生成版本。我对其他现在看不到的问题表示担忧。

即使有这些顾虑，我也无法摆脱恐惧，我理解他们的恐惧。我想知道是否有人对我们的问题有任何不同的解决方案。

更新

在最初的恐惧之后，我们正在从master分支生成版本。在master分支上进行测试后，我们将master中的release分支合并，并从那里生成版本。因此，所有版本标记都保留在release分支中。

如果在master分支中检测到某些问题，我们会删除此分支并生成一个新分支，而不会出现问题。

DBA脚本与某些特定的功能无关，它们是独立执行的，现在保存在另一个存储库中。

Answer 1

首先，需要有一些非常好的流程规则才能使这些工作起作用，听起来你有一个多组件应用程序，其代码库的结构确实不便于提供。

我这样做： -master分支是真实的源代码，包含所有已完成的功能，只有构建主/架构师/任何合并/樱桃选择到此 -release_x.y是代表该版本的最终产品的分支。

在开发周期开始时，将从先前版本分支

创建发布分支

每个功能团队都有自己的分支，在他们开始功能工作的任何时候都是由master创建的。功能团队中的任何人都可以查看此分支。

当一项功能完成后，相应的提交将被挑选/合并/压缩为主，并删除功能分支。

由于某个版本的功能得到确认，因此这些提交会被挑选/合并/压缩到发布分支中。构建是从发布分支完成的。

如果您对先前版本有错误修复，请使用该版本的分支进行初始修复。至少，你需要挑选变化到主人，你可能必须挑选其他功能和/或发布分支，这取决于影响分析

进行功能开发的另一种方法是在给定时间点基于master创建单独的团队回购。取决于您的偏好，我喜欢单独的可以独立分支或标记的回购（例如敏捷项目中的冲刺）。它还使各个功能团队更容易在可能存在依赖关系的情况下交换正在进行的工作。在任何一种情况下，您可能需要将master的更新带入您的团队/功能仓库，但这是可行的。

但是，您可能只有一个复杂的源代码树，其中包含大量耦合，如果删除，可能会使源代码树更易于管理