推送操作的目标“远程仓库”。此参数可以是 URL（请参阅下面的 Git URLS 部分）或远程仓库的名称（请参阅下面的 远程仓库 部分）。

指定用什么源对象更新什么目标引用。

推送所有分支（即 refs/heads/ 下的引用）；不能与其他 <refspec> 一起使用。

删除没有本地对应项的远程分支。例如，如果名为 tmp 的本地分支不再存在，则远程分支 tmp 将被删除。这也尊重 refspec，例如 git push --prune remote refs/heads/*:refs/tmp/* 将确保如果 refs/heads/foo 不存在，远程的 refs/tmp/foo 将被删除。

不指定要推送的每个引用，而是指定将 refs/ 下的所有引用（包括但不限于 refs/heads/、refs/remotes/ 和 refs/tags/）镜像到远程仓库。新创建的本地引用将推送到远程端，本地更新的引用将在远程端强制更新，删除的引用将从远程端移除。如果配置选项 remote.<remote>.mirror 被设置，则这是默认行为。

执行所有操作，但实际上不发送更新。

生成机器可读的输出。每条引用（ref）的状态输出行将以制表符分隔并发送到 stdout 而不是 stderr。将给出引用的完整符号名称。

所有列出的引用都将从远程仓库中删除。这相当于在所有引用前面加上冒号。

除了在命令行中明确列出的 refspec 外，还将推送 refs/tags 下的所有引用。

推送没有此选项时会推送的所有引用，还会推送远程仓库中缺失但指向可达于正在推送的引用（ref-ish）的带注释的标签（annotated tags）。这也可以通过配置变量 push.followTags 指定。有关更多信息，请参阅 git-config[1] 中 push.followTags 的说明。

GPG 对推送请求进行签名，以更新接收端的引用，从而允许钩子检查和/或记录。如果设置为 false 或 --no-signed，则不尝试签名。如果设置为 true 或 --signed，则服务器不支持签名推送时，推送将失败。如果设置为 if-asked，则仅当服务器支持签名推送时才进行签名。如果实际调用 gpg --sign 失败，推送也将失败。有关接收端细节，请参阅 git-receive-pack[1]。

如果可用，则在远程端使用原子事务。要么所有引用都得到更新，要么在发生错误时，没有任何引用得到更新。如果服务器不支持原子推送，推送将失败。

将给定字符串发送到服务器，服务器会将其传递给 pre-receive 和 post-receive 钩子。给定字符串不能包含 NUL 或 LF 字符。当给出多个 --push-option=<option> 时，它们将按命令行中列出的顺序全部发送到另一端。当命令行中未给出 --push-option=<option> 时，将使用 push.pushOption 配置变量的值。

远程端的 git-receive-pack 程序的路径。当通过 ssh 推送到远程仓库，并且该程序不在默认 $PATH 的目录中时，有时会很有用。

通常，“git push”会拒绝更新不是用于覆盖它的本地引用的祖先的远程引用。

git remote add origin-push $(git config remote.origin.url)
git fetch origin-push

git push --force-with-lease origin-push

git fetch              # update 'master' from remote
git tag base master    # mark our base point
git rebase -i master   # rewrite some commits
git push --force-with-lease=master:base master:master

通常，git push 会拒绝更新不是被推送提交的祖先的分支。

仅当远程跟踪引用的尖端已在本地集成时，才强制更新。

此选项等同于 <repository> 参数。如果两者都指定，则命令行参数具有优先权。

对于每个更新或成功推送的分支，添加上游（跟踪）引用，用于无参数的 git-pull[1] 和其他命令。有关更多信息，请参阅 git-config[1] 中 branch.<name>.merge 的说明。

这些选项被传递给 git-send-pack[1]。当发送方和接收方共享许多相同的对象时，薄传输（thin transfer）会显著减少发送的数据量。默认是 --thin。

抑制所有输出，包括更新的引用的列表，除非发生错误。进度不会报告到标准错误流。

运行详细模式。

默认情况下，当标准错误流连接到终端时，会报告进度状态，除非指定了 -q。此标志强制报告进度状态，即使标准错误流未定向到终端。

可用于确保要推送的修订版本所使用的所有子模块提交都存在于远程跟踪分支上。如果使用 check，Git 将验证要推送的修订版本中更改的所有子模块提交是否至少存在于子模块的一个远程仓库上。如果缺少任何提交，推送将被中止并以非零状态退出。如果使用 on-demand，则将推送所有在要推送的修订版本中更改的子模块。如果 on-demand 无法推送所有必需的修订版本，它也将被中止并以非零状态退出。如果使用 only，则推送所有子模块，而超项目保持未推送。使用 no 或 --no-recurse-submodules 可以覆盖 push.recurseSubmodules 配置变量，当不需要子模块递归时。

切换 pre-push 钩子（请参阅 githooks[5]）。默认是 --verify，给钩子一个阻止推送的机会。使用 --no-verify 时，钩子将被完全绕过。

仅使用 IPv4 地址，忽略 IPv6 地址。

仅使用 IPv6 地址，忽略 IPv4 地址。

一个字符，表示引用的状态

对于成功推送的引用，摘要显示了引用的旧值和新值，格式适用于作为 git log 的参数（大多数情况下是 <old>..<new>，对于强制的非快进更新是 <old>...<new>）。

正在推送的本地引用的名称，减去其 refs/<type>/ 前缀。在删除的情况下，本地引用的名称被省略。

正在更新的远程引用的名称，减去其 refs/<type>/ 前缀。

可读的解释。对于成功推送的引用，不需要解释。对于失败的引用，会描述失败的原因。

工作方式类似于 git push <remote>，其中 <remote> 是当前分支的远程（或 origin，如果当前分支没有配置远程）。

在没有额外配置的情况下，将当前分支推送到配置的上游（branch.<name>.merge 配置变量），前提是它与当前分支同名，否则会报错而不推送。

将“匹配”的分支推送到 origin。有关“匹配”分支的描述，请参见上文 OPTIONS 部分中的 <refspec>。

在源存储库中查找与 master 匹配的引用（最有可能找到 refs/heads/master），并使用它更新 origin 存储库中的同一引用（例如 refs/heads/master）。如果 master 在远程不存在，则会创建它。

将当前分支推送到远程同名分支的便捷方法。

使用与 master 匹配的源引用（例如 refs/heads/master）来更新 mothership 存储库中与 satellite/master 匹配的引用（最可能是 refs/remotes/satellite/master）；对 dev 和 satellite/dev 执行相同的操作。

将当前分支推送到 origin 存储库中与 master 匹配的远程引用。这种形式便于推送当前分支，而不必考虑其本地名称。

通过复制当前的 master 分支，在 origin 存储库中创建 experimental 分支。仅当本地名称和远程名称不同时，才需要此形式来创建远程存储库中的新分支或标签；否则，仅使用 ref 名称即可。

在 origin 存储库中查找与 experimental 匹配的引用（例如 refs/heads/experimental），并删除它。

使用 dev 分支更新 origin 存储库的 master 分支，允许非快进更新。这可能会在 origin 存储库中留下未引用的提交。考虑以下情况，其中无法进行快进更新：

	    o---o---o---A---B  origin/master
		     \
		      X---Y---Z  dev

		      A---B  (unnamed branch)
		     /
	    o---o---o---X---Y---Z  master

如果设置为“true”，则在当前分支没有上游跟踪时，默认推送假定为 --set-upstream；此选项在 push.default 选项simple、upstream和current时生效。如果您希望新分支默认推送到默认远程（如push.default=current的行为），并且还希望设置上游跟踪，那么此选项非常有用。最有可能受益于此选项的工作流程是simple中心化工作流程，其中所有分支都应在远程具有相同的名称。

定义 git push 在没有给出 refspec（无论是来自命令行、配置还是其他地方）时应执行的操作。不同的值适用于特定的工作流程；例如，在纯粹的中心化工作流程（即 fetch 源等于 push 目标）中，upstream 可能是您想要的。可能的值有：

如果设置为 true，则默认启用 --follow-tags 选项。您可以通过指定 --no-follow-tags 在推送时覆盖此配置。

可以设置为布尔值，或字符串if-asked。true 值会导致所有推送都经过 GPG 签名，如同将 --signed 传递给 git-push[1]。字符串if-asked会导致在服务器支持的情况下对推送进行签名，如同将 --signed=if-asked 传递给git push。false 值可能会覆盖较低优先级配置文件中的值。显式的命令行标志始终覆盖此配置选项。

当命令行为给出 --push-option=<option> 参数时，git push 的行为就像将该变量的每个 <value> 作为 --push-option=<value> 一样。

Example:

/etc/gitconfig
  push.pushoption = a
  push.pushoption = b

~/.gitconfig
  push.pushoption = c

repo/.git/config
  push.pushoption =
  push.pushoption = b

This will result in only b (a and c are cleared).

可以是“check”、“on-demand”、“only”或“no”，其行为与“push --recurse-submodules”相同。如果未设置，则默认使用no，除非设置了submodule.recurse（在这种情况下，true值表示on-demand）。

如果设置为“true”，则等同于在命令行中将 --force-if-includes 指定为 git-push[1] 的选项。在推送时添加 --no-force-if-includes 会覆盖此配置设置。

如果设置为“true”，则尝试通过客户端和服务器之间尝试查找共同提交的协商轮次来减小发送的 packfile 的大小。如果设置为“false”，Git 将仅依赖服务器的 ref 广告来查找共同提交。

如果设置为“false”，则禁用“git push”使用位图，即使 pack.useBitmaps 为“true”，但不会阻止其他 git 操作使用位图。默认为 true。