GitFlow：如何维护以前的版本？

Question

我目前正在为我的团队制定工作流程。我们收到的建议是使用 GitFlow 方案。该方案可以放在图表上如下：

但是，我有一个关于如何管理特定案例的问题。由于我们的活动，我们必须维护客户可能仍在使用的以前版本，并且由于各种原因不想更新。

在 GitFlow 方案中，主干应该是发布发生的地方。主干中的提交是可能可交付的产品，并且应该收到版本标签。

那么...我怎样才能回到过去，为旧版本生成修复程序并将其合并回主干以生成该版本？

另一个问题是我是否不想将该修复程序带回后备箱？

在我看来，这种工作流程更适合不断向客户推送新版本的软件，例如移动应用程序，但不适用于工业产品，即使它们是从 CI 构建的。但也许我在这里遗漏了一些东西，因此我的问题

Answer 1

让我们将您的问题分为两部分：

我怎样才能回到过去，为旧版本提供修复程序？

第二张图中的问号完全适合这一点。只需找到您想要修改的版本的标签，从它分支出来（可能将其命名为类似hotfix/1.1.1），然后提交新的更改。然后标记“发布”。

对于问题的后半部分：

我怎样才能...将它合并回后备箱？

尤其是如果：

我不希望该修复被带回后备箱？

如果您确实希望将该修补程序集成到主干中，这很简单 - 只需将其合并即可（如果您有冲突，请像平常一样解决它们）。

如果您不想将该修补程序集成到主干中，您有一些选择：

1. 无限期地留在你hotfix/1.1.1身边。分支机构非常便宜，这是许多公司使用的有效策略。master（事实上​​，许多公司在类似 Git-Flow 的策略中完全废除了分支，release/只是无限期地保留其分支。）如果你走这条路，有一天你可能会拥有许多远程分支，在这种情况下，我建议使用伪分支名称中的目录斜杠字符 ( /)，如hotfix/1.1.1. 许多 Git 客户端允许您通过伪目录汇总分支，这样您就不必查看数百个您不感兴趣的分支（通过折叠视图hotfix/中的目录）。
2. 我个人的偏好是不要永远保留大量修补程序分支，因此您可以花点心思将修补程序分支合并回主干，但告诉 Git 忽略更改。执行此操作后，您可以删除修补程序分支，因为所有信息都包含在主干中的新标记提交中。

以下是如何在不进行更改的情况下合并分支：

git fetch
git branch -D main # in case you have an old copy of it
git switch main # now you should be up to date with origin/main
git merge --strategy=ours hotfix/1.1.1 # bring in commits without their changes!

请注意，与我们的策略合并对工作副本没有影响。它的唯一目的是从修补程序分支中引入提交，以便您不再需要维护修补程序分支；此时您可以简单地删除它。

提示：请友善地使用描述性提交消息来解释您这样做的原因以及原因！

你没有问这个，但根据我的经验，最终肯定会出现：

如果我想集成修补程序中的一些更改而不是其他更改，该怎么办？

这是一个很棒的问题！有多种方法可以给这只猫剥皮，在我了解与我们的策略合并之前，我会简单地与标志进行合并--no-commit，手动撤消我不想保留的内容，然后提交合并。这样做的缺点是，您必须相信合并提交已正确完成，并且可能很难排除故障。如果您走这条路，一条描述性提交消息解释您做了什么以及为什么在这里很重要。

我目前处理此问题的首选方法是将修补程序更改分为两部分（通常是 2 次提交，但也可能更多）。确保您想要集成的所有提交首先位于修补程序分支上，然后您不希望集成的提交稍后出现。（很可能您可以rebase -i在事后根据需要重新排序它们，只要是在标记并释放它之前。）接下来的步骤非常简单：

git fetch
git switch -c merge-hotfix-into-main origin/main --no-track # create a temp branch
git merge <last-commit-you-want-to-integrate> # take in commits and changes
git merge --strategy=ours hotfix/1.1.1 # bring in remaining commits without changes
git branch -D main # in case you have an old copy of it
git switch main #
git merge merge-hotfix-into-main --no-ff

merge-hotfix-into-main请注意，这里实际上并不需要临时分支，但为了遵循Git Flow 定义的--no-ff合并精神，每个第一个父提交都应该代表一个版本，除非临时分支及其是2 个合并提交通过 上的单个合并提交引入。mainmainmain

旁注：这是一个小问题，但您的第一个图表似乎违反了 Git Flow 原则，主要是标记的版本没有足够快地返回develop。通常，您的蓝点会develop立即指向回。您可以看到 3 个尚未发布的蓝点版本develop。