执行git checkout恢复文件后远程自动同步，疑惑原因及是否曾误推？

本地仓库有3个分支——main、major-test、recovery，远程仓库也有对应的同名分支。当前工作分支为major-test。
在尝试回滚一个错误提交时，我使用了一系列git reset和git revert命令，最后发现把事情搞砸了，于是将包含正确修改的myfile.java文件移到了recovery分支。现在我想从recovery分支取回该文件，将其修改同步到当前的major-test分支，因此执行了以下命令：

git checkout recovery -- src/myfile.java

该命令按预期生效，本地src目录下的myfile.java已更新为所需版本。但我意外发现远程仓库也同时被更新了。通常我会使用以下命令将本地修改同步到名为origin的远程仓库：

git push -u origin major_test:major_test

但这次无需执行该命令，我对此感到困惑。登录GitHub仓库网页后，发现远程的该文件已是更新后的版本。执行git status命令时，输出如下：

On branch major_test
Your branch is up to date with 'origin/major_test'.
nothing to commit, working tree clean

是否有可能在之前尝试修复错误提交时，我意外将修改推送到了远程仓库，但因本地仓库未同步而未察觉？

• 你猜测的情况完全成立。在之前用git reset和git revert处理错误提交的过程中，你大概率误执行了git push操作，把本地major-test分支的修改推送到了远程origin/major-test。但后续你又做了本地的重置、回滚操作，导致本地分支和远程分支出现偏差，只是当时没留意到。
• 当你用git checkout recovery -- src/myfile.java恢复文件后，本地的修改刚好和远程已存在的版本一致，所以git status显示本地分支与远程分支同步、工作区干净。这就造成了“没推送却更新了远程”的错觉，实际上远程的版本是你之前误推送上去的，这次只是本地状态追上了远程。
• 你可以执行git log --oneline major_test origin/major_test查看两个分支的提交历史对比，确认远程分支是否存在你之前误推送的提交记录，就能验证这个推测。

内容的提问来源于stack exchange，提问作者AVO