46

我们的软件产品线需要同时开发和维护多个软件版本。我们是相对的 Git 新手，最近采用了 Git Flow 来利用Driessen 的分支模型。我们有一个非常小的软件团队，很少有专门的开发人员（我们都身兼数职），也没有“集成大师”。

很多搜索都没有找到关于如何使 Git 和 Git Flow 适应我们的需求的具体建议。事实证明，Git Flow 不太适合同时支持多个版本。关于 SO 的一个相关讨论有答案表明需要使用单独的分支名称来跟踪单独版本的历史记录。这和相关策略会消除 Git Flow，除非它被修改；请参阅上面的团队限制，以了解这对我们来说不实用的原因。

关键问题是其他人发现什么是在支持多个发布线的同时尽可能紧密地实施 Driessen 分支模型的好方法？

更新：

通过更有针对性的搜索和对一些选项的内部讨论来提炼下面的答案（特别是@Rasmus'），我们正在实施以下解决方案，我提供的解决方案可能与类似条件下的类似团队相关。

我们不会继续使用 Git Flow。相反，我们将通过在每个分支名称前加上其预期的发布字符串，将 Driessen 的模型应用于 repo 中的每个单独的发布行，例如：

r1.5/develop

项目的所有版本都包含在 Git 存储库中。开始一个新的项目版本包括创建一小组以发布字符串开头的新的长期存在的分支（例如r1.6/develop，在我们的例子中，r1.6/release; 不master，它暗示单个当前良好的可构建状态）。

我们在服务器上为每个项目建立一个中央公共存储库，这将是通过本地存储库remote链接共享代码的主要途径。推送到此存储库表示代码已准备好供其他人使用。合并RX.Y/develop然后推送RX.Y/release分支表示要发布的代码。 feature, hotfix, 等。人。分支的处理方式类似。给定发布行的分支合并/提交历史记录清晰易懂。我们不希望典型的 Git 分布式存储库策略有利于避免合并此类存储库的复杂性，随着时间的推移，这些存储库可能会在结构上出现分歧。

在某些 Git GUI（例如 SourceTree）中，此分支结构被识别并显示为分层结构，这有助于从分支结构中了解项目的顶级历史。

很抱歉没有对任何答案进行投票；我在 SO 上的声誉还不是这样做的最低要求。

4

3 回答 3

9

我们有一个类似的设置，除了我们有 300 多名专门的开发人员，我们有你描述的几个版本，我们需要提供给不同的客户。

我们已经划分了它，所以我们有一个像 refs/heads/platformX.Y/ 这样的初始 ref，然后我们在此基础上构建

因此，根据您需要做什么，您可以检查 platformX.Y/develop 并从该点开始在功能分支上工作，并在完成后合并回开发。

这对我们有用，我们可以遵循 nvie 模型。

最重要的是，我们将所有这些 platformX.Y 分支合并到我们的主开发分支，因此在这些分支上更正的错误也会发布到最新的软件中。

于 2013-08-14T12:59:41.883 回答
2

我们通常的开发过程非常适合 Driessen 的流程工作流，但有时我们需要为专门的版本开发具有多个功能的分支，我们不希望包含大部分正在进行的开发。我们已经找到了一种使用现有工具在流程中执行此操作的方法，只需几个额外的步骤。（我们正在使用 mercurial，但 git flow 和 hg flow 的选项是相同的。）

例如，我们的下一个正常版本是 23.0，而我们的特殊“沙盒”版本是 22.4.2。对于这些情况，我们：

  1. 早期，在创建新功能之前，为开发的特殊版本创建一个发布分支 22.4.2。如果某些功能在我们想要排除的开发工作之后没有出现，那么早点启动它们是可以的。
  2. 为方便起见在此处制作标签（start-22.4.2）
  3. 使用 start-22.4.2 （开发中的变更集）启动每个新的 22.4.2 功能，因为它是 parent/base 。这可以防止任何合并到同时开发的工作泄漏到发布分支上。除了提示之外，命令行和 Sourcetree 都支持选择父级git flow feature start。
  4. 如果需要，可以根据需要从 22.4.2 分支的尖端手动合并到特性，以从分支中引入任何已完成的特性。这让我们可以处理分支上新的 22.4.2 功能之间的任何关注交互。
  5. git flow feature finish该功能将其合并以正常开发。（对我们来说，这些功能应该包含在未来的版本中。我们只是保护 22.4.2 免受测试较少的工作。）
  6. 之后finish，我们手动将功能关闭之前的最后一个变更集合并到 22.4.2 分支上。
于 2014-12-11T21:13:27.363 回答
1

一种解决方案是更改配置变量gitflow.branch.develop。您在发布的版本中创建一个分支，并将该分支用作新的开发分支。从那里，您可以使用通常的 git-flow 命令。如果您想自动将该工作合并回原始开发分支，请gitflow.branch.develop在 git-flow 完成命令之前更改变量。

于 2013-08-16T10:17:24.250 回答