合并发布分支后，为什么主分支比开发分支多一个提交？

Question

我还是新手，因此我试图理解为什么在将一个 release 分支合并回 develop 和 master 后，master 的提交记录会比 develop 多 1 个，而不是一致。

我的 develop 分支比 master 多 5 个提交，然后我创建了一个 release 分支并打了标签，该分支也比 master 多 5 个提交，然后我将 release 分支合并回 develop 和 master，但是 master 的提交记录数最终比 develop 多了 1 个。

这是因为 release 分支没有进行任何更改，与 develop 相同，因此合并没有在 develop 上创建提交记录，但在 master 上创建了提交记录，导致master 多了 1 个提交，即使此时的 master 和 develop 实际上相同，这样做有问题吗？

这样做没问题吗？会引起什么问题吗？

- OutOFTouch

Answer 1

问题在于检测到了合并提交。你的提交历史记录可能看起来像这样：

*------------------ A [master]
 \                 /
  *---*---*---*---B [develop,release]

提交 B 如您所述，比 master 提交领先了 5 个。当您将发布分支合并回 master 时，这会创建一个合并提交 A。该合并提交尚不存在于 develop 中。

这不是您需要担心的事情，因为合并提交本身不包含任何更改，它只是将两个历史记录合并在一起。通常，下次您完成 hotfix 分支时，该提交将自动出现在 develop 中。

- Scott Weldon

---

将master合并回develop而不是release，这样做不是更好吗？ - Bas

@Bas：不太确定你在评论的后半部分所指的是什么（release被合并到了master而不是develop）。其实没有必要将master合并回develop，因为develop缺失的只是合并提交（但develop已经包含了合并提交中包含的所有更改）。 - Scott Weldon

@jmng：我编辑了我的答案以澄清一下。 master 中有一个（暂时的）提交不在 develop 中并不重要，因为该提交除了合并两个历史记录外不包含任何更改。 [tag:git-flow] 设置为使 master 和 develop 成为长期运行的分支，因此虽然从功能上讲 develop 将领先于 master，但 master 有一个额外的提交也是可以的。 - Scott Weldon

@jmng：回答你的直接问题，热修补是基于“master”分支创建的，并合并到“master”和“develop”分支。因此，当热修补完成时，它的历史记录，包括最后一次合并提交，将会出现在“develop”分支中。 - Scott Weldon

@jmng: 除了热修补之外，你可以将 master 合并到 develop 中。但实际上没有必要这样做，因为虽然提交不同，但自从 release 分支从 develop 开始并已经合并到 master，master 和 develop 的内容已经完全相同。 - Scott Weldon

Answer 2

在我看来，1个提交超前于origin/master或您的主分支正在跟踪的远程分支。由于您在本地分支上执行了合并，因此会在您的本地主分支上创建一个新的提交以进行该合并，因此使其超前1个提交。

- Ran0990BK

---

我一直认为开发应该始终领先于主分支，你怎么看？ - OutOFTouch

当我将发布合并到主分支和开发分支时，我只看到了一个提交到主分支的提交记录，这是因为在创建发布后没有更改，与开发分支处于同一点？我同意你的说法，提交是在本地主分支完成并推送到远程仓库，即使在远程分支上，开发分支现在也落后于主分支1个提交。由于我是独立开发者，通常不创建发布和功能分支，我只是在远程服务器上将开发分支合并到主分支。虽然这似乎是错误的做法，但我希望改变这种做法。 - OutOFTouch

1. 这是正常的。
2. 我仍然认为 ahead/behind 讨论的是本地分支与远程分支之间的关系，所以不适用。
3. 对于这个问题是肯定的。至于最佳实践部分，老实说我不知道。

- Ran0990BK

Answer 3

现在你必须快速发展成为大师，才能让大师和开发者处于同一水平。

- Cdca

---

虽然将master快进合并到develop可以在技术上解决这个“问题”，但这是不必要的（请参见我的答案），也不被标准的[git-flow]分支模型所推荐。 - Scott Weldon