git pull 和 git reset --hard origin/<branch> 有什么区别？答案

【问题标题】：What is the difference between git pull and git reset --hard origin/<branch>?git pull 和 git reset --hard origin/<branch> 有什么区别？
【发布时间】：2017-08-19 14:56:42
【问题描述】：

我发现后者比第一个快，所以我通常在git fetch 之后，每当我需要将我的本地分支与远程同步时这样做。如果有的话有什么区别？

【问题讨论】：

git pull 从远程存储库获取，git reset 处理本地树。它们有什么可比性？
如果您的本地分支与远程分支不同，git pull 会进行合并。 git fetch 和 git reset --hard 仅结帐。
作为一个非常松散的类比，将git pull（即git fetch，后跟git merge）想象为：将我搬到一个新地址，带走我所有的财产。将git fetch 后跟git reset --hard 想象为：烧掉我所有的财产，然后将我安置在新地址。既然房子是装修好的，如果你没有自己的财产，结果是一样的。但是如果你做，那么……
git stash - 我没有任何财产.. :-)
@hurturk 或者，烧掉我所有的财产。

标签： git version-control git-pull

【解决方案1】：

$ 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，不像如果reset那么你的本地将有A，C而不是B。

【讨论】：

【解决方案2】：

他们的工作完全不同：

git pull: 将来自远程存储库的更改合并到当前分支中。在其默认模式下，git pull 是 git fetch 后跟 git merge FETCH_HEAD 的简写。

使用git reset --hard origin/branch Git 会：

使您当前的分支（通常是 master）回到指向 <SOME-COMMIT>。
然后使工作树中的文件和索引（“暂存区”）与<SOME-COMMIT> 中提交的版本相同。

注意：始终值得注意的是，git reset --hard 是一个潜在的危险命令，因为它会丢弃所有未提交的更改。为安全起见，在使用 git status 之前，应该经常检查输出是否干净（即为空）。

【讨论】：

【解决方案3】：

这两个命令主要用于不同的情况。

git pull 从远程拉取（获取和合并）更改到本地，尤其是其他推送到远程的提交，并且您希望这些提交适用于您的本地分支。

git reset --hard origin/branch 强制使您的本地分支指向 origin/branch 指向的提交。这通常是针对你想放弃你所做的本地更改并将本地分支保持为远程状态的情况。

【讨论】：

【解决方案4】：

获取源更新的方式比性能问题更重要。您需要将它们用于特定情况。我可以给你举两个例子：

git reset --hard ... 可用于更新生产中的代码，如果你经常发现自己在修改生产代码调试。这通常发生在项目的早期阶段用懒惰的想法部署。
git pull 是获得新提交的最被接受的方式，它通常是有道理的，你不会有巨大的本地变化。如果你的提交时间更长，有更多人参与同一个分支，你最终可能会有直觉去做git pull --rebase 或先获取再比较。

Git 可以明确地满足您开发风格的非常具体的需求，您可以在路上发现它们。一旦您对自己的工作安全感到满意，就根本不必担心性能。

【讨论】：

【解决方案5】：

以下命令：

git fetch
git reset --hard origin/<branch>

将丢弃所有本地更改。

在哪里：

git pull

与以下内容完全相同：

git fetch
git merge origin/<branch>

将尝试保留本地更改。

【讨论】：