我们正在尝试采用git-flow实现的成功的Git分支模型.现在,我们正在开发至少两个发布分支,一个用于最新的稳定版本,另一个用于下一个("预览")版本.我不明白为什么所有版本似乎都"线性化"到主人并在那里标记.为什么不在发布分支中标记发行版？为什么大师呢？或者为什么开发分支而不是使用master呢？
我们的软件产品线需要同时开发和维护多个软件版本.我们是相对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上的声誉还不是最低要求.