我们的软件产品线需要同时开发和维护多个软件版本。我们是相对新手的Git用户，最近采用了Driessen的分支模型来充分利用它。我们有一个非常小的软件团队，只有少数专门的开发人员（我们都扮演许多角色），没有“集成大师”。
尽管我们进行了大量搜索，但很少有关于如何将Git和Git Flow适应我们需求的具体建议。已经发现的是，Git Flow不适合同时支持多个版本。在SO上相关的讨论中，一些答案表明需要使用单独的分支名称来跟踪不同版本的历史记录。这种方法及其相关策略消除了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分布式repo策略，而是避免合并此类repo的复杂性，这些repo随着时间的推移可能会发生结构分歧。
在某些Git GUI（例如SourceTree），此分支结构被识别并显示为分层结构，有助于从分支结构理解项目的顶级历史。
很抱歉没有为任何答案点赞；我在SO上的声望还不足以这样做。