简体中文 ▾ Topics ▾ Latest version ▾ git-push last updated in 2.43.2


git-push - 与相关对象一起更新远程分支引用


git push [--all | --branches | --mirror | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
	   [--repo=<仓库>] [-f | --force] [-d | --delete] [--prune] [-q | --quiet] [-v | --verbose]
	   [-u | --set-upstream] [-o <字符串> | --push-option=<字符串>]
	   [--force-with-lease[=<引用名>[:<expect>]] [--force-if-includes]]
	   [--no-verify] [<仓库> [<引用规范>…​]]



You can make interesting things happen to a repository every time you push into it, by setting up hooks there. See documentation for git-receive-pack[1].

When the command line does not specify where to push with the <repository> argument, branch.*.remote configuration for the current branch is consulted to determine where to push. If the configuration is missing, it defaults to origin.

当命令行没有用 <引用规范>... 参数或 --all--mirror--tags 选项指定推送内容时,命令通过查阅 remote.*.push 配置找到默认的 < 引用规范 >,如果没有找到,则以 push.default 配置决定推送内容(关于 push.default 的含义,见 git-config[1] )。

当命令行和配置都没有指定推送的内容时,将使用默认行为,这与 push.defaultsimple 值相对应:当前分支被推送到相应的上游分支,但作为一项安全措施,如果上游分支的名称与本地分支不一致,推送将被中止。



The "remote" repository that is the destination of a push operation. This parameter can be either a URL (see the section GIT URLS below) or the name of a remote (see the section REMOTES below).


Specify what destination ref to update with what source object. The format of a <refspec> parameter is an optional plus +, followed by the source object <src>, followed by a colon :, followed by the destination ref <dst>.

<src> 通常是你想推送的分支的名字,但它可以是任何任意的“SHA-1 表达式”,比如 master~4HEAD(见 gitrevisions[7])。

The <dst> tells which ref on the remote side is updated with this push. Arbitrary expressions cannot be used here, an actual ref must be named. If git push [<repository>] without any <refspec> argument is set to update some ref at the destination with <src> with remote.<repository>.push configuration variable, :<dst> part can be omitted—​such a push will update a ref that <src> normally updates without any <refspec> on the command line. Otherwise, missing :<dst> means to update the same ref as the <src>.

如果 <dst> 不是以 refs/ 开头(例如 refs/heads/master),我们将根据被推送的 <src> 的类型和 <dst> 是否含糊不清,尝试推断它在目的地 < 仓库 > 的 refs/* 中的位置。

  • 如果 <dst> 明确地指向 < 仓库 > 远程的一个引用,那么就推送到该引用。

  • 如果 <src> 解析为以 refs/heads/ 或 refs/tags/ 开头的引用,则将其前置到 <dst>。

  • 其他含糊的解决方案可能会在未来加入,但现在我们所尝试的任何其他情况都会出错,并根据`advice.pushUnqualifiedRefname`配置(见git-config[1])建议你可能想推送到哪个类型的引用中。

由 <src> 引用的对象被用来更新远程端的 <dst> 引用。这是否被允许取决于 <dst> 引用在`refs/*`中的位置,下面将详细描述,在这些章节中,“更新”意味着除了删除之外的任何修改,正如在接下来的几节中所指出的,这将被不同地对待。

refs/heads/* 命名空间只接受提交对象,只有在可以快进的情况下才接受更新。

refs/tags/* 命名空间将接受任何种类的对象(因为提交、树和二进制对象都可以被标记),对它们的任何更新都将被拒绝。

可以将任何类型的对象推送到 refs/{tags,heads}/* 之外的任何命名空间。在标签和提交的情况下,这些将被视为 refs/heads/* 内的提交,以决定是否允许更新。

也就是说,允许在 refs/{tags,heads}/* 之外进行快进提交和标签,即使被快进的不是一个提交,而是一个标签对象,它恰好指向一个新的提交,而这个提交是它所替代的最后一个标签(或提交)的快进。用一个完全不同的标签替换一个标签也是允许的,如果它指向同一个提交,以及推送一个剥离的标签,即推送现有标签对象所指向的提交,或现有提交所指向的新标签对象。

refs/{tags,heads}/* 之外的树和二进制对象的处理方式与在 refs/tags/* 之内的相同,它们的任何更新都会被拒绝。

上面描述的所有关于不允许更新的规则都可以通过在引用规范前面添加一个可选 + 来覆盖(或者使用 --force 命令行选项)。唯一的例外是,无论如何强制都不会使 refs/heads/* 命名空间接受一个非提交对象。钩子和配置也可以覆盖或修改这些规则,例如见 git-config[1] 中的 receive.denyNonFastForwardsgithooks[5] 中的 pre-receiveupdate

推送一个空的 <src> 允许你从远程版本库中删除 <dst> 的引用。除非配置或钩子禁止,否则在引用规范中没有前面的 + (或 --force) ,删除总是被接受的。参见 git-config[1] 中的 receive.denyDeletes 以及 githooks[5] 中的 pre-receiveupdate

The special refspec : (or +: to allow non-fast-forward updates) directs Git to push "matching" branches: for every branch that exists on the local side, the remote side is updated if a branch of the same name already exists on the remote side.

tag <tag>refs/tags/<tag>:refs/tags/<tag> 意思相同。


推送所有分支(即`refs/heads/`下的引用);不能与其他 < 引用规范 > 一起使用。


Remove remote branches that don’t have a local counterpart. For example a remote branch tmp will be removed if a local branch with the same name doesn’t exist any more. This also respects refspecs, e.g. git push --prune remote refs/heads/*:refs/tmp/* would make sure that remote refs/tmp/foo will be removed if refs/heads/foo doesn’t exist.


Instead of naming each ref to push, specifies that all refs under refs/ (which includes but is not limited to refs/heads/, refs/remotes/, and refs/tags/) be mirrored to the remote repository. Newly created local refs will be pushed to the remote end, locally updated refs will be force updated on the remote end, and deleted refs will be removed from the remote end. This is the default if the configuration option remote.<remote>.mirror is set.




Produce machine-readable output. The output status line for each ref will be tab-separated and sent to stdout instead of stderr. The full symbolic names of the refs will be given.




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


Push all the refs that would be pushed without this option, and also push annotated tags in refs/tags that are missing from the remote but are pointing at commit-ish that are reachable from the refs being pushed. This can also be specified with configuration variable push.followTags. For more information, see push.followTags in git-config[1].


GPG-sign the push request to update refs on the receiving side, to allow it to be checked by the hooks and/or be logged. If false or --no-signed, no signing will be attempted. If true or --signed, the push will fail if the server does not support signed pushes. If set to if-asked, sign if and only if the server supports signed pushes. The push will also fail if the actual call to gpg --sign fails. See git-receive-pack[1] for the details on the receiving end.


Use an atomic transaction on the remote side if available. Either all refs are updated, or on error, no refs are updated. If the server does not support atomic pushes the push will fail.

-o <选项>

Transmit the given string to the server, which passes them to the pre-receive as well as the post-receive hook. The given string must not contain a NUL or LF character. When multiple --push-option=<option> are given, they are all sent to the other side in the order listed on the command line. When no --push-option=<option> is given from the command line, the values of configuration variable push.pushOption are used instead.


Path to the git-receive-pack program on the remote end. Sometimes useful when pushing to a remote repository over ssh, and you do not have the program in a directory on the default $PATH.

--force-with-lease=< 引用名 >:< 期望>

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

This option overrides this restriction if the current value of the remote ref is the expected value. "git push" fails otherwise.

Imagine that you have to rebase what you have already published. You will have to bypass the "must fast-forward" rule in order to replace the history you originally published with the rebased history. If somebody else built on top of your original history while you are rebasing, the tip of the branch at the remote may advance with their commit, and blindly pushing with --force will lose their work.

这个选项允许你说,你希望你更新的历史是你重新建立的,并希望取代它。如果远程引用仍然指向你指定的提交,你就可以确定没有其他人对该引用做了什么。这就像在没有明确锁定的情况下对引用进行“租赁”,只有在 “租赁”仍然有效的情况下才会更新远程引用。


--force-with-lease=< 引用名 >,没有指定预期值,将保护命名的引用(单独),如果它要被更新,要求其当前值与我们对它的远程跟踪分支相同。

--force-with-lease=<refname>:<expect> will protect the named ref (alone), if it is going to be updated, by requiring its current value to be the same as the specified value <expect> (which is allowed to be different from the remote-tracking branch we have for the refname, or we do not even have to have such a remote-tracking branch when this form is used). If <expect> is the empty string, then the named ref must not already exist.

请注意,除了`--force-with-lease=< 引用名 >:< 期望 >`以外的所有形式都是明确指定引用的预期当前值,这些形式仍然是试验性的,它们的语义可能会随着我们对这个功能的经验积累而改变。

"--no-force-with-lease " 将取消之前在命令行上所有的 --force-with-lease。

关于安全性的一般说明:在没有预期值的情况下提供这个选项,即 --force-with-lease 或`--force-with-lease=< 引用名 >,会与任何在后台隐式运行 `git fetch 的远端推送的进程产生非常不好的互动,例如仓库中 cronjob 的 git fetch origin

--force 相比,它提供的保护是确保你的工作不基于后续的变化,但如果有后台进程在后台更新引用,这一点就很容易被破坏。除了远程跟踪信息外,我们没有任何你期望看到并愿意去破解可以作为启发式引用的东西。

如果你的编辑器或其他系统在后台为你运行`git fetch`,减轻这种情况的方法是简单地设置另一个远程:

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

现在,当后台进程运行 git fetch origin 时,`origin-push`上的引用将不会被更新,因此,像这样的命令:

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

除非你手动运行 git fetch origin-push,否则会失败。当然,这种方法完全可以被运行 git fetch --all 的东西打败,在这种情况下,你需要禁用它或者做一些更繁琐的事情,比如:

git fetch              # 从远程仓库更新 'master' 分支
git tag base master    # 标记基点
git rebase -i master   # 重写某些提交
git push --force-with-lease=master:base master:master

也就是说,为你已经看到并愿意覆盖的上游仓库创建一个`base` 标签,然后重写历史,最后如果远程版本仍然在 base,则强制推送修改到`master`,不管你本地的 remotes/origin/master 在后台更新了什么。

另外,在“推送”时将 --force-if-includes 作为辅助选项与 --force-with-lease[=< 引用名 >] 一起指定(即不说远程的引用必须指向什么确切的提交,或远程的哪些引用被保护),将验证远程跟踪引用的更新是否在允许强制更新之前被整合在本地。


Usually, the command refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it. Also, when --force-with-lease option is used, the command refuses to update a remote ref whose current value does not match what is expected.


Note that --force applies to all the refs that are pushed, hence using it with push.default set to matching or with multiple push destinations configured with remote.*.push may overwrite refs other than the current branch (including local refs that are strictly behind their remote counterpart). To force a push to only one branch, use a + in front of the refspec to push (e.g git push origin +master to force a push to the master branch). See the <refspec>... section above for details.




如果该选项没有指定 --force-with-lease,或者与 `--force-with-lease=< 引用名 >:< 期望 >`一起指定,则是“无选项”的。

指定 ---no-force-if-includes 就可以禁止这种行为。


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


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


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






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


May be used to make sure all submodule commits used by the revisions to be pushed are available on a remote-tracking branch. If check is used Git will verify that all submodule commits that changed in the revisions to be pushed are available on at least one remote of the submodule. If any commits are missing the push will be aborted and exit with non-zero status. If on-demand is used all submodules that changed in the revisions to be pushed will be pushed. If on-demand was not able to push all necessary revisions it will also be aborted and exit with non-zero status. If only is used all submodules will be pushed while the superproject is left unpushed. A value of no or using --no-recurse-submodules can be used to override the push.recurseSubmodules configuration variable when no submodule recursion is required.

当使用 "on-demand" 或 "only" 时,如果一个子模块有 "push.recurseSubmodules={on-demand,only}" 或 "submodule.recurse"配置,将发生进一步递归。在这种情况下,"only" 被视为 "on-demand"。


Toggle the pre-push hook (see githooks[5]). The default is --verify, giving the hook a chance to prevent the push. With --no-verify, the hook is bypassed completely.


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


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

GIT 地址

In general, URLs contain information about the transport protocol, the address of the remote server, and the path to the repository. Depending on the transport protocol, some of this information may be absent.

Git 支持 ssh,git,http 和 https 协议(此外,可以使用 ftp 和 ftps 进行抓取,但这效率低下且不建议使用;请勿使用)。

本地传输(即 git:// URL)不进行身份验证,在不安全的网络上应谨慎使用。


  • ssh://[user@]host.xz[:port]/path/to/repo.git/

  • git://host.xz[:port]/path/to/repo.git/

  • http[s]://host.xz[:port]/path/to/repo.git/

  • ftp[s]://host.xz[:port]/path/to/repo.git/

ssh 协议也可以使用类似 scp 的语法:

  • [user@]host.xz:path/to/repo.git/

仅当第一个冒号之前没有斜杠时才能识别此语法。这有助于区分包含冒号的本地路径。例如,可以将本地路径 foo:bar 指定为绝对路径,或者将 ./foo:bar 指定为绝对路径,以避免被误识别为 ssh url。

ssh 和 git 协议还支持 ~username 扩展:

  • ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/

  • git://host.xz[:port]/~[user]/path/to/repo.git/

  • [user@]host.xz:/~[user]/path/to/repo.git/

对于本地仓库(Git 本身也支持),可以使用以下语法:

  • /path/to/repo.git/

  • file:///path/to/repo.git/

这两种语法几乎是等效的,除了在克隆时,前者暗含 --local 选项。有关详细信息,请参阅 git-clone[1]

git clonegit fetchgit pull(但不包括 git push)也会接受合适的捆绑包文件。参见 git-bundle[1]

当 Git 不知道如何处理某种传输协议时,它会尝试使用 remote-<传输方式> 远程帮助程序(如果存在)。要显式请求远程帮助程序,可以使用以下语法:

  • <传送>::<地址>

其中,<地址> 可以是路径,服务器与路径,也可以是可被调用的特定远程帮助程序识别的类似于网页地址的任意字符串。有关详细信息,请参阅 gitremote-helpers[7]


	[url "<actual-url-base>"]
		insteadOf = <other-url-base>


	[url "git://"]
		insteadOf = host.xz:/path/to/
		insteadOf = work:

诸如 "work:repo.git" 或 "host.xz:/path/to/repo.git" 的地址会在任何类似于 "git://" 地址的上下文中重写。


	[url "<actual-url-base>"]
		pushInsteadOf = <other-url-base>


	[url "ssh://"]
		pushInsteadOf = git://

类似于 "git://" 的地址会被重写为 "ssh://",用于推送。但拉取代码时仍然使用原始的地址。



  • 一个远端的配置文件在此仓库的git配置文件: $GIT_DIR/config

  • 这个文件在`$GIT_DIR/remotes`目录下,或者

  • a file in the $GIT_DIR/branches directory.


在配置文件中命名为 remote

你可以选择提供你之前用 git-remote[1]、linkgit:git-config[1] 或甚至通过手动编辑 $GIT_DIR/config 文件配置的远程名称。 这个远程的 URL 将被用来访问仓库。 当你没有在命令行上提供引用规范时,这个远程仓库的引用规范将被默认使用。 配置文件中的条目会像这样:

	[remote "<name>"]
		url = <URL>
		pushurl = <pushurl>
		push = <refspec>
		fetch = <refspec>

<pushurl> 仅用于推送。它是可选的,默认为 <URL>。向远程推送会影响所有定义的推送urls,如果没有定义推送urls,则推送到所有定义的url。然而,如果定义了多个 URL,fetch 将只从第一个定义的 URL 获取。

$GIT_DIR/remotes 中的命名文件

你可以选择提供 $GIT_DIR/remotes 中的文件名。 这个文件中的 URL 将被用来访问仓库。 当你没有在命令行上提供引用规范时,该文件中的引用规范将被作为默认使用。 这个文件应该有以下格式:

	URL: one of the above URL format
	Push: <引用规范>
	Pull: <引用规范>

Push: 行被 git push 使用,Pull: 行被 git pullgit fetch 使用。 可以为额外的分支映射指定多个 Push:Pull: 行。

$GIT_DIR/branches 中的命名文件

你可以选择提供 $GIT_DIR/branches 中的文件名。 这个文件中的 URL 将被用来访问仓库。 这个文件应该有以下格式:


<URL> 是必须的;#<head> 是可选的。

根据不同的操作,如果你没有在命令行上提供一个引用规范,git 会使用以下其中一个。 <分支> 是该文件在 $GIT_DIR/branches 中的名称,<头分支> 默认为 master

git fetch 使用:


git push uses:



"git push" 的输出取决于所使用的传输方式;本节将介绍通过 Git 协议(本地或通过 ssh)推送时的输出。


 <标志> <概述> <起始> -> <结束> (<原因>)

如果使用了 --porcelain ,那么输出的每一行都是这样的:

 <标志> \t <起始>:<结束> \t <概述> (<原因>)

只有在使用 --porcelain 或 --verbose 选项时,才会显示最新引用的状态。
















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



Git 根本没有尝试发送引用,典型的原因是它不是快速合并并且你没有强制更新。


The remote end refused the update. Usually caused by a hook on the remote side, or because the remote repository has one of the following safety options in effect: receive.denyCurrentBranch (for pushes to the checked out branch), receive.denyNonFastForwards (for forced non-fast-forward updates), receive.denyDeletes or receive.denyDeleteCurrent. See git-config[1].




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


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




当一个更新将原来指向提交 A 的分支(或更普遍的,一个引用)改为指向另一个提交 B 时,当且仅当 B 是 A 的后代时,它被称为快速合并。

In a fast-forward update from A to B, the set of commits that the original commit A built on top of is a subset of the commits the new commit B builds on top of. Hence, it does not lose any history.

In contrast, a non-fast-forward update will lose history. For example, suppose you and somebody else started at the same commit X, and you built a history leading to commit B while the other person built a history leading to commit A. The history looks like this:


进一步假设对方已经将 A 导致的修改推送回原仓库,你们俩从原仓库中获得原始提交 X。

The push done by the other person updated the branch that used to point at commit X to point at commit A. It is a fast-forward.

But if you try to push, you will attempt to update the branch (that now points at A) with commit B. This does not fast-forward. If you did so, the changes introduced by commit A will be lost, because everybody will now start building on top of B.


如果你不想丢失你的工作(从 X 到 B 的历史)或对方的工作(从 X 到 A 的历史),你需要先从仓库中获取历史,创建一个包含双方修改的历史,并将结果推送回去。

You can perform "git pull", resolve potential conflicts, and "git push" the result. A "git pull" will create a merge commit C between commits A and B.

     /   /

用所产生的合并提交更新 A,将快速合并,你的推送将被接受。

Alternatively, you can rebase your change between X and B on top of A, with "git pull --rebase", and push the result back. The rebase will create a new commit D that builds the change between X and B on top of A.

      B   D
     /   /

同样的,用这个提交更新 A 会快速合并,你的推送会被接受。

还有一种常见的情况是,当你试图推送时,可能会遇到非快速合并拒绝,即使你推送到一个没有人推送的版本库中也有可能。在你自己推送了提交 A(在本节的第一幅图中),用 "git commit --amend" 替换后产生了提交 B,你试图推送它,因为忘记了你已经推送了 A。在这种情况下,只有当您确定在此期间没有人取走您先前的提交 A(并在其基础上开始构建),您才能运行 "git push --force" 来覆盖它。换句话说,"git push --force" 是一种保留给你确实想失去历史的情况的方法。


git push

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

git push origin

不需要额外配置,如果它与当前分支同名,并且错误输出而不推送其他分支,则将其推送到配置过的上游仓库(branch.<分支名>.merge 配置变量)。

当没有给出< 引用规范 >时,该命令的默认行为可以通过设置远程仓库的 push 选项或 `push.default`配置变量来配置。

For example, to default to pushing only the current branch to origin use git config remote.origin.push HEAD. Any valid <refspec> (like the ones in the examples below) can be configured as the default for git push origin.

git push origin :

将 “匹配” 的分支推送到 origin。关于 “匹配” 分支的描述,请参见上面 选项 部分的 [引用规范]

git push origin master

Find a ref that matches master in the source repository (most likely, it would find refs/heads/master), and update the same ref (e.g. refs/heads/master) in origin repository with it. If master did not exist remotely, it would be created.

git push origin HEAD


git push mothership master:satellite/master dev:satellite/dev

Use the source ref that matches master (e.g. refs/heads/master) to update the ref that matches satellite/master (most probably refs/remotes/satellite/master) in the mothership repository; do the same for dev and satellite/dev.

关于匹配语义的讨论,请参见上面描述 <引用规范>... 的部分。

这是为了模拟在`母舰` 上运行的 git fetch ,使用 git push 以相反的方向运行,以便整合 卫星 上完成的工作,当你只能以一种方式进行连接时(即卫星可以ssh到母舰,但母舰不能启动与卫星的连接,因为后者在防火墙后面或不运行 sshd),这往往是必要的。

卫星 机器上运行这个 git push 后,你将 ssh 进入 母舰 并在那里运行 git merge ,以完成对 母舰 上运行的 git pull 的模拟,以拉取 卫星 上的修改。

git push origin HEAD:master

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

git push origin master:refs/heads/experimental

Create the branch experimental in the origin repository by copying the current master branch. This form is only needed to create a new branch or tag in the remote repository when the local name and the remote name are different; otherwise, the ref name on its own will work.

git push origin :experimental

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

git push origin +dev:master

Update the origin repository’s master branch with the dev branch, allowing non-fast-forward updates. This can leave unreferenced commits dangling in the origin repository. Consider the following situation, where a fast-forward is not possible:

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

上面的命令将 origin 仓库更改为

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

Commits A and B would no longer belong to a branch with a symbolic name, and so would be unreachable. As such, these commits would be removed by a git gc command on the origin repository.




  1. 受害者发送 "have" 行,宣传它所拥有的对象的 ID,这些对象并没有明确地打算被共享,但如果对等体也有这些对象,就可以用来优化传输。攻击者选择了一个对象 ID X 来窃取,并向 X 发送了一个引用,但不需要发送 X 的内容,因为受害者已经拥有它。现在,受害者认为攻击者拥有 X,它稍后将 X 的内容发回给攻击者。(这种攻击对于客户端来说在服务器上执行是最直接的,通过在客户端可以访问的命名空间中创建一个 X 的引用,然后获取它。服务器最可能在客户端执行的方式是将 X "合并" 到一个公共分支,并希望用户在这个分支上做额外的工作,然后在没有注意到合并的情况下将其推回给服务器。)

  2. As in #1, the attacker chooses an object ID X to steal. The victim sends an object Y that the attacker already has, and the attacker falsely claims to have X and not Y, so the victim sends Y as a delta against X. The delta reveals regions of X that are similar to Y to the attacker.



Missing zh_HANS-CN/includes/cmd-config-section-all.txt

See original version for this content.


Missing zh_HANS-CN/config/push.txt

See original version for this content.


属于 git[1] 文档