您可以通过以下方式查看差异 ：
git log HEAD..origin/master在拉它之前（fetch + merge）（另请参阅“如何让 git 始终从特定分支中拉出来？” ）
如果您有以下消息：
“你的分支和'origin / master'分歧，＃并分别有 1 个和 1 个不同的提交。”
，检查是否需要更新origin 。如果origin是最新的，那么当您在本地进行自己的提交时，一些提交已被推送到另一个 repo 的origin 。
... o ---- o ---- A ---- B origin/master (upstream work)
\
C master (your work)您基于提交 A 提交 C，因为这是您当时从上游获取的最新工作。
但是，在您尝试推回原点之前，其他人推送了提交 B.
发展历史已分化为不同的路径。
然后，您可以合并或变基。有关详细信息，请参阅Pro Git：Git Branching - Rebasing 。
合并
使用 git merge 命令：
$ git merge origin/master这告诉 Git 将来自origin/master的更改集成到您的工作中并创建合并提交。
历史图现在看起来像这样：
... o ---- o ---- A ---- B origin/master (upstream work)
\ \
C ---- M master (your work)新的 merge，commit M，有两个父节点，每个父节点代表一条开发路径，导致存储在该提交中的内容。
请注意，M 背后的历史现在是非线性的。
变基
使用 git rebase 命令：
$ git rebase origin/master这告诉 Git 重放提交 C（你的工作），好像你是基于提交 B 而不是 A.
CVS 和 Subversion 用户在提交之前更新时会定期在上游工作之上重新定义其本地更改。
Git 只是在 commit 和 rebase 步骤之间添加了明确的分离。
历史图现在看起来像这样：
... o ---- o ---- A ---- B origin/master (upstream work)
\
C' master (your work) Commit C' 是由 git rebase 命令创建的新提交。
它在两个方面与 C 不同：
请注意，C' 背后的历史仍然是线性的。
我们选择（目前）只允许在cmake.org/cmake.git使用线性历史记录。
这种方法保留了之前使用的基于 CVS 的工作流程，可以简化过渡。
尝试将 C' 推入我们的存储库将起作用（假设您有权限，并且在您重新定位时没有人推送）。
git pull 命令提供了一种从源获取并在其上重新定义本地工作的简写方法：
$ git pull --rebase这将上面的 fetch 和 rebase 步骤合并为一个命令。
即使在阅读了上述回复之后，我也有了这个并且因为它导致了什么而感到困惑。我的解决方案是做
git reset --hard origin/master然后，这只是将我的（本地）主副本（我假设被搞砸了）重置到正确的点，由（远程）origin / master 表示。
警告 ：您将丢失尚未推送到
origin/master所有更改。
git pull --rebase origin/master是一个单一的命令，可以帮助您的大部分时间。
编辑：从原点 / 主数据中提取提交，并在新提取的分支历史记录上应用更改。