10

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

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

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

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

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

4

4 回答 4

6

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

基本上只要从 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

产品显示错字

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 中得到修复

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
于 2020-06-02T14:30:54.247 回答
6

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

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

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

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

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

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

master o-------o-----o-------o
               \-----o      /
                 br1 \-----/
                       bf1
于 2016-07-15T12:40:58.710 回答
4

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

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

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

于 2017-01-06T17:40:40.910 回答
0

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

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

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

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

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

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

这让我想到以下几点：

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

于 2017-02-23T13:22:14.100 回答