"使用"一个成功的Git分支模型",在Github中,这个分支是提前1次提交,1次提交后"

Question

我只用一个文件在一个干净的仓库工作.我是唯一的开发人员.

我想在一个成功的git分支模型中进行开发 - 发布 - 主工作流程,所以我做了:

注意:请记住,默认情况下我有快进,所以请考虑所有merge命令merge --no-ff.

我的起源是Github.

在主分支:

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"

我准备将此版本合并到master中.

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"

然后我推动两个主人并发展到Github

git push origin master
git push origin develop

当我检查Github中的develop分支时,它说:

该分支提前1次提交,1次提交后提交.

该主分支机构不具有这样的消息.

我该怎么做才能解决这个问题？无论主和发展应该是平等的,在这一点上,他们与合并两个版本,0.0.

Answer 1

不，这将不相等，因为默认情况下您禁用了快进功能。每次合并都会创建一个新的提交，并且合并提交具有不同的ID。因此，master中的合并提交不是develop中的合并提交。因此，develop不在master中提交，而master不在开发中。因此，信息正在发展。

至于主服务器中不存在该消息，这是因为该消息是在将分支与主服务器进行比较时出现的。因此，如果您将master与master进行比较，则不需要此消息。

一种解决方案是启用快速转发并在发行版和主数据库中显式创建合并提交，然后保持快速转发的发展。另一个选择是在每次合并到母版后重新开发。您要如何实现它完全是您的个人选择，具体取决于您的工作流程和代码。

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

Answer 2

只是为了添加其他答案:

最初的git-flow自2012年以来一直没有开发,并且已经被很多地方的git-flow AVH版本所取代(包括Ubuntu存储库和Git for Windows).

AVH版本引入的差异之一是最终合并是master*into develop而不是release to develop.

这使得master成为develop的直接父级,并且应该消除你看到的消息的一部分; 只保留"1提前".它还使得更容易验证主人和开发人员没有意外分歧.

*更准确地说,它是合并到开发中的新标签(在主站上).