GitHub分支始终比主分支落后一个提交

Question

我有一个GitHub项目，其中包含一个master分支和一个dev分支。当我从dev合并到master时，我发现合并提交似乎导致dev分支被认为是比master落后一次提交。

这种工作流程是否常见？还是我做错了什么？我尝试从master回合并到dev，但情况变得更糟（比master落后一次提交+领先一次提交）。还尝试了从master到dev的变基合并，但dev仍然落后一次提交。

这个问题的解决方案是什么？

谢谢

编辑，附带dev的提交历史： 和master:

- Pop Flamingo

---

为什么开发分支落后于主分支一个提交是个问题？你已经知道原因（合并提交），这对开发分支来说并不相关。 - chepner

@chepner 是的，基本上，从X到Y的简单合并会导致X被认为落后于Y这一事实，一开始对我来说有点违反直觉，以至于我想知道是否做错了什么。但如果这是常见情况，那太好了！:)谢谢 - Pop Flamingo

真正的问题是你的开发分支正在“跟踪”主分支，而不是其他分支。如果 dev 应该跟踪主分支，则应该将提交从 dev 推送到主分支，而不是合并。 - chepner

@chepner 我不确定在 GitHub UI 的上下文中跟踪意味着什么？难道跟踪不只是关于将本地分支链接到远程分支吗？ - Pop Flamingo

@chepner，最初我只想不时地从dev合并到master，而不是相反。在我的情况下，我这样做是因为我被“落后一个提交”所困扰，但在其他情况下我永远不会这样做。 - Pop Flamingo

Answer 1

更新的回答

好的，你已经进行了拉取请求，但整体原则是相同的：是的，在第一次合并到主分支（master）时，你的源分支（develop）实际上会比主分支落后一个提交，就像我在下面的第一个版本描述的那样。你可以放心，这种工作流程中很常见，它不会阻止你之后的合并，只是简单的快进。

---

（以下是答案的第一版，错误地假设本地合并操作）

当你在第一次合并后处于你所描述的状态时，master 有一个更多的提交，这是合并提交，就像你正确猜测的那样。

此时，如果你想要使两个分支完全同步（尽管在这一点上它们已经在文件方面相似），你需要将 master 合并回 develop，这将是一个简单的快进，其中 develop 获得最后一个提交。

- Romain Valeri

---

感谢您的回答。我已经在我的帖子中更新了两个分支的提交历史的截图，问题是我不记得自己做了什么，因为我进行了一些重置合并，这可能不会出现在历史记录中？奇怪的是，从我记得的情况来看，我再次从主分支合并到开发分支，但从我记得的情况来看，它并没有解决问题。 - Pop Flamingo

最后，既然落后一个提交是正常的，那就没关系了，但我仍然希望能够准确理解发生了什么以及为什么我无法使它们与GitHub完全相同。 - Pop Flamingo

回忆起来，我记得今天回答了一个类似的问题。链接在这里：https://stackoverflow.com/questions/54349058/how-to-detect-merged-branches-that-were-deleted-in-remote/54350401#54350401 - Romain Valeri

如果你只需要你的develop分支与master同步，为什么不干脆放弃它，然后从master重新创建一个develop分支呢？（当然，假设没有整个团队都在从develop拉取代码） - Romain Valeri

那是一个不错的替代方案，尽管我很惊讶似乎没有其他容易的方法。 - Pop Flamingo