git 合并修补程序的分支

Question

我们有3个分支（master、acpt、devl）和对应的环境：production、acpt和devl。我们的团队有多个开发人员。试图弄清楚如何使用最佳开发模型来解决以下情况

devl 有以下提交：A、B、C
acpt 有：A
主人有：一个

我有一个需要推送到 master 的修补程序提交。我使用 master 创建了一个名为 hotfix 的新分支，使用提交 D 进行了更改。

我应该将修补程序分支合并到 master、acpt 和 devl 吗？我想合并到 acpt 和 master 会很好。但是由于 devl 已经提前到 C，devl 会有 A,D,B,C 还是 A,B,C,D？试图找出最佳实践。

Answer 1

注意：Raymond Chen 的 "stop cherry-picking, start merging" 比我在 space 中描述的更好。

我相信 "right" 的工作流程是合并 在引入错误时 所做的修复。

您描述了三个可以访问公共存储库的组，总共可以访问三个提交。这不是一个非常现实的场景：此时典型的 Git 存储库将有数百或数千次提交。绘制问题就足够了，但我认为最好绘制六个或更多提交。我在下面画了八张。

（我也不会使用你的分支名称；事实上，我只会使用一个，开始。）

让我们画出我们可能拥有的东西：

                   I--J--K   <-- develop
                  /
...--D--E--F--G--H   <-- tag:v1.0

标签 v1.0 是作为 1.0 版发布的特定提交。与此同时，开发人员继续开发并做出了三个新的提交。

一位客户现在打电话给支持人员，说某些特定的命令或功能有一些特定的错误。此错误现在记录为错误 #1234。支持 and/or 开发人员分析了该错误，发现该错误是在提交 F 中引入的。这是他们应该做的：

                  I--J--K   <-- develop
                 /
             G--H   <-- tag:v1.0
            /
...--D--E--F   <-- fixes/bug-1234

也就是说，我们现在在fixes/名称中有一个新的分支名称-space，其中包含错误ID。我们现在想出一个错误的修复并提交它，使用它的新的和唯一的哈希 ID 进行新的提交。同时开发组已经添加了一个新的提交 L:

                  I--J--K--L   <-- develop
                 /
             G--H   <-- tag:v1.0
            /
...--D--E--F--F1   <-- fixes/bug-1234

我们测试修复，可能通过将其合并到新发布候选分支 (rc/1.1) 下的提交 H，并将生成的合并提交提供给测试组：

                    I--J--K--L   <-- develop
                   /
               G--H   <-- tag:v1.0
              /    \
             /   _--M   <-- rc/1.1
            /   /
...--D--E--F--F1   <-- fixes/bug-1234

如果一切顺利，候选版本 1.1 将成为标记为 1.1 的版本（可能在还添加了更多修复程序之后，但此处未绘制这些修复程序）：

                 I--J--K--L   <-- develop
                /
               G--H   <-- tag:v1.0
              /    \
             /   _--M   <-- rc/1.1, tag:v1.1
            /   /
...--D--E--F--F1   <-- fixes/bug-1234

（此时可以删除候选发布分支名称——它不再有任何用处。它只是用来测试 M，也许还有其他合并。）

现在是时候将提交 F1（错误修复）也合并到主线开发中了。这很难画！这是一个尝试：

                 I--J--K--L------__
                /                  \
               G--H   <-- tag:v1.0  \
              /    \                 \
             /   _--M   <-- tag:v1.1  \
            /   /_____-----------------N   <-- develop
...--D--E--F--F1   <-- fixes/bug-1234

如果在提交 D 或 E 或 G 中发现错误，我们可以用 fixes/bug-1235 标记该提交，修复它，并将修复合并到发布候选 and/or develop 分支也是如此。绘图会变得非常混乱，但 Git 会在每种情况下自动完成尽可能好的合并工作。

自动识别哪些标记 and/or 分支有修复合并到它们也相对容易。提交 F1 现在在 develop 的祖先中，因此它被合并到那里。它在祖先标签v1.1中是，而在标签v1.0的祖先标签中不是，所以客户使用v1。 0 有 bug #1234 应该升级到 v1.1。

git 合并修补程序的分支

git merge branching for hotfixes

git

merge

branch