作为推送操作的目的地的 “远程” 仓库。 这个参数可以是一个网址（见下面 GIT 地址 一节），也可以是一个远程库的名称（见下面 远程仓库 一节）。

指定要用哪个源对象来更新哪个目标引用。

推送所有分支（即`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 签名，以在接收端更新引用时允许钩子检查和/或记录。可选值：

如果有的话，在远程仓库使用一个原子事务。 要么所有的引用都被更新，要么出错时，没有引用被更新。 如果服务器不支持原子推送，推送将会失败。

将给定的字符串传输给服务器，服务器将它们传递给 pre-receive 以及 post-receive 钩子。给定的字符串不能包含 NUL 或 LF 字符。 当给出多个 --push-option=< 选项 > 时，它们将按照命令行中列出的顺序全部发送给对方。 当命令行中没有给出 --push-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              # 从远程仓库更新 'master' 分支
	git tag base master    # 标记基点
	git rebase -i master   # 重写某些提交
	git push --force-with-lease=master:base master:master

通常，git push 会拒绝更新一个不是用来覆盖它的本地引用的远程父引用。

只有远程跟踪的引用顶端被整合到本地才强制更新。

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

对于每一个已经更新或成功推送的分支，添加上游（跟踪）引用，由无参数的 git-pull[1] 和其他命令使用。更多信息，见 git-config[1] 中的 branch.< 分支名 >.merge。

这些选项被传递给 git-send-pack[1]。当发送方和接收方有许多共同的对象时，稀松传输会大大减少发送的数据量。默认是 --thin。

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

详细运行。

当标准错误流连接到终端时，除非指定了 -q，否则默认情况下会在标准错误流上报告进展状态。即使标准错误流没有指向终端，这个标志也会强制显示进度状态。

可用于确保要推送的修订所使用的所有子模块提交在某个远程跟踪分支上可用。可选值：

切换 pre-push 钩子（见 githooks[5]）。 默认是 --verify，给钩子一个机会来阻止推送。 如果使用 --no-verify，钩子会被完全绕过。

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

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

表示引用状态的单个字符：

对于一个成功获取的引用，摘要以适合作为 git log 参数的形式显示该引用的新旧值（在大多数情况下是 <旧>..<新>，对于强制非快速合并是 <旧>...<新>）。

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

被更新的本地引用的名称，去掉其 refs/< 类型 >/ 前缀。

一个人类可读的解释。在成功推送引用的情况下，不需要解释。对于操作失败的引用，要描述失败的原因。

像`git push < 远程 >那样工作，其中 < 远程 > 是当前分支的远程仓库（或者`origin，如果没有为当前分支配置远程仓库）。

不需要额外配置，如果它与当前分支同名，并且错误输出而不推送其他分支，则将其推送到配置过的上游仓库（branch.<分支名>.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`做同样的操作。

推送当前分支到远程引用匹配 master 的 origin 仓库中。这种形式可以方便地推送当前分支，而不必考虑其本地名称。

通过复制当前的 master 分支，在 origin 仓库创建 experimental 分支。 只有在本地名称和远程名称不同的情况下，在远程仓库中创建新的分支或标签时才需要这个表单；否则，引用名称本身就可以了。

在 origin 仓库（例如`refs/heads/experimental`）中找到一个与 experimental 相匹配的引用，并将其删除。

用开发分支更新仓库的主分支，允许非快速合并更新。 *这可能会使未引用的提交在源码库中悬空。*考虑以下情况，即不可能进行快速合并：

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

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

若设为 true，当当前分支尚无上游跟踪分支时，默认 push 会假定带上 --set-upstream；该选项在 push.default 为 simple、upstream 和 current 时生效。若你希望新分支默认推送到默认远程（类似 push.default=current 的行为），同时又希望设置上游跟踪关系，则此选项很有用。最可能受益的工作流是 simple 的集中式工作流：期望所有分支在远程都有同名分支。

定义在未提供 refspec（无论来自命令行、配置或其他来源）时 git push 应采取的动作。不同取值适合不同工作流；例如在纯集中式工作流（即 fetch 源与 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 的行为就像为本变量中的每个 <option> 都提供了 --push-option=<option> 一样。

例如：

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

~/.gitconfig
  push.pushoption = c

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

这将导致只剩下 b（a 和 c 被清除）。

可以是 check、on-demand、only 或 no，其行为与 push --recurse-submodules 相同。若未设置，则默认使用 no，除非设置了 submodule.recurse（此时值为 true 表示 on-demand）。

若设为 true，等同于在命令行中为 git-push[1] 指定 --force-if-includes 选项。在 push 时添加 --no-force-if-includes 会覆盖此配置。

若设为 true，则在客户端和服务器尝试找出共同提交的多轮协商过程中，尝试减小发送的 packfile 大小。若为 false，Git 将仅依赖服务器的 ref 通告来查找共同提交。

若设为 false，则即使 pack.useBitmaps 为 true，也会禁用 git push 对 bitmap 的使用，但不会 阻止其他 git 操作使用 bitmap。默认值为 true。