java - 没有开发分支的特征分支模型的Git分支策略

Question

我的团队有一个问题需要解决，这是针对我们案件的最佳策略。

我们的情况


每个功能都有一个单独的分支
我们有一个从release创建的master分支，以准备下一个版本。下一个版本中将包含的功能已在此分支中合并。但是，正如我所说，在最后一刻，某些功能可能无法使用。
最后的每个功能都可以退出版本（release分支）。我们不确定下一个版本中将提供什么功能。因此，我们不能使用develop分支之类的东西（如Git Flow中所述）。
DBA团队在生产中执行一些与版本无关的脚本。该脚本是在master上提交的，因为它们已经在生产中。


我的建议

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

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

但这并不适用于整个团队。

害怕

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

我的团队的另一个担心是有人直接向master提交（或合并功能），而master上生成的版本具有意外的提交。他们确信这一定会发生。

发生这种恐惧的部分原因是因为DBA犯了“混乱”主历史。主版本仅需要提交版本，但我不知道如何组织DBA团队与版本无关的SQL脚本。这些SQL脚本与下一版本一起发布是没有意义的，因为这些脚本已在生产数据库中执行。

解决方法（临时？）

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

我的想法

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


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


即使有这些担忧，我也无法消除恐惧，我理解他们的恐惧。我想知道是否有人对我们的问题有其他解决方案。

更新

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

如果在release分支中检测到某些问题，我们将删除该分支并生成一个新分支，而不会出现有问题的功能。

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

Answer 1

首先，要使所有这些功能都需要一定的良好流程规范，这听起来像您已经拥有一个多组件应用程序，其代码库的构造实际上并没有很容易实现。

我做这样的事情：
-master分支是真实的来源，包含所有已完成的功能，只有构建master / architect /将所有内容合并/ cherry-pick
-release_x.y是代表该版本最终产品的分支。

在开发周期的开始，从先前的发行分支创建发行分支。

每个功能团队在开始功能工作的任何时间都由master创建自己的分支。功能小组中的任何人都可以签入此分支。

功能完成后，将适当的提交挑选/合并/压入master，然后删除功能分支。

确认已发布的功能后，提交便会被选中/合并/压入发布分支。构建是从release分支完成的。

如果您有以前版本的错误修复，请使用该版本的分支进行初始修复。至少，您需要将更改放入主节点中，可能必须插入其他功能和/或发布分支中，具体取决于影响分析

进行功能开发的另一种方法是在给定的时间点基于master创建单独的团队仓库。根据您的喜好，我喜欢拥有可以独立分支或标记的单独存储库（例如，敏捷项目中的sprint）。这也使各个功能团队更容易交换正在进行的工作，因为它们之间可能存在依赖关系。无论哪种情况，您都可能需要将更新母版带入团队/功能存储库中，但这是可行的。

但是，您可能只是具有许多耦合的复杂源代码树，如果将其删除，则可能会使您的源代码树更易于管理