假设我正在本地存储库中处理license.txt，并对其进行了修改。在我提交之前，Susan 修改并提交到远程存储库。
如果我选择git fetch，我的更新究竟会发生什么？结果去哪儿了？
【问题讨论】：
You have uncommitted changes in the working directory 消息中停下来
origin/master）。
标签： git
您的更新没有任何反应。 git fetch，由于没有更好的词，从远程存储库获取提交并将它们放置在对象数据库的本地副本中。由于您在自己的分支上工作，因此它们之间没有交互，直到您明确选择进行一些交互，例如，通过 rebase、cherry-picking 等。
您可以通过检查它们各自的分支（例如，origin/master）来访问获取的提交。
【讨论】：
origin/master）
git fetch 不会改变工作树的状态。事实上，它不需要工作树：git fetch 可以在裸存储库（没有工作树的存储库）中工作。
Susan 的提交在她的存储库中生成了一个新对象。在您执行提取之前，该对象在您的工作区中是未知的。那时，该对象在您的空间中可用。因为该对象由其哈希标识，这是一个非常大的整数，所以它几乎肯定不同于（不冲突）您已经拥有的任何其他对象。
除了获取新的提交，git fetch 还将更新远程分支指针。例如，假设 Susan 的 master 分支和您的分支在 Susan 提交之前是相同的。在 Susan 提交之后，她的分支有一个新的提交，而你的没有。当您执行git fetch 时，您的本地origin/master 分支指针会更新以指示其头部现在是Susan 的提交。但是，您本地的 master 分支保持不变。
此时您可以运行git checkout（不带参数），您将收到类似branch master is behind origin/master by 1 commit and can be fast-forwarded 的消息。这来自比较master 和origin/master。
您现在可以通过多种方式融入 Susan 的变化：
git rebase：在 origin/master 的新变化之上挑选仅在您本地 master 中的变化（从而重写它们的历史），并将结果作为本地 master 上的新 HEAD ）。在此之后，master 严格领先于origin/master：它与origin/master 相同，加上您的更改。 git merge：保持您的更改完好无损，并在 master 上生成一个新提交，它将它们折叠并合并它们。此提交有两个父项：master 上的前一个提交（在本例中为 Susan 的提交）和您的一系列本地提交中的最后一个提交，其原始形式。同样，master 现在严格领先于origin/master。git reset --hard origin/master：为了表彰 Susan 让你所有的工作都过时的承诺，你扔掉你的工作，纯粹快进你本地的 master 到 Susan 的改变。现在master 等同于origin/master。前两个操作使用git pull 命令与git fetch 组合。 git pull 要么执行 git fetch，然后执行 git merge，要么执行 git fetch，由 git rebase 执行。每个分支的行为都是可配置的，并且有一个关于应该以哪种方式配置新创建的分支的全局选项。您可以使用git pull --rebase 或git pull --merge 覆盖该行为。
由于您的本地更改未提交，因此您将无法执行这些集成操作（变基或合并）。 Git 希望您首先将更改转换为提交。新获取的对象之间没有交互，并且您根据本地更改进行提交。
您现在不必采取任何行动。感谢git fetch，您可以了解上游活动，而无需立即与它们集成。例如，您可以通过git log origin/master 来查看有哪些新内容，以及它可能如何影响您的工作。但是你可以把它放在一边，继续进行新的提交。
【讨论】：