我的团队有一个问题需要解决,这是针对我们案件的最佳策略。
我们的情况
每个功能都有一个单独的分支
我们有一个从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脚本是独立执行的,现在保存在另一个存储库中。
最佳答案
首先,要使所有这些功能都需要一定的良好流程规范,这听起来像您已经拥有一个多组件应用程序,其代码库的构造实际上并没有很容易实现。
我做这样的事情:
-master分支是真实的来源,包含所有已完成的功能,只有构建master / architect /将所有内容合并/ cherry-pick
-release_x.y是代表该版本最终产品的分支。
在开发周期的开始,从先前的发行分支创建发行分支。
每个功能团队在开始功能工作的任何时间都由master创建自己的分支。功能小组中的任何人都可以签入此分支。
功能完成后,将适当的提交挑选/合并/压入master,然后删除功能分支。
确认已发布的功能后,提交便会被选中/合并/压入发布分支。构建是从release分支完成的。
如果您有以前版本的错误修复,请使用该版本的分支进行初始修复。至少,您需要将更改放入主节点中,可能必须插入其他功能和/或发布分支中,具体取决于影响分析
进行功能开发的另一种方法是在给定的时间点基于master创建单独的团队仓库。根据您的喜好,我喜欢拥有可以独立分支或标记的单独存储库(例如,敏捷项目中的sprint)。这也使各个功能团队更容易交换正在进行的工作,因为它们之间可能存在依赖关系。无论哪种情况,您都可能需要将更新母版带入团队/功能存储库中,但这是可行的。
但是,您可能只是具有许多耦合的复杂源代码树,如果将其删除,则可能会使您的源代码树更易于管理
关于java - 没有开发分支的特征分支模型的Git分支策略,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/35353879/