git - GitLab上的修补程序

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

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

是不是意味着，主人会有超过1次提交？例如，第一次提交（实际合并请求）是测试修复是否正常，第二次提交是第一次提交失败。

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

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

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

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

我在https://github.com/oldsj/test-hotfix/commits/master可用的测试修补程序存储库中对修补程序过程进行了实验

基本上，只要从prod分支创建了hotfix分支，即使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

Typo在较低环境中测试后通过将“ PR”合并到这些环境分支中而在产品中修复现在让我们促进开发人员的变化（提交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

dev更改现在已在imp和prod中以及此修复程序中

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

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

的文档

如果您需要通过修补程序挑选提交，通常在功能分支上开发它并使用合并请求将其合并到master中，不要删除功能分支。如果掌握是好的（如果你正在练习持续交付，那么你应该将它合并到其他分支机构）。如果这是不可能的，因为需要更多的手动测试，您可以将功能从功能分支发送到下游分支。

我认为关键是，你总是合并“下坡”。这意味着它来自大师 - ＆gt;分期 - ＆gt;生产，但从来没有一个修复生产，然后掌握。如果你想“挑选”一个修补程序，你可以将它作为一个功能分支。然后将该功能分支合并到master而不关闭它。如果需要，它已经过测试，然后该功能分支可以合并到分段然后生产。

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

我实际上正在使用Gitlab流与master和production分支： * master部署在staging上 *生产部署在preprod上 *生产中的标签部署在生产中

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

从master（HEAD）创建分支。固定。提交。
创建合并请求到主
当测试通过时，樱桃挑选合并请求到生产
最后创建一个新标记以发布此修补程序。

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

我从master创建了一个修补程序分支来修复一个文件不同于生产（由主要合并的功能更新但是还没有投入生产。
我把它合并到主人没有问题。
但是樱桃挑选生产是相互矛盾的。所以我需要用手来解决冲突并继续下去。

这让我想到以下几点：

如果我从生产中创建了一个修补程序分支并且从主要内容中创建了一个修补程序分支怎么办？

GitLab上的修补程序

4 个答案: