使用“成功的 Git 分支模型”时在 Github 中的“此分支提前 1 次提交，主次后提交 1 次”

Question

我正在一个干净的仓库中工作，只有一个文件。我是唯一的开发者。

我想在A succesful git branching model 中执行develop-release-master 工作流程，所以我做了：

注意：请记住，我默认关闭了快进功能，因此将所有merge 命令视为merge --no-ff。

我的出身是 Github。

在 ma​​ster 分支中：

git add .
git commit -m "Initial commit"
git push origin master
git checkout -b develop

在 develop 分支中。我对文件进行了更改，然后：

git add .
git commit -m "work in the file"

我已准备好将其发布为 0.0 版

git checkout -b release-0.0 develop

在 release-0.0 分支中。我在文件中添加了一个版本号。

git add .    
git commit -m "Bumped version 0.0"

我已准备好将此版本合并到主版本中。

git checkout master
git merge release-0.0 -m "Releasing v0.0"
git tag -a 0.0 -m "Version 0.0"

...进入开发阶段。

git checkout develop
git merge release-0.0 -m "Merge release 0.0 into develop"

然后我将 ma​​ster 和 develop 都推送到 Github

git push origin master
git push origin develop

当我检查 Github 中的 develop 分支时，它说：

这个分支提前 1 次提交，在 master 后面 1 次提交。

ma​​ster 分支没有这样的消息。

我能做些什么来解决这个问题？此时 ma​​ster 和 develop 应该相等，因为它们都与 release-0.0 合并。

Answer 1

不，它不会相等，因为默认情况下您禁用了快进。每个合并都会创建一个新的提交，并且合并提交具有不同的 id。所以master中的合并提交不是develop中的合并提交。因此，develop 的提交不在 master 中，而 master 的提交不在 develop 中。因此，发展中的消息。

至于消息不在master中，那是因为消息是在将分支与master进行比较时出现的。所以如果你比较master和master，这个消息是没有必要的。

一种解决方案是启用快进并在发布版和主版中显式创建合并提交，然后继续快进开发。另一种选择是在每次合并到 master 后重新开发。你想怎么做完全是你个人的选择，取决于你的工作流程和代码。

此外，只要分支中的代码完全符合您的要求，您就不必担心存在的消息。

Answer 2

只是添加到其他答案：

原来的 git-flow 自 2012 年以来一直没有开发，它在许多地方已被 git-flow AVH edition 取代（包括 Ubuntu repositories 和 Git for Windows）。

AVH 版本引入的差异之一是最终合并是 ma​​ster* 合并到 develop 而不是 release进入开发。

这使得 ma​​ster 成为 develop 的直接父级，并且应该消除您看到的消息的一部分；只应保留“1 次提交”。这也使得验证 master 和 development 没有意外分歧变得稍微容易一些。

* 更准确地说，是新标签（在master上）被合并到develop中。

Answer 3

因为您使用的是--no-ff，所以每次合并都是不同的提交。当您将release-0.0 合并到develop 和master 时，合并提交会有所不同。下面是它的样子：

如您所见，develop 分支有一个提交（将版本 0.0 合并到开发中），它不在（无法从）master 中，而 master 分支有一个不在开发中的提交（发布 v0.0）分支。这就是 GitHub 用该消息所说的，它完全没问题（内容相同，但提交不同）。

如果你想使用 git flow 你应该看看https://github.com/nvie/gitflow，这对你有很大帮助。