作为推送操作目的地的“远程”仓库。此参数可以是 URL（参见下面的 GIT URL 部分）或远程名称（参见下面的 远程 部分）。

指定用哪个源对象更新哪个目标引用。<引用规范> 参数的格式是可选的加号 +，后跟源对象 <src>，再跟冒号 :，最后跟目标引用 <dst>。

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

删除没有本地对应分支的远程分支。例如，如果同名的本地分支不再存在，则远程分支 tmp 将被删除。这也遵循引用规范，例如 git push --prune remote refs/heads/*:refs/tmp/* 将确保如果 refs/heads/foo 不存在，则远程 refs/tmp/foo 将被删除。

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

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

生成机器可读的输出。每个引用的输出状态行将以制表符分隔，并发送到标准输出而非标准错误。将给出引用的完整符号名称。

所有列出的引用都将从远程仓库中删除。这与在所有引用前加上冒号的效果相同。

除了命令行中明确列出的引用规范外，refs/tags 下的所有引用都将被推送。

推送所有在没有此选项时会被推送的引用，并且还推送远程端缺失但指向从被推送引用可达的提交对象的 refs/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

通常，该命令会拒绝更新不是用于覆盖它的本地引用的祖先的远程引用。此外，当使用 --force-with-lease 选项时，如果远程引用的当前值与期望值不匹配，则该命令会拒绝更新该远程引用。

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

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

对于每个已是最新或已成功推送的分支，添加上游（跟踪）引用，该引用被无参数的 git-pull[1] 和其他命令使用。有关详细信息，请参见 git-config[1] 中的 branch.<name>.merge。

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

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

运行详细模式。

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

可用于确保要推送的修订版所使用的所有子模块提交都在远程跟踪分支上可用。如果使用 *check*，Git 将验证要推送的修订版中更改的所有子模块提交在子模块的至少一个远程上可用。如果缺少任何提交，推送将中止并以非零状态退出。如果使用 *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 <远程仓库>，其中 <远程仓库> 是当前分支的远程仓库（如果当前分支未配置远程仓库，则为 origin）。

如果没有额外的配置，如果当前分支的名称与配置的上游分支（branch.<name>.merge 配置变量）相同，则将当前分支推送到配置的上游分支，否则会报错而不进行推送。

推送“匹配”分支到 origin。有关“匹配”分支的描述，请参见上面 选项 部分中的 <引用规范>。

在源仓库中找到与 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。当本地名称与远程名称不同时，才需要此形式在远程仓库中创建新分支或标签；否则，单独的引用名称即可。

在 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* 的行为），并且还希望设置上游跟踪，则此功能很有用。最可能受益于此选项的工作流程是所有分支都预期在远程上具有相同名称的*简单*集中式工作流程。

定义了在未给定引用规范（无论是来自命令行、配置或其他地方）时 git push 应采取的操作。不同的值适用于特定的工作流程；例如，在纯粹的集中式工作流程中（即抓取源等于推送目的地），upstream 可能就是您想要的。可能的值有

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

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

当命令行中没有给出 --push-option=<option> 参数时，git push 的行为如同此变量的每个 <值> 都被作为 --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 将仅依赖服务器的引用通告来寻找共同提交。

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