我们的软件产品线需要同时开发和维护多个软件版本。我们是相对Git新手，最近采用Git Flow来利用Driessen's branching model。我们有一个非常小的软件团队，很少有专门的开发人员（我们都戴着很多帽子）而且没有“集成大师”。
对于如何使Git和Git Flow适应我们的需求，很多搜索都没有提出具体的建议。结果发现，Git Flow不太适合同时支持多个版本。一个related discussion on 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上的声誉还不是最低要求。
答案 0 :(得分：9)
我们有类似的设置，除了我们有300多名专职开发人员，我们完全按照您所描述的几个版本我们需要提供给不同的客户。
我们对它进行了划分，因此我们有一个像refs / heads / platformX.Y /那样的初始引用，然后我们建立在
之上因此，根据您的需要，您可以检查platformX.Y / develop并从功能分支上的那一点开始工作，然后在完成后合并回来进行开发。
这适用于我们，我们可以遵循nvie模型。
除了我们将所有这些platformX.Y分支合并到我们的主要开发分支之外，所以在这些分支上纠正的错误也会发布到最新的软件中。
答案 1 :(得分：2)
我们通常的开发流程很好地适应了Driessen的流程工作流程，但我们有时需要为专业版本开发一个具有多个功能的分支，我们不希望包含大量正在进行的开发。我们已经找到了一种使用现有工具在流程中执行此操作的方法，只需几个额外的步骤。 （我们正在使用mercurial，但git flow和hg flow的选项是相同的。）
例如，我们的下一个正常版本是23.0，我们的特殊“沙盒”版本是22.4.2。对于这些情况，我们：
git flow feature start的提示之外的父级。git flow feature finish该功能，将其合并为正常开发。 （对我们来说，这些功能 意味着包含在未来的版本中。我们只是保护22.4.2免受经过较少测试的工作。）finish之后，我们手动将功能结束前的最后一个变更集合并到22.4.2分支上。答案 2 :(得分：1)
一种解决方案是更改配置变量gitflow.branch.develop。您可以在已发布的版本中创建分支，并将该分支用作新的开发分支。从那里，您使用通常的git-flow命令。如果要将该工作自动合并回原始开发分支，请在git-flow finish命令之前更改gitflow.branch.develop变量。