"This branch is 1 commit ahead, 1 commit behind master" 在 Github 中使用 "A successful Git branching model"
"This branch is 1 commit ahead, 1 commit behind master" in Github while using "A successful Git branching model"
我正在一个干净的仓库中工作，只有一个文件。我是唯一的开发者。
我想在 A succesful git branching model 中执行 develop-release-master 工作流，所以我做了：
注意：请记住我默认关闭快进，所以将所有 merge 命令视为 merge --no-ff。
我的出身是Github.
在master分支中：
git add .
git commit -m "Initial commit"
git push origin master
git checkout -b 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"
然后我将 master 和 develop 都推送到 Github
git push origin master
git push origin develop
当我检查 Github 中的 develop 分支时，它说：
This branch is 1 commit ahead, 1 commit behind master.
master分支没有这样的消息
我该怎么做才能解决这个问题？此时 master 和 develop 应该相等，因为它们都与 release-0.0 合并了.
不，它不会相等，因为默认情况下您禁用了快进。每次合并都会创建一个新的提交，并且合并提交具有不同的 ID。所以master中的merge commit不是develop中的merge commit。因此 develop 有一个不在 master 中的提交，而 master 有一个不在 develop 中的提交。因此开发中的消息。
至于master中没有消息，那是因为分支与master比较时会出现消息。所以如果你拿master跟master比较的话，留言就没有必要了
一种解决方案是启用快进并在发布和主控中显式创建合并提交，然后保持快进开发。另一种选择是在每次合并到 master 后重新开发开发。您想如何去做完全是您的个人选择，具体取决于您的工作流程和代码。
此外，只要分支中的代码完全符合您的要求，您就不必担心消息。
因为您使用的是 --no-ff，所以每次合并都是一次不同的提交。当您将 release-0.0 合并到 develop 和 master 中时，合并提交将不同。这是它的样子：
如您所见，开发分支有一个提交（将版本 0.0 合并到开发中）不在主分支中（无法访问），主分支有一个提交（发布 v0.0）不在主分支中开发分支。这就是 GitHub 对该消息所说的，完全没问题（内容相同，但提交不同）。
如果您想使用 git 流程，您应该看看 https://github.com/nvie/gitflow，这将对您有很大帮助。
补充一下其他答案：
原git-flow hasn't been in development since 2012, and it has been superseded by git-flow AVH edition in many places (including the Ubuntu repositories and Git for Windows).
AVH 版本引入的差异之一是最终合并是 master* 到 develop 而不是 develop 发布进入开发.
这使得 master 成为 develop 的直接父级并且应该删除您看到的消息的一部分；应该只保留“1 commit ahead”。这也使得验证 master 和 develop 没有意外分离变得稍微容易一些。
* 更确切地说，是合并到 develop 中的新标签（在 master 上）。
我正在一个干净的仓库中工作，只有一个文件。我是唯一的开发者。
我想在 A succesful git branching model 中执行 develop-release-master 工作流，所以我做了：
注意：请记住我默认关闭快进，所以将所有 merge 命令视为 merge --no-ff。
我的出身是Github.
在master分支中：
git add .
git commit -m "Initial commit"
git push origin master
git checkout -b 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"
然后我将 master 和 develop 都推送到 Github
git push origin master
git push origin develop
当我检查 Github 中的 develop 分支时，它说：
This branch is 1 commit ahead, 1 commit behind master.
master分支没有这样的消息
我该怎么做才能解决这个问题？此时 master 和 develop 应该相等，因为它们都与 release-0.0 合并了.
不，它不会相等，因为默认情况下您禁用了快进。每次合并都会创建一个新的提交，并且合并提交具有不同的 ID。所以master中的merge commit不是develop中的merge commit。因此 develop 有一个不在 master 中的提交，而 master 有一个不在 develop 中的提交。因此开发中的消息。
至于master中没有消息，那是因为分支与master比较时会出现消息。所以如果你拿master跟master比较的话，留言就没有必要了
一种解决方案是启用快进并在发布和主控中显式创建合并提交，然后保持快进开发。另一种选择是在每次合并到 master 后重新开发开发。您想如何去做完全是您的个人选择，具体取决于您的工作流程和代码。
此外，只要分支中的代码完全符合您的要求，您就不必担心消息。
因为您使用的是 --no-ff，所以每次合并都是一次不同的提交。当您将 release-0.0 合并到 develop 和 master 中时，合并提交将不同。这是它的样子：
如您所见，开发分支有一个提交（将版本 0.0 合并到开发中）不在主分支中（无法访问），主分支有一个提交（发布 v0.0）不在主分支中开发分支。这就是 GitHub 对该消息所说的，完全没问题（内容相同，但提交不同）。
如果您想使用 git 流程，您应该看看 https://github.com/nvie/gitflow，这将对您有很大帮助。
补充一下其他答案：
原git-flow hasn't been in development since 2012, and it has been superseded by git-flow AVH edition in many places (including the Ubuntu repositories and Git for Windows).
AVH 版本引入的差异之一是最终合并是 master* 到 develop 而不是 develop 发布进入开发.
这使得 master 成为 develop 的直接父级并且应该删除您看到的消息的一部分；应该只保留“1 commit ahead”。这也使得验证 master 和 develop 没有意外分离变得稍微容易一些。
* 更确切地说，是合并到 develop 中的新标签（在 master 上）。