mkl*_*in9 45 git release-management git-flow
我们的软件产品线需要同时开发和维护多个软件版本.我们是相对Git新手,最近采用Git Flow来利用Driessen的分支模型.我们有一个非常小的软件团队,很少有专门的开发人员(我们都戴着很多帽子)而且没有"整合大师".
很多搜索都没有就如何使Git和Git Flow适应我们的需求提出具体的建议.结果发现,Git Flow不太适合同时支持多个版本.关于SO的一个相关讨论具有答案,指示需要使用单独的分支名称来跟踪单独版本的历史.除非经过修改,否则这个及相关策略将消除Git Flow; 看看我们团队的上述限制因为这对我们来说不切实际.
关键问题是,在支持多个释放线的同时,还有其他人认为是尽可能接近实施Driessen分支模型的好方法吗？
更新:
通过更有针对性的搜索和一些选项的内部讨论来提炼下面的答案(特别是@Rasmus')会导致我们正在实施的以下解决方案,并且我提供了一种可能与类似条件下的类似团队相关的方法.
我们不会继续使用Git Flow.相反,我们将Driessen的模型应用于回购中的每个单独的发布行,方法是将每个分支名称与其预期的发布字符串对应,例如:
r1.5/develop
项目的所有版本都包含在Git存储库中.启动一个新的项目版本包括创建一小组新的长期分支,这些分支以发布字符串开头(例如r1.6/develop,在我们的例子中,r1.6/release没有master它具有单个当前良好可构建状态的含义).
我们在服务器上为每个项目建立一个中央公共存储库,这将是通过本地repo remote链接共享代码的主要途径.推送到此存储库表示可供其他人使用的代码.合并RX.Y/develop然后推送RX.Y/release分支表示要发布的代码. feature,hotfix等.人.分支处理类似.给定版本行的分支合并/提交历史记录是干净且易于理解的.我们不希望典型的Git分布式回购策略有利于避免合并这种回购的复杂性,随着时间的推移,这种回购可能会在结构上发生分歧.
在某些Git GUI(例如SourceTree)中,此分支结构被识别并显示为分层结构,这有助于从分支结构中了解项目的顶级历史记录.
抱怨没有对任何答案进行投票; 我在SO上的声誉还不是最低要求.
我们有类似的设置,除了我们有超过300个专门的开发人员,我们完全按照您所描述的几个版本我们需要提供给不同的客户.
我们对它进行了划分,因此我们有一个像refs/heads/platformX.Y /那样的初始引用
因此,根据您需要做什么,您可以检查platformX.Y/develop并从功能分支上的那一点开始工作,然后在完成后合并回来进行开发.
这适用于我们,我们可以遵循nvie模型.
在我们将所有这些platformX.Y分支合并到我们的主要开发分支的所有内容之上,因此在这些分支上纠正的错误也会发布到最新的软件中.