假设您已经了解 git 的“对象”模型（您的提交和文件等都只是“git 数据库中的对象”，“松散”的对象——那些没有打包以节省空间的对象——存储在 .git/objects/12/34567...之类的）...
你是对的：git fetch 检索对象“他们”（origin，在这种情况下）拥有你没有的对象，并在它们上面贴上标签：origin/master 等。更具体地说，你的 git 在互联网电话（或任何其他合适的传输方式）上调用他们的，并询问：你有哪些分支，那些提交 ID 是什么？他们有master，ID 是1234567...，所以你的git 要求1234567... 和你还没有的任何其他需要的对象，并使你的origin/master 指向提交对象1234567...。
git push 的对称部分在这里是这样的：你的 git 像往常一样在同一个互联网电话上调用他们的 git，但是这一次，而不是仅仅询问他们他们的分支，你的 git 告诉他们你的 分支和你的 git 存储库对象，然后说：“我让你将master 设置为56789ab... 怎么样？”
他们的 git 会查看您发送过来的对象（新提交 56789ab... 以及您拥有的任何其他他们没有的对象，他们需要接受它）。然后他们的 git 会考虑将 他们的 master 设置为 56789ab... 的请求。
作为Chris K already answered，这里没有发生合并：你的 git 只是建议他们的 git 用这个新的提交 ID 覆盖他们的master。由他们的 git 决定是否允许这样做。
如果“他们”（无论他们是谁）没有设置任何特殊规则，这里 git 使用的默认规则非常简单：如果更改是“快进”，则允许覆盖。它还有一个附加功能：如果更改是在设置了“force”标志的情况下完成的，也允许覆盖。在这里设置强制标志通常不是一个好主意，因为默认规则“仅快进”通常是正确规则。
这里明显的问题是：什么是快进？我们稍后会讨论这个问题；首先，我需要对标签进行一些扩展，或者说“参考”更正式。
Git 的参考资料
在 git 中，一个分支或一个标签，甚至像 stash 和 HEAD 这样的东西都是引用。其中大部分位于.git/refs/，这是 git 存储库的子目录。 （一些顶级引用，包括 HEAD，就在 .git 本身中。）所有引用都是一个包含 SHA-1 ID 的文件1，例如 7452b4b5786778d5d87f5c90a94fab8936502e20。 SHA-1 ID 很麻烦而且人们无法记住，因此我们使用名称，例如 v2.1.0（在本例中为标签，即 git 本身的 2.1.0 版本）为我们保存它们。
有些引用是——或者至少是打算是——完全静态的。标签v2.1.0 不应引用除上述SHA-1 ID 之外的其他内容。但有些参考文献更具动态性。具体来说，您自己的本地分支机构，例如master，正在移动目标。一种特殊情况，HEAD，甚至不是它自己的目标：它通常包含移动目标分支的 name。所以“间接”引用有一个例外：HEAD 通常包含字符串ref: refs/heads/master，或ref: refs/heads/branch，或类似的东西；并且 git 不会（也不能）对引用执行“永不更改”规则。尤其是分支变化很大。
您如何知道引用是否应该更改？好吧，很多这只是按照惯例：分支移动而标签不移动。但是你应该问：你怎么知道一个引用是一个分支，或者一个标签，还是什么？
引用的命名空间：refs/heads/、refs/tags/ 等。
除了特殊的顶级引用之外，所有 git 的引用都在refs/ 中，正如我们上面已经提到的。但是，在refs/ 目录（或“文件夹”，如果您在 Windows 或 Mac 上）中，我们可以拥有完整的子目录集合。在这一点上，Git 有四个定义明确的子目录：refs/heads/ 包含所有分支，refs/tags/ 包含所有标签，refs/remotes/ 包含所有“远程跟踪分支”，refs/notes/ 包含 git 的“注释” "（这里我会忽略，因为它们有点复杂）。
因为你所有的分支都在refs/heads/，git 可以告诉这些应该被允许改变，因为你所有的标签都在refs/tags/，git 可以告诉这些不应该。
树枝的自动运动
当你进行新的提交，并且在像 master 这样的分支上时，git 会自动移动引用。您的新提交是使用其“父提交”作为先前的分支提示创建的，一旦您的新提交被安全保存，git 将更改 master 以包含 new 提交的 ID。换句话说，它确保分支name，即heads 子目录中的引用，始终指向最尖端的提交。
（事实上，分支，就作为存储在存储库中的提交图的一部分的提交集合而言，是由存储库中的提交组成的数据结构。它与分支的唯一连接name 是分支本身的提示提交以该名称存储在引用标签中。这在以后很重要，如果随着存储库增加更多提交而更改或删除分支名称时。对于现在只需要记住一点：“分支提示”（即“分支名称”指向的位置）与分支作为提交子集的 DAG 之间存在差异。有点不幸的是git 倾向于将这些不同的概念集中在一个名称“分支”下。）
究竟什么是快进？
通常您会在合并的上下文中看到“快进”，通常将合并作为git pull 中的第二步完成。但实际上，“快进”其实是标签移动的一个属性。
让我们画一点提交图。小的o 节点代表提交，每个节点都有一个指向其父节点（或父节点）的左箭头、左上箭头或左下箭头（或者在一种情况下，两个箭头）。为了能够通过名称引用三个，我将给它们大写字母名称而不是o。此外，这个基于角色的艺术作品没有箭头，所以你必须想象它们；请记住，它们都指向左或左，就像三个名字一样。
o - A <-- name1
/
o - o - o - o - B <-- name2
\ /
o - C <-- name3
当您要求 git 更改引用时，您只需要求它在标签中粘贴一个新的提交 ID。在这种情况下，这些标签位于 refs/heads/ 中，因此是分支名称，因此它们应该能够采用新值。
如果我们告诉 git 将 B 放入 name1，我们会得到：
o - A
/
o - o - o - o - B <-- name1, name2
\ /
o - C <-- name3
请注意，提交 A 现在有 no 名称，并且它左侧的 o 只能通过找到 A 才能找到……这很难，因为 A 有无名。提交A 已被放弃，这两个提交已符合“垃圾收集”的条件。 （在 git 中，“reflog”中留下了一个“ghost name”，它使带有A 的分支通常保持大约 30 天。但这完全是一个不同的话题。）
告诉 git 将B 放入name3 怎么样？如果我们接下来这样做，我们会得到：
o - A
/
o - o - o - o - B <-- name1, name2, name3
\ /
o - C
在这里，commit C 仍然有办法找到它：从 B 开始，向下和向左工作，到它的另一个（第二个）父 commit，你会找到 commit C。所以提交C没有被放弃了。
像这样更新name1 不是快进，但更新name3 是。
更具体地说，引用更改是“快进”当且仅当对象（通常是提交）通过从 new 开始仍然可以访问用于指向的引用沿着所有可能的向后路径放置和向后工作。在图形方面，如果旧节点是新节点的祖先，则它是快进。
通过合并使push 成为快进
当您唯一要做的就是添加新提交时，就会发生分支名称快进；而且，如果您添加了新的提交，那么您也合并了其他人添加的任何新提交。也就是说，假设你的仓库中有这个，在你做了一个新的提交之后：
o <-- master
/
...- o - o <-- origin/master
此时，“向上和向右”移动origin/master 将是快进。但是，其他人出现并更新了另一个 (origin) 存储库，因此您执行 git fetch 并从他们那里获得新的提交。你的 git 移动你的 origin/master 标签（在你的 repo 上的快进操作中，碰巧）：
o <-- master
/
...- o - o - o <-- origin/master
此时，将origin/master 移动到master 将不是快进，因为它会放弃一个新的提交。
但是，您可以执行 git merge origin/master 操作以在 您的 master 上使用两个父提交 ID 进行新提交。让我们标记这个M（用于合并）：
o - M <-- master
/ /
...- o - o - o <-- origin/master
您现在可以将git push 这回origin 并要求他们设置他们的 master——你称之为origin/master——等于你的 （新）M，因为对他们来说，现在这是一个快进操作！
请注意，您也可以发送git rebase，但让我们将其留给不同的 stackoverflow 发布。 :-)
1事实上，git 引用总是作为各个子目录中的单个文件开始的，但是如果一个引用很长时间没有更新，它往往会被“打包”（连同所有其他主要是静态的引用）到一个充满打包引用的文件中。这只是一个省时的优化，这里的关键不是依赖于具体的实现，而是使用git的rev-parse和update-ref命令从一个引用中提取当前的SHA-1，或者更新一个引用包含一个新的 SHA-1。