从逻辑上讲，这应该是对所有三个答案（在我写这篇文章时）推荐的顺序的评论。
git stash
git pull
git stash pop
所有这些都是很好的答案。但我需要足够的空间来格式化内容并写很多东西。 :-)
我不想提交这些更改
不要害怕提交！您也可以提交，然后取消提交。实际上，使用 git stash 进行提交：它们只是没有在 任何 分支上的提交。这可以在下面的第二件事情上有所帮助。但关键在于记住，您的本地分支是您的，可以按照您的意愿处理。
使用
git fetch——这也是
git pull 在执行第二个操作之前会先执行的操作——对你的分支没有影响，只对所谓的远程跟踪分支有影响。这些远程跟踪分支是 Git 记住了在
origin 上看到的内容的方式。也就是说，例如你的
origin/master 记录了他们现在的内容。当他们在他们的 Git 中进行更改时，你的
origin/master 逐渐落后，但是你可以随时运行
git fetch 并获取“他们现在的内容”，你的
origin/master 再次更新。这对你自己的
master 没有影响。
在获取(fetch)之后，你需要使用第二个Git命令将"他们"的工作合并到一个或多个分支中。这个第二个命令可以是
git merge或
git rebase。如果你运行
git pull，那么你已经
隐式地选择了其中的一种命令。我总是认为最好要
明确地选择一个命令，这样你就知道自己在做什么，但如果你愿意，也可以让
git pull来选择。它默认会选择
git merge。这意味着你将得到
git merge的所有复杂性，而没有
git rebase的任何复杂性。
你可能根本不想要任何复杂性。这有点困难，因为Git就是Git，你总是会遇到复杂性。有时合并会失败。有时变基会失败。这就是我认为你应该明确选择一个命令的原因之一：当
git pull失败时，你
需要知道git pull运行了哪个第二个命令导致失败！
我怀疑你回避提交是因为拥有自己的提交会使得
git merge 或者
git rebase 更容易失败。这是正确的！这也是为什么
git stash 会有所帮助。但是请记住，
git stash 只是创建了不在你分支上的提交——这意味着如果你在前两步
git pull 运行时避免了失败，你只是把失败点移动到了当你使用
git stash pop 或者
git stash apply 恢复时！
无论你做什么，最终都会遇到一个问题：你所做的某些更改与其他人所做的更改冲突。你必须合并这些更改，Git 称之为“合并”。合并是一个动作——一个动词，它既适用于“git merge”，也适用于“git rebase”，还适用于“git stash apply”（这是“git stash pop”的前半部分）。
用 git stash 来做这件事没有问题，但最终你还是需要学会如何做。一旦你知道了如何做，你也可以使用 git merge 或者 git rebase 来做。在 Git 中进行合并时，你需要使用提交，无论这些提交是由 git stash 进行的，还是由你自己运行 git commit 进行的。所以不要害怕提交！当然你可以一直拖延不提交，使用 git stash 在拉取之前可能会让这更容易，但请记住 git stash 正在做提交，而 git pull 正在运行合并！
