当我将发布分支合并到 main 中，然后合并到 dev 中以合并其中的更改时，我的开发人员说 X 提交在前面，X 提交在后面。为什么？
我正在遵循 gitflow 分支 模型。我非常严格地遵循这些准则。
- 我从 dev 创建一个发布分支，并在那里进行最终的错误修复和调整，
- 然后将其合并到 main 中，然后合并到 dev 中，然后删除发布分支
- 我在合并时使用 --no-ff （无快进）标志我的发布分支分为 main 和 dev，
- 目前我唯一不遵循的就是在将发布的更改合并到其中后，从 git 标记我的 main。相反，我使用发布功能从 GitHub 存储库中标记它。
然而，我的开发分支现在这样说：
此分支提前 1 次提交，主分支后 1 次提交。
我对此感到困惑。看来每个分支上的新合并提交（由将发行版合并到 dev 和 main 中引起）是唯一的区别。这应该发生吗？我做错了什么吗？
I'm following the gitflow branching model. I follow the guidelines quite closely.
- I create a release branch from dev, and make final bugfixes and adjustments there
- I then merge this into main, and then into dev, and then delete the release branch
- I use the --no-ff (no fast-forward) flag when merging my release branch into both main and dev
- the only thing that I currently don't follow is tagging my main from git after incorporating the changes from release into it. Instead I tag it from the GitHub repo using the releases feature.
However, my dev branch now says this:
This branch is 1 commit ahead, 1 commit behind main.
I'm confused by this. It appears that the new merge commit (caused by merging release into dev and main) on each branch is the only difference. Is this supposed to happen? Am I doing something wrong?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这完全没问题，并且在某些情况下是预期的。让我们来看看发生了什么：
develop的提示创建了分支release。此时develop和release是相同的。release（或者不添加，它实际上不会改变这个问题的结果）。release感到满意，您就可以使用--no-ff（无快进）将其部署并合并到main中旗帜。这会在main上创建一个新的合并提交。因此，此时release和main具有相同的内容，但main上有一个额外的提交。release合并回develop，同样使用--no-ff。这会在develop上创建一个新的提交，该提交不在release或main上。release。因此，此时，
develop有至少 1 个不在main上的提交，并且main恰好有一项提交不在develop中。据推测，自创建release分支以来，您没有向develop添加任何提交，因此develop将比早 1 次提交main，并且在main之后恰好有 1 次提交。注意：下次执行
release分支时，将会发生相同的过程，但最终您将在main上得到 2 次提交t 在develop中，并且这将继续递增，直到您执行第一个hotfix分支，这会将所有旧的合并提交带回develop一键完成。这是预料之中的，但第一次看到它时可能会感到困惑。提示：在经历了
hotfix分支将许多合并提交带回develop后，现在当我在使用 Git Flow 的存储库中工作时，合并后 < code>release 到main中，我更喜欢将main合并到develop中，而不是将release合并到 <代码>开发。内容将是相同的，但现在develop将不再位于main后面。这还有一个额外的优点，即可以在部署之前更轻松地确定任何release分支是否与main完全同步；您只需确保master指向的提交也在release中。This is completely fine, and expected in certain situations. Let's walk through what happened:
releasefrom the tip ofdevelop. At this momentdevelopandreleaseare identical.release(or not, it doesn't actually change the outcome for the purposes of this question).release, you deploy it and merge it intomainusing the--no-ff(no fast-forward) flag. This creates a new merge commit onmain. So at this momentreleaseandmainhave identical contents, butmainhas one extra commit on it.releaseback down intodevelop, also using--no-ff. This creates a new commit ondevelopthat isn't onreleaseormain.release.So at this point,
develophas at least 1 commit on it that isn't onmain, andmainhas exactly one commit on it that isn't indevelop. Presumably you didn't add any commits todevelopsince creating thereleasebranch, and thereforedevelopwould be exactly 1 commit ahead ofmain, and exactly 1 commit behindmain.Note: the next time you do a
releasebranch the same process will occur, but you will end up with 2 commits onmainthat aren't indevelop, and this will continue incrementing until you do your firsthotfixbranch, which will bring all of those older merge commits back intodevelopall in one shot. This is expected, but can be confusing the first time you see it.Tip: After experiencing the
hotfixbranch bringing many merge commits back intodevelop, now when I work in repos that use Git Flow, after mergingreleaseintomain, I prefer to mergemainintodeveloprather thanreleaseintodevelop. The contents will be identical, but nowdevelopwon't be behindmainanymore. This also has the added advantage of making it easier to determine if anyreleasebranch is fully up to date withmainbefore you deploy it; you simply need to make sure the commitmasterpoints to is also inrelease.