需要具有多个开发分支的 Git 工作流

Question

我希望有人能给我指出一个对我们的设置有意义的工作流程，因为事实证明，对所有相互冲突的在线信息进行分类有点无用。

在过去的几个月里，我们一直在使用“GitFlow”工作流程的修改版本。这些是我们拥有的永久分支：

• master（包含生产就绪代码）
• 测试版（包含客户端的最新“演示”）
• develop（包含项目的最新工作）

如您所见，我们的工作流程与传统 GitFlow 的不同之处在于，除了 develop 之外，我们还有一个 beta 分支。因此，我们经常不得不在beta 中包含单个功能（来自功能分支），而不需要合并整个develop。这就是我们出现问题的地方。

当我们从develop 创建一个特性分支时，它会经常与develop 同步。这意味着当我们尝试将功能合并到 beta 时，它会包含在 develop 上发生的大量不需要的提交。

我们能够找到的唯一“解决方案”是将功能分支中的更改手动重新提交（或挑选）到beta。这是非常违反直觉的，我知道必须有更好的方法。

另一个问题是，当我们需要为整个项目创建一个修补程序（应用到所有分支）时，我们从master 创建它，它不会合并到develop 没有疯狂的数量合并冲突。这也可以通过挑选来完成，但我们绝对需要使用 GitHub 桌面应用程序和网站 100% 完成我们的工作流程。我对命令行很熟悉，但我得到了明确的指示，我们不能依赖它。

我考虑过的一个选项是尝试以变基为中心的工作流程，而不是基于合并的工作流，但这是有问题的，因为变基不像合并那么简单（而且我什至认为不可能不使用命令行）。

请帮忙！！必须有一种简单的方法来做到这一点，而我们只是没有看到它。

Answer 1

是的，您可以使用TortoiseGit作为GUI或其他，操作类似。

1. 将功能分支的更改放到 beta 分支：

TortoiseGit -> 创建补丁序列 -> 为 Since 选择 feature -> 为 Number Commits 选择 1（如果您只想在 bate 上应用最新的提交分支）-> 好的

-> TortoiseGit -> Switch/Checkout -> beta ->ok

-> TortoiseGit -> 应用补丁序列 -> 添加刚刚创建的补丁 -> 应用。

现在只有来自特性分支的最新提交应用于 beta 分支。

1. 对于从hotfix分支应用更改到develop的问题，您也可以使用上述创建/应用补丁序列的方式。

Answer 2

进入 Dymitruk

您正在寻找 Adam Dymitruk http://dymitruk.com/blog/2012/02/05/branch-per-feature/ 的“每个功能的分支”。这正是您所要求的。

它与 GitFlow 有不同的转折；它使用 3 种主要类型的分支：master、功能分支和 qa 分支。后者就像你的beta 分支。

master 是您当前生产服务器上的版本。 所有其他分支都离开了这个分支。

功能分支就是这样。它们总是从master 分支出来（这是与 GitFlow 的主要区别）。

qa 是根据定义将在生产服务器上上线的“下一个”版本。

它使用大量的 rebase，以及 git 的 rerere 缓存，避免了一遍又一遍地解决冲突。

功能分支永远不会合并到某种develop 分支中（没有）。相反，在您拥有一组可供测试的功能分支的任何时候，qa 都会从头开始重新创建，从master 开始，并将“就绪”功能分支合并到其中。没有分支从qa 开始，并且您永远不会向qa 提交任何内容。您也永远不会将功能的更改重新合并到 qa，您总是从头开始。

这听起来像是一场冲突的噩梦，但实际上非常简单。由于 rerere 缓存，通常只发生“必要的”冲突。每个曾经发生过的冲突都会由git 自动解决。这个操作当然是通过一个相对简单的 shell 脚本自动完成的。

作为具有巨大好处的副作用，在任何时候从qa 中支持功能都是微不足道的（只需重建qa，忽略该功能）。

这意味着当我们尝试将某个功能合并到 beta 时，它会包含大量在开发时发生的不需要的提交。

使用 Dymitruk，测试版（又名 qa）从 master 开始，将所有可供测试的功能合并到其中。

另一个问题是，当我们需要为整个项目创建一个修补程序（应用于所有分支）时，我们从 master 创建它，如果没有大量的合并冲突，它不会合并到 develop 中

使用 Dymitruk，修补程序进入 master（当然，master 反映了生产服务器）。然后，所有功能分支都重新基于新的master，最后，qa 从头开始​​创建，从新的master 开始。

变基并不像合并那么简单（而且我什至认为没有命令行是不可能的）。

在这种情况下，变基实际上比合并更简单，因为变基应用一个又一个提交，因此适用于较小的工作单元。相反，合并包含分支上发生的所有提交。这意味着一旦rerere缓存进入游戏，git将能够自行解决大部分冲突。

显然，如果有人决定将所有代码文件中的所有空格都更改为制表符，并开始向master 提交这样的更改，那么你就完蛋了。但这与合并没有什么不同。问题只是发生在不同的时间点。

由于您只对特性分支进行 rebase，因此只有在多个开发人员同时处理特定特性分支时，才会真正遇到常见的 rebase 问题。您可以通过使功能分支足够小来避免这种情况。或者，您必须在开发人员之间进行沟通。但最后，如果人们知道他们在做什么，那么分布式变基肯定是可能的。如果有疑问，您可以使用大量标记作为备用措施，以避免实际丢失任何东西；但过一段时间你会发现这真的不是问题。

附录

来自cmets：

假设有人正在开发一个功能分支，他们需要来自另一个正在进行的功能的代码（这种情况经常发生）。

您可以从另一个功能分支而不是master 开始一个功能分支。

当然，那你要注意一点；如果父功能分支获得更多提交，您希望在其上重新设置子功能。如果master 发生变化，您必须确保先重新设置父功能的基础，然后将子功能重新设置为父功能，而不是master。

关于qa，没有任何变化。

由于您将使用脚本进行两​​个主要操作（重新制作 qa，重新定位所有功能），因此只需在这些脚本中跟踪这一点（不需要任何额外的存储或配置；这些情况可以很容易地用基本的git branch --list 命令来扣除。

另外，有没有什么方法可以使用 GUI 完成这个工作流程？

您将希望至少（重新）创建qa 和脚本化处理变基。由于在这些过程中会定期解决冲突，因此需要开发人员注意，因此最好通过命令行脚本来完成。当然，您可以使用您通常首选的 git GUI 来解决合并/变基冲突；在幕后，一切都像往常一样 git。