GitLab 上的修补程序答案

【问题标题】：Hotfix on GitLabGitLab 上的修补程序
【发布时间】：2016-11-18 15:04:03
【问题描述】：

我正在尝试了解 GitLab 在 http://docs.gitlab.com/ee/workflow/gitlab_flow.html 上的建议流程。但是，我不太确定这个说法：

如果您需要挑选带有修补程序的提交，通常在功能分支上开发它并通过合并将其合并到 master 请求，不要删除功能分支。如果主人很高兴（它应该是如果您练习持续交付）然后将其合并到其他分支。

这是否意味着，master 中将有超过 1 个提交？例如，第一次提交（实际上是合并请求）是为了测试修复是否有效，第二次提交是在第一次提交失败时。

另一件事是，（假设我们有一个生产分支）如果我们将修补程序合并到 master 中，我认为我们必须在 master 上部署其他功能，不是吗？否则，我们会挑选 master 中的修补程序提交到生产分支中。

实际上建议的流程不像http://nvie.com/posts/a-successful-git-branching-model/中的另一个流程那么详细。所以，这有点令人困惑。

【问题讨论】：

标签： git gitlab hotfix

【解决方案1】：

我在https://github.com/oldsj/test-hotfix/commits/master 提供的测试修补程序存储库中试验了修补程序过程

基本上只要修补程序分支是从 prod 分支创建的，这个过程似乎相当简单，即使 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)

让我们在 prod 之前向 master 添加一些提交

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

在开发中看起来不错！让我们合并到 imp 和 prod

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”合并到那些环境分支，在较低环境中进行测试后，错字在 prod 中得到修复现在让我们来推动开发更改（提交 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

【讨论】：

【解决方案2】：

这并不是问题的真正答案。更多的是“反弹”。

我实际上是在使用带有主分支和生产分支的 Gitlab 流程： * master 部署在 staging 上 * 生产部署在 preprod 上 * 生产环境中的标签部署在生产环境中

对于修补程序，我的理解是：

从 master (HEAD) 创建一个分支。使固定。提交。
向主服务器创建合并请求
测试通过后，将合并请求挑选到生产环境中
最后创建一个新标签来发布修补程序。

但我最近遇到一个问题：

我从 master 创建了一个修补程序分支来修复一个与生产不同（由合并到 master 中的功能更新，但尚未投入生产。
我将它合并到 master 没有问题。
但是生产中的樱桃采摘是相互矛盾的。所以我需要用双手解决冲突并继续前进。

这让我想到以下几点：

如果我已经从生产分支创建了修补程序分支并从樱桃挑选到主分支怎么办？

【讨论】：

这是另一种显示方式：slideshare.net/viniciusban/gitlab-flow-solo-39625228。但是在这种情况下，您需要挑选到掌握并挑选到生产。它更复杂。我不知道这是否正确。 gitlab 文档并没有说清楚。如何在 gitlab 上使用修补程序？什么时候有紧急事情需要在master可以去之前去生产？有点雾。
git 实验室文档说 “这个工作流，提交只流向下游，......”。因此，我认为从生产中进行挑选热修复并从主人那里挑选生产是错误的。你将做一个“上游”。

【解决方案3】：

来自https://docs.gitlab.com/ee/workflow/gitlab_flow.html的文档

如果您需要选择带有修补程序的提交，通常在功能分支上开发它并通过合并请求将其合并到 master 中，请不要删除功能分支。如果 master 很好（如果您正在练习持续交付，应该是这样），那么您可以将其合并到其他分支。如果由于需要更多手动测试而无法实现，您可以将合并请求从功能分支发送到下游分支。

我认为重点是，你总是合并“下坡”。这意味着它从主 -> 登台 -> 生产，但从来没有一个修补程序到生产，然后再到主控。如果你想“挑选”一个修补程序，你可以将它作为一个特性分支。然后将该功能分支合并到 master 而不关闭它。如果需要，它会经过测试，然后该功能分支可以很好地合并到下线以进行暂存，然后再进行生产。

【讨论】：

没错。恕我直言，令人困惑的部分是您的修补程序分支必须在 master 中的同一提交中创建，该提交已合并到生产中，而 not 来自 master 的提示。此外，这里的“cherry-pick”与 Git 中的含义不同，更令人困惑（实际上是合并）。不幸的是，GitLab 文档中没有提到这一点。

【解决方案4】：

这个工作流程的关键是从正确的点创建一个错误修复分支。假设这是您当前的历史记录：

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

现在您必须修复 master 分支。为此，从master 开始创建一个功能分支，如果需要，它将合并到master 和br1：

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

使用此工作流程，您可以跟踪错误修复，并可以将其应用于任何需要的分支。

要避免的错误是从分支br1开始创建bugfix分支，因为如果你将它合并到master，那么分支br1也会被合并：

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

【讨论】：

为 ascii 艺术点赞。基本上：确保在创建修补程序分支之前执行git checkout master :) 如有疑问，git status 是您的朋友。
hotfix 旨在修复生产中的某些问题。我认为，我们应该改为从生产分支中创建一个修补程序分支。然后合并到master（即集成分支）。之后，让生产分支从 master 中挑选提交。我不知道我的逻辑是否正常。
@sancho21 您应该将hotfix 分支合并到production 分支（我会使用选项--no-ff 和--log），而不是master 之一。除非将master 合并到生产分支没有问题，但我对此表示怀疑。然后将hotfix分支也合并到master中。