对于git非专家来说，build议使用多个版本发行版和git-flow
我们的软件产品线需要同时开发和维护多个软件版本。 我们是相对Git新手，最近采用Git Flow来利用Driessen的分支模型 。 我们有一个非常小的软件团队，几乎没有专门的开发人员（我们都戴着很多的帽子），没有“整合专家”。
对于如何根据我们的需求来调整Git和Git Flow，大量的search没有提出具体的build议。 结果是，Git Flow并不适合同时支持多个版本。 关于SO的一个相关讨论有答案，指出需要使用单独的分支名称来跟踪不同版本的历史logging。 这和相关的策略，消除Gitstream，除非它被修改; 看到我们的团队上面的限制，为什么这对我们不实际的原因。
关键的问题是，其他人认为在支持多个版本发行的同时，如何尽可能紧密地实施Driessen的分支模型？
更新：
在下面的答案（尤其是@Rasmus）中提供更有针对性的search和内部讨论，可以得出我们正在实施的以下解决scheme，并将其作为一种可能与类似条件下类似团队相关的方法。
我们不会继续使用Git Flow。 相反，我们将把Driessen的模型应用到回购中的每个单独的发行版本，方法是将每个分支名称与其预期的发行版string相连，例如：
r1.5/develop 所有版本的项目都包含在Git仓库中。 开始一个新的项目版本包括创build一个由释放string开头的一r1.6/develop新的分支（例如r1.6/develop ，在我们的例子中是r1.6/release ;没有master它的单个电stream良好的可build立状态）。
我们在服务器上为每个项目build立一个中央公共存储库，这将成为通过本地回购remote链接共享代码的主要途径。 推送到这个存储库意味着代码已经准备好被其他人使用。 将RX.Y/develop合并，然后推送RX.Y/release分支表示要发布的代码。 feature ， hotfix等。 人。 分支机构处理类似 给定版本行的分支合并/提交历史logging是干净的，可以理解的。 我们不希望典型的Git分布式回购策略倾向于避免合并这种回购的复杂性，随着时间的推移，这种回购在结构上可能会出现分歧。
在一些Git GUI（例如SourceTree）中，这个分支结构被识别并显示为分层结构，这有助于从分支结构中了解项目的顶层历史logging。
对任何答案不投票表示歉意; 我在SO上的声誉还不是最低要求。
我们有一个类似的设置，除了我们有300多个专门的开发人员，我们正是你所描述的几个修订我们需要提供给不同的客户。
我们已经把它分开了，所以我们有一个像ref / heads / platformX.Y /这样的初始参考
所以取决于你需要做什么你checkout platformX.Y /开发和开始工作从一个function分支上的这一点，你合并回来发展，当你完成。
这对我们很有用，我们可以按照nvie模式。
除了我们正在将所有这些platformX.Y分支合并到我们的主要开发分支之外，所以在这些分支上纠正的错误也被发布到最新的软件中。
我们平时的开发stream程与Driessen的stream程工作stream程非常吻合，但是我们有时需要开发一个分支，这个分支有专门的发布版本，我们不希望包含大量的正在进行的开发。 我们已经find了使用现有工具在stream程内执行此操作的一种方法，只需几个额外的步骤。 （我们正在mercurial工作，但gitstream和hgstream的选项是一样的。）
例如，我们下一个正常版本是23.0，而我们特殊的“沙盒”版本是22.4.2。 对于这些情况，我们：
- 在创build新function之前，在开发的特殊版本上创build一个版本分支22.4.2。 如果有一些function开始的时候，只要他们没有对我们想要排除的开发进行任何工作，就可以。
- 在那里做一个标签以方便起步（22.4.2开始）
- 以start-22.4.2开始每个新的22.4.2特性（开发变更集），因为它是父/基 。 这样可以防止任何合并开发的工作同时泄漏到发布分支上。 命令行和Sourcetree都支持为
git flow feature start除了提示之外的select父项。 - 如果需要，可以手动从22.4.2分支的尖端合并到特征中，并根据需要随时从分支中引入任何完成的特征。 这让我们可以处理分支上新的22.4.2特性之间的任何交互问题。
-
git flow feature finishfunction，它将它合并为正常发展。 （对于我们来说，这些function将被包含在将来的版本中，我们只保护22.4.2免受较lesstesting的工作。） -
finish之后，我们手动合并最后一个变更集在特性closures之前到22.4.2分支。
一个解决scheme是更改configurationvariablesgitflow.branch.develop 。 您可以在发布的版本中创build分支，并将该分支用作新的开发分支。 从那里，你使用通常的git-flow命令。 如果您想自动将该工作合并回原始开发分支，请在git-flow完成命令之前更改gitflow.branch.developvariables。
