GitFlow：如何维护以前的版本？
GitFlow: How to maintain previous releases?
我目前正在为我的团队制定工作流程。
我们收到的建议是使用 GitFlow 方案。这个方案可以放在图表上如下：
但是，我有一个关于如何处理特定案例的问题。
由于我们的活动，我们必须维护我们的客户可能仍在使用并且出于各种原因不想更新的先前版本。
在 GitFlow 方案中，主干应该是发布发生的地方。主干中的提交是一个潜在的可交付产品，应该收到一个版本标签。
所以...我怎样才能回到过去，为旧版本生成修复并将其合并回主干以生成该版本？
另一个问题，如果我不想将修复程序带回后备箱？
在我看来，此工作流程更适合不断向客户推送新版本的软件，例如移动应用程序，但不适用于工业产品，即使它们是从 CI 构建的。但也许我在这里遗漏了一些东西，因此我的问题
让我们把你的问题分成两部分：
how can I go back in time, [to] produce a fix for an older version ?
你在第二张图中的问号是完全正确的。只需找到您希望修改的版本的标签，从中分支（也许将其命名为 hotfix/1.1.1），然后提交您的新更改。然后标记“发布”。
你的后半部分问题：
how can I ... merge it back in the trunk ?
特别是如果：
I do not want that fix to be brought back in the trunk ?
如果您确实希望将该修补程序集成到主干中，这很容易 - 只需将其合并（如果您有冲突，可以像往常一样解决它们）。
如果您不希望将该修补程序集成到主干中，您有一些选择：
- 无限期地保持你的
hotfix/1.1.1。分支机构非常便宜，这是许多公司使用的有效策略。 （事实上 ，许多公司在 Git-Flow-Like 策略中完全取消了 master 分支，只是无限期地保留他们的 release/ 分支。）如果你走这条路，你可能有一天有许多远程分支，在这种情况下，我建议在您的分支名称中使用伪目录斜杠字符 (/)，如 hotfix/1.1.1 所建议的那样。许多 Git 客户端允许您按伪目录汇总分支，因此您不必查看数百个您不感兴趣的分支（通过折叠视图中的 hotfix/ 目录。）
- 我个人的偏好是不要永远保留大量修补程序分支，因此您可以花点心思将修补程序分支合并回主干，但是告诉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!
请注意我们的合并策略对工作副本没有影响。它的唯一目的是从 hotfix 分支中引入提交，这样你就不需要再维护 hotfix 分支了；此时您可以简单地删除它。
提示：请善待并使用描述性的提交消息来解释您这样做以及原因！
你没有问这个，但根据我的经验，它最终肯定会出现：
What if I want to integrate some of changes from the hotfix and not others?
这是一个很好的问题！有多种方法可以给这只猫蒙皮，在我了解与我们的策略合并之前，我会简单地使用 --no-commit 标志进行合并，手动撤消我不想保留的内容，然后提交合并。这样做的缺点是您只能相信合并提交已正确完成，并且可能很难（呃）进行故障排除。如果你走这条路，一个描述性的提交消息解释你做了什么以及为什么在这里很重要。
我目前首选的处理方式是将修补程序更改分成两部分（通常是 2 次提交，但也可能更多）。确保所有你想集成的提交首先在 hotfix 分支上，然后是你不想集成的提交。 （如果事后需要，很可能你可以使用 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，但为了保持 --no-ff 的精神，合并到 main 中，如 Git 流程所定义，每个第一个父提交到 main 应该代表一个版本，除非临时分支和它的 2 个合并提交通过 main.[=33 上的单个合并提交引入，否则这不会是真的=]
旁注：这是一个小问题，但您的第一个图表似乎违反了一个 Git 流程原则，主要是标记的版本没有制作他们返回 develop 的路够快了。通常，您的蓝点会立即指向 develop。您可以看到 develop 中没有的 3 个蓝点版本。
我目前正在为我的团队制定工作流程。 我们收到的建议是使用 GitFlow 方案。这个方案可以放在图表上如下：
但是，我有一个关于如何处理特定案例的问题。 由于我们的活动，我们必须维护我们的客户可能仍在使用并且出于各种原因不想更新的先前版本。
在 GitFlow 方案中，主干应该是发布发生的地方。主干中的提交是一个潜在的可交付产品，应该收到一个版本标签。
所以...我怎样才能回到过去，为旧版本生成修复并将其合并回主干以生成该版本？
另一个问题，如果我不想将修复程序带回后备箱？
在我看来，此工作流程更适合不断向客户推送新版本的软件，例如移动应用程序，但不适用于工业产品，即使它们是从 CI 构建的。但也许我在这里遗漏了一些东西，因此我的问题
让我们把你的问题分成两部分：
how can I go back in time, [to] produce a fix for an older version ?
你在第二张图中的问号是完全正确的。只需找到您希望修改的版本的标签，从中分支（也许将其命名为 hotfix/1.1.1），然后提交您的新更改。然后标记“发布”。
你的后半部分问题：
how can I ... merge it back in the trunk ?
特别是如果：
I do not want that fix to be brought back in the trunk ?
如果您确实希望将该修补程序集成到主干中，这很容易 - 只需将其合并（如果您有冲突，可以像往常一样解决它们）。
如果您不希望将该修补程序集成到主干中，您有一些选择：
- 无限期地保持你的
hotfix/1.1.1。分支机构非常便宜，这是许多公司使用的有效策略。 （事实上 ，许多公司在 Git-Flow-Like 策略中完全取消了master分支，只是无限期地保留他们的release/分支。）如果你走这条路，你可能有一天有许多远程分支，在这种情况下，我建议在您的分支名称中使用伪目录斜杠字符 (/)，如hotfix/1.1.1所建议的那样。许多 Git 客户端允许您按伪目录汇总分支，因此您不必查看数百个您不感兴趣的分支（通过折叠视图中的hotfix/目录。） - 我个人的偏好是不要永远保留大量修补程序分支，因此您可以花点心思将修补程序分支合并回主干，但是告诉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!
请注意我们的合并策略对工作副本没有影响。它的唯一目的是从 hotfix 分支中引入提交，这样你就不需要再维护 hotfix 分支了；此时您可以简单地删除它。
提示：请善待并使用描述性的提交消息来解释您这样做以及原因！
你没有问这个，但根据我的经验，它最终肯定会出现：
What if I want to integrate some of changes from the hotfix and not others?
这是一个很好的问题！有多种方法可以给这只猫蒙皮，在我了解与我们的策略合并之前，我会简单地使用 --no-commit 标志进行合并，手动撤消我不想保留的内容，然后提交合并。这样做的缺点是您只能相信合并提交已正确完成，并且可能很难（呃）进行故障排除。如果你走这条路，一个描述性的提交消息解释你做了什么以及为什么在这里很重要。
我目前首选的处理方式是将修补程序更改分成两部分（通常是 2 次提交，但也可能更多）。确保所有你想集成的提交首先在 hotfix 分支上，然后是你不想集成的提交。 （如果事后需要，很可能你可以使用 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，但为了保持 --no-ff 的精神，合并到 main 中，如 Git 流程所定义，每个第一个父提交到 main 应该代表一个版本，除非临时分支和它的 2 个合并提交通过 main.[=33 上的单个合并提交引入，否则这不会是真的=]
旁注：这是一个小问题，但您的第一个图表似乎违反了一个 Git 流程原则，主要是标记的版本没有制作他们返回 develop 的路够快了。通常，您的蓝点会立即指向 develop。您可以看到 develop 中没有的 3 个蓝点版本。