GitLab的热修复

Question

我正在尝试理解GitLab在http://docs.gitlab.com/ee/workflow/gitlab_flow.html上建议的流程。但是，我不太确定这句话的意思：

如果您需要使用热修复(cherry-pick)提交，通常会在一个功能分支上开发，并将其合并到主干(master)上以进行合并请求(merge request)，不要删除该功能分支。如果主干(master)已经准备好了(如果您正在进行持续交付的实践)，然后再将其合并到其他分支。

这是否意味着主干(master)中会有多个提交？例如，第一个提交（实际上是合并请求）是为了测试修复程序是否有效，第二个提交是当第一个提交失败时。

另一件事是，（假设我们有一个生产分支）如果我们将热修复合并到主干(master)中，我认为我们必须部署在主干(master)上的其他特性，不是吗？否则，我们将从主干(master)中cherry-pick热修补提交到生产分支。

实际上，建议的流程与另一个流程不太详细，因此有点令人困惑。

- sancho21

Answer 1

我在一个名为test-hotfix的repo中进行了热修复过程的实验，该repo可以在以下地址找到：https://github.com/oldsj/test-hotfix/commits/master。

基本上，只要从生产分支创建了热修复分支，该过程似乎相当简单，即使master比imp/prod领先也是如此。

注：我们将imp称为“预生产环境”。

master (开发分支)

git init
echo "Hello wolrd" > hello.txt
git add -A .
git commit -m "add hello.txt"
git log
commit 66b1a08080f0db548da85471b4673c5a9f6d703f (HEAD -> master)

cat hello.txt
Hello wolrd

git checkout -b imp
git checkout -b prod

产品显示错字

cat hello.txt
Hello wolrd

git log
commit 66b1a08080f0db548da85471b4673c5a9f6d703f (HEAD -> prod, master, imp)

让我们在生产环境之前向主分支添加一些提交。

git checkout master
git log
commit 66b1a08080f0db548da85471b4673c5a9f6d703f (HEAD -> master, prod, imp)

echo "new stuff" >> newstuff.txt
git add -A .
git commit -m "add newstuff.txt"
git log
commit df1ca012262c26ab3a29d81b5cb6d46f6c1fc3cc (HEAD -> master)
commit 66b1a08080f0db548da85471b4673c5a9f6d703f (prod, imp)

有用户报告在 prod 环境中发现了一个错别字，让我们通过从 prod 分支创建新分支来进行紧急修复：

git checkout prod
git log
commit 66b1a08080f0db548da85471b4673c5a9f6d703f (HEAD -> prod, imp)

git checkout -b hotfix
Switched to a new branch 'hotfix'
git log
commit 66b1a08080f0db548da85471b4673c5a9f6d703f (HEAD -> hotfix, prod, imp)

echo "Hello world" > hello.txt
git add -A .
git commit -m "fix typo"
git log
commit 1243123edc75e0abf349e1bb154d39c9f25dab2d (HEAD -> hotfix)

cat hello.txt
Hello world

很棒，我们在hotfix分支中修复了拼写错误，现在合并到主分支(master)并在开发(dev)环境中进行测试。

git checkout master
git merge hotfix
git log
commit 2672d5059a55472132f02178c7f51d8b1af0f8ea (HEAD -> master)

> cat hello.txt
Hello world

在开发环境中看起来很不错！让我们合并到重要环境和生产环境中。

git checkout imp
git merge hotfix
git log
commit 1243123edc75e0abf349e1bb154d39c9f25dab2d (HEAD -> imp, hotfix)
cat hello.txt
Hello world

git checkout prod
git merge hotfix
git log
commit 1243123edc75e0abf349e1bb154d39c9f25dab2d (HEAD -> imp, hotfix)
cat hello.txt
Hello world

git branch -D hotfix

通过将“PR”合并到这些环境分支中，在较低的环境中测试后，在生产环境中修复了错别字。现在让我们将开发更改提升(commit df1ca012262c26ab3a29d81b5cb6d46f6c1fc3cc)。

git checkout master
git log
commit 2672d5059a55472132f02178c7f51d8b1af0f8ea (HEAD -> master, imp)
commit 1243123edc75e0abf349e1bb154d39c9f25dab2d (prod)
commit df1ca012262c26ab3a29d81b5cb6d46f6c1fc3cc
commit 66b1a08080f0db548da85471b4673c5a9f6d703f

git checkout imp
git merge master
git log
commit 2672d5059a55472132f02178c7f51d8b1af0f8ea (HEAD -> imp, master)
commit 1243123edc75e0abf349e1bb154d39c9f25dab2d (prod)
commit df1ca012262c26ab3a29d81b5cb6d46f6c1fc3cc
commit 66b1a08080f0db548da85471b4673c5a9f6d703f

cat newstuff.txt
new stuff
cat hello.txt
Hello world

git checkout prod
git merge imp
git log
commit 2672d5059a55472132f02178c7f51d8b1af0f8ea (HEAD -> prod, master, imp)
commit 1243123edc75e0abf349e1bb154d39c9f25dab2d
commit df1ca012262c26ab3a29d81b5cb6d46f6c1fc3cc
commit 66b1a08080f0db548da85471b4673c5a9f6d703f

开发更改现已在imp和prod中，包括热修复。

cat hello.txt
Hello world
cat newstuff.txt
new stuff

- James Olds

Answer 2

在这个工作流程中的关键是从正确的位置创建一个bugfix分支。假设这是您当前的历史记录：

master o-------o-----o
               \-----o
                 br1

现在您必须修补 master 分支。为此，请创建一个特性分支，从 master 开始合并到 master 和 br1（如果需要）：

master o-------o-----o--o
               \-----o--+
               | bf1    |
               \-----o--o
                 br1

使用这个工作流程，你可以跟踪错误修复，并在任何需要的分支上应用它。

需要避免的错误是从分支br1开始创建错误修复分支，因为如果将其合并到主分支，则分支br1也将被合并。

master o-------o-----o-------o
               \-----o      /
                 br1 \-----/
                       bf1

- Frodon

---

在程序员相关的内容中翻译以下文字：为 ASCII 艺术点赞。基本上：在创建热修复分支之前，请确保执行 git checkout master 命令 :) 当有疑问时，git status 是您的好友。 - Gimby

热修补（hotfix）旨在修复生产环境中的问题。我认为，我们应该从生产分支中创建一个热修补分支，然后将其合并到主分支（即集成分支）。之后，让生产分支从主分支中挑选需要的提交。我不知道我的逻辑是否正确。 - sancho21

@sancho21，你应该将hotfix分支合并到production分支上（我会使用选项--no-ff和--log），而不是master分支。除非没有问题将master合并到生产分支中，但我怀疑这点。然后再将hotfix分支合并到master上。 - Frodon

Answer 3

从https://docs.gitlab.com/ee/workflow/gitlab_flow.html的文档中得知，如果您需要挑选一个包含热修复的提交，通常可以在功能分支上进行开发，并使用合并请求将其合并到主分支(master)中，不要删除该功能分支。如果主分支(master)可以用于生产(如果您正在实践持续交付, 它应该可以)，则可以将其合并到其他分支。如果不可能这样做，因为需要更多手动测试，则可以从功能分支发送合并请求到下游分支。

我认为重点是：您总是要进行“下坡”合并。这意味着它从主分支（master）-> 部署分支(staging) -> 生产分支(production)，但永远不会是直接将热修复合并到生产分支(production)，然后再合并到主分支（master）。如果您想要 "挑选(cherry-pick)" 一个热修复，您需要将其作为一个功能分支(feature branch)。然后将该功能分支合并到主分支(master)中而无需关闭它。它经过测试后，如果需要，就可以将该功能分支逐步合并到部署分支(staging)和生产分支(production)中。

- TS Wannabe

---

没错。我认为令人困惑的是，你的热修复分支必须从合并到生产环境的“master”提交中创建，而不是从“master”的最新提交开始。此外，“cherry-pick”在这里在Git中有着不同的含义，这更加令人困惑（实际上它是一种合并）。不幸的是，这在GitLab文档中没有提到。 - flaviovs

Answer 4

这并不是问题的真正答案，更像是一个“反弹”。

我实际上正在使用 Gitlab 流程，包括主分支和生产分支： * 主分支部署在暂存环境 * 生产分支部署在预生产环境 * 在生产环境中部署标签

对于热修复，我的理解是：

• 从主分支（HEAD）创建一个分支。修复。提交。
• 创建一个合并请求到主分支
• 当测试通过时，将合并请求 cherry-pick 到生产分支
• 最后创建一个新标签来发布热修复。

但最近我遇到了一个问题：

• 我从主分支创建了一个热修复分支，以修复与生产环境不同的文件（由于在主分支中合并但尚未在生产环境中合并的功能更新而更新）。
• 我毫无问题地将其合并到了主分支。
• 但是，在将其 cherry-pick 到生产分支时发生了冲突。所以我需要手动解决冲突并继续进行。

这让我想到了以下问题：

如果我从生产分支创建了热修复分支，并将其 cherry-pick 到主分支下面会怎样？

- Jean LAMY

---

这里有一个替代方案：https://www.slideshare.net/viniciusban/gitlab-flow-solo-39625228。但在这种情况下，您需要从cherry-pick到主分支，并从cherry-pick到生产分支。 这更加复杂。 我不知道是否正确。 Gitlab文档没有明确说明。如何在Gitlab上处理热修复？ 当某些事情很紧急并且需要在主分支之前进入生产环境时怎么办？ 这有点模糊。 - Jadson Santos

Git Lab文档中提到：“这种工作流只有提交向下游流动……”，因此我认为从生产环境进行cherry-pick热修复并从主分支向下游进行cherry-pick是错误的。你需要进行“上游”操作。 - Jadson Santos