但是我应该忽略“这个分支是主分支之后的1个提交”吗

**tl;dr：**可能，是的，如果你不想调整你的工作流程，你可以忽略它。
详细数据：

为了确定你是否可以忽略它，你需要了解 * 为什么 * 会发生这种情况。当完成一个拉取请求时，有不同的选项。默认选项是创建一个合并提交。在你的例子中，在master上创建了一个新的提交，而不是在orm上，这就是为什么在PR完成后orm会立即落后一个提交。当这种情况发生时，你可以安全地忽略它。下次你完成从orm到master的PR时，你将落后2个提交，下次落后3个提交，以此类推。只要orm和master之间的差异没有变化，你就可以安全地忽略它。
在某个时候，如果一个不同的分支被合并到master中，那么orm将落后更多的提交，并且差异将不再匹配，这时您应该考虑再次将master合并回orm中。

其他备注：

1.当completing PRs on GitHub调用“Squash Commits”和“Rebase and merge”时，还有其他合并选项。在你的例子中，你也不需要这些选项，因为在这两种情况下GitHub都会重写提交（即使在不需要重定基的情况下也是如此）。使用这些选项，您的orm分支将以1次提前提交和1次滞后提交结束。GitHub目前没有快速-正向合并，这是您在PR完成后使分支保持相同所需的。请考虑以下选项之一来解决您的问题，或者忽略它。
1.你真的需要一个长寿命的orm分支吗？根据你的团队的分支策略，你可以考虑使用特性分支而不是orm，每次你开始工作的时候，你可以简单地从最新的master分支出来，然后那个分支就已经有了所有的合并提交，并且是完全最新的。
1.在完成orm到master的PR之后，在本地，你可以考虑把最新的master合并到orm中，在你开始添加更多的提交之前把合并提交放到orm上。注意这和crystal's suggestion把master拉到orm中非常相似。是否使用--rebase标志取决于你自己，并且取决于你是否有其他人与你共享orm分支。如果你总是在完成orm到master的PR之后立即这样做，那么你是否使用rebase应该没有区别。

创建拉式请求后，只要基础和主服务器之间的比较为绿色，则一切正常。
通常在我开始开发之前，总是下载最新的代码：

git pull origin <branchName> --rebase

注意：在您的情况下，请将<branchName>替换为master。

让我们考虑orm分支在master之后提交的情况。

切换到本地orm分支

git checkout orm

这将显示分支之间的计数差异，其中orm是master之后的1提交

git rev-list --count orm..master

这将根据远程master分支获取更改并重置本地orm分支

git fetch origin; git reset --hard origin/master

这会将本地orm分支更改推送到远程orm分支

git push origin orm

刷新github存储库页面，希望您的问题得到解决。
P.S. I personally solved same issue using above steps.个