我发现后者比第一个更快，所以我通常在git fetch后每当我需要将本地分支与遥控器同步时都会这样做。有什么区别？
以下命令：
git fetch
git reset --hard origin/<branch>
将放弃所有本地更改。
其中：
git pull
这与以下完全相同：
git fetch
git merge origin/<branch>
将尝试保留本地更改。
$ git pull
# takes the latest changes of origin/branch (exists both local & remote changes)
$ git reset --hard origin/branch
# replace your local with origin's branch history (discard local changes)
示例：假设我们在本地A中有两个提交，B和远程有两个提交A，C。现在，如果你拉动，那么你的本地包含A、B、C，与重置不同，你的本地将有A，C不会B。
这两个命令主要用于不同的情况。
git pull从远程到本地的拉取(获取和合并(更改，尤其是其他推送提交到远程，您希望这些提交应用于本地分支。
git reset --hard origin/branch强制使您的本地分支指向源/分支指向的提交。这通常是针对您希望放弃所做的本地更改并将本地分支保留为远程状态的情况。
获取源更新的方式比性能问题更重要。您需要在特定情况下使用它们。我可以给你举两个例子：
-
git reset --hard ...可用于更新生产中的代码，如果您经常发现自己正在修改生产代码调试。这通常发生在项目的早期阶段用懒惰的想法部署。 -
git pull是获取新提交的最被接受的方式，它通常，您不会有巨大的本地更改是有道理的。如果您的提交期较长，并且有更多的人同一个分支，你最终可能会有一种直觉来做git pull --rebase或先获取，然后再比较。
Git 可以明确地满足你的开发风格的非常具体的需求，你可以在路上发现它们。一旦你对工作安全感到满意，性能就不应该成为问题。
它们在做什么上完全不同：
git pull ：将来自远程存储库的更改合并到当前分支中。在默认模式下，git pull 是 git fetch 的简写，后跟 git merge FETCH_HEAD。
有了git reset --hard origin/branch Git 将：
- 使当前分支(通常是主分支(返回到指向
<SOME-COMMIT>。 - 然后使工作树和索引("暂存区域"(中的文件与
<SOME-COMMIT>中提交的版本相同。
注：始终值得注意的是，git reset --hard是一个潜在的危险命令，因为它会丢弃所有未提交的更改。为了安全起见，在使用之前，您应该始终检查 git status 的输出是否干净(即空(。