GitLab 上的修补程序

Question

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

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

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

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

实际上，建议的流程不如http://nvie.com/posts/a-successful-git-branching-model/ 中的另一个流程详细。所以，有点混乱。

Answer 1

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

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

现在您必须修补master分支。为此，创建一个功能分支，从master该分支开始，master并br1在需要时合并：

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

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

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

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

Answer 2

我在https://github.com/oldsj/test-hotfix/commits/master提供的 test-hotfix repo 中尝试了 hotfix 过程

基本上只要 hotfix 分支是从 prod 分支创建的，这个过程看起来就相当简单，即使 master 领先于 imp/prod。

注意：imp就是我们所说的“预生产”

主（开发分支）

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

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

很酷，我们的错字已在修补程序分支中修复，让我们合并到 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

Answer 3

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

如果您需要选择带有修补程序的提交，通常会在功能分支上开发它并通过合并请求将其合并到主干，不要删除功能分支。如果 master 可以正常运行（如果您正在练习持续交付，则应该如此），然后将其合并到其他分支。如果由于需要更多手动测试而无法做到这一点，您可以将合并请求从功能分支发送到下游分支。

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