git documentation - en to zh_HANS-CN translation catalogue (5897 entries)

note: type: Plain text
en: Show blank SHA-1 for boundary commits.  This can also be controlled via the `blame.blankBoundary` config option.
zh_HANS-CN: 为边界提交显示空白的 SHA-1。  这也可以通过 `blame.blankBoundary` 配置选项来控制。

note: type: Plain text
en: Do not treat root commits as boundaries.  This can also be controlled via the `blame.showRoot` config option.
zh_HANS-CN: 不把根提交当作边界。  这也可以通过 `blame.showRoot` 配置选项来控制。

note: type: Plain text
en: Include additional statistics at the end of blame output.
zh_HANS-CN: 在历史追溯输出的结尾处包括额外的统计数据。

note: type: Plain text
en: Annotate only the line range given by '<start>,<end>', or by the function name regex '<funcname>'.  May be specified multiple times. Overlapping ranges are allowed.
zh_HANS-CN: 仅注释由'<start>，<end>'或功能名称正则表达式'<funcname>'给出的行范围。 可以指定多次。 允许重叠范围。

note: type: Plain text
en: '<start>' and '<end>' are optional. `-L <start>` or `-L <start>,` spans from '<start>' to end of file. `-L ,<end>` spans from start of file to '<end>'.
zh_HANS-CN: '<start>' 和 '<end>' 是可选的 `-L <start>` 或 `-L <start>,` 范围从 '<start>' 到文件末尾。 `-L ,<end>` 从文件开始到 '<end>'.

note: type: Plain text
en: Show long rev (Default: off).
zh_HANS-CN: 显示长转（默认值：关闭）。

note: type: Plain text
en: Show raw timestamp (Default: off).
zh_HANS-CN: 显示原始时间戳（默认值：关闭）。

note: type: Plain text
en: Use revisions from revs-file instead of calling linkgit:git-rev-list[1].
zh_HANS-CN: 使用revs-file中的修订，而不是调用 linkgit:git-rev-list[1]。

note: type: Plain text
en: Walk history forward instead of backward. Instead of showing the revision in which a line appeared, this shows the last revision in which a line has existed. This requires a range of revision like START..END where the path to blame exists in START.  `git blame --reverse START` is taken as `git blame --reverse START..HEAD` for convenience.
zh_HANS-CN: 向前调用历史记录，而不向后调用历史记录。 与其显示行所在的修订，不显示行所在的最后一个修订。 这就需要进行一系列修订，例如START..END，其中的归咎路径在START中。 为方便起见，将git blame --reverse START。当作git blame --reverse START..HEAD。

note: type: Plain text
en: Follow only the first parent commit upon seeing a merge commit. This option can be used to determine when a line was introduced to a particular integration branch, rather than when it was introduced to the history overall.
zh_HANS-CN: 在看到合并提交时只关注第一个父提交。这个选项可以用来确定某一行何时被引入某个特定的集成分支，而不是何时被引入整个历史中。

note: type: Plain text
en: Show the porcelain format, but output commit information for each line, not just the first time a commit is referenced.  Implies --porcelain.
zh_HANS-CN: 显示上层命令格式，但输出每一行的提交信息，而不仅仅是第一次引用提交时的信息。 意味着 --porcelain。

note: type: Plain text
en: Specifies the encoding used to output author names and commit summaries. Setting it to `none` makes blame output unconverted data. For more information see the discussion about encoding in the linkgit:git-log[1] manual page.
zh_HANS-CN: 指定用于输出作者姓名和提交摘要的编码。设置为 `none` 会使历史追溯输出未转换的数据。更多信息见 linkgit:git-log[1] 手册页中关于编码的讨论。

note: type: Plain text
en: Annotate using the contents from the named file, starting from <rev> if it is specified, and HEAD otherwise. You may specify '-' to make the command read from the standard input for the file contents.
zh_HANS-CN: 使用指定文件中的内容进行注释，如果指定了 <rev>，则从 <rev> 开始，否则从 HEAD 开始。你可以指定 '-' 来使命令从标准输入中读取文件内容。

note: type: Labeled list
en: --date <format>
zh_HANS-CN: --date <格式>

note: type: Plain text
en: Specifies the format used to output dates. If --date is not provided, the value of the blame.date config variable is used. If the blame.date config variable is also not set, the iso format is used. For supported values, see the discussion of the --date option at linkgit:git-log[1].
zh_HANS-CN: 指定用于输出日期的格式。如果没有提供 --date，则使用 blame.date 配置变量的值。如果 blame.date 配置变量也没有设置，则使用 iso 格式。关于支持的值，请参见 linkgit:git-log[1] 中关于 --date 选项的讨论。

note: type: Plain text
en: Progress status is reported on the standard error stream by default when it is attached to a terminal. This flag enables progress reporting even if not attached to a terminal. Can't use `--progress` together with `--porcelain` or `--incremental`.
zh_HANS-CN: 当它连接到一个终端时，默认情况下进度状态会在标准错误流中报告。这个标志可以使进度报告即使没有连接到终端。`--porcelain`或`--incremental` 不能与 `--progress` 一起使用。

note: type: Plain text
en: Detect moved or copied lines within a file. When a commit moves or copies a block of lines (e.g. the original file has A and then B, and the commit changes it to B and then A), the traditional 'blame' algorithm notices only half of the movement and typically blames the lines that were moved up (i.e. B) to the parent and assigns blame to the lines that were moved down (i.e. A) to the child commit.  With this option, both groups of lines are blamed on the parent by running extra passes of inspection.
zh_HANS-CN: 检测文件中移动或复制的行。当一次提交移动或复制一个行块时（例如，原始文件有 A，然后是 B，而提交将其改为 B，然后是 A），传统的 'blame' 算法只注意到一半的移动，通常将向上移动的行（即 B ）归咎于父代，而将向下移动的行（即 A ）归咎于子代提交。 有了这个选项，通过运行额外的检查，两组行都会被归咎于父代。

note: type: Plain text
en: <num> is optional but it is the lower bound on the number of alphanumeric characters that Git must detect as moving/copying within a file for it to associate those lines with the parent commit. The default value is 20.
zh_HANS-CN: <num> 是可选的，但它是 Git 必须检测到的在文件中移动或复制的字母数字字符的数量的下限，以便它将这些行与父提交相关联。默认值是20。

note: type: Plain text
en: In addition to `-M`, detect lines moved or copied from other files that were modified in the same commit.  This is useful when you reorganize your program and move code around across files.  When this option is given twice, the command additionally looks for copies from other files in the commit that creates the file. When this option is given three times, the command additionally looks for copies from other files in any commit.
zh_HANS-CN: 除了`-M`之外，还可以检测在同一提交中被修改的其他文件中移动或复制的行。 这在你重新组织程序并在不同文件间移动代码时很有用。 当这个选项被赋予两次时，命令会在创建文件的提交中额外寻找其他文件的拷贝。当这个选项出现三次时，命令会在任何一次提交中额外寻找其他文件的副本。

note: type: Plain text
en: <num> is optional but it is the lower bound on the number of alphanumeric characters that Git must detect as moving/copying between files for it to associate those lines with the parent commit. And the default value is 40. If there are more than one `-C` options given, the <num> argument of the last `-C` will take effect.
zh_HANS-CN: <num>是 可选的，但它是 Git 必须检测到的在文件之间移动或复制的字母数字字符的数量的下限，以便它将这些行与父提交关联起来。而默认值是 40。如果有一个以上的 `-C ` 选项，只有最后一个 `-C `的 <num> 参数起作用。

note: type: Plain text
en: Ignore changes made by the revision when assigning blame, as if the change never happened.  Lines that were changed or added by an ignored commit will be blamed on the previous commit that changed that line or nearby lines.  This option may be specified multiple times to ignore more than one revision.  If the `blame.markIgnoredLines` config option is set, then lines that were changed by an ignored commit and attributed to another commit will be marked with a `?` in the blame output.  If the `blame.markUnblamableLines` config option is set, then those lines touched by an ignored commit that we could not attribute to another revision are marked with a '*'.
zh_HANS-CN: 在分配责任时忽略修订版所做的修改，就像该修改从未发生过一样。 被忽略的提交所改变或增加的行将被归咎于改变该行或附近行的前一个提交。 这个选项可以多次指定，以忽略一个以上的修订。 如果设置了 `blame.markIgnoredLines` 配置选项，那么被忽略的提交所改变的行将被归咎于另一个提交，在归咎输出中会标上`?` 如果设置了 `blame.markUnblamableLines` 配置选项，那么那些被忽略的提交所触及的、我们无法归因于另一个修订版的行将被标记为 '*'。

note: type: Labeled list
en: --ignore-revs-file <file>
zh_HANS-CN: --ignore-revs-file <文件>

note: type: Plain text
en: Ignore revisions listed in `file`, which must be in the same format as an `fsck.skipList`.  This option may be repeated, and these files will be processed after any files specified with the `blame.ignoreRevsFile` config option.  An empty file name, `""`, will clear the list of revs from previously processed files.
zh_HANS-CN: 忽略 `file` 中列出的修订，其格式必须与 `fsck.skipList` 相同。 这个选项可以重复使用，这些文件将在任何用 `blame.ignoreRevsFile` 配置选项指定的文件之后被处理。 一个空的文件名，`""`，将清除以前处理的文件的 Revs 列表。

note: type: Plain text
en: Color line annotations in the default format differently if they come from the same commit as the preceding line. This makes it easier to distinguish code blocks introduced by different commits. The color defaults to cyan and can be adjusted using the `color.blame.repeatedLines` config option.
zh_HANS-CN: 在默认格式下，如果行注释与前一行来自同一提交，则颜色不同。这可以让我们更容易区分不同提交的代码块。颜色默认为青色，可以使用 `color. blame.repeatedLines` 配置选项进行调整。

note: type: Plain text
en: Color line annotations depending on the age of the line in the default format.  The `color.blame.highlightRecent` config option controls what color is used for each range of age.
zh_HANS-CN: 根据默认格式的行的阶段，给行的注释着色。 `color.blue.highlightRecent` 配置选项控制每个阶段范围使用什么颜色。

note: type: Plain text
en: Show help message.
zh_HANS-CN: 显示帮助信息。

note: type: Plain text
en: Annotate file lines with commit information.
zh_HANS-CN: 用提交信息来注释文件行。

note: type: Plain text
en: Show what revision and author last modified each line of a file.
zh_HANS-CN: 显示文件的每一行最后修改的版本和作者。

note: type: Plain text
en: Collect information for user to file a bug report.
zh_HANS-CN: 收集信息，以便用户提交错误报告。

note: type: Plain text
en: Count unpacked number of objects and their disk consumption.
zh_HANS-CN: 计数对象的解包数量和它们的磁盘消耗。

note: type: Plain text
en: Generate a zip archive of diagnostic information.
zh_HANS-CN: 生成一个诊断信息的压缩文件。

note: type: Plain text
en: Show changes using common diff tools.
zh_HANS-CN: 使用常见的差异工具显示变化。

note: type: Plain text
en: Verifies the connectivity and validity of the objects in the database.
zh_HANS-CN: 验证数据库中的对象的连接性和有效性。

note: type: Plain text
en: Display help information about Git.
zh_HANS-CN: 显示有关Git的帮助信息。

note: type: Plain text
en: Instantly browse your working repository in gitweb.
zh_HANS-CN: 在gitweb中浏览您的工作存储库。

note: type: Plain text
en: Reuse recorded resolution of conflicted merges.
zh_HANS-CN: 重新使用记录的冲突合并的解决方案。

note: type: Plain text
en: Show branches and their commits.
zh_HANS-CN: 显示分支和它们的提交。

note: type: Plain text
en: Check the GPG signature of commits.
zh_HANS-CN: 检查提交的GPG签名。

note: type: Plain text
en: Check the GPG signature of tags.
zh_HANS-CN: 检查tag的GPG签名。

note: type: Plain text
en: Show logs with difference each commit introduces.
zh_HANS-CN: 显示每次提交带来的差异的日志。

note: type: Plain text
en: Get and set repository or global options.
zh_HANS-CN: 获取和设置存储库或全局选项。

note: type: Plain text
en: Git data exporter.
zh_HANS-CN: Git 数据导出器。

note: type: Plain text
en: Backend for fast Git data importers.
zh_HANS-CN: 快速 Git 数据导入器的后端。

note: type: Plain text
en: Rewrite branches.
zh_HANS-CN: 重写分支。

note: type: Plain text
en: Run merge conflict resolution tools to resolve merge conflicts.
zh_HANS-CN: 运行合并冲突解决工具来解决合并冲突。

note: type: Plain text
en: Pack heads and tags for efficient repository access.
zh_HANS-CN: 包装头和标签用于有效的仓库访问。

note: type: Plain text
en: Prune all unreachable objects from the object database.
zh_HANS-CN: 从对象数据库中修剪所有不可达的对象。

note: type: Plain text
en: Manage reflog information.
zh_HANS-CN: 管理reflog信息。

note: type: Plain text
en: Manage set of tracked repositories.
zh_HANS-CN: 管理一组被跟踪的仓库。

note: type: Plain text
en: Pack unpacked objects in a repository.
zh_HANS-CN: 在存储库中打包未打包的对象。

note: type: Plain text
en: Create, list, delete refs to replace objects.
zh_HANS-CN: 创建、列出、删除替换对象的引用。

note: type: Plain text
en: Import a GNU Arch repository into Git.
zh_HANS-CN: 导入一个GNU Arch仓库到Git。

note: type: Plain text
en: Export a single commit to a CVS checkout.
zh_HANS-CN: 导出单次commit到CVS checkout。

note: type: Plain text
en: Salvage your data out of another SCM people love to hate.
zh_HANS-CN: 把你的数据从另一个人们爱恨交加的 SCM 中解救出来。

note: type: Plain text
en: A CVS server emulator for Git.
zh_HANS-CN: 用于Git的CVS服务器模拟器。

note: type: Plain text
en: Import from and submit to Perforce repositories.
zh_HANS-CN: 从 Perforce 存储库导入和提交。

note: type: Plain text
en: Applies a quilt patchset onto the current branch.
zh_HANS-CN: 将 quilt 补丁集应用到当前分支

note: type: Plain text
en: Generates a summary of pending changes.
zh_HANS-CN: 生成一个悬而未决的更改摘要。

note: type: Plain text
en: Send a collection of patches as emails.
zh_HANS-CN: 以电子邮件的形式发送补丁集合。

note: type: Plain text
en: A Git core tutorial for developers.
zh_HANS-CN: 面向开发者的 Git 核心教程。

note: type: Plain text
en: Providing usernames and passwords to Git.
zh_HANS-CN: 向 Git 提供用户名和密码。

note: type: Plain text
en: Git for CVS users.
zh_HANS-CN: 为 CVS 用户提供的 Git。

note: type: Plain text
en: Tweaking diff output.
zh_HANS-CN: 调整差异输出。

note: type: Plain text
en: A useful minimum set of commands for Everyday Git.
zh_HANS-CN: 一套有用的最小化 Git 命令集。

note: type: Plain text
en: Frequently asked questions about using Git.
zh_HANS-CN: 关于使用 Git 的常见问题。

note: type: Plain text
en: Helper programs to interact with remote repositories.
zh_HANS-CN: 与远程仓库互动的辅助程序。

note: type: Plain text
en: Mounting one repository inside another.
zh_HANS-CN: 将一个存储库挂载在另一个存储库内。

note: type: Plain text
en: A tutorial introduction to Git.
zh_HANS-CN: Git入门教程。

note: type: Plain text
en: A tutorial introduction to Git: part two.
zh_HANS-CN: Git 的教程介绍：第二部分。

note: type: Plain text
en: An overview of recommended workflows with Git.
zh_HANS-CN: 推荐使用 Git 的工作流程概述。

note: type: Plain text
en: Apply a series of patches from a mailbox.
zh_HANS-CN: 从一个邮箱中应用一系列的补丁。

note: type: Plain text
en: Create an archive of files from a named tree.
zh_HANS-CN: 从一个命名的目录中创建一个文件档案。

note: type: Plain text
en: Use binary search to find the commit that introduced a bug.
zh_HANS-CN: 使用二进制搜索查找引入错误的提交。

note: type: Plain text
en: List, create, or delete branches.
zh_HANS-CN: 列出、创建或删除分支。

note: type: Plain text
en: Move objects and refs by archive.
zh_HANS-CN: 通过存档移动对象和引用。

note: type: Plain text
en: Switch branches or restore working tree files.
zh_HANS-CN: 切换分支或恢复工作区文件。

note: type: Plain text
en: Apply the changes introduced by some existing commits.
zh_HANS-CN: 应用一些现有的提交所带来的变化。

note: type: Plain text
en: Remove untracked files from the working tree.
zh_HANS-CN: 从工作区上删除未跟踪的文件。

note: type: Plain text
en: Record changes to the repository.
zh_HANS-CN: 记录对仓库的更改。

note: type: Plain text
en: Give an object a human readable name based on an available ref.
zh_HANS-CN: 根据一个可用的引用，给一个对象易于理解的名字。

note: type: Plain text
en: Show changes between commits, commit and working tree, etc.
zh_HANS-CN: 显示提交之间的变化，提交和工作区，等。

note: type: Plain text
en: Download objects and refs from another repository.
zh_HANS-CN: 从另一个仓库下载对象和引用。

note: type: Plain text
en: Prepare patches for e-mail submission.
zh_HANS-CN: 为提交电子邮件准备补丁。

note: type: Plain text
en: Cleanup unnecessary files and optimize the local repository.
zh_HANS-CN: 清理不必要的文件，优化本地仓库。

note: type: Plain text
en: Print lines matching a pattern.
zh_HANS-CN: 打印符合模式的行。

note: type: Plain text
en: A portable graphical interface to Git.
zh_HANS-CN: Git的可移植图形界面。

note: type: Plain text
en: Show commit logs.
zh_HANS-CN: 展示提交日志。

note: type: Plain text
en: Run tasks to optimize Git repository data.
zh_HANS-CN: 运行任务来优化Git存储库的数据。

note: type: Plain text
en: Join two or more development histories together.
zh_HANS-CN: 将两个或更多的开发历史连接在一起。

note: type: Plain text
en: Move or rename a file, a directory, or a symlink.
zh_HANS-CN: 移动或重命名一个文件、一个目录或一个符号链接。

note: type: Plain text
en: Add or inspect object notes.
zh_HANS-CN: 添加或检查对象注释。

note: type: Plain text
en: Fetch from and integrate with another repository or a local branch.
zh_HANS-CN: 从另一个仓库或本地分支获取并整合。

note: type: Plain text
en: Update remote refs along with associated objects.
zh_HANS-CN: 更新远程仓库引用和相关对象。

note: type: Plain text
en: Compare two commit ranges (e.g. two versions of a branch).
zh_HANS-CN: 比较两个提交范围（例如一个分支的两个版本）。

note: type: Plain text
en: Reapply commits on top of another base tip.
zh_HANS-CN: 在另一个基础提示的基础上重新提交。

note: type: Plain text
en: Reset current HEAD to the specified state.
zh_HANS-CN: 重置当前HEAD到指定状态。

note: type: Plain text
en: Restore working tree files.
zh_HANS-CN: 恢复工作区文件。

note: type: Plain text
en: Revert some existing commits.
zh_HANS-CN: 还原一些现有的提交。

note: type: Plain text
en: Remove files from the working tree and from the index.
zh_HANS-CN: 从工作区和索引中删除文件。

note: type: Plain text
en: Show various types of objects.
zh_HANS-CN: 展示各种类型的对象。

note: type: Plain text
en: Reduce your working tree to a subset of tracked files.
zh_HANS-CN: 将你的工作区减少到一个被跟踪的文件子集。

note: type: Plain text
en: Stash the changes in a dirty working directory away.
zh_HANS-CN: 把这些变化贮藏在一个脏工作目录中。

note: type: Plain text
en: Show the working tree status.
zh_HANS-CN: 显示工作区状态。

note: type: Plain text
en: Initialize, update or inspect submodules.
zh_HANS-CN: 初始化、更新或检查子模块。

note: type: Plain text
en: Switch branches.
zh_HANS-CN: 切换分支。

note: type: Plain text
en: Manage multiple working trees.
zh_HANS-CN: 管理多个工作区。

note: type: Plain text
en: The Git repository browser.
zh_HANS-CN: Git 仓库浏览器。

note: type: Plain text
en: Provide content or type and size information for repository objects.
zh_HANS-CN: 为仓库对象提供内容或类型和大小信息。

note: type: Plain text
en: Find commits yet to be applied to upstream.
zh_HANS-CN: 查找尚未应用于上游仓库的提交。

note: type: Plain text
en: Compares files in the working tree and the index.
zh_HANS-CN: 比较工作区和索引中的文件。

note: type: Plain text
en: Compare a tree to the working tree or index.
zh_HANS-CN: 将目录树与工作目录或索引进行比较。

note: type: Plain text
en: Run a Git command on a list of repositories.
zh_HANS-CN: 在一个仓库列表上运行一个 Git 命令。

note: type: Plain text
en: Extract commit ID from an archive created using git-archive.
zh_HANS-CN: 从使用git archive创建的存档中提取commit ID。

note: type: Plain text
en: Show information about files in the index and the working tree.
zh_HANS-CN: 显示索引和工作区中的文件信息。

note: type: Plain text
en: List references in a remote repository.
zh_HANS-CN: 列出远程仓库中的引用。

note: type: Plain text
en: List the contents of a tree object.
zh_HANS-CN: 列出一个树对象的内容。

note: type: Plain text
en: Find as good common ancestors as possible for a merge.
zh_HANS-CN: 尽可能找到好的共同祖先进行合并。

note: type: Plain text
en: Find symbolic names for given revs.
zh_HANS-CN: 为给定的 revs 寻找符号名称。

note: type: Plain text
en: Find redundant pack files.
zh_HANS-CN: 寻找多余的包文件。

note: type: Plain text
en: Lists commit objects in reverse chronological order.
zh_HANS-CN: 按时间顺序倒序列出提交对象。

note: type: Plain text
en: Pick out and massage parameters.
zh_HANS-CN: 挑选并按摩参数。

note: type: Plain text
en: Show packed archive index.
zh_HANS-CN: 显示打包的档案索引。

note: type: Plain text
en: List references in a local repository.
zh_HANS-CN: 列出本地仓库中的引用。

note: type: Plain text
en: Creates a temporary file with a blob's contents.
zh_HANS-CN: 创建包含blob内容的临时文件。

note: type: Plain text
en: Copy files from the index to the working tree.
zh_HANS-CN: 从索引中复制文件到工作目录。

note: type: Plain text
en: Write and verify Git commit-graph files.
zh_HANS-CN: 编写并验证Git commit-graph文件。

note: type: Plain text
en: Create a new commit object.
zh_HANS-CN: 创建一个新的提交对象。

note: type: Plain text
en: Build pack index file for an existing packed archive.
zh_HANS-CN: 为现有的打包档案建立打包索引文件。

note: type: Plain text
en: Run a three-way file merge.
zh_HANS-CN: 运行一个三向文件合并。

note: type: Plain text
en: Run a merge for files needing merging.
zh_HANS-CN: 为需要合并的文件运行合并程序。

note: type: Plain text
en: Creates a tag object with extra validation.
zh_HANS-CN: 创建一个具有额外验证功能的标签对象。

note: type: Plain text
en: Write and verify multi-pack-indexes.
zh_HANS-CN: 编写和验证多包索引。

note: type: Plain text
en: Create a packed archive of objects.
zh_HANS-CN: 创建一个打包的对象档案。

note: type: Plain text
en: Remove extra objects that are already in pack files.
zh_HANS-CN: 删除已经存在于包文件中的额外对象。

note: type: Plain text
en: Reads tree information into the index.
zh_HANS-CN: 将目录树的信息读入索引。

note: type: Plain text
en: Read, modify and delete symbolic refs.
zh_HANS-CN: 读取、修改和删除符号引用。

note: type: Plain text
en: Unpack objects from a packed archive.
zh_HANS-CN: 从打包的档案中解压对象。

note: type: Plain text
en: Register file contents in the working tree to the index.
zh_HANS-CN: 将工作区中的文件内容登记到索引中。

note: type: Plain text
en: Update the object name stored in a ref safely.
zh_HANS-CN: 安全地更新存储在引用中的对象名称。

note: type: Plain text
en: Create a tree object from the current index.
zh_HANS-CN: 从当前索引创建一个树形对象。

note: type: Plain text
en: Display gitattributes information.
zh_HANS-CN: 显示属性信息。

note: type: Plain text
en: Debug gitignore / exclude files.
zh_HANS-CN: 调试gitignore/排除文件。

note: type: Plain text
en: Show canonical names and email addresses of contacts.
zh_HANS-CN: 显示联系人的规范名称和电子邮件地址。

note: type: Plain text
en: Ensures that a reference name is well formed.
zh_HANS-CN: 确保一个引用名称是否规范。

note: type: Plain text
en: Display data in columns.
zh_HANS-CN: 以列显示数据。

note: type: Plain text
en: Retrieve and store user credentials.
zh_HANS-CN: 检索和存储用户凭证。

note: type: Plain text
en: Helper to temporarily store passwords in memory.
zh_HANS-CN: 用于在内存中临时存储密码的助手。

note: type: Plain text
en: Helper to store credentials on disk.
zh_HANS-CN: 帮助在磁盘上存储凭证。

note: type: Plain text
en: Produce a merge commit message.
zh_HANS-CN: 产生一个合并提交信息。

note: type: Plain text
en: Run git hooks.
zh_HANS-CN: 运行 git hooks。

note: type: Plain text
en: Add or parse structured information in commit messages.
zh_HANS-CN: 在提交信息中添加或解析结构化信息。

note: type: Plain text
en: Extracts patch and authorship from a single e-mail message.
zh_HANS-CN: 从单一的电子邮件中提取补丁和作者。

note: type: Plain text
en: Simple UNIX mbox splitter program.
zh_HANS-CN: 简单的 UNIX mbox 拆分器程序。

note: type: Plain text
en: The standard helper program to use with git-merge-index.
zh_HANS-CN: 与git-merge-index一起使用的标准帮助程序。

note: type: Plain text
en: Compute unique ID for a patch.
zh_HANS-CN: 为补丁计算唯一的主键ID。

note: type: Plain text
en: Git's i18n setup code for shell scripts.
zh_HANS-CN: Git的i18n(国际化)安装代码- shell脚本.

note: type: Plain text
en: Common Git shell script setup code.
zh_HANS-CN: 通用Git shell脚本安装代码。

note: type: Plain text
en: Remove unnecessary whitespace.
zh_HANS-CN: 删除不必要的空白。

note: type: Plain text
en: Download from a remote Git repository via HTTP.
zh_HANS-CN: 通过HTTP从远程Git存储库下载。

note: type: Plain text
en: Push objects over HTTP/DAV to another repository.
zh_HANS-CN: 通过HTTP/DAV将对象推送到另一个存储库。

note: type: Plain text
en: Receive what is pushed into the repository.
zh_HANS-CN: 接收推送到仓库的内容。

note: type: Plain text
en: Restricted login shell for Git-only SSH access.
zh_HANS-CN: Git-only SSH 通道使用的限制登录脚本。

note: type: Plain text
en: Send archive back to git-archive.
zh_HANS-CN: 将归档文件发送回git-archive。

note: type: Plain text
en: Send objects packed back to git-fetch-pack.
zh_HANS-CN: 将打包的对象发送回git-fetch-pack。

note: type: Plain text
en: A really simple server for Git repositories.
zh_HANS-CN: 一个非常简单的Git存储库服务器。

note: type: Plain text
en: Receive missing objects from another repository.
zh_HANS-CN: 从另一个仓库接收丢失的对象。

note: type: Plain text
en: Push objects over Git protocol to another repository.
zh_HANS-CN: 通过Git协议将对象推送到另一个存储库。

note: type: Plain text
en: Update auxiliary info file to help dumb servers.
zh_HANS-CN: 更新辅助信息文件以帮助哑服务器。

note: type: Plain text
en: The Git configuration file contains a number of variables that affect the Git commands' behavior. The files `.git/config` and optionally `config.worktree` (see the "CONFIGURATION FILE" section of linkgit:git-worktree[1]) in each repository are used to store the configuration for that repository, and `$HOME/.gitconfig` is used to store a per-user configuration as fallback values for the `.git/config` file. The file `/etc/gitconfig` can be used to store a system-wide default configuration.
zh_HANS-CN: Git 配置文件包含了一些影响 Git 命令行为的变量。每个仓库中的文件 `.git/config` 和可选的 `config.worktree`（见linkgit:git-worktree[1]的 “配置文件” 部分）用于存储该仓库的配置，`$HOME/.gitconfig` 用于存储每个用户的配置，作为 `.git/config` 文件的后退值。文件 `/etc/gitconfig` 可以用来存储全系统的默认配置。

note: type: Plain text
en: The configuration variables are used by both the Git plumbing and the porcelains. The variables are divided into sections, wherein the fully qualified variable name of the variable itself is the last dot-separated segment and the section name is everything before the last dot. The variable names are case-insensitive, allow only alphanumeric characters and `-`, and must start with an alphabetic character.  Some variables may appear multiple times; we say then that the variable is multivalued.
zh_HANS-CN: 配置变量同时被 Git 底层和上层命令使用。变量被分为几个部分，其中变量本身的完全合格的变量名是最后一个点分隔的部分，而部分名称是最后一个点之前的所有内容。变量名称不区分大小写，只允许使用字母数字字符和 `-`，并且必须以字母字符开头。  有些变量可能会出现多次；那么我们就说这个变量是多值的。

note: type: Plain text
en: The syntax is fairly flexible and permissive; whitespaces are mostly ignored.  The '#' and ';' characters begin comments to the end of line, blank lines are ignored.
zh_HANS-CN: 语法是相当灵活和宽松的；空白处大多被忽略。  '#' 和 ';' 字符开始注释到行末，空行被忽略。

note: type: Plain text
en: The file consists of sections and variables.  A section begins with the name of the section in square brackets and continues until the next section begins.  Section names are case-insensitive.  Only alphanumeric characters, `-` and `.` are allowed in section names.  Each variable must belong to some section, which means that there must be a section header before the first setting of a variable.
zh_HANS-CN: 该文件由章节和变量组成。  一个章节以方括号中的章节名称开始，一直到下一个章节开始。  节的名称是不区分大小写的。  在章节名称中只允许使用字母数字字符、`-` 和 `.`。  每个变量都必须属于某个部分，这意味着在第一次设置变量之前必须有一个部分标题。

note: type: Plain text
en: Sections can be further divided into subsections.  To begin a subsection put its name in double quotes, separated by space from the section name, in the section header, like in the example below:
zh_HANS-CN: 节可以进一步划分为子节。  要开始一个分节，请将其名称放在双引号中，与节的名称用空格隔开，放在节的标题中，如下面的例子：

note: type: Plain text
en: Subsection names are case sensitive and can contain any characters except newline and the null byte. Doublequote `"` and backslash can be included by escaping them as `\"` and `\\`, respectively. Backslashes preceding other characters are dropped when reading; for example, `\t` is read as `t` and `\0` is read as `0`. Section headers cannot span multiple lines.  Variables may belong directly to a section or to a given subsection. You can have `[section]` if you have `[section "subsection"]`, but you don't need to.
zh_HANS-CN: 分节名称是区分大小写的，可以包含任何字符，除了换行和空字节。双引号 `"` 和反斜杠可以分别通过转义为 `\"`和 `\\` 来包含。读取时，其他字符前面的反斜杠将被删除；例如，`\t` 被读作 `t`，`\0` 被读作 `0`。章节标题不能跨越多行。  变量可以直接属于某一节或某一小节。如果你有 `[section "subsection"]`，你可以有 `[section]`，但你不需要这样。

note: type: Plain text
en: There is also a deprecated `[section.subsection]` syntax. With this syntax, the subsection name is converted to lower-case and is also compared case sensitively. These subsection names follow the same restrictions as section names.
zh_HANS-CN: 还有一种废弃的 `[section.subsection]` 语法。在这种语法中，分节名称被转换为小写字母，并且也会敏感地比较大小写。这些分节名称遵循与章节名称相同的限制。

note: type: Plain text
en: All the other lines (and the remainder of the line after the section header) are recognized as setting variables, in the form 'name = value' (or just 'name', which is a short-hand to say that the variable is the boolean "true").  The variable names are case-insensitive, allow only alphanumeric characters and `-`, and must start with an alphabetic character.
zh_HANS-CN: 所有其他行（以及部分标题之后的剩余行）都被认为是设置变量，形式为 'name = value'（或者只是 'name'，这是一个简写，表示变量是布尔值 "true"）。  变量名称不区分大小写，只允许使用字母数字字符和 `-`，并且必须以字母字符开头。

note: type: Plain text
en: A line that defines a value can be continued to the next line by ending it with a `\`; the backslash and the end-of-line are stripped.  Leading whitespaces after 'name =', the remainder of the line after the first comment character '#' or ';', and trailing whitespaces of the line are discarded unless they are enclosed in double quotes.  Internal whitespaces within the value are retained verbatim.
zh_HANS-CN: 定义一个值的行可以通过以 `\` 结束来延续到下一行；反斜杠和行尾被剥离。  在 'name =' 之后的前导空白，在第一个注释字符 '#' 或 ';' 之后的剩余行，以及该行的尾部空白都会被丢弃，除非它们被包含在双引号中。  值中的内部空白将被逐字保留。

note: type: Plain text
en: Inside double quotes, double quote `"` and backslash `\` characters must be escaped: use `\"` for `"` and `\\` for `\`.
zh_HANS-CN: 在双引号内，双引号 `"` 和反斜杠 `\` 字符必须被转义：用 `\"` 表示 `"`，用 `\\` 表示 `\`。

note: type: Plain text
en: The following escape sequences (beside `\"` and `\\`) are recognized: `\n` for newline character (NL), `\t` for horizontal tabulation (HT, TAB)  and `\b` for backspace (BS).  Other char escape sequences (including octal escape sequences) are invalid.
zh_HANS-CN: 以下转义序列（除了 `\"` 和 `\\`）可以被识别：`\n` 表示换行符（NL），`\t` 表示水平制表（HT，TAB），`\b` 表示退格（BS）。  其他字符转义序列（包括八进制转义序列）是无效的。

note: type: Plain text
en: The `include` and `includeIf` sections allow you to include config directives from another source. These sections behave identically to each other with the exception that `includeIf` sections may be ignored if their condition does not evaluate to true; see "Conditional includes" below.
zh_HANS-CN: `include` 和 `includeIf` 部分允许你从另一个来源包含配置指令。这些部分的行为与其他部分相同，但如果 `includeIf` 部分的条件没有评估为真，则可以忽略；见下面的 “有条件的包含”。

note: type: Plain text
en: You can include a config file from another by setting the special `include.path` (or `includeIf.*.path`) variable to the name of the file to be included. The variable takes a pathname as its value, and is subject to tilde expansion. These variables can be given multiple times.
zh_HANS-CN: 你可以通过设置特殊的 `include.path`（或 `includeIf.*.path` ）变量来包含另一个配置文件，即要包含的文件名。该变量将路径名作为其值，并接受 tilde 扩展。这些变量可以被多次赋予。

note: type: Plain text
en: The contents of the included file are inserted immediately, as if they had been found at the location of the include directive. If the value of the variable is a relative path, the path is considered to be relative to the configuration file in which the include directive was found.  See below for examples.
zh_HANS-CN: 被包含的文件的内容会被立即插入，就像它们是在 include 指令的位置被发现的一样。如果该变量的值是一个相对路径，则该路径被认为是相对于发现 include 指令的配置文件。  请看下面的例子。

note: type: Title ~
en: Conditional includes
zh_HANS-CN: 有条件的包括

note: type: Plain text
en: You can include a config file from another conditionally by setting a `includeIf.<condition>.path` variable to the name of the file to be included.
zh_HANS-CN: 你可以通过设置 `includeIf.<条件>.path` 变量来有条件地包含另一个配置文件，即要包含的文件名称。

note: type: Plain text
en: The condition starts with a keyword followed by a colon and some data whose format and meaning depends on the keyword. Supported keywords are:
zh_HANS-CN: 条件以一个关键词开始，后面是冒号和一些数据，其格式和含义取决于关键词。支持的关键词有：

note: type: Plain text
en: The data that follows the keyword `gitdir:` is used as a glob pattern. If the location of the .git directory matches the pattern, the include condition is met.
zh_HANS-CN: 关键字 `gitdir:` 后面的数据被用作匹配模式。如果. git 目录的位置与该模式相匹配，则满足包含条件。

note: type: Plain text
en: The pattern can contain standard globbing wildcards and two additional ones, `**/` and `/**`, that can match multiple path components. Please refer to linkgit:gitignore[5] for details. For convenience:
zh_HANS-CN: 该模式可以包含标准的通配符和两个额外的通配符，`**/` 和 `/**`，可以匹配多个路径组件。详情请参考 linkgit:gitignore[5]。为了方便起见：

note: type: Plain text
en: If the pattern starts with `~/`, `~` will be substituted with the content of the environment variable `HOME`.
zh_HANS-CN: 如果该模式以 `~/` 开头，`~` 将被替换为环境变量 `HOME` 的内容。

note: type: Plain text
en: If the pattern starts with `./`, it is replaced with the directory containing the current config file.
zh_HANS-CN: 如果模式以 `./` 开头，它将被替换为包含当前配置文件的目录。

note: type: Plain text
en: If the pattern does not start with either `~/`, `./` or `/`, `**/` will be automatically prepended. For example, the pattern `foo/bar` becomes `**/foo/bar` and would match `/any/path/to/foo/bar`.
zh_HANS-CN: 如果模式不以 `~/` 、`./` 或 `/` 开头，`**/` 将被自动添加。例如，模式 `foo/bar` 变成 `**/foo/bar`，将匹配 `/any/path/to/foo/bar`。

note: type: Plain text
en: If the pattern ends with `/`, `**` will be automatically added. For example, the pattern `foo/` becomes `foo/**`. In other words, it matches "foo" and everything inside, recursively.
zh_HANS-CN: 如果模式以 `/` 结尾，`**` 将被自动添加。例如，模式 `foo/` 变成 `foo/**`。换句话说，它匹配 "foo" 和里面的所有内容，是递归的。

note: type: Plain text
en: This is the same as `gitdir` except that matching is done case-insensitively (e.g. on case-insensitive file systems)
zh_HANS-CN: 这与 `gitdir` 相同，只是匹配时不区分大小写（例如，在不区分大小写的文件系统上）

note: type: Plain text
en: The data that follows the keyword `onbranch:` is taken to be a pattern with standard globbing wildcards and two additional ones, `**/` and `/**`, that can match multiple path components.  If we are in a worktree where the name of the branch that is currently checked out matches the pattern, the include condition is met.
zh_HANS-CN: 关键词 `onbranch: ` 后面的数据被认为是一个带有标准通配符和两个额外的通配符的模式，`**/` 和 `/**`，可以匹配多个路径组件。  如果我们在一个工作树中，当前签出的分支的名称与该模式相匹配，则满足包含条件。

note: type: Plain text
en: If the pattern ends with `/`, `**` will be automatically added. For example, the pattern `foo/` becomes `foo/**`. In other words, it matches all branches that begin with `foo/`. This is useful if your branches are organized hierarchically and you would like to apply a configuration to all the branches in that hierarchy.
zh_HANS-CN: 如果模式以 `/` 结尾，`**` 将被自动添加。例如，模式 `foo/` 变成 `foo/**`。换句话说，它匹配所有以 "foo/" 开头的分支。如果你的分支是分层组织的，而你想将一个配置应用于该层级中的所有分支，这就很有用了。

note: type: Plain text
en: The data that follows this keyword is taken to be a pattern with standard globbing wildcards and two additional ones, `**/` and `/**`, that can match multiple components. The first time this keyword is seen, the rest of the config files will be scanned for remote URLs (without applying any values). If there exists at least one remote URL that matches this pattern, the include condition is met.
zh_HANS-CN: 这个关键词后面的数据被认为是一个带有标准的通配符和两个额外的通配符的模式，`**/` 和 `/**`，可以匹配多个组件。第一次看到这个关键词时，其余的配置文件将被扫描以寻找远程 URL（不应用任何值）。如果存在至少一个匹配该模式的远程 URL，则满足包含条件。

note: type: Plain text
en: Files included by this option (directly or indirectly) are not allowed to contain remote URLs.
zh_HANS-CN: 由该选项包含的文件（直接或间接）不允许包含远程 URLs。

note: type: Plain text
en: Note that unlike other includeIf conditions, resolving this condition relies on information that is not yet known at the point of reading the condition. A typical use case is this option being present as a system-level or global-level config, and the remote URL being in a local-level config; hence the need to scan ahead when resolving this condition. In order to avoid the chicken-and-egg problem in which potentially-included files can affect whether such files are potentially included, Git breaks the cycle by prohibiting these files from affecting the resolution of these conditions (thus, prohibiting them from declaring remote URLs).
zh_HANS-CN: 请注意，与其他 includeIf 条件不同，解决这个条件依赖于读取条件时还不知道的信息。一个典型的用例是这个选项作为系统级或全局级的配置出现，而远程 URL 在本地级配置中；因此在解决这个条件时需要提前扫描。为了避免鸡生蛋蛋生鸡的问题，即潜在包含的文件会影响这些文件是否被潜在包含，Git 通过禁止这些文件影响这些条件的解决来打破这个循环（因此，禁止它们声明远程 URLs）。

note: type: Plain text
en: A few more notes on matching via `gitdir` and `gitdir/i`:
zh_HANS-CN: 关于通过 `gitdir` 和 `gitdir/i` 进行匹配的一些补充说明：

note: type: Plain text
en: Symlinks in `$GIT_DIR` are not resolved before matching.
zh_HANS-CN: `$GIT_DIR` 中的符号链接在匹配前没有被解决。

note: type: Plain text
en: Both the symlink & realpath versions of paths will be matched outside of `$GIT_DIR`. E.g. if ~/git is a symlink to /mnt/storage/git, both `gitdir:~/git` and `gitdir:/mnt/storage/git` will match.
zh_HANS-CN: 在 `$GIT_DIR` 之外，符号链接和实际路径版本的路径都将被匹配。例如，如果 ~/git 是 /mnt/storage/git 的符号链接，`gitdir:~/git` 和 `gitdir:/mnt/storage/git` 都会匹配。

note: type: Plain text
en: This was not the case in the initial release of this feature in v2.13.0, which only matched the realpath version. Configuration that wants to be compatible with the initial release of this feature needs to either specify only the realpath version, or both versions.
zh_HANS-CN: 在 v2.13.0 版本中，这个功能的初始版本不是这样的，它只匹配 realpath 版本。想要与这个功能的初始版本兼容的配置，要么只指定 realpath 版本，要么就指定两个版本。

note: type: Plain text
en: Note that "../" is not special and will match literally, which is unlikely what you want.
zh_HANS-CN: 请注意，"../" 不是特殊的，将按字面意思匹配，这不太可能是你想要的。

note: type: delimited block -
en: # Core variables
    [core]
    	; Don't trust file modes
    	filemode = false
zh_HANS-CN: # 核心变量
    [core]
    	; 不信任文件模式
    	filemode = false

note: type: delimited block -
en: # Our diff algorithm
    [diff]
    	external = /usr/local/bin/diff-wrapper
    	renames = true
zh_HANS-CN: # 我们的差异算法
    [diff]
    	external = /usr/local/bin/diff-wrapper
    	renames = true

note: type: delimited block -
en: # Proxy settings
    [core]
    	gitProxy="ssh" for "kernel.org"
    	gitProxy=default-proxy ; for the rest
zh_HANS-CN: # 代理设置
    [core]
    	gitProxy="ssh" for "kernel.org"
    	gitProxy=default-proxy ; 其余为

note: type: delimited block -
en: ; include if $GIT_DIR is /path/to/foo/.git
    [includeIf "gitdir:/path/to/foo/.git"]
    	path = /path/to/foo.inc
zh_HANS-CN: ;如果 $GIT_DIR 是 /path/to/foo/.git 就包含
    [includeIf "gitdir:/path/to/foo/.git"]
    	path = /path/to/foo.inc

note: type: delimited block -
en: ; include for all repositories inside $HOME/to/group
    [includeIf "gitdir:~/to/group/"]
    	path = /path/to/foo.inc
zh_HANS-CN: ; 包括 $HOME/to/group 内的所有仓库
    [includeIf "gitdir:~/to/group/"]
    	path = /path/to/foo.inc

note: type: delimited block -
en: ; relative paths are always relative to the including
    ; file (if the condition is true); their location is not
    ; affected by the condition
    [includeIf "gitdir:/path/to/group/"]
    	path = foo.inc
zh_HANS-CN: ; 相对路径总是相对于包括
    ; 文件（如果条件为真）；其位置不受
    ; 的位置不受条件的影响。
    [includeIf "gitdir:/path/to/group/"]
    	path = foo.inc

note: type: delimited block -
en: ; include only if we are in a worktree where foo-branch is
    ; currently checked out
    [includeIf "onbranch:foo-branch"]
    	path = foo.inc
zh_HANS-CN: ; 只有工作区当前检出了 foo-branch 
    ; 才包括
    [includeIf "onbranch:foo-branch"] 。
    	路径 = foo.inc

note: type: delimited block -
en: ; include only if a remote with the given URL exists (note
    ; that such a URL may be provided later in a file or in a
    ; file read after this file is read, as seen in this example)
    [includeIf "hasconfig:remote.*.url:https://example.com/**"]
    	path = foo.inc
    [remote "origin"]
    	url = https://example.com/git
zh_HANS-CN: ; 只有在给定 URL 的远程仓库存在的情况下才包括（注意
    ; 这样的URL可能在以后的文件中提供，或者在这个文件被读取后的一个
    ; 文件中提供，正如在这个例子中看到的那样)
    [includeIf "hasconfig:remote.*.url:https://example.com/*" ]
    	路径 = foo.inc
    [remote "origin"]
    	url = https://example.com/git

note: type: Plain text
en: Values of many variables are treated as a simple string, but there are variables that take values of specific types and there are rules as to how to spell them.
zh_HANS-CN: 许多变量的值都被当作一个简单的字符串，但有些变量取的是特定类型的值，对于如何拼写它们有一些规则。

note: type: Plain text
en: When a variable is said to take a boolean value, many synonyms are accepted for 'true' and 'false'; these are all case-insensitive.
zh_HANS-CN: 当一个变量被称为采取布尔值时，许多同义词被接受为 'true' 和 'false' ；这些都是不分大小写的。

note: type: Plain text
en: Boolean true literals are `yes`, `on`, `true`, and `1`.  Also, a variable defined without `= <value>` is taken as true.
zh_HANS-CN: 布尔真值是 `yes`、`on`、`true`和 `1`。 此外，一个没有 `= <值>` 的变量被认为是真。

note: type: Plain text
en: Boolean false literals are `no`, `off`, `false`, `0` and the empty string.
zh_HANS-CN: 布尔假值是 `no`、`off`、`false`、`0` 和空字符串。

note: type: Plain text
en: When converting a value to its canonical form using the `--type=bool` type specifier, 'git config' will ensure that the output is "true" or "false" (spelled in lowercase).
zh_HANS-CN: 当使用 `--type=bool` 类型指定符将一个值转换为其规范形式时，'git config' 将确保输出为 "true" 或 "false"（用小写字母拼写）。

note: type: Plain text
en: The value for many variables that specify various sizes can be suffixed with `k`, `M`,... to mean "scale the number by 1024", "by 1024x1024", etc.
zh_HANS-CN: 许多指定各种尺寸的变量的值可以以 `k`、`M`...为后缀，表示 “以1024为比例的数字”、“以1024x1024为比例”，等等。

note: type: Plain text
en: The value for a variable that takes a color is a list of colors (at most two, one for foreground and one for background)  and attributes (as many as you want), separated by spaces.
zh_HANS-CN: 接受颜色的变量的值是一个颜色（最多两个，一个用于前景，一个用于背景）和属性（你想要多少就有多少）的列表，用空格分隔。

note: type: Plain text
en: The basic colors accepted are `normal`, `black`, `red`, `green`, `yellow`, `blue`, `magenta`, `cyan`, `white` and `default`.  The first color given is the foreground; the second is the background.  All the basic colors except `normal` and `default` have a bright variant that can be specified by prefixing the color with `bright`, like `brightred`.
zh_HANS-CN: 接受的基本颜色是 `normal`、`black`、`red`、`green`、`yellow`、`blue`、`magenta`、`cyan`、`white` 和 `default`。 给出的第一种颜色是前景；第二种是背景。 除了`normal'和`default'之外，所有的基本颜色都有一个明亮的变体，可以通过在颜色前面加上`bright'来指定，比如`brightred'。

note: type: Plain text
en: The color `normal` makes no change to the color. It is the same as an empty string, but can be used as the foreground color when specifying a background color alone (for example, "normal red").
zh_HANS-CN: 颜色`normal`不会使颜色发生变化。它与空字符串相同，但在单独指定背景颜色时可以作为前景颜色（例如，"normal red"）。

note: type: Plain text
en: The color `default` explicitly resets the color to the terminal default, for example to specify a cleared background. Although it varies between terminals, this is usually not the same as setting to "white black".
zh_HANS-CN: 颜色`default` 明确地将颜色重置为终端的默认值，例如，指定一个清除的背景。虽然不同的终端有差异，但这通常与设置为 "white black" 不一样。

note: type: Plain text
en: Colors may also be given as numbers between 0 and 255; these use ANSI 256-color mode (but note that not all terminals may support this).  If your terminal supports it, you may also specify 24-bit RGB values as hex, like `#ff0ab3`.
zh_HANS-CN: 颜色也可以用 0 到 255 之间的数字来表示；这些颜色使用 ANSI 256 色模式（但注意不是所有的终端都支持这个）。 如果你的终端支持，你也可以指定 24 位 RGB 值为十六进制，如 `#ff0ab3`。

note: type: Plain text
en: The accepted attributes are `bold`, `dim`, `ul`, `blink`, `reverse`, `italic`, and `strike` (for crossed-out or "strikethrough" letters).  The position of any attributes with respect to the colors (before, after, or in between), doesn't matter. Specific attributes may be turned off by prefixing them with `no` or `no-` (e.g., `noreverse`, `no-ul`, etc).
zh_HANS-CN: 可接受的属性是 `bold`、`dim`、`ul`、`blink`、`reverse`、`italic` 和 `strike`（用于划掉的字母或 “删除线”）。 任何属性相对于颜色的位置（在前，在后，或在中间）并不重要。特定的属性可以通过在它们前面加上 `no` 或 `no-` 来关闭（例如，`noreverse`，`no-ul`，等等）。

note: type: Plain text
en: The pseudo-attribute `reset` resets all colors and attributes before applying the specified coloring. For example, `reset green` will result in a green foreground and default background without any active attributes.
zh_HANS-CN: 伪属性 `reset` 在应用指定的着色之前重置所有颜色和属性。例如，`reset green` 将导致一个绿色的前景和默认的背景，没有任何激活的属性。

note: type: Plain text
en: An empty color string produces no color effect at all. This can be used to avoid coloring specific elements without disabling color entirely.
zh_HANS-CN: 一个空的颜色字符串根本不会产生任何颜色效果。这可以用来避免给特定的元素上色而不完全禁用颜色。

note: type: Plain text
en: For git's pre-defined color slots, the attributes are meant to be reset at the beginning of each item in the colored output. So setting `color.decorate.branch` to `black` will paint that branch name in a plain `black`, even if the previous thing on the same output line (e.g.  opening parenthesis before the list of branch names in `log --decorate` output) is set to be painted with `bold` or some other attribute.  However, custom log formats may do more complicated and layered coloring, and the negated forms may be useful there.
zh_HANS-CN: 对于 git 的预定义颜色槽，属性是为了在彩色输出的每一项开始时被重置。所以将 `color.decorate.branch` 设置为 `black` 会将该分支名称涂成普通的 `black`，即使同一输出行中的前一个东西（例如`log -decorate`输出中的分支名称列表前的括号）被设置为 `bold` 或其他属性。 然而，自定义的日志格式可能会做更复杂和分层的着色，而否定的形式在那里可能很有用。

note: type: Plain text
en: A variable that takes a pathname value can be given a string that begins with "`~/`" or "`~user/`", and the usual tilde expansion happens to such a string: `~/` is expanded to the value of `$HOME`, and `~user/` to the specified user's home directory.
zh_HANS-CN: 一个获取路径名值的变量可以被赋予一个以 "`~/`" 或 "`~user/`" 开头的字符串，通常的 tilde 扩展会发生在这样一个字符串上： `~/` 被扩展为 `$HOME` 的值，而 `~user/` 被扩展为指定用户的主目录。

note: type: Plain text
en: If a path starts with `%(prefix)/`, the remainder is interpreted as a path relative to Git's "runtime prefix", i.e. relative to the location where Git itself was installed. For example, `%(prefix)/bin/` refers to the directory in which the Git executable itself lives. If Git was compiled without runtime prefix support, the compiled-in prefix will be substituted instead. In the unlikely event that a literal path needs to be specified that should _not_ be expanded, it needs to be prefixed by `./`, like so: `./%(prefix)/bin`.
zh_HANS-CN: 如果一个路径以 `%(prefix)/` 开头，其余部分将被解释为相对于 Gi t的 "运行时前缀" 的路径，即相对于 Git 本身安装的位置。例如，`%(prefix)/bin/` 指的是 Git 可执行文件本身所在的目录。如果 Git 在编译时不支持运行时前缀，那么编译时的前缀将被替代。在不太可能的情况下，如果需要指定一个不应该被扩展的字面路径，需要以 `./` 为前缀，就像这样： `./%（前缀）/bin`。

note: type: Plain text
en: Note that this list is non-comprehensive and not necessarily complete.  For command-specific variables, you will find a more detailed description in the appropriate manual page.
zh_HANS-CN: 请注意，这个列表并不全面，也不一定完整。 对于特定命令的变量，你会在相应的手册页中找到更详细的描述。

note: type: Plain text
en: Other git-related tools may and do use their own variables.  When inventing new variables for use in your own tool, make sure their names do not conflict with those that are used by Git itself and other popular tools, and describe them in your documentation.
zh_HANS-CN: 其他与 git 相关的工具可能也确实使用了他们自己的变量。 当发明新的变量用于自己的工具时，要确保它们的名字不与 Git 本身和其他流行的工具所使用的名字冲突，并在你的文档中描述它们。

note: type: Plain text
en: By default, Git does not create an extra merge commit when merging a commit that is a descendant of the current commit. Instead, the tip of the current branch is fast-forwarded. When set to `false`, this variable tells Git to create an extra merge commit in such a case (equivalent to giving the `--no-ff` option from the command line). When set to `only`, only such fast-forward merges are allowed (equivalent to giving the `--ff-only` option from the command line).
zh_HANS-CN: 默认情况下，当合并当前提交的后裔提交时，Git 不会创建一个额外的合并提交。相反，当前分支的顶端会被快进。当设置为 "false "时，这个变量告诉Git在这种情况下创建一个额外的合并提交（相当于在命令行中给出 "no-ff "选项）。当设置为`only`时，只允许这种快进合并（相当于从命令行给出`--ff-only`选项）。

note: type: Plain text
en: If true, this is equivalent to the --verify-signatures command line option. See linkgit:git-merge[1] for details.
zh_HANS-CN: 如果为真，这等同于 --verify-signatures 命令行选项。详见 linkgit:git-merge[1]。

note: type: Plain text
en: Whether Git detects renames.  If set to "false", rename detection is disabled. If set to "true", basic rename detection is enabled.  Defaults to the value of diff.renames.
zh_HANS-CN: Git是否会检测重名。  如果设置为 "false"，重名检测被禁用。如果设置为 "true"，则启用基本重名检测。  默认为 diff.renames 的值。

note: type: Plain text
en: Whether Git detects directory renames, affecting what happens at merge time to new files added to a directory on one side of history when that directory was renamed on the other side of history.  If merge.directoryRenames is set to "false", directory rename detection is disabled, meaning that such new files will be left behind in the old directory.  If set to "true", directory rename detection is enabled, meaning that such new files will be moved into the new directory.  If set to "conflict", a conflict will be reported for such paths.  If merge.renames is false, merge.directoryRenames is ignored and treated as false.  Defaults to "conflict".
zh_HANS-CN: Git是否检测目录重名，影响在合并时对历史一侧的目录被重命名时加入的新文件的处理。  如果merge.directoryRenames设置为 "false"，目录重名检测将被禁用，这意味着这些新文件将被遗留在旧目录中。  如果设置为 "true"，目录重名检测被启用，意味着这样的新文件将被移到新目录中。  如果设置为 "冲突"，将报告此类路径的冲突。  如果merge.renames为false，merge.directoryRenames将被忽略并被视为false。  默认为 "冲突"。

note: type: Plain text
en: Tell Git that canonical representation of files in the repository has changed over time (e.g. earlier commits record text files with CRLF line endings, but recent ones use LF line endings).  In such a repository, Git can convert the data recorded in commits to a canonical form before performing a merge to reduce unnecessary conflicts.  For more information, see section "Merging branches with differing checkin/checkout attributes" in linkgit:gitattributes[5].
zh_HANS-CN: 告诉 Git 仓库中文件的正则表示法随着时间的推移而改变（例如，早期的提交记录文本文件使用 CRLF 行结尾，但最近的提交使用 LF 行结尾）。  在这样的仓库中，Git 可以在执行合并之前将提交的数据转换为规范的形式，以减少不必要的冲突。  更多信息，请参阅 linkgit:gitattributes[5] 中的 "合并具有不同签入/签出属性的分支 "一节。

note: type: Plain text
en: Whether to print the diffstat between ORIG_HEAD and the merge result at the end of the merge.  True by default.
zh_HANS-CN: 是否在合并结束后打印ORIG_HEAD和合并结果之间的差异统计表。  默认为 "真"。

note: type: Plain text
en: When set to true, automatically create a temporary stash entry before the operation begins, and apply it after the operation ends.  This means that you can run merge on a dirty worktree.  However, use with care: the final stash application after a successful merge might result in non-trivial conflicts.  This option can be overridden by the `--no-autostash` and `--autostash` options of linkgit:git-merge[1].  Defaults to false.
zh_HANS-CN: 当设置为 "true "时，在操作开始前自动创建一个临时的储藏库条目，并在操作结束后应用它。  这意味着你可以在一个肮脏的工作树上运行merge。  然而，要小心使用：在成功的合并之后，最后的储藏库应用可能会导致非实质性的冲突。  这个选项可以被 linkgit:git-merge[1] 的 `--no-autostash` 和 `--autostash` 选项覆盖。  默认为false。

note: type: Plain text
en: Controls which merge tool is used by linkgit:git-mergetool[1].  The list below shows the valid built-in values.  Any other value is treated as a custom merge tool and requires that a corresponding mergetool.<tool>.cmd variable is defined.
zh_HANS-CN: 控制linkgit:git-mergetool[1]使用哪个合并工具。  下面的列表显示了有效的内置值。  任何其他值都被视为自定义的合并工具，需要定义一个相应的mergetool.<tool>.cmd变量。

note: type: Plain text
en: Controls which merge tool is used by linkgit:git-mergetool[1] when the -g/--gui flag is specified. The list below shows the valid built-in values.  Any other value is treated as a custom merge tool and requires that a corresponding mergetool.<guitool>.cmd variable is defined.
zh_HANS-CN: 控制linkgit:git-mergetool[1]在指定-g/-gui标志时使用的合并工具。下面的列表显示了有效的内置值。  任何其他值都被视为自定义的合并工具，需要定义一个相应的mergetool.<guitool>.cmd变量。

note: type: Plain text
en: Controls the amount of output shown by the recursive merge strategy.  Level 0 outputs nothing except a final error message if conflicts were detected. Level 1 outputs only conflicts, 2 outputs conflicts and file changes.  Level 5 and above outputs debugging information.  The default is level 2.  Can be overridden by the `GIT_MERGE_VERBOSITY` environment variable.
zh_HANS-CN: 控制递归合并策略所显示的输出量。  0级除了在检测到冲突时有一个最终的错误信息外，什么都不输出。1级只输出冲突，2级输出冲突和文件变化。  5级及以上输出调试信息。  默认是第2级。  可以通过`GIT_MERGE_VERBOSITY`环境变量覆盖。

note: type: Labeled list
en: merge.<driver>.name
zh_HANS-CN: 合并.<driver>.name

note: type: Plain text
en: Defines a human-readable name for a custom low-level merge driver.  See linkgit:gitattributes[5] for details.
zh_HANS-CN: 为自定义的低级合并驱动定义了一个人类可读的名字。  详情见 linkgit:gitattributes[5]。

note: type: Plain text
en: Defines the command that implements a custom low-level merge driver.  See linkgit:gitattributes[5] for details.
zh_HANS-CN: 定义实现自定义低级合并驱动程序的命令。详见链接git:gitattributes[5]。

note: type: Plain text
en: Names a low-level merge driver to be used when performing an internal merge between common ancestors.  See linkgit:gitattributes[5] for details.
zh_HANS-CN: 在执行共同祖先之间的内部合并时，命名一个低级别的合并驱动。  详情见 linkgit:gitattributes[5]。

note: type: Plain text
en: An element with an empty value can be used to clear the list of globs accumulated from previous configuration entries.  When there is no `merge.suppressDest` variable defined, the default value of `master` is used for backward compatibility.
zh_HANS-CN: 一个空值的元素可以用来清除以前配置项积累的globs列表。  当没有定义`merge.suppressDest`变量时，为了向后兼容，会使用默认值`master`。

note: type: Plain text
en: In addition to recognizing all date formats above, the `--date` option will also try to make sense of other, more human-centric date formats, such as relative dates like "yesterday" or "last Friday at noon".
zh_HANS-CN: 除了识别上述所有日期格式外，`--date` 选项还将尝试理解其它非标准化的日期格式，如 "昨天" 或 "上周五中午" 等相对日期。

note: type: Plain text
en: the number of deleted lines;
zh_HANS-CN: 已删除行数;

note: type: Title -
en: Generating patch text with -p
zh_HANS-CN: 使用选项 `-p` 生成补丁文本

note: type: Plain text
en: What the -p option produces is slightly different from the traditional diff format:
zh_HANS-CN: -p 选项产生的内容与传统的差异格式略有不同：

note: type: Plain text
en: It is preceded with a "git diff" header that looks like this:
zh_HANS-CN: 它前面有一个 `git diff` 头，如下所示：

note: type: Plain text
en: The `a/` and `b/` filenames are the same unless rename/copy is involved.  Especially, even for a creation or a deletion, `/dev/null` is _not_ used in place of the `a/` or `b/` filenames.
zh_HANS-CN: `a/` 和 `b/` 的文件名相同，除非涉及到重命名/复制。特别地，即使是创建或删除，也 _不_ 使用 `/dev/null` 来代替 `a/` 或 `b/` 文件名。

note: type: Plain text
en: When rename/copy is involved, `file1` and `file2` show the name of the source file of the rename/copy and the name of the file that rename/copy produces, respectively.
zh_HANS-CN: 当涉及到重命名/复制时，`file1` 和 `file2` 分别显示重命名/复制的源文件的名称和重命名/复制产生的文件的名称。

note: type: Plain text
en: It is followed by one or more extended header lines:
zh_HANS-CN: 它的后面是一个或多个扩展头信息行：

note: type: Plain text
en: old mode <mode>
    new mode <mode>
    deleted file mode <mode>
    new file mode <mode>
    copy from <path>
    copy to <path>
    rename from <path>
    rename to <path>
    similarity index <number>
    dissimilarity index <number>
    index <hash>..<hash> <mode>
zh_HANS-CN: old mode <模式>
    new mode <模式>
    deleted file mode <模式>
    new file mode <模式>
    copy from <路径>
    copy to <路径>
    rename from <路径>
    rename to <路径>
    similarity index <数字>
    dissimilarity index <数字>
    index <哈希>..<哈希> <模式>

note: type: Plain text
en: File modes are printed as 6-digit octal numbers including the file type and file permission bits.
zh_HANS-CN: 文件模式被打印为6位八进制数字，包括文件类型和文件权限位。

note: type: Plain text
en: Path names in extended headers do not include the `a/` and `b/` prefixes.
zh_HANS-CN: 扩展头信息中的路径名称不包括 `a/` 和 `b/` 前缀。

note: type: Plain text
en: The similarity index is the percentage of unchanged lines, and the dissimilarity index is the percentage of changed lines.  It is a rounded down integer, followed by a percent sign.  The similarity index value of 100% is thus reserved for two equal files, while 100% dissimilarity means that no line from the old file made it into the new one.
zh_HANS-CN: 相似性指数是未改变的行占比，而不相似性指数是改变的行占比。它是四舍五入的整数，后有百分号。因此，100%的相似度指数指为两个文件相等，而 100% 的不相似度意味着入新文件中没有旧文件中的行。

note: type: Plain text
en: The index line includes the blob object names before and after the change.  The <mode> is included if the file mode does not change; otherwise, separate lines indicate the old and the new mode.
zh_HANS-CN: 索引行包括改变前和改变后的 blob 对象名称。如果文件模式没有变化，则包含 <模式>；否则，分别显示新旧模式。

note: type: Plain text
en: Pathnames with "unusual" characters are quoted as explained for the configuration variable `core.quotePath` (see linkgit:git-config[1]).
zh_HANS-CN: 含有 "不常见" 字符的路径名会被引用，这一点在配置变量` core.quotePath` 中有所解释（见 linkgit:git-config[1]）。

note: type: Plain text
en: All the `file1` files in the output refer to files before the commit, and all the `file2` files refer to files after the commit.  It is incorrect to apply each change to each file sequentially.  For example, this patch will swap a and b:
zh_HANS-CN: 输出中所有的 `file1` 文件都是指提交前的文件，而所有的 `file2` 文件都是指提交后的文件。按顺序对每个文件进行修改是不正确的。例如，这个补丁将交换文件 a 和 b：

note: type: Plain text
en: Hunk headers mention the name of the function to which the hunk applies.  See "Defining a custom hunk-header" in linkgit:gitattributes[5] for details of how to tailor to this to specific languages.
zh_HANS-CN: 块头提到了块头所适用的函数的名称。  参见 linkgit:gitattributes[5] 中的 "定义自定义 hunk-header"，以了解如何针对特定语言进行定制。

note: type: Title -
en: Combined diff format
zh_HANS-CN: 合并的差异格式

note: type: Plain text
en: Any diff-generating command can take the `-c` or `--cc` option to produce a 'combined diff' when showing a merge. This is the default format when showing merges with linkgit:git-diff[1] or linkgit:git-show[1]. Note also that you can give suitable `--diff-merges` option to any of these commands to force generation of diffs in specific format.
zh_HANS-CN: 任何生成差异的命令都可以使用 `-c` 或 `-cc` 选项，在显示合并时产生一个 "合并差异"。当用 linkgit:git-diff[1] 或 linkgit:git-show[1] 显示合并时，这默认格式。还需要注意的是，你可以给这些命令适当的 `--diff-merges` 选项来强制生成特定格式的差异。

note: type: Plain text
en: A "combined diff" format looks like this:
zh_HANS-CN: "合并的差异" 的格式如下：

note: type: Plain text
en: It is preceded with a "git diff" header, that looks like this (when the `-c` option is used):
zh_HANS-CN: 它前面有 "git diff" 头，如下（当使用 `c` 选项时）：

note: type: Plain text
en: or like this (when the `--cc` option is used):
zh_HANS-CN: 或如下（当使用 `--cc` 选项时）：

note: type: Plain text
en: It is followed by one or more extended header lines (this example shows a merge with two parents):
zh_HANS-CN: 它的后面是一个或多个扩展头信息行（本例显示的是与两个父提交的合并）：

note: type: Plain text
en: index <hash>,<hash>..<hash>
    mode <mode>,<mode>..<mode>
    new file mode <mode>
    deleted file mode <mode>,<mode>
zh_HANS-CN: index <哈希>,<哈希>..<哈希>
    mode <模式>,<模式>..<模式>
    new file mode <模式>
    deleted file mode <模式>,<模式>

note: type: Plain text
en: It is followed by two-line from-file/to-file header
zh_HANS-CN: 它的后面是两行源文件/目标文件的头信息

note: type: Plain text
en: Similar to two-line header for traditional 'unified' diff format, `/dev/null` is used to signal created or deleted files.
zh_HANS-CN: 类似于传统的 "统一" 差异格式的双行头，`/dev/null` 用来表示创建或删除的文件。

note: type: Plain text
en: However, if the --combined-all-paths option is provided, instead of a two-line from-file/to-file you get a N+1 line from-file/to-file header, where N is the number of parents in the merge commit
zh_HANS-CN: 但是，如果提供了 --combined-all-paths 选项，你就会得到一个 N+1 行的源文件/目标文件头，其中 N 是合并提交中的父提交数量

note: type: Plain text
en: This extended format can be useful if rename or copy detection is active, to allow you to see the original name of the file in different parents.
zh_HANS-CN: 如果重命名或复制检测处于活动状态，这种扩展格式可能很有用，可以让你在不同的父提交中看到文件的原始名称。

note: type: Plain text
en: Chunk header format is modified to prevent people from accidentally feeding it to `patch -p1`. Combined diff format was created for review of merge commit changes, and was not meant to be applied. The change is similar to the change in the extended 'index' header:
zh_HANS-CN: 修改了文件块头信息的格式，以防止不小心将其送入 `patch -p1`。合并的差异格式是为审查合并提交的修改而创建的，并不是为了应用。这个变化类似于扩展的 "索引" 头信息的变化：

note: type: Plain text
en: There are (number of parents + 1) `@` characters in the chunk header for combined diff format.
zh_HANS-CN: 块中有（父提交数量+1）`@` 字符，用于合并的差异格式。

note: type: Plain text
en: Unlike the traditional 'unified' diff format, which shows two files A and B with a single column that has `-` (minus -- appears in A but removed in B), `+` (plus -- missing in A but added to B), or `" "` (space -- unchanged) prefix, this format compares two or more files file1, file2,... with one file X, and shows how X differs from each of fileN.  One column for each of fileN is prepended to the output line to note how X's line is different from it.
zh_HANS-CN: 与传统的 "统一" 差异格式不同，这种格式显示两个文件 A 和 B 的列，其中有 `-`（减号 -- 在 A 中出现，但在 B 中删除），`+`（加号 -- 在 A 中缺少，但在 B 中增加），或 `" "`（空格 -- 不变）前缀，这种格式比较两个或多个文件与一个文件 X，并显示 X 与其中每个文件的差异。文件中的每一个都有一列被前置在输出行中，以指出 X 的行与它的不同之处。

note: type: Plain text
en: A `-` character in the column N means that the line appears in fileN but it does not appear in the result.  A `+` character in the column N means that the line appears in the result, and fileN does not have that line (in other words, the line was added, from the point of view of that parent).
zh_HANS-CN: 第 N 列中的 `-` 字符意味着该行出现在文件 N 中，但它没有出现在结果文件中。第 N 列中的 `+` 字符意味着该行出现在结果文件中，而文件 N 中没有该行（换句话说，从该父提交的角度来看，该行是被添加的）。

note: type: Plain text
en: In the above example output, the function signature was changed from both files (hence two `-` removals from both file1 and file2, plus `++` to mean one line that was added does not appear in either file1 or file2).  Also eight other lines are the same from file1 but do not appear in file2 (hence prefixed with `+`).
zh_HANS-CN: 在上面的输出示例中，两个文件中的函数签名都被改变了（因此从文件 1 和文件 2 中都有表示删除的 `-`，而 `++` 表示被添加的一行没有出现在文件 1 或文件 2 中）。另外还有 8 行与文件 1 中的相同，但没有出现在文件 2 中（因此前缀为 `+`）。

note: type: Plain text
en: When shown by `git diff-tree -c`, it compares the parents of a merge commit with the merge result (i.e. file1..fileN are the parents).  When shown by `git diff-files -c`, it compares the two unresolved merge parents with the working tree file (i.e. file1 is stage 2 aka "our version", file2 is stage 3 aka "their version").
zh_HANS-CN: 当用 `git diff-tree -c` 显示时，它将合并提交的父提交文件与合并结果进行比较（即文件 1 ... 文件 N 是父提交文件）。当用 `git diff-files -c` 显示时，它将两个未解决的合并父提交文件与工作树文件进行比较（即文件 1 是阶段 2 ，又称 "我们的版本"，文件 2 是阶段 3，又称 "他们的版本"）。

note: type: Plain text
en: Generate plain patches without any diffstats.
zh_HANS-CN: 生成没有任何差异状态(diffstats)的普通补丁。

note: type: Plain text
en: <<generate_patch_text_with_p, "Generating patch text with -p">>).
zh_HANS-CN: 使用选项 `-p` 生成补丁文本。

note: type: Plain text
en: Specify diff format to be used for merge commits. Default is {diff-merges-default} unless `--first-parent` is in use, in which case `first-parent` is the default.
zh_HANS-CN: 指定合并提交时使用的差异格式。默认为 {diff-merges-default}，但当使用 `--first-parent` 选项时，默认为 `first-parent`。

note: type: Plain text
en: Disable output of diffs for merge commits. Useful to override implied value.
zh_HANS-CN: 禁用合并提交时的差异输出。对覆盖隐含值很有用。

note: type: Plain text
en: This option makes merge commits show the full diff with respect to the first parent only.
zh_HANS-CN: 此选项使合并提交只显示与第一个父提交之间的完整差异。

note: type: Plain text
en: The output emitted when this option is used is subject to change, and so is its interaction with other options (unless explicitly documented).
zh_HANS-CN: 使用该选项时发出的输出是可以改变的，它与其他选项的互动也是可以改变的（除非有明确的记录）。

note: type: Plain text
en: With this option, diff output for a merge commit shows the differences from each of the parents to the merge result simultaneously instead of showing pairwise diff between a parent and the result one at a time. Furthermore, it lists only files which were modified from all parents. `-c` implies `-p`.
zh_HANS-CN: 使用此选项，合并提交的差异输出将同时显示每个父提交与合并结果的差异，而不是一次显示一个父提交与结果之间的成对差异 。此外，它只列出所有父提交中修改的文件。`-c` 选项暗含 `-p` 选项。

note: type: Labeled list
en: --stat[=<width>[,<name-width>[,<count>]]]
zh_HANS-CN: --stat[=<宽度>[,<名称宽度>[,<数值>]]]

note: type: Plain text
en: Synonym for --dirstat=cumulative
zh_HANS-CN: --dirstat=cumulative 同义

note: type: Plain text
en: Synonym for `-p --stat`.
zh_HANS-CN: 同义词 '-p --stat'。

note: type: Plain text
en: Show only names of changed files. The file names are often encoded in UTF-8.  For more information see the discussion about encoding in the linkgit:git-log[1] manual page.
zh_HANS-CN: 只显示更改过的文件的名称。文件名通常以 UTF-8 编码。  更多信息见 linkgit:git-log[1] 手册页中关于编码的讨论。

note: type: Labeled list
en: --color-moved[=<mode>]
zh_HANS-CN: --color-moved[=<模式>]

note: type: Labeled list
en: --color-moved-ws=<modes>
zh_HANS-CN: --color-moved-ws=<模式>

note: type: Labeled list
en: --color-words[=<regex>]
zh_HANS-CN: --color-words[=<正则表达式>]

note: type: Plain text
en: 	If `n` is specified, it is a threshold on the similarity
    	index (i.e. amount of addition/deletions compared to the
    	file's size). For example, `-M90%` means Git should consider a
    	delete/add pair to be a rename if more than 90% of the file
    	hasn't changed.  Without a `%` sign, the number is to be read as
    	a fraction, with a decimal point before it.  I.e., `-M5` becomes
    	0.5, and is thus the same as `-M50%`.  Similarly, `-M05` is
    	the same as `-M5%`.  To limit detection to exact renames, use
    	`-M100%`.  The default similarity index is 50%.
zh_HANS-CN: 	如果指定了 `n`，则其为相似度指数阈值（即相比于文件大小的增/删量）。
    	例如，`-M90％` 表示如果文件90％以上的内容没有更改，则 Git 应将删除/添加对视为重命名。
    	如果没有 `％` 符号，则该数字应作为小数读取，并在其前面加上小数点。
     	即 `-M5` 变为 0.5，因此与 `-M50％` 相同。 同样，`-M05` 与 `-M5％` 相同。
     	要将检测限制为精确的重命名，请使用 `-M100％`。 默认相似度指数为50％。

note: type: Plain text
en: Omit the preimage for deletes, i.e. print only the header but not the diff between the preimage and `/dev/null`. The resulting patch is not meant to be applied with `patch` or `git apply`; this is solely for people who want to just concentrate on reviewing the text after the change. In addition, the output obviously lacks enough information to apply such a patch in reverse, even manually, hence the name of the option.
zh_HANS-CN: 删除时省略原内容，即只打印头信息，而不打原内容和 `/dev/null` 之间的差异。所产生的补丁并不是要用于 `patch` 或 `git apply`；这只是为了让人们只专注于审查修改后的文本。此外，输出结果显然缺乏足够的信息来反转，或手动应用这样一个补丁，因此这个选项的名称如此。

note: type: Plain text
en: When used together with `-B`, omit also the preimage in the deletion part of a delete/create pair.
zh_HANS-CN: 当与 `-B` 一起使用时，也省略删除/创建对中删除部分的原内容。

note: type: Labeled list
en: -l<num>
zh_HANS-CN: -l<数量>

note: type: Plain text
en: Select only files that are Added (`A`), Copied (`C`), Deleted (`D`), Modified (`M`), Renamed (`R`), have their type (i.e. regular file, symlink, submodule, ...) changed (`T`), are Unmerged (`U`), are Unknown (`X`), or have had their pairing Broken (`B`).  Any combination of the filter characters (including none) can be used.  When `*` (All-or-none) is added to the combination, all paths are selected if there is any file that matches other criteria in the comparison; if there is no file that matches other criteria, nothing is selected.
zh_HANS-CN: 只选择添加（`A`）、复制（`C`）、删除（`D`）、修改（`M`）、重命名（`R`）、类型（即常规文件、符号链接、子模块......）改变（`T`）、未合并（`U`）、未知（`X`）或配对被破坏（`B`）的文件。可以使用过滤字符的任何组合（包括空）。当组合中加入 `*`（全部或空）时，如果在比较中有任何文件与其他条件匹配，则选择所有路径；如果没有符合其他条件的文件，则不会选择任何内容。

note: type: Plain text
en: Also, these upper-case letters can be downcased to exclude.  E.g.  `--diff-filter=ad` excludes added and deleted paths.
zh_HANS-CN: 另外，这些大写字母也可以通过使用小写排除。例如：`--diff-filter=ad` 排除添加和删除的路径。

note: type: Plain text
en: Look for differences that change the number of occurrences of the specified string (i.e. addition/deletion) in a file.  Intended for the scripter's use.
zh_HANS-CN: 寻找改变文件中指定字符串出现次数的差异（即增加/删除）。供脚本编写者使用。

note: type: Plain text
en: Binary files are searched as well.
zh_HANS-CN: 二进制文件也会被搜索到。

note: type: Labeled list
en: -G<regex>
zh_HANS-CN: -G<正则表达式>

note: type: Plain text
en: Look for differences whose patch text contains added/removed lines that match <regex>.
zh_HANS-CN: 查找其补丁文本包含与 <正则表达式> 匹配的添加/删除行的差异。

note: type: Plain text
en: To illustrate the difference between `-S<regex> --pickaxe-regex` and `-G<regex>`, consider a commit with the following diff in the same file:
zh_HANS-CN: 为了说明 `-S<正则表达式> --pickaxe-regex` 和 `-G<正则表达式>` 之间的区别，假设某次提交在同一文件中有以下差异：

note: type: Plain text
en: While `git log -G"frotz\(nitfol"` will show this commit, `git log -S"frotz\(nitfol" --pickaxe-regex` will not (because the number of occurrences of that string did not change).
zh_HANS-CN: `git log -G "frotz\(nitfol"` 会显示这次提交，但 `git log -S "frotz\(nitfol" --pickaxe-regex` 不会显示（因为该字符串的出现次数没有改变）。

note: type: Plain text
en: See the 'pickaxe' entry in linkgit:gitdiffcore[7] for more information.
zh_HANS-CN: 更多信息请参见 linkgit:gitdiffcore[7] 中的 'pickaxe' 条目。

note: type: Labeled list
en: --find-object=<object-id>
zh_HANS-CN: --find-object=<对象ID>

note: type: Plain text
en: Look for differences that change the number of occurrences of the specified object. Similar to `-S`, just the argument is different in that it doesn't search for a specific string but for a specific object id.
zh_HANS-CN: 查找指定对象出现次数的差异。与 `-S` 类似，只是参数不同：它不搜索特定的字符串，而是搜索特定的对象 id。

note: type: Plain text
en: The object can be a blob or a submodule commit. It implies the `-t` option in `git-log` to also find trees.
zh_HANS-CN: 该对象可以是一个 blob 或一个子模块提交。它意味着 `git-log` 中的 `-t` 选项也能找到工作树。

note: type: Plain text
en: When `-S` or `-G` finds a change, show all the changes in that changeset, not just the files that contain the change in <string>.
zh_HANS-CN: 当使用 `-S` 或 `-G` 选项找到一个更改时，显示该更改集中的所有更改，而不仅仅是显示包含 <string> 更改的文件。

note: type: Plain text
en: Treat the <string> given to `-S` as an extended POSIX regular expression to match.
zh_HANS-CN: 将 `-S` 选项的 <string> 参数当作扩展的 POSIX 正则表达式来匹配。

note: type: Labeled list
en: -O<orderfile>
zh_HANS-CN: -O<顺序控制文件>

note: type: Plain text
en: Control the order in which files appear in the output.  This overrides the `diff.orderFile` configuration variable (see linkgit:git-config[1]).  To cancel `diff.orderFile`, use `-O/dev/null`.
zh_HANS-CN: 控制文件在输出中出现的顺序。这将覆盖 `diff.orderFile` 配置变量（参见 linkgit:git-config[1]）。要取消 `diff.orderFile`，请使用 `-O/dev/null`。

note: type: Plain text
en: The output order is determined by the order of glob patterns in <orderfile>.  All files with pathnames that match the first pattern are output first, all files with pathnames that match the second pattern (but not the first) are output next, and so on.  All files with pathnames that do not match any pattern are output last, as if there was an implicit match-all pattern at the end of the file.  If multiple pathnames have the same rank (they match the same pattern but no earlier patterns), their output order relative to each other is the normal order.
zh_HANS-CN: 输出顺序由 <顺序控制文件> 中的 glob 模式的顺序决定。所有路径名与第一个模式匹配的文件首先输出，路径名与第二个模式匹配（但不与第一个模式匹配）的文件其次输出，以此类推。所有路径名与任何模式匹配的文件会最后输出，就像在文件末尾有一个隐含的全部匹配模式。如果多个路径名具有相同的等级（它们匹配相同的模式，但没有匹配先前的模式），它们相对于彼此的输出顺序是正常的。

note: type: Plain text
en: <orderfile> is parsed as follows:
zh_HANS-CN: <顺序控制文件> 格式如下：

note: type: Plain text
en: Blank lines are ignored, so they can be used as separators for readability.
zh_HANS-CN: 空白行会被忽略，因此可以用它们作为分隔符，以保证可读性。

note: type: Plain text
en: Lines starting with a hash ("`#`") are ignored, so they can be used for comments.  Add a backslash ("`\`") to the beginning of the pattern if it starts with a hash.
zh_HANS-CN: 以井号（"`#`"）开头的行会被忽略，所以它们可以用来做注释。如果模式以井号开头，则需要在模式的开头加上反斜杠（"`\`"）。

note: type: Plain text
en: Each other line contains a single pattern.
zh_HANS-CN: 每一行都包含一个模式。

note: type: Plain text
en: Patterns have the same syntax and semantics as patterns used for fnmatch(3) without the FNM_PATHNAME flag, except a pathname also matches a pattern if removing any number of the final pathname components matches the pattern.  For example, the pattern "`foo*bar`" matches "`fooasdfbar`" and "`foo/bar/baz/asdf`" but not "`foobarx`".
zh_HANS-CN: 模式的语法和语义与 fnmatch(3) 中使用的相同，不包括 FNM_PATHNAME 标志，但在删除路径名中结尾任意几个成分后匹配的情况下例外。例如，模式 "`foo*bar`" 匹配 "`fooasdfbar`" 和 "`foo/bar/baz/asdf`"，但不匹配 "`foobarx`"。

note: type: Plain text
en: Discard the files before the named <file> from the output (i.e. 'skip to'), or move them to the end of the output (i.e. 'rotate to').  These were invented primarily for use of the `git difftool` command, and may not be very useful otherwise.
zh_HANS-CN: 从输出中丢弃命名为 <文件> 之前的文件（即 '跳过'），或将它们移到输出的末尾（即 '旋转'）。这些选项主要是为了使用 `git difftool` 命令而添加的，在其他情况下可能不是很有用。

note: type: Plain text
en: Swap two inputs; that is, show differences from index or on-disk file to tree contents.
zh_HANS-CN: 交换两个输入；即显示从索引或磁盘文件到目录树内容的差异。

note: type: Labeled list
en: --relative[=<path>]
zh_HANS-CN: --relative[=<路径>]

note: type: Plain text
en: When run from a subdirectory of the project, it can be told to exclude changes outside the directory and show pathnames relative to it with this option.  When you are not in a subdirectory (e.g. in a bare repository), you can name which subdirectory to make the output relative to by giving a <path> as an argument.  `--no-relative` can be used to countermand both `diff.relative` config option and previous `--relative`.
zh_HANS-CN: 当从项目的子目录中运行时，可以排除目录外的变化，并通过这个选项显示相对于它的路径名。当你不在子目录中时（例如在纯仓库中），你可以通过 <路径> 参数来指明要使输出相对于哪个子目录。`--no-relative` 可以用来取消 `diff.relative`配置选项和之前的 `--relative` 选项。

note: type: Plain text
en: Treat all files as text.
zh_HANS-CN: 将一切输入文件视为文本。

note: type: Plain text
en: Ignore carriage-return at the end of line when doing a comparison.
zh_HANS-CN: 在进行比较时，忽略行末的回车。

note: type: Plain text
en: Ignore whitespace when comparing lines.  This ignores differences even if one line has whitespace where the other line has none.
zh_HANS-CN: 比较行时忽略空格。即使一行有空格而另一行没有空格，也会忽略差异。

note: type: Plain text
en: Ignore changes whose lines are all blank.
zh_HANS-CN: 忽略空白行的变化。

note: type: Plain text
en: Show the context between diff hunks, up to the specified number of lines, thereby fusing hunks that are close to each other.  Defaults to `diff.interHunkContext` or 0 if the config option is unset.
zh_HANS-CN: 显示块差异之间的上下文，最多显示指定的行数，从而合并彼此接近的块。 默认认为 `diff.interHunkContext`，如果配置选项未设置，则默认为0。

note: type: Plain text
en: Show whole function as context lines for each change.  The function names are determined in the same way as `git diff` works out patch hunk headers (see 'Defining a custom hunk-header' in linkgit:gitattributes[5]).
zh_HANS-CN: 在每个修改中的上下文行显示整个函数。函数名称的确定方式与 `git diff` 计算补丁头的方式相同（参见 linkgit:gitattributes[5] 中的 '自定义区块头' ）。

note: type: Plain text
en: Make the program exit with codes similar to diff(1).  That is, it exits with 1 if there were differences and 0 means no differences.
zh_HANS-CN: 让程序以类似 diff(1) 的代码退出。也就是说，如果有差异则返回1，否则返回0。

note: type: Plain text
en: Disable all output of the program. Implies `--exit-code`.
zh_HANS-CN: 禁用程序的所有输出。暗含 `--exit-code`。

note: type: Plain text
en: Disallow external diff drivers.
zh_HANS-CN: 禁止使用外部差异器。

note: type: Plain text
en: Allow (or disallow) external text conversion filters to be run when comparing binary files. See linkgit:gitattributes[5] for details. Because textconv filters are typically a one-way conversion, the resulting diff is suitable for human consumption, but cannot be applied. For this reason, textconv filters are enabled by default only for linkgit:git-diff[1] and linkgit:git-log[1], but not for linkgit:git-format-patch[1] or diff plumbing commands.
zh_HANS-CN: 允许（或不允许）在比较二进制文件时运行外部文本转换过滤器。详情请参见 linkgit:gitattributes[5] 。由于文本转换过滤器通常是单向转换，因此产生的差异适合人类用户使用，但不能应用（apply）。因此默认情况下，只有 linkgit:git-diff[1] 和 linkgit:git-log[1] 启用文本转换过滤器，而 linkgit:git-format-patch[1] 或 diff plumbing 命令则不启用。

note: type: Plain text
en: Ignore changes to submodules in the diff generation. <when> can be either "none", "untracked", "dirty" or "all", which is the default.  Using "none" will consider the submodule modified when it either contains untracked or modified files or its HEAD differs from the commit recorded in the superproject and can be used to override any settings of the 'ignore' option in linkgit:git-config[1] or linkgit:gitmodules[5]. When "untracked" is used submodules are not considered dirty when they only contain untracked content (but they are still scanned for modified content). Using "dirty" ignores all changes to the work tree of submodules, only changes to the commits stored in the superproject are shown (this was the behavior until 1.7.0). Using "all" hides all changes to submodules.
zh_HANS-CN: 在生成差异时忽略子模块的修改。<when> 可以是 "none"、"untracked"、"dirty " 或 "all"，"all" 是默认选项。使用 "none" 会在子模块包含未跟踪或修改的文件，或者它的HEAD 与上级项目中记录的提交不同时，认为它被修改了，并且可以用来覆盖 linkgit:git-config[1] 或 linkgit:gitmodules[5] 中 '忽略' 选项的设置。当使用 "untracked" 时，当子模块只包含未跟踪的内容时，它们不会被认为是有改动的（但它们仍然会被扫描是否有被修改的内容）。使用 "dirty" 会忽略所有对子模块工作树的修改，只有存储在上级项目中的提交的修改才会被显示出来（这是在1.7.0之前的行为）。使用 "all" 会隐藏所有对子模块的修改。

note: type: Plain text
en: Show the given source prefix instead of "a/".
zh_HANS-CN: 显示给定的源前缀而不是 "a/"。

note: type: Plain text
en: Show the given destination prefix instead of "b/".
zh_HANS-CN: 显示给定的目标前缀，而不是“b/”。

note: type: Plain text
en: Do not show any source or destination prefix.
zh_HANS-CN: 不显示任何源或目的前缀。

note: type: Plain text
en: Use the default source and destination prefixes ("a/" and "b/").  This is usually the default already, but may be used to override config such as `diff.noprefix`.
zh_HANS-CN: 使用默认的源和目标前缀（"a/"和 "b/"）。  这通常已经是默认的，但可以用来覆盖配置，如 `diff.noprefix`。

note: type: Plain text
en: Prepend an additional prefix to every line of output.
zh_HANS-CN: 在每一行输出前加上一个额外的前缀。

note: type: Plain text
en: By default entries added by "git add -N" appear as an existing empty file in "git diff" and a new file in "git diff --cached".  This option makes the entry appear as a new file in "git diff" and non-existent in "git diff --cached". This option could be reverted with `--ita-visible-in-index`. Both options are experimental and could be removed in future.
zh_HANS-CN: 默认情况下，通过 "git add -N" 添加的条目在 "git diff" 中显示为现有的空文件，在 "git diff --cached" 中显示为新文件。这个选项使得条目在 "git diff" 中显示为一个新文件，而在 "git diff --cached" 中显示为不存在的文件。这个选项可以用 `--ita-visible-in-index` 来还原。这两个选项都是试验性的，将来可能会被删除。

note: type: Plain text
en: For more detailed explanation on these common options, see also linkgit:gitdiffcore[7].
zh_HANS-CN: 关于这些常用选项的更多解释，请参见 linkgit:gitdiffcore[7]。

note: type: Plain text
en: Fetch all remotes.
zh_HANS-CN: 抓取所有远程。

note: type: Plain text
en: Append ref names and object names of fetched refs to the existing contents of `.git/FETCH_HEAD`.  Without this option old data in `.git/FETCH_HEAD` will be overwritten.
zh_HANS-CN: 在 `.git/FETCH_HEAD` 的现有内容中添加获取的引用名称和对象名称。  如果没有这个选项，`.git/FETCH_HEAD` 中的旧数据将被覆盖。

note: type: Plain text
en: Use an atomic transaction to update local refs. Either all refs are updated, or on error, no refs are updated.
zh_HANS-CN: 使用一个原子事务来更新本地索引。要么所有的引用都被更新，要么在出错时，没有引用被更新。

note: type: Plain text
en: Limit fetching to the specified number of commits from the tip of each remote branch history. If fetching to a 'shallow' repository created by `git clone` with `--depth=<depth>` option (see linkgit:git-clone[1]), deepen or shorten the history to the specified number of commits. Tags for the deepened commits are not fetched.
zh_HANS-CN: 限制从每个远程分支历史的顶端获取指定数量的提交。如果获取的是由 `git clone` 创建的 '浅层' 仓库，并使用 `--depth=<depth>` 选项（见 linkgit:git-clone[1]），则加深或缩短历史，达到指定数量的提交。深化后的提交的标签不会被获取。

note: type: Labeled list
en: --deepen=<depth>
zh_HANS-CN: --deepen=<深度>

note: type: Plain text
en: Similar to --depth, except it specifies the number of commits from the current shallow boundary instead of from the tip of each remote branch history.
zh_HANS-CN: 与--depth类似，只是它指定了从当前浅层边界开始的提交数量，而不是从每个远程分支历史的顶端开始。

note: type: Labeled list
en: --shallow-since=<date>
zh_HANS-CN: --shallow-since=<日期>

note: type: Plain text
en: Deepen or shorten the history of a shallow repository to include all reachable commits after <date>.
zh_HANS-CN: 加深或缩短浅层仓库的历史，包括<日期>之后所有可触及的提交。

note: type: Labeled list
en: --shallow-exclude=<revision>
zh_HANS-CN: --shallow-exclude=<修订版本>

note: type: Plain text
en: Deepen or shorten the history of a shallow repository to exclude commits reachable from a specified remote branch or tag.  This option can be specified multiple times.
zh_HANS-CN: 深化或缩短浅层版本库的历史，以排除从指定的远程分支或标记中可以到达的提交。  这个选项可以指定多次。

note: type: Plain text
en: If the source repository is complete, convert a shallow repository to a complete one, removing all the limitations imposed by shallow repositories.
zh_HANS-CN: 如果源仓库是完整的，将浅层资源库转换为完整的仓库，消除浅层仓库带来的所有限制。

note: type: Plain text
en: If the source repository is shallow, fetch as much as possible so that the current repository has the same history as the source repository.
zh_HANS-CN: 如果源仓库是浅层的，尽可能多的获取，使当前仓库的历史与源仓库相同。

note: type: Plain text
en: By default when fetching from a shallow repository, `git fetch` refuses refs that require updating .git/shallow. This option updates .git/shallow and accept such refs.
zh_HANS-CN: 默认情况下，当从浅层仓库获取时，`git fetch` 会拒绝需要更新 .git/shallow 的引用。这个选项更新了 .git/shallow 并接受这样的引用。

note: type: Plain text
en: By default, Git will report, to the server, commits reachable from all local refs to find common commits in an attempt to reduce the size of the to-be-received packfile. If specified, Git will only report commits reachable from the given tips.  This is useful to speed up fetches when the user knows which local ref is likely to have commits in common with the upstream ref being fetched.
zh_HANS-CN: 默认情况下，Git 会向服务器报告从所有本地引用中可触及的提交，以寻找共同的提交，试图减少待接收的打包文件的大小。如果指定的话，Git将只报告从给定提示中的可达提交。  当用户知道哪个本地引用可能与被获取的上游引用有共同的提交时，这会加快抓取文件的速度。

note: type: Plain text
en: This option may be specified more than once; if so, Git will report commits reachable from any of the given commits.
zh_HANS-CN: 这个选项可以指定多次；如果是这样，Git将报告从任何一个给定的提交中可达提交。

note: type: Plain text
en: The argument to this option may be a glob on ref names, a ref, or the (possibly abbreviated) SHA-1 of a commit. Specifying a glob is equivalent to specifying this option multiple times, one for each matching ref name.
zh_HANS-CN: 这个选项的参数可以是一个引用名称的通配符，一个引用，或者一个提交的SHA-1（可能是缩写的）。指定一个通配符相当于多次指定这个选项，为每个匹配的引用名称指定该选项。

note: type: Plain text
en: See also the `fetch.negotiationAlgorithm` and `push.negotiate` configuration variables documented in linkgit:git-config[1], and the `--negotiate-only` option below.
zh_HANS-CN: 参见 linkgit:git-config[1] 中记录的 `fetch.negotiAlgorithm` 和 `push.negoti` 配置变量，以及下面的 `--negotiate-only` 选项。

note: type: Plain text
en: Do not fetch anything from the server, and instead print the ancestors of the provided `--negotiation-tip=*` arguments, which we have in common with the server.
zh_HANS-CN: 不从服务器获取任何东西，而是打印所提供的 `--negotiation-tip=*` 参数与服务器上的共同祖先。

note: type: Plain text
en: This is incompatible with `--recurse-submodules=[yes|on-demand]`.  Internally this is used to implement the `push.negotiate` option, see linkgit:git-config[1].
zh_HANS-CN: 这与 `--recurse-submodules=[yes|on-demand]` 不兼容。  在内部，这被用来实现 `push.negotiate` 选项，见linkgit:git-config[1]。

note: type: Plain text
en: Show what would be done, without making any changes.
zh_HANS-CN: 显示会做什么，而不做任何改变。

note: type: Plain text
en: Print the output to standard output in an easy-to-parse format for scripts. See section OUTPUT in linkgit:git-fetch[1] for details.
zh_HANS-CN: 将输出结果以易于解析的格式打印到标准输出，供脚本使用。详情见 linkgit:git-fetch[1] 中的输出部分。

note: type: Plain text
en: This is incompatible with `--recurse-submodules=[yes|on-demand]` and takes precedence over the `fetch.output` config option.
zh_HANS-CN: 这与 `--recurse-submodules=[yes|on-demand]` 选项不兼容，并且优先于 `fetch.output` 配置选项。

note: type: Plain text
en: Write the list of remote refs fetched in the `FETCH_HEAD` file directly under `$GIT_DIR`.  This is the default.  Passing `--no-write-fetch-head` from the command line tells Git not to write the file.  Under `--dry-run` option, the file is never written.
zh_HANS-CN: 直接在`$GIT_DIR`下的`FETCH_HEAD`文件中写入获取的远程引用列表。  这是默认的。  从命令行传递`--no-write-fetch-head`，告诉Git不要写入该文件。  在`--dry-run`选项下，该文件永远不会被写入。

note: type: Plain text
en: When 'git fetch' is used with `<src>:<dst>` refspec it may refuse to update the local branch as discussed
zh_HANS-CN: 正如讨论的那样，当 'git fetch' 与 `<src>:<dst>` 引用规范一起使用时，它可能会拒绝更新本地分支

note: type: Plain text
en: 	in the `<refspec>` part of the linkgit:git-fetch[1]
    	documentation.
zh_HANS-CN: 	在linkgit:git-fetch[1]的`<引用规范>`部分。
    	文档中。

note: type: Plain text
en: 	in the `<refspec>` part below.
zh_HANS-CN: 	在下面的 `<引用规范>` 部分。

note: type: Plain text
en: 	This option overrides that check.
zh_HANS-CN: 	这个选项覆盖了这个检查。

note: type: Plain text
en: Keep downloaded pack.
zh_HANS-CN: 保存下载的包。

note: type: Plain text
en: Allow several <repository> and <group> arguments to be specified. No <refspec>s may be specified.
zh_HANS-CN: 允许指定几个 <仓库> 和 <group> 参数。不可以指定 <引用规范>。

note: type: Plain text
en: Run `git maintenance run --auto` at the end to perform automatic repository maintenance if needed. (`--[no-]auto-gc` is a synonym.)  This is enabled by default.
zh_HANS-CN: 在最后运行 `git maintenance run --auto`，以在需要时执行自动仓库维护。（与 "--[no-]auto-gc" 选项效果一样。）这个功能默认启用。

note: type: Plain text
en: Write a commit-graph after fetching. This overrides the config setting `fetch.writeCommitGraph`.
zh_HANS-CN: 在获取后写一个提交图。这会覆盖 `fetch.writeCommitGraph` 配置选项。

note: type: Plain text
en: Before fetching, remove any remote-tracking references that no longer exist on the remote.  Tags are not subject to pruning if they are fetched only because of the default tag auto-following or due to a --tags option.  However, if tags are fetched due to an explicit refspec (either on the command line or in the remote configuration, for example if the remote was cloned with the --mirror option), then they are also subject to pruning. Supplying `--prune-tags` is a shorthand for providing the tag refspec.
zh_HANS-CN: 在获取之前，删除任何不再存在于远程的远程跟踪引用。  如果只是因为默认的标签自动跟踪或者因为 --tags 选项而获取标签，则不需要剪枝。  然而，如果标签是由于明确的引用规范（无论是在命令行还是在远程配置中，例如，如果远程是用 --mirror 选项克隆的）而被获取的，那么它们也会被剪除。提供 `--prune-tags` 是提供标签引用规范的速记方法。

note: type: Plain text
en: See the PRUNING section below for more details.
zh_HANS-CN: 更多细节见下面的 剪枝 部分。

note: type: Plain text
en: Before fetching, remove any local tags that no longer exist on the remote if `--prune` is enabled. This option should be used more carefully, unlike `--prune` it will remove any local references (local tags) that have been created. This option is a shorthand for providing the explicit tag refspec along with `--prune`, see the discussion about that in its documentation.
zh_HANS-CN: 在获取之前，如果 `--prune` 被启用，则删除任何不再存在于远程的本地标签。这个选项应该更谨慎使用，与`--prune`不同，它将删除任何已经创建的本地引用（本地标签）。这个选项是与`--prune`一起提供明确的标签引用规范的速记形式，见其文档中关于这个的讨论。

note: type: Plain text
en: By default, tags that point at objects that are downloaded from the remote repository are fetched and stored locally.  This option disables this automatic tag following. The default behavior for a remote may be specified with the remote.<name>.tagOpt setting. See linkgit:git-config[1].
zh_HANS-CN: 默认情况下，指向从远程仓库下载的对象的标签会被获取并存储到本地。  这个选项禁用了这种自动标记跟踪。远程的默认行为可以通过 remote.<远程名称>.tagOpt 设置来指定。参见 linkgit:git-config[1]。

note: type: Plain text
en: Instead of negotiating with the server to avoid transferring commits and associated objects that are already present locally, this option fetches all objects as a fresh clone would. Use this to reapply a partial clone filter from configuration or using `--filter=` when the filter definition has changed. Automatic post-fetch maintenance will perform object database pack consolidation to remove any duplicate objects.
zh_HANS-CN: 这个选项不是与服务器协商以避免传输本地已经存在的提交和相关对象，而是像一个新的克隆那样获取所有对象。当过滤器定义发生变化时，使用此选项重新应用配置中的部分克隆过滤器或使用 `--filter=`。自动获取后的维护将执行对象数据库包的整合，以删除任何重复的对象。

note: type: Plain text
en: When fetching refs listed on the command line, use the specified refspec (can be given more than once) to map the refs to remote-tracking branches, instead of the values of `remote.*.fetch` configuration variables for the remote repository.  Providing an empty `<refspec>` to the `--refmap` option causes Git to ignore the configured refspecs and rely entirely on the refspecs supplied as command-line arguments. See section on "Configured Remote-tracking Branches" for details.
zh_HANS-CN: 当获取命令行上列出的引用时，使用指定的引用规范（可以是多个）来映射引用到远程跟踪分支，而不是远程仓库的 `remote.*.fetch` 配置变量的值。  为 `--refmap` 选项提供一个空的 `<引用规范>` 会导致Git忽略配置的引用规范，而完全依赖作为命令行参数提供的引用规范。详见 "配置的远程跟踪分支" 一节。

note: type: Plain text
en: Fetch all tags from the remote (i.e., fetch remote tags `refs/tags/*` into local tags with the same name), in addition to whatever else would otherwise be fetched.  Using this option alone does not subject tags to pruning, even if --prune is used (though tags may be pruned anyway if they are also the destination of an explicit refspec; see `--prune`).
zh_HANS-CN: 从远程获取所有标签（即，将远程标签 `refs/tags/*` 获取为同名的本地标签），除此之外，还可以获取其他东西。  单独使用这个选项，即使使用了 --prune，也不会对标签进行修剪（尽管标签是一个明确了无论如何也要删除的引用规范目标，见 `--prune` 选项）。

note: type: Plain text
en: This option controls if and under what conditions new commits of submodules should be fetched too. When recursing through submodules, `git fetch` always attempts to fetch "changed" submodules, that is, a submodule that has commits that are referenced by a newly fetched superproject commit but are missing in the local submodule clone. A changed submodule can be fetched as long as it is present locally e.g.  in `$GIT_DIR/modules/` (see linkgit:gitsubmodules[7]); if the upstream adds a new submodule, that submodule cannot be fetched until it is cloned e.g. by `git submodule update`.
zh_HANS-CN: 这个选项控制是否以及在什么条件下，子模块的新提交也应该被获取。当遍历子模块时，`git fetch` 总是试图获取 "改变的" 子模块，也就是说，一个子模块的提交被新获取的父项目提交所引用，但在本地的子模块克隆中却没有。一个改变了的子模块可以被获取，只要它在本地存在，例如在`$GIT_DIR/modules/`（见linkgit:gitsubmodules[7]）；如果上游添加了一个新的子模块，该子模块不能被获取，直到它被克隆，例如通过`git submodule update`。

note: type: Plain text
en: When set to 'on-demand', only changed submodules are fetched. When set to 'yes', all populated submodules are fetched and submodules that are both unpopulated and changed are fetched. When set to 'no', submodules are never fetched.
zh_HANS-CN: 当设置为 'on-demand' 时，只取回已改变的子模块。当设置为 'yes' 时，所有已填充的子模块都被获取，同时未填充和已改变的子模块也被获取。当设置为 'no' 时，子模块永远不会被获取。

note: type: Plain text
en: When unspecified, this uses the value of `fetch.recurseSubmodules` if it is set (see linkgit:git-config[1]), defaulting to 'on-demand' if unset.  When this option is used without any value, it defaults to 'yes'.
zh_HANS-CN: 当未指定时，如果设置了 `fetch.recurseSubmodules`，则使用该值（见linkgit:git-config[1]），如果未设置则默认为 'on-demand'。  当这个选项被使用而没有任何值时，它默认为 'yes'。

note: type: Plain text
en: Number of parallel children to be used for all forms of fetching.
zh_HANS-CN: 用于所有形式的获取的并行子进程的数量。

note: type: Plain text
en: If the `--multiple` option was specified, the different remotes will be fetched in parallel. If multiple submodules are fetched, they will be fetched in parallel. To control them independently, use the config settings `fetch.parallel` and `submodule.fetchJobs` (see linkgit:git-config[1]).
zh_HANS-CN: 如果指定了 `--multiple` 选项，不同的远程将被并行获取。如果多个子模块被取走，它们将并行获取。要独立控制它们，使用配置 `fetch.parallel` 和 `submodule.fetchJobs`（见linkgit:git-config[1]）。

note: type: Plain text
en: Typically, parallel recursive and multi-remote fetches will be faster. By default fetches are performed sequentially, not in parallel.
zh_HANS-CN: 通常情况下，并行的递归和多远程的提取会更快。默认情况下，检索是按顺序进行的，而不是并行的。

note: type: Plain text
en: Disable recursive fetching of submodules (this has the same effect as using the `--recurse-submodules=no` option).
zh_HANS-CN: 禁用子模块的递归获取（这与使用 `--recurse-submodules=no` 选项的效果相同）。

note: type: Plain text
en: If the remote is fetched successfully, add upstream (tracking) reference, used by argument-less linkgit:git-pull[1] and other commands. For more information, see `branch.<name>.merge` and `branch.<name>.remote` in linkgit:git-config[1].
zh_HANS-CN: 如果远程被成功获取，添加上游（跟踪）引用，由无参数的 linkgit:git-pull[1] 和其他命令使用。更多信息，见 linkgit:git-config[1] 中的 `branch.<名称>.merge` 和 `branch.<名称>.remote`。

note: type: Plain text
en: Prepend <path> to paths printed in informative messages such as "Fetching submodule foo".  This option is used internally when recursing over submodules.
zh_HANS-CN: 将 <路径> 添加到信息性消息中打印的路径，例如“获取子模块 foo”。递归子模块时在内部使用此选项。

note: type: Plain text
en: This option is used internally to temporarily provide a non-negative default value for the --recurse-submodules option.  All other methods of configuring fetch's submodule recursion (such as settings in linkgit:gitmodules[5] and linkgit:git-config[1]) override this option, as does specifying --[no-]recurse-submodules directly.
zh_HANS-CN: 这个选项在内部被用来为 --recurse-submodules 选项暂时提供一个非负的默认值。  所有其他配置获取子模块递归的方法（比如 linkgit:gitmodules[5] 和 linkgit:git-config[1] 中的设置）都覆盖这个选项，直接指定 --[no-]recurse-submodules 也是如此。

note: type: Plain text
en: By default 'git fetch' refuses to update the head which corresponds to the current branch.  This flag disables the check.  This is purely for the internal use for 'git pull' to communicate with 'git fetch', and unless you are implementing your own Porcelain you are not supposed to use it.
zh_HANS-CN: 默认情况下，"git fetch" 拒绝更新与当前分支相对应的头部。  这个标志禁用了这种检查。  这纯粹是为了让 'git pull' 与 'git fetch' 沟通的内部使用，除非你正在实现你自己的上层命令，否则你不应该使用它。

note: type: Plain text
en: When given, and the repository to fetch from is handled by 'git fetch-pack', `--exec=<upload-pack>` is passed to the command to specify non-default path for the command run on the other end.
zh_HANS-CN: 当给出时，并且要获取的仓库是由 'git fetch-pack' 处理的，`--exec=<upload-pack>` 被传递到命令中，为另一端运行的命令指定非默认路径。

note: type: Plain text
en: Pass --quiet to git-fetch-pack and silence any other internally used git commands. Progress is not reported to the standard error stream.
zh_HANS-CN: 将 --quiet 传递给 git-fetch-pack，并使任何其他内部使用的 git 命令保持沉默。进度不会报告给标准错误流。

note: type: Plain text
en: Be verbose.
zh_HANS-CN: 详细日志。

note: type: Plain text
en: Progress status is reported on the standard error stream by default when it is attached to a terminal, unless -q is specified. This flag forces progress status even if the standard error stream is not directed to a terminal.
zh_HANS-CN: 当标准错误流连接到终端时，除非指定了 -q，否则默认情况下会在标准错误流上报告进展状态。即使标准错误流没有指向终端，这个标志也会强制显示进度状态。

note: type: Labeled list
en: -o <option>
zh_HANS-CN: -o <选项>

note: type: Labeled list
en: --server-option=<option>
zh_HANS-CN: --server-option=<选项>

note: type: Plain text
en: Transmit the given string to the server when communicating using protocol version 2.  The given string must not contain a NUL or LF character.  The server's handling of server options, including unknown ones, is server-specific.  When multiple `--server-option=<option>` are given, they are all sent to the other side in the order listed on the command line.
zh_HANS-CN: 使用协议版本2进行通信时，将给定的字符串传输到服务器。给定的字符串不得包含NUL或LF字符。服务器对服务器选项（包括未知选项）的处理是取决于服务器。当给出多个`--server-option = <option>`时，它们都按照命令行中列出的顺序发送到另一端。

note: type: Plain text
en: By default, git checks if a branch is force-updated during fetch. This can be disabled through fetch.showForcedUpdates, but the --show-forced-updates option guarantees this check occurs.  See linkgit:git-config[1].
zh_HANS-CN: 默认情况下，git 在获取过程中会检查一个分支是否被强制更新了。这可以通过 fetch.showForcedUpdates 禁用，但 --show-forced-updates 选项保证了这种检查的发生。  参见 linkgit:git-config[1]。

note: type: Plain text
en: By default, git checks if a branch is force-updated during fetch. Pass --no-show-forced-updates or set fetch.showForcedUpdates to false to skip this check for performance reasons. If used during 'git-pull' the --ff-only option will still check for forced updates before attempting a fast-forward update. See linkgit:git-config[1].
zh_HANS-CN: 默认情况下，git 会在获取过程中检查一个分支是否被强制更新了。通过 --no-show-forced-updates 或将 fetch.showForcedUpdates 设置为 false 来跳过这个检查，以保证性能。如果在 'git-pull' 中使用 --ff-only 选项，在尝试快速更新前仍会检查强制更新。见 linkgit:git-config[1]。

note: type: Plain text
en: Use IPv4 addresses only, ignoring IPv6 addresses.
zh_HANS-CN: 仅使用 IPv4 地址，忽略 IPv6 地址。

note: type: Plain text
en: Use IPv6 addresses only, ignoring IPv4 addresses.
zh_HANS-CN: 仅使用 IPv6 地址，忽略 IPv4 地址。

note: type: Title -
en: NAME
zh_HANS-CN: 名称

note: type: Plain text
en: git-add - Add file contents to the index
zh_HANS-CN: git-add - 添加文件内容到索引

note: type: Title -
en: SYNOPSIS
zh_HANS-CN: 概述

note: type: Title -
en: DESCRIPTION
zh_HANS-CN: 描述

note: type: Plain text
en: This command updates the index using the current content found in the working tree, to prepare the content staged for the next commit.  It typically adds the current content of existing paths as a whole, but with some options it can also be used to add content with only part of the changes made to the working tree files applied, or remove paths that do not exist in the working tree anymore.
zh_HANS-CN: 该命令使用工作区的内容来更新索引，为下一次提交准备暂存的内容。通常情况下会添加当前目录的所有内容到索引，但是通过某些选项，它也可以用于仅添加对工作树文件所做的部分更改，或删除工作树中不存在的路径。

note: type: Plain text
en: The "index" holds a snapshot of the content of the working tree, and it is this snapshot that is taken as the contents of the next commit.  Thus after making any changes to the working tree, and before running the commit command, you must use the `add` command to add any new or modified files to the index.
zh_HANS-CN: 索引区中储存着一份工作区的快照，在下次提交时这份快照会被保存到 Git 仓库中。因此在工作区做过修改后以及在运行下一次提交命令前，你必须通过 `add` 命令来添加新创建的文件或者保存新的改动到索引中。

note: type: Plain text
en: This command can be performed multiple times before a commit.  It only adds the content of the specified file(s) at the time the add command is run; if you want subsequent changes included in the next commit, then you must run `git add` again to add the new content to the index.
zh_HANS-CN: 提交前可以多次执行此命令。它仅在运行add命令时添加指定文件的内容；如果要在下一次提交中包含后续更改，则必须再次运行`git add`将新内容添加到索引中。

note: type: Plain text
en: The `git status` command can be used to obtain a summary of which files have changes that are staged for the next commit.
zh_HANS-CN: `git status` 命令可用于获取摘要，说明哪些变化的文件已暂存，准备下一次提交。

note: type: Plain text
en: The `git add` command will not add ignored files by default.  If any ignored files were explicitly specified on the command line, `git add` will fail with a list of ignored files.  Ignored files reached by directory recursion or filename globbing performed by Git (quote your globs before the shell) will be silently ignored.  The 'git add' command can be used to add ignored files with the `-f` (force) option.
zh_HANS-CN: `git add` 命令默认不会添加被忽略的文件。如果在命令行上明确指定了任何被忽略的文件，则`git add`会失败，并显示被忽略文件的列表。由目录递归或Git执行的文件名通配符（在shell之前引用的通配符）所涉及的忽略文件将被静默忽略。 'git add' 命令可用于通过 -f 选项（force）强制添加忽略的文件。

note: type: Plain text
en: Please see linkgit:git-commit[1] for alternative ways to add content to a commit.
zh_HANS-CN: 请参阅 linkgit:git-commit[1] 了解将内容添加到提交的其他替代方法。

note: type: Title -
en: OPTIONS
zh_HANS-CN: 选项

note: type: Plain text
en: Files to add content from.  Fileglobs (e.g. `*.c`) can be given to add all matching files.  Also a leading directory name (e.g. `dir` to add `dir/file1` and `dir/file2`) can be given to update the index to match the current state of the directory as a whole (e.g.  specifying `dir` will record not just a file `dir/file1` modified in the working tree, a file `dir/file2` added to the working tree, but also a file `dir/file3` removed from the working tree). Note that older versions of Git used to ignore removed files; use `--no-all` option if you want to add modified or new files but ignore removed ones.
zh_HANS-CN: 要从中添加内容的文件。可以使用文件通配符（例如 `*.c`）来添加所有匹配的文件。此外，还可以提供一个前导目录名（例如，指定 `dir` 以添加 `dir/file1` 和 `dir/file2`）来更新索引，使其与整个目录的当前状态相匹配（例如，指定 `dir` 不仅会记录在工作树中修改的文件 `dir/file1`，还会记录在工作树中添加的文件 `dir/file2`，还有从工作树中删除的文件 `dir/file3`）。请注意，旧版本的 Git 会忽略已删除的文件；如果要添加已修改的文件或新文件，但忽略已删除的文件，请使用 `--no all` 选项。

note: type: Plain text
en: For more details about the <pathspec> syntax, see the 'pathspec' entry in linkgit:gitglossary[7].
zh_HANS-CN: 有关 <指定路径> 格式的更多细节，请参考 linkgit:gitglossary[7]。

note: type: Plain text
en: Don't actually add the file(s), just show if they exist and/or will be ignored.
zh_HANS-CN: 实际上不添加文件，仅展示文件是否存在或是否忽略。

note: type: Plain text
en: Allow adding otherwise ignored files.
zh_HANS-CN: 允许添加已被忽略的文件。

note: type: Plain text
en: Allow updating index entries outside of the sparse-checkout cone.  Normally, `git add` refuses to update index entries whose paths do not fit within the sparse-checkout cone, since those files might be removed from the working tree without warning. See linkgit:git-sparse-checkout[1] for more details.
zh_HANS-CN: 允许更新稀疏检出 cone 之外的索引条目。  通常，`git add` 拒绝更新其路径不适合稀疏检出 cone 的索引条目，因为这些文件可能会在没有警告的情况下从工作区中删除。有关更多详细信息，请参阅链接 git:git-sparse-checkout[1]。

note: type: Plain text
en: This effectively runs `add --interactive`, but bypasses the initial command menu and directly jumps to the `patch` subcommand.  See ``Interactive mode'' for details.
zh_HANS-CN: 参见这可以有效地运行 `add --interactive`，但是会绕过初始命令菜单，而直接跳转到 `patch` 子命令。有关详细信息，请参见``交互模式''。

note: type: Plain text
en: This option can only be used together with --dry-run. By using this option the user can check if any of the given files would be ignored, no matter if they are already present in the work tree or not.
zh_HANS-CN: 此选项只能与--dry-run一起使用。通过使用此选项，用户可以检查是否会忽略任何给定的文件，无论它们是否已存在于工作树中。

note: type: Plain text
en: By default, `git add` will warn when adding an embedded repository to the index without using `git submodule add` to create an entry in `.gitmodules`. This option will suppress the warning (e.g., if you are manually performing operations on submodules).
zh_HANS-CN: 默认情况下， `git add` 将在向索引添加嵌入式存储库时发出警告，而不使用 `git submodule add` 在 `.gitmodules` 中创建条目。此选项将抑制警告（例如，如果手动对子模块执行操作）。

note: type: Plain text
en: Pathspec is passed in `<file>` instead of commandline args. If `<file>` is exactly `-` then standard input is used. Pathspec elements are separated by LF or CR/LF. Pathspec elements can be quoted as explained for the configuration variable `core.quotePath` (see linkgit:git-config[1]). See also `--pathspec-file-nul` and global `--literal-pathspecs`.
zh_HANS-CN: Pathspec在 `<file>` 中传递，而不是在命令行参数中传递。如果 `<file>` 正好是 `-`，则使用标准输入。Pathspec 元素由 LF 或 CR/LF 分隔。可以引用配置变量 `core.quotePath` 的 Pathspec 元素（请参见 linkgit:git-config[1]）。另请参见 `--pathspec-file-nul `和全局 `--literal-pathspecs`。

note: type: Title -
en: EXAMPLES
zh_HANS-CN: 实例

note: type: Plain text
en: Note that the asterisk `*` is quoted from the shell in this example; this lets the command include the files from subdirectories of `Documentation/` directory.
zh_HANS-CN: 注意，在本例中，星号 `*` 是从 shell 中引入的；这使得该命令可以包含 `Documentation/` 的子目录中的文件。

note: type: Title -
en: INTERACTIVE MODE
zh_HANS-CN: 交互模式

note: type: Labeled list
en: status
zh_HANS-CN: 状态

note: type: Labeled list
en: revert
zh_HANS-CN: 还原

note: type: Labeled list
en: add untracked
zh_HANS-CN: 添加未跟踪文件

note: type: Labeled list
en: patch
zh_HANS-CN: 补丁

note: type: Title -
en: EDITING PATCHES
zh_HANS-CN: 编辑补丁

note: type: Labeled list
en: added content
zh_HANS-CN: 添加的内容

note: type: Labeled list
en: removed content
zh_HANS-CN: 删除的内容

note: type: Labeled list
en: modified content
zh_HANS-CN: 修改的内容

note: type: Labeled list
en: modifying existing content
zh_HANS-CN: 修改现有的内容

note: type: Labeled list
en: new content
zh_HANS-CN: 新的内容

note: type: Title -
en: CONFIGURATION
zh_HANS-CN: 配置

note: type: Title -
en: SEE ALSO
zh_HANS-CN: 参见

note: type: Plain text
en: Part of the linkgit:git[1] suite
zh_HANS-CN: 属于 linkgit:git[1] 文档

note: type: Plain text
en: Splits mail messages in a mailbox into commit log message, authorship information and patches, and applies them to the current branch. You could think of it as a reverse operation of linkgit:git-format-patch[1] run on a branch with a straight history without merges.
zh_HANS-CN: 将邮箱中的邮件信息拆分为提交日志信息、作者信息和补丁，并将其应用到当前分支。你可以把它看作是 linkgit:git-format-patch[1] 的反向操作，在一个没有合并历史的分支上运行。

note: type: Plain text
en: The list of mailbox files to read patches from. If you do not supply this argument, the command reads from the standard input.  If you supply directories, they will be treated as Maildirs.
zh_HANS-CN: 要读取补丁的邮箱文件的列表。如果你不提供这个参数，命令将从标准输入中读取。 如果你提供目录，它们将被视为邮箱目录。

note: type: Plain text
en: Add a `Signed-off-by` trailer to the commit message, using the committer identity of yourself.  See the signoff option in linkgit:git-commit[1] for more information.
zh_HANS-CN: 在提交信息中加入 `Signed-off-by` 的尾注，使用自己的提交者身份。 更多信息见 linkgit:git-commit[1] 中的 signoff 选项。

note: type: Plain text
en: Pass `-k` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]).
zh_HANS-CN: 传递`-k` 标志给 'git mailinfo'（见linkgit:git-mailinfo[1]）。

note: type: Plain text
en: Pass `-b` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]).
zh_HANS-CN: 将 `-b` 标志传递给 'git mailinfo'（见linkgit:git-mailinfo[1]）。

note: type: Plain text
en: With `--keep-cr`, call 'git mailsplit' (see linkgit:git-mailsplit[1])  with the same option, to prevent it from stripping CR at the end of lines. `am.keepcr` configuration variable can be used to specify the default behaviour.  `--no-keep-cr` is useful to override `am.keepcr`.
zh_HANS-CN: 使用 `--keep-cr`，调用 'git mailsplit'（见linkgit:git-mailsplit[1]），并使用相同的选项，以防止它在行末剥离 CR。`am.keepcr` 配置变量可以用来指定默认行为。 `--no-keep-cr` 可以用来覆盖 `am.keepcr`。

note: type: Plain text
en: Remove everything in body before a scissors line (see linkgit:git-mailinfo[1]). Can be activated by default using the `mailinfo.scissors` configuration variable.
zh_HANS-CN: 移除正文中剪切行之前的所有内容（见linkgit:git-mailinfo[1]）。可以使用 `mailinfo.scissors` 配置变量来默认激活。

note: type: Plain text
en: Ignore scissors lines (see linkgit:git-mailinfo[1]).
zh_HANS-CN: 忽略剪切线（见linkgit:git-mailinfo[1]）。

note: type: Plain text
en: This flag will be passed down to 'git mailinfo' (see linkgit:git-mailinfo[1]).
zh_HANS-CN: 这个标志将被传递给 'git mailinfo'（见 linkgit:git-mailinfo[1]）。

note: type: Plain text
en: By default, or when the option is set to 'stop', the command errors out on an input e-mail message lacking a patch and stops into the middle of the current am session. When this option is set to 'drop', skip such an e-mail message instead.  When this option is set to 'keep', create an empty commit, recording the contents of the e-mail message as its log.
zh_HANS-CN: 默认情况下，或者当该选项被设置为 'stop' 时，该命令在输入缺乏补丁的电子邮件时出错，并停止到当前 am 会话的中间。当这个选项被设置为 'drop' 时，跳过这样的电子邮件信息。 当这个选项被设置为 'keep' 时，会创建一个空的提交，将电子邮件的内容记录为日志。

note: type: Plain text
en: Pass the `-m` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]), so that the Message-ID header is added to the commit message.  The `am.messageid` configuration variable can be used to specify the default behaviour.
zh_HANS-CN: 传递 `-m` 标志给 'git mailinfo'（见 linkgit:git-mailinfo[1]），这样 Message-ID 头会被添加到提交信息中。 `am.messageid` 配置变量可以用来指定默认行为。

note: type: Plain text
en: Do not add the Message-ID header to the commit message.  `no-message-id` is useful to override `am.messageid`.
zh_HANS-CN: 不要在提交信息中添加 Message-ID 头。  `no-message-id` 对于覆盖 `am.messageid` 很有用。

note: type: Plain text
en: Be quiet. Only print error messages.
zh_HANS-CN: 保持安静。只打印错误信息。

note: type: Plain text
en: Pass `-u` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]).  The proposed commit log message taken from the e-mail is re-coded into UTF-8 encoding (configuration variable `i18n.commitEncoding` can be used to specify project's preferred encoding if it is not UTF-8).
zh_HANS-CN: 传递 `-u` 标志给 'git mailinfo'（见linkgit:git-mailinfo[1]）。 建议从邮件中提取的提交日志信息被重新编码为 UTF-8 编码（配置变量 `i18n.commitEncoding` 可以用来指定项目的首选编码，如果它不是 UTF-8）。

note: type: Plain text
en: This was optional in prior versions of git, but now it is the
    default.   You can use `--no-utf8` to override this.
zh_HANS-CN: 这在以前的 git 版本中是可选的，但现在它是
    默认的。  你可以使用 `--no-utf8` 来覆盖它。

note: type: Plain text
en: Pass `-n` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]).
zh_HANS-CN: 传递 `-n` 标志给 'git mailinfo'（见linkgit:git-mailinfo[1]）。

note: type: Plain text
en: When the patch does not apply cleanly, fall back on 3-way merge if the patch records the identity of blobs it is supposed to apply to and we have those blobs available locally. `--no-3way` can be used to override am.threeWay configuration variable. For more information, see am.threeWay in linkgit:git-config[1].
zh_HANS-CN: 当补丁不能干净地应用时，如果补丁记录了它应该应用到的二进制文件的身份，并且我们有这些二进制文件可以在本地使用，那么就退回到三路合并。`--no-3way` 可以用来覆盖 am.threeWay 配置变量。更多信息，见 linkgit:git-config[1] 中的 am.threeWay。

note: type: Labeled list
en: --exclude=<path>
zh_HANS-CN: --exclude=<路径>

note: type: Plain text
en: These flags are passed to the 'git apply' (see linkgit:git-apply[1])  program that applies the patch.
zh_HANS-CN: 这些标志会传递给应用补丁的 "git apply"（见 linkgit:git-apply[1]）程序。

note: type: Plain text
en: By default the command will try to detect the patch format automatically. This option allows the user to bypass the automatic detection and specify the patch format that the patch(es) should be interpreted as. Valid formats are mbox, mboxrd, stgit, stgit-series and hg.
zh_HANS-CN: 默认情况下，该命令将尝试自动检测补丁格式。这个选项允许用户绕过自动检测，并指定补丁的格式，以便将其解释为补丁。有效的格式是 mbox、mboxrd、stgit、stgit-series 和 hg。

note: type: Plain text
en: Run interactively.
zh_HANS-CN: 交互式运行。

note: type: Plain text
en: By default the command records the date from the e-mail message as the commit author date, and uses the time of commit creation as the committer date. This allows the user to lie about the committer date by using the same value as the author date.
zh_HANS-CN: 默认情况下，该命令将电子邮件中的日期作为提交者日期，并使用提交者的创建时间作为提交者日期。这使得用户可以通过使用与作者日期相同的值来谎报提交者日期。

note: type: Plain text
en: By default the command records the date from the e-mail message as the commit author date, and uses the time of commit creation as the committer date. This allows the user to lie about the author date by using the same value as the committer date.
zh_HANS-CN: 默认情况下，该命令将电子邮件中的日期作为提交者日期，并使用提交者的创建时间作为提交者日期。这使得用户可以通过使用与提交者日期相同的值来谎报作者日期。

note: type: Plain text
en: Skip the current patch.  This is only meaningful when restarting an aborted patch.
zh_HANS-CN: 跳过当前的补丁。 这只有在重新启动一个中止的补丁时才有意义。

note: type: Plain text
en: GPG-sign commits. The `keyid` argument is optional and defaults to the committer identity; if specified, it must be stuck to the option without a space. `--no-gpg-sign` is useful to countermand both `commit.gpgSign` configuration variable, and earlier `--gpg-sign`.
zh_HANS-CN: GPG 签名提交。`keyid` 参数是可选的，默认为提交者身份；如果指定了，则必须与选项相连，不加空格。`--no-gpg-sign` 用于还原 `commit.gpgSign` 配置变量和先前的 `--gpg-sign`。

note: type: Plain text
en: After a patch failure (e.g. attempting to apply conflicting patch), the user has applied it by hand and the index file stores the result of the application.  Make a commit using the authorship and commit log extracted from the e-mail message and the current index file, and continue.
zh_HANS-CN: 补丁失败后（如试图应用冲突的补丁），用户已经手工应用，索引文件存储了应用的结果。 使用从电子邮件中提取的作者和提交日志以及当前的索引文件进行提交，然后继续运行。

note: type: Plain text
en: When a patch failure occurs, <msg> will be printed to the screen before exiting.  This overrides the standard message informing you to use `--continue` or `--skip` to handle the failure.  This is solely for internal use between 'git rebase' and 'git am'.
zh_HANS-CN: 当发生补丁失败时，<信息> 将在退出前被打印到屏幕上。 这将覆盖标准信息，通知你使用 `--continue` 或 `--skip` 来处理失败。 这只是为了在 'git rebase' 和 'git am' 之间的内部使用。

note: type: Plain text
en: Restore the original branch and abort the patching operation.  Revert contents of files involved in the am operation to their pre-am state.
zh_HANS-CN: 恢复原来的分支，放弃打补丁的操作。 将 am 操作中涉及的文件内容恢复到 am 前的状态。

note: type: Plain text
en: Abort the patching operation but keep HEAD and the index untouched.
zh_HANS-CN: 中止打补丁的操作，但保留 HEAD 和索引不被接触。

note: type: Plain text
en: Show the message at which `git am` has stopped due to conflicts.  If `raw` is specified, show the raw contents of the e-mail message; if `diff`, show the diff portion only.  Defaults to `raw`.
zh_HANS-CN: 显示`git am` 因冲突而停止的消息。 如果指定了 `raw`，显示电子邮件的原始内容；如果是 `diff`，只显示差异部分。 默认为 `raw`。

note: type: Plain text
en: After a patch failure on an input e-mail message lacking a patch, create an empty commit with the contents of the e-mail message as its log message.
zh_HANS-CN: 在对缺乏补丁的输入邮件信息进行补丁失败后，创建一个空的提交，将邮件信息的内容作为其日志信息。

note: type: Title -
en: DISCUSSION
zh_HANS-CN: 讨论

note: type: Plain text
en: The commit author name is taken from the "From: " line of the message, and commit author date is taken from the "Date: " line of the message.  The "Subject: " line is used as the title of the commit, after stripping common prefix "[PATCH <anything>]".  The "Subject: " line is supposed to concisely describe what the commit is about in one line of text.
zh_HANS-CN: 提交者的名字取自信息的 "From:" 行，而提交者的日期则取自信息的 "Date:" 行。 "Subject:" 行是提交的标题，在去掉普通前缀 "[PATCH <任何东西>]" 之后。 "Sbuject: " 是为了用一行文字简洁地描述提交的内容。

note: type: Plain text
en: "From: ", "Date: ", and "Subject: " lines starting the body override the respective commit author name and title values taken from the headers.
zh_HANS-CN: "From: "、"Date: " 和 "Subject: " 行开始的正文覆盖了从标题中获取的各自的提交者名称和标题值。

note: type: Plain text
en: The commit message is formed by the title taken from the "Subject: ", a blank line and the body of the message up to where the patch begins.  Excess whitespace at the end of each line is automatically stripped.
zh_HANS-CN: 提交信息由 "Subject: " 中的标题、一个空行和直到补丁开始的信息正文组成。  每行末尾多余的空格会被自动删除。

note: type: Plain text
en: The patch is expected to be inline, directly following the message.  Any line that is of the form:
zh_HANS-CN: 补丁应该是内联的，直接跟在信息后面。 任何形式的行：

note: type: Plain text
en: three-dashes and end-of-line, or
zh_HANS-CN: 三个破折号和行末，或

note: type: Plain text
en: a line that begins with "diff -", or
zh_HANS-CN: 以 "diff - " 开头的一行，或

note: type: Plain text
en: a line that begins with "Index: "
zh_HANS-CN: 以 "index: " 开头的一行

note: type: Plain text
en: is taken as the beginning of a patch, and the commit log message is terminated before the first occurrence of such a line.
zh_HANS-CN: 被认为是一个补丁的开始，提交日志信息在第一次出现这样的行之前就结束了。

note: type: Plain text
en: When initially invoking `git am`, you give it the names of the mailboxes to process.  Upon seeing the first patch that does not apply, it aborts in the middle.  You can recover from this in one of two ways:
zh_HANS-CN: 当最初调用 `git am` 时，你给了它要处理的邮箱的名字。 当看到第一个不适用的补丁时，它就会在中间中止。 你可以通过以下两种方式之一恢复：

note: type: Plain text
en: skip the current patch by re-running the command with the `--skip` option.
zh_HANS-CN: 通过重新运行带有 `--skip` 选项的命令，跳过当前补丁。

note: type: Plain text
en: hand resolve the conflict in the working directory, and update the index file to bring it into a state that the patch should have produced.  Then run the command with the `--continue` option.
zh_HANS-CN: 手解决工作目录中的冲突，并更新索引文件，使其进入补丁应该产生的状态。 然后用 `--continue` 选项运行该命令。

note: type: Plain text
en: The command refuses to process new mailboxes until the current operation is finished, so if you decide to start over from scratch, run `git am --abort` before running the command with mailbox names.
zh_HANS-CN: 在当前操作完成之前，该命令拒绝处理新的邮箱，所以如果你决定从头开始，在运行带有邮箱名称的命令之前，运行 `git am --abort`。

note: type: Plain text
en: Before any patches are applied, ORIG_HEAD is set to the tip of the current branch.  This is useful if you have problems with multiple commits, like running 'git am' on the wrong branch or an error in the commits that is more easily fixed by changing the mailbox (e.g.  errors in the "From:" lines).
zh_HANS-CN: 在应用任何补丁之前，ORIG_HEAD 被设置为当前分支的顶端。 如果你在多个提交中遇到问题，比如在错误的分支上运行 'git am'，或者提交中的错误更容易通过改变邮箱来解决（比如 "From: " 行中的错误），这就很有用了。

note: type: Plain text
en: This command can run `applypatch-msg`, `pre-applypatch`, and `post-applypatch` hooks.  See linkgit:githooks[5] for more information.
zh_HANS-CN: 这个命令可以运行 `applypatch-msg`, `pre-applypatch`, 和 `post-applypatch` 钩子。 更多信息见 linkgit:githooks[5]。

note: type: Plain text
en: Annotates each line in the given file with information from the commit which introduced the line. Optionally annotates from a given revision.
zh_HANS-CN: 用引入该行的提交信息来注释给定文件中的每一行。也可以选择从给定的修订版中进行注释。

note: type: Plain text
en: The only difference between this command and linkgit:git-blame[1] is that they use slightly different output formats, and this command exists only for backward compatibility to support existing scripts, and provide a more familiar command name for people coming from other SCM systems.
zh_HANS-CN: 这个命令和 linkgit:git-blame[1] 的唯一区别是，它们使用的输出格式略有不同，这个命令的存在只是为了向后兼容，以支持现有的脚本，并为来自其他 SCM 系统的人提供一个更熟悉的命令名称。

note: type: Plain text
en: Reads the supplied diff output (i.e. "a patch") and applies it to files.  When running from a subdirectory in a repository, patched paths outside the directory are ignored.  With the `--index` option the patch is also applied to the index, and with the `--cached` option the patch is only applied to the index.  Without these options, the command applies the patch only to files, and does not require them to be in a Git repository.
zh_HANS-CN: 读取提供的差异输出（即 "一个补丁" ）并将其应用于文件。 当从版本库中的子目录运行时，目录外的补丁路径会被忽略。 使用 `--index `选项，补丁也会应用到索引中，使用 `--cached` 选项，补丁只应用到索引中。 如果没有这些选项，该命令只对文件打补丁，而不要求它们在 Git 仓库中。

note: type: Plain text
en: This command applies the patch but does not create a commit.  Use linkgit:git-am[1] to create commits from patches generated by linkgit:git-format-patch[1] and/or received by email.
zh_HANS-CN: 该命令会应用补丁，但不会创建提交。 使用 linkgit:git-am[1] 从 linkgit:git-format-patch[1] 生成的和/或通过电子邮件收到的补丁创建提交。

note: type: Plain text
en: The files to read the patch from.  '-' can be used to read from the standard input.
zh_HANS-CN: 要读取补丁的文件。 '-' 可以用来从标准输入中读取。

note: type: Plain text
en: Instead of applying the patch, output diffstat for the input.  Turns off "apply".
zh_HANS-CN: 不应用补丁，而是输出输入的差异状态。 关掉 "apply"。

note: type: Plain text
en: Similar to `--stat`, but shows the number of added and deleted lines in decimal notation and the pathname without abbreviation, to make it more machine friendly.  For binary files, outputs two `-` instead of saying `0 0`.  Turns off "apply".
zh_HANS-CN: 类似于 `--stat`，但是用十进制符号显示增加和删除的行数，路径名不加缩写，使其对机器更友好。 对于二进制文件，输出两个`-` 而不是 `0 0`。 关闭 "apply"。

note: type: Plain text
en: Instead of applying the patch, output a condensed summary of information obtained from git diff extended headers, such as creations, renames and mode changes.  Turns off "apply".
zh_HANS-CN: 不应用补丁，而是输出从 git dif f扩展头文件中获得的信息的浓缩摘要，如创建、重命名和模式变化。 关闭 "apply"。

note: type: Plain text
en: Instead of applying the patch, see if the patch is applicable to the current working tree and/or the index file and detects errors.  Turns off "apply".
zh_HANS-CN: 看看该补丁是否适用于当前工作树和/或索引文件，并检测到错误，而不是应用该补丁。 关闭 "apply"。

note: type: Plain text
en: Apply the patch to both the index and the working tree (or merely check that it would apply cleanly to both if `--check` is in effect). Note that `--index` expects index entries and working tree copies for relevant paths to be identical (their contents and metadata such as file mode must match), and will raise an error if they are not, even if the patch would apply cleanly to both the index and the working tree in isolation.
zh_HANS-CN: 在索引和工作目录上都打上补丁（如果 `--check`生 效，则只需检查它是否能干净地应用于两者）。注意，`--index` 希望相关路径的索引条目和工作区副本是相同的（它们的内容和元数据，如文件模式必须匹配），如果它们不相同，将引发一个错误，即使该补丁可以干净地应用于索引和工作区。

note: type: Plain text
en: Apply the patch to just the index, without touching the working tree. If `--check` is in effect, merely check that it would apply cleanly to the index entry.
zh_HANS-CN: 将补丁只应用于索引，而不触及工作目录。如果 `--check` 是有效的，只需检查它是否能干净地应用于索引条目。

note: type: Plain text
en: When applying the patch only to the working tree, mark new files to be added to the index later (see `--intent-to-add` option in linkgit:git-add[1]). This option is ignored unless running in a Git repository and `--index` is not specified.  Note that `--index` could be implied by other options such as `--cached` or `--3way`.
zh_HANS-CN: 当只在工作树上应用补丁时，标记新的文件，以便以后添加到索引中（见 linkgit:git-add[1] 中的 `--intent-to-add` 选项）。除非在 Git 仓库中运行且没有指定 `--index`，否则该选项将被忽略。 请注意，`--index` 可能是由其他选项暗示的，如 `--cached` 或 `--3way`。

note: type: Plain text
en: Attempt 3-way merge if the patch records the identity of blobs it is supposed to apply to and we have those blobs available locally, possibly leaving the conflict markers in the files in the working tree for the user to resolve.  This option implies the `--index` option unless the `--cached` option is used, and is incompatible with the `--reject` option.  When used with the `--cached` option, any conflicts are left at higher stages in the cache.
zh_HANS-CN: 如果补丁记录了它应该应用到的二进制文件的身份，并且我们有这些二进制文件在本地可用，则尝试三方合并，可能会在工作树中的文件中留下冲突标记，由用户解决。  这个选项意味着 `--index` 选项，除非使用 `--cached` 选项，并且与 `--reject` 选项不兼容。  当与 `--cached` 选项一起使用时，任何冲突都被留在缓存的较高阶段。

note: type: Plain text
en: Newer 'git diff' output has embedded 'index information' for each blob to help identify the original version that the patch applies to.  When this flag is given, and if the original versions of the blobs are available locally, builds a temporary index containing those blobs.
zh_HANS-CN: 较新的 "git diff" 输出为每个 blob 嵌入了 "索引信息"，以帮助识别补丁所适用的原始版本。 当给出这个标志时，如果 blob 的原始版本在本地可用，则建立一个包含这些 blob 的临时索引。

note: type: Plain text
en: When a pure mode change is encountered (which has no index information), the information is read from the current index instead.
zh_HANS-CN: 当遇到一个纯粹的模式变化（没有索引信息）时，将从当前索引中读取信息。

note: type: Plain text
en: Apply the patch in reverse.
zh_HANS-CN: 反过来应用补丁。

note: type: Plain text
en: For atomicity, 'git apply' by default fails the whole patch and does not touch the working tree when some of the hunks do not apply.  This option makes it apply the parts of the patch that are applicable, and leave the rejected hunks in corresponding *.rej files.
zh_HANS-CN: 为了保证原子性，'git apply' 默认情况下会使整个补丁失效，并且在某些目标不适用的情况下不会接触工作区。 这个选项让它应用补丁中适用的部分，并将被拒绝的目标留在相应的 *.rej 文件中。

note: type: Plain text
en: When `--numstat` has been given, do not munge pathnames, but use a NUL-terminated machine-readable format.
zh_HANS-CN: 当 `--numstat` 被给出时，不对路径名进行编码，而是使用以 NUL 结尾的机器可读格式。

note: type: Plain text
en: Ensure at least <n> lines of surrounding context match before and after each change.  When fewer lines of surrounding context exist they all must match.  By default no context is ever ignored.
zh_HANS-CN: 确保每次更改前后至少有 <n> 行的周围环境相匹配。 当周围环境的行数较少时，它们必须全部匹配。 在默认情况下，没有任何上下文被忽略。

note: type: Plain text
en: By default, 'git apply' expects that the patch being applied is a unified diff with at least one line of context.  This provides good safety measures, but breaks down when applying a diff generated with `--unified=0`. To bypass these checks use `--unidiff-zero`.
zh_HANS-CN: 默认情况下，'git apply' 希望被应用的补丁是一个至少有一行上下文的统一差异。 这提供了很好的安全措施，但在应用以 `--unified=0` 生成的差异时，会出现问题。要绕过这些检查，请使用 `--unidiff-zero`。

note: type: Plain text
en: Note, for the reasons stated above usage of context-free patches is discouraged.
zh_HANS-CN: 注意，由于上述原因，不鼓励使用无语境补丁。

note: type: Plain text
en: If you use any of the options marked "Turns off 'apply'" above, 'git apply' reads and outputs the requested information without actually applying the patch.  Give this flag after those flags to also apply the patch.
zh_HANS-CN: 如果您使用了上面标有 "关闭 'apply' " 的任何选项，'git apply' 会读取并输出所需的信息，而不会实际应用补丁。 在这些标志之后给出这个标志，也可以应用该补丁。

note: type: Plain text
en: When applying a patch, ignore additions made by the patch.  This can be used to extract the common part between two files by first running 'diff' on them and applying the result with this option, which would apply the deletion part but not the addition part.
zh_HANS-CN: 当应用一个补丁时，忽略该补丁所做的添加内容。 这可以用来提取两个文件之间的共同部分，首先对它们运行 'diff'，然后用这个选项应用结果，这将应用删除的部分，但不应用增加的部分。

note: type: Plain text
en: Historically we did not allow binary patch applied without an explicit permission from the user, and this flag was the way to do so.  Currently we always allow binary patch application, so this is a no-op.
zh_HANS-CN: 历史上，我们不允许在没有用户明确许可的情况下应用二进制补丁，而这个标志是这样做的。 目前，我们总是允许应用二进制补丁，所以这是一个无用功。

note: type: Plain text
en: Don't apply changes to files matching the given path pattern. This can be useful when importing patchsets, where you want to exclude certain files or directories.
zh_HANS-CN: 不要对符合给定路径模式的文件进行修改。这在导入补丁集时，你想把某些文件或目录排除在外的情况下很有用。

note: type: Plain text
en: Apply changes to files matching the given path pattern. This can be useful when importing patchsets, where you want to include certain files or directories.
zh_HANS-CN: 将修改应用于与给定路径模式相匹配的文件。这在导入补丁集时，你想包括某些文件或目录的情况下很有用。

note: type: Plain text
en: When `--exclude` and `--include` patterns are used, they are examined in the order they appear on the command line, and the first match determines if a patch to each path is used.  A patch to a path that does not match any include/exclude pattern is used by default if there is no include pattern on the command line, and ignored if there is any include pattern.
zh_HANS-CN: 当使用 `--exclude` 和 `-include` 模式时，会按照它们在命令行中出现的顺序进行检查，第一个匹配项决定是否使用每个路径的补丁。 如果命令行上没有include模式，则默认使用不匹配任何 include/exclude 模式的路径的补丁，如果有任何 include 模式，则忽略。

note: type: Plain text
en: When applying a patch, ignore changes in whitespace in context lines if necessary.  Context lines will preserve their whitespace, and they will not undergo whitespace fixing regardless of the value of the `--whitespace` option. New lines will still be fixed, though.
zh_HANS-CN: 当应用一个补丁时，如果有必要，请忽略上下文行中的空白变化。 上下文行将保留其空白，无论 `--whitespace` 选项的值是多少，它们都不会进行空白修正。不过，新的行仍然会被修复。

note: type: Plain text
en: When applying a patch, detect a new or modified line that has whitespace errors.  What are considered whitespace errors is controlled by `core.whitespace` configuration.  By default, trailing whitespaces (including lines that solely consist of whitespaces) and a space character that is immediately followed by a tab character inside the initial indent of the line are considered whitespace errors.
zh_HANS-CN: 当应用一个补丁时，检测一个新的或修改过的行有空格错误。 什么是空格错误是由 `core.whitespace` 配置控制的。 默认情况下，尾部的空白（包括仅由空白组成的行）和紧跟在行的初始缩进内的 Tab 字符的空白字符被认为是空白错误。

note: type: Plain text
en: By default, the command outputs warning messages but applies the patch.  When `git-apply` is used for statistics and not applying a patch, it defaults to `nowarn`.
zh_HANS-CN: 默认情况下，该命令输出警告信息，但会应用补丁。 当 `git-apply` 被用于统计而不应用补丁时，它默认为 `nowarn`。

note: type: Plain text
en: `nowarn` turns off the trailing whitespace warning.
zh_HANS-CN: `nowarn` 关闭尾部空白警告。

note: type: Plain text
en: `warn` outputs warnings for a few such errors, but applies the patch as-is (default).
zh_HANS-CN: `warn` 对少数此类错误输出警告，但按原样应用补丁（默认）。

note: type: Plain text
en: `fix` outputs warnings for a few such errors, and applies the patch after fixing them (`strip` is a synonym -- the tool used to consider only trailing whitespace characters as errors, and the fix involved 'stripping' them, but modern Gits do more).
zh_HANS-CN: `fix` 对一些这样的错误输出警告，并在修复后应用补丁（`strip` 是一个同义词--该工具过去只考虑尾部空白字符的错误，修复涉及 'stripping' 等，但现代 Gits 做得更多）。

note: type: Plain text
en: `error` outputs warnings for a few such errors, and refuses to apply the patch.
zh_HANS-CN: `error` 对几个这样的错误输出警告，并拒绝应用补丁。

note: type: Plain text
en: `error-all` is similar to `error` but shows all errors.
zh_HANS-CN: `error-all` 与 `error` 类似，但显示所有错误。

note: type: Plain text
en: Under certain circumstances, some versions of 'diff' do not correctly detect a missing new-line at the end of the file. As a result, patches created by such 'diff' programs do not record incomplete lines correctly. This option adds support for applying such patches by working around this bug.
zh_HANS-CN: 在某些情况下，某些版本的 'diff ' 不能正确检测到文件末尾缺少的换行。因此，由这类 'diff' 程序创建的补丁不能正确记录不完整的行。这个选项通过解决这个错误来增加对应用这种补丁的支持。

note: type: Plain text
en: Report progress to stderr. By default, only a message about the current patch being applied will be printed. This option will cause additional information to be reported.
zh_HANS-CN: 向标准错误流报告进度。默认情况下，只有关于当前正在应用的补丁的信息会被打印出来。这个选项将导致报告额外的信息。

note: type: Plain text
en: Suppress stderr output. Messages about patch status and progress will not be printed.
zh_HANS-CN: 抑制标准错误流输出。关于补丁状态和进度的信息将不被打印。

note: type: Plain text
en: Do not trust the line counts in the hunk headers, but infer them by inspecting the patch (e.g. after editing the patch without adjusting the hunk headers appropriately).
zh_HANS-CN: 不信任组头中的行数，而是通过检查补丁来推断（例如，在编辑补丁后没有适当调整组头）。

note: type: Plain text
en: Prepend <root> to all filenames.  If a "-p" argument was also passed, it is applied before prepending the new root.
zh_HANS-CN: 将 <根目录> 预置到所有文件名中。 如果还传递了 "-p " 参数，则在预置新根目录之前应用。

note: type: Plain text
en: For example, a patch that talks about updating `a/git-gui.sh` to `b/git-gui.sh` can be applied to the file in the working tree `modules/git-gui/git-gui.sh` by running `git apply --directory=modules/git-gui`.
zh_HANS-CN: 例如，一个关于将 `a/git-gui.sh` 更新为 `b/git-gui.sh` 的补丁可以通过运行 `git apply --directory=modules/git-gui` 来应用于工作区 `modules/git-gui/git-gui.sh` 中的文件。

note: type: Plain text
en: By default, a patch that affects outside the working area (either a Git controlled working tree, or the current working directory when "git apply" is used as a replacement of GNU patch) is rejected as a mistake (or a mischief).
zh_HANS-CN: 默认情况下，影响到工作区域之外（无论是 Git 控制的工作区，还是用 "git apply" 替代 GNU patch 时的当前工作目录）的补丁会被当作错误（或恶作剧）而拒绝。

note: type: Plain text
en: When `git apply` is used as a "better GNU patch", the user can pass the `--unsafe-paths` option to override this safety check.  This option has no effect when `--index` or `--cached` is in use.
zh_HANS-CN: 当 `git apply` 被用作 "更好的 GNU 补丁" 时，用户可以通过 `--unsafe-paths` 选项来覆盖这个安全检查。 当使用 `--index` 或 `--cached` 时，该选项没有作用。

note: type: Plain text
en: Don't return error for patches containing no diff. This includes empty patches and patches with commit text only.
zh_HANS-CN: 对于不包含差异的补丁，不返回错误。这包括空补丁和只有提交文本的补丁。

note: type: Title -
en: SUBMODULES
zh_HANS-CN: 子模块

note: type: Plain text
en: If the patch contains any changes to submodules then 'git apply' treats these changes as follows.
zh_HANS-CN: 如果该补丁包含对子模块的任何修改，那么 'git apply' 会对这些修改进行如下处理。

note: type: Plain text
en: If `--index` is specified (explicitly or implicitly), then the submodule commits must match the index exactly for the patch to apply.  If any of the submodules are checked-out, then these check-outs are completely ignored, i.e., they are not required to be up to date or clean and they are not updated.
zh_HANS-CN: 如果 `--index` 被指定（显式或隐式），那么子模块的提交必须与索引完全匹配，补丁才能应用。 如果任何一个子模块被检出，那么这些检出的模块将被完全忽略，也就是说，它们不需要是最新的或干净的，它们也不会被更新。

note: type: Plain text
en: If `--index` is not specified, then the submodule commits in the patch are ignored and only the absence or presence of the corresponding subdirectory is checked and (if possible) updated.
zh_HANS-CN: 如果没有指定 `--index`，那么补丁中的子模块提交将被忽略，只检查相应的子目录是否存在，并（如果可能）更新。

note: type: Plain text
en: git-archimport - Import a GNU Arch repository into Git
zh_HANS-CN: git-archimport - 将 GNU Arch 仓库导入 Git 中

note: type: Plain text
en: 'git archimport' [-h] [-v] [-o] [-a] [-f] [-T] [-D <depth>] [-t <tempdir>]
    	       <archive>/<branch>[:<git-branch>]...
zh_HANS-CN: 'git archimport' [-h] [-v] [-o] [-a] [-f] [-T] [-D <深度>] [-t <缓存目录>]
    	       <归档>/<分支>[:<git 分支>]...

note: type: Plain text
en: Imports a project from one or more GNU Arch repositories.  It will follow branches and repositories within the namespaces defined by the <archive>/<branch> parameters supplied. If it cannot find the remote branch a merge comes from it will just import it as a regular commit. If it can find it, it will mark it as a merge whenever possible (see discussion below).
zh_HANS-CN: 从一个或多个 GNU Arch 仓库导入一个项目。 它将在所提供的 <归档>/<分支> 参数所定义的命名空间内跟踪分支和仓库。如果它找不到合并后的远程分支，就会把它作为一个普通的提交导入。如果它能找到它，它会尽可能地将其标记为合并（见下面的讨论）。

note: type: Plain text
en: The script expects you to provide the key roots where it can start the import from an 'initial import' or 'tag' type of Arch commit. It will follow and import new branches within the provided roots.
zh_HANS-CN: 该脚本希望你提供关键的根目录，它可以从 'initial' 或 'tag' 类型的 Arch 提交开始导入。它将跟踪并导入所提供的根目录下的新分支。

note: type: Plain text
en: It expects to be dealing with one project only. If it sees branches that have different roots, it will refuse to run. In that case, edit your <archive>/<branch> parameters to define clearly the scope of the import.
zh_HANS-CN: 它希望只处理一个项目。如果它看到有不同根目录的分支，它将拒绝运行。在这种情况下，编辑你的 <归档>/<分支> 参数，以明确定义导入的范围。

note: type: Plain text
en: 'git archimport' uses `tla` extensively in the background to access the Arch repository.  Make sure you have a recent version of `tla` available in the path. `tla` must know about the repositories you pass to 'git archimport'.
zh_HANS-CN: 'git archimport' 在后台广泛使用 `tla` 来访问Arch仓库。 确保你的路径中有一个最新版本的 `tla`。`tla` 必须知道你传递给 'git archimport' 的仓库。

note: type: Plain text
en: While 'git archimport' will try to create sensible branch names for the archives that it imports, it is also possible to specify Git branch names manually.  To do so, write a Git branch name after each <archive>/<branch> parameter, separated by a colon.  This way, you can shorten the Arch branch names and convert Arch jargon to Git jargon, for example mapping a "PROJECT{litdd}devo{litdd}VERSION" branch to "master".
zh_HANS-CN: 虽然 'git archimport' 会尝试为它导入的档案创建合理的分支名，但也可以手动指定 Git 分支名。 要做到这一点，在每个 <归档>/<分支> 参数后面写一个 Git 分支名，用冒号隔开。 这样，你可以缩短 Arch 分支的名称，并将 Arch 的行话转换成 Git 的行话，例如将 "PROJECT{litdd}devo{litdd}VERSION" 分支映射为 "master"。

note: type: Plain text
en: Associating multiple Arch branches to one Git branch is possible; the result will make the most sense only if no commits are made to the first branch, after the second branch is created.  Still, this is useful to convert Arch repositories that had been rotated periodically.
zh_HANS-CN: 将多个 Arch 分支关联到一个 Git 分支是可能的；只有在创建第二个分支后没有向第一个分支提交的情况下，其结果才是最合理的。 不过，这对于转换定期轮换的 Arch 仓库还是很有用的。

note: type: Plain text
en: Patch merge data from Arch is used to mark merges in Git as well. Git does not care much about tracking patches, and only considers a merge when a branch incorporates all the commits since the point they forked. The end result is that Git will have a good idea of how far branches have diverged. So the import process does lose some patch-trading metadata.
zh_HANS-CN: Arch 的补丁合并数据在 Git 中也被用来标记合并。Git 并不关心对补丁的追踪，只有当一个分支包含了自分叉点以来的所有提交时，才会考虑合并。最终的结果是，Git 会很好地了解分支的分歧程度。所以导入过程确实会丢失一些补丁交易的元数据。

note: type: Plain text
en: Fortunately, when you try and merge branches imported from Arch, Git will find a good merge base, and it has a good chance of identifying patches that have been traded out-of-sequence between the branches.
zh_HANS-CN: 幸运的是，当你尝试合并从 Arch 导入的分支时，Git 会找到一个好的合并基础，而且它有很大的机会识别出在分支之间被交易的不符合顺序的补丁。

note: type: Plain text
en: Display usage.
zh_HANS-CN: 显示用途。

note: type: Plain text
en: Many tags. Will create a tag for every commit, reflecting the commit name in the Arch repository.
zh_HANS-CN: 多标签。将为每个提交创建一个标签，反映 Arch 库中的提交名称。

note: type: Plain text
en: Use the fast patchset import strategy.  This can be significantly faster for large trees, but cannot handle directory renames or permissions changes.  The default strategy is slow and safe.
zh_HANS-CN: 使用快速补丁集导入策略。 这对大目录树来说可以明显加快，但不能处理目录重名或权限变化。 默认策略是缓慢而安全的。

note: type: Plain text
en: Use this for compatibility with old-style branch names used by earlier versions of 'git archimport'.  Old-style branch names were category{litdd}branch, whereas new-style branch names are archive,category{litdd}branch{litdd}version.  In both cases, names given on the command-line will override the automatically-generated ones.
zh_HANS-CN: 为了与早期版本的 'git archimport' 所使用的旧式分支名兼容，使用这个名字。 旧式的分支名是 category{litdd}branch，而新式的分支名是 archive,category{litdd}branch{litdd}version。 在这两种情况下，在命令行中给出的名字将覆盖自动生成的名字。

note: type: Plain text
en: Follow merge ancestry and attempt to import trees that have been merged from.  Specify a depth greater than 1 if patch logs have been pruned.
zh_HANS-CN: 遵循合并的祖先，并尝试导入已经合并的目录树。 如果补丁日志已经被修剪，则指定一个大于 1 的深度。

note: type: Plain text
en: Attempt to auto-register archives at `http://mirrors.sourcecontrol.net` This is particularly useful with the -D option.
zh_HANS-CN: 尝试在 `http://mirrors.sourcecontrol.net` 上自动注册档案，这在 -D 选项下特别有用。

note: type: Labeled list
en: -t <tmpdir>
zh_HANS-CN: -t <缓存目录>

note: type: Plain text
en: Override the default tempdir.
zh_HANS-CN: 重写默认缓存目录。

note: type: Plain text
en: <archive>/<branch> identifier in a format that `tla log` understands.
zh_HANS-CN: <归档>/<分支> 标识符的格式是 `tla log` 能理解的。

note: type: Plain text
en: git-archive - Create an archive of files from a named tree
zh_HANS-CN: git-archive - 从命名的目录树中创建一个归档文件

note: type: Plain text
en: Creates an archive of the specified format containing the tree structure for the named tree, and writes it out to the standard output.  If <prefix> is specified it is prepended to the filenames in the archive.
zh_HANS-CN: 创建一个指定格式的档案，包含命名的目录树的结构，并将其写入标准输出。 如果 <前缀> 被指定，它将被预置在归档文件的文件名上。

note: type: Plain text
en: 'git archive' behaves differently when given a tree ID versus when given a commit ID or tag ID.  In the first case the current time is used as the modification time of each file in the archive.  In the latter case the commit time as recorded in the referenced commit object is used instead.  Additionally the commit ID is stored in a global extended pax header if the tar format is used; it can be extracted using 'git get-tar-commit-id'. In ZIP files it is stored as a file comment.
zh_HANS-CN: 'git archive' 在给定树的 ID 和给定提交的 ID 或标签的 ID 时表现不同。 在前一种情况下，当前时间被用作档案中每个文件的修改时间。 在后一种情况下，则使用参考的提交对象中记录的提交时间。 此外，如果使用 tar 格式，提交 ID 会被存储在一个全局扩展的 pax 头中；可以用 'git get-tar-commit-id' 来提取它。在 ZIP 文件中，它被存储为一个文件注释。

note: type: Plain text
en: Format of the resulting archive. Possible values are `tar`, `zip`, `tar.gz`, `tgz`, and any format defined using the configuration option `tar.<format>.command`. If `--format` is not given, and the output file is specified, the format is inferred from the filename if possible (e.g. writing to `foo.zip` makes the output to be in the `zip` format). Otherwise the output format is `tar`.
zh_HANS-CN: 归档文件的格式。可能的值是 `tar`, `zip`, `tar.gz`, `tgz`, 以及使用配置选项 `tar.<格式>.command` 定义的任何格式。如果没有给出 `--format`，并且指定了输出文件，如果可能的话，将从文件名中推断出格式（例如，写入`foo.zip` 会使输出为`zip`格式）。否则，输出格式为`tar`。

note: type: Plain text
en: Show all available formats.
zh_HANS-CN: 显示所有可用的格式。

note: type: Plain text
en: Report progress to stderr.
zh_HANS-CN: 向标准错误流报告进度。

note: type: Plain text
en: Prepend <prefix>/ to paths in the archive.  Can be repeated; its rightmost value is used for all tracked files.  See below which value gets used by `--add-file` and `--add-virtual-file`.
zh_HANS-CN: 将 <前缀>/ 预置到存档中的路径。 可以重复使用；其最右边的值用于所有跟踪的文件。 请看下面的 `--add-file` 和 `--add-virtual-file` 所使用的值。

note: type: Plain text
en: Write the archive to <file> instead of stdout.
zh_HANS-CN: 将存档写入 <文件> 而不是标准输出流。

note: type: Plain text
en: Add a non-tracked file to the archive.  Can be repeated to add multiple files.  The path of the file in the archive is built by concatenating the value of the last `--prefix` option (if any)  before this `--add-file` and the basename of <file>.
zh_HANS-CN: 添加一个非跟踪的文件到存档。 可以重复添加多个文件。 归档文件的路径是由这个 `--add-file` 之前的最后一个 `--prefix` 选项（如果有的话）的值和 <文件> 的基本名称连接而成的。

note: type: Labeled list
en: --add-virtual-file=<path>:<content>
zh_HANS-CN: --add-virtual-file=<路径>:<内容>

note: type: Plain text
en: Add the specified contents to the archive.  Can be repeated to add multiple files.  The path of the file in the archive is built by concatenating the value of the last `--prefix` option (if any)  before this `--add-virtual-file` and `<path>`.
zh_HANS-CN: 将指定的内容添加到档案中。 可以重复添加多个文件。 归档文件的路径是由这个 `--add-virtual-file` 之前的最后一个 `--prefix` 选项（如果有的话）和 `<路径>` 相连而成的。

note: type: Plain text
en: The `<path>` argument can start and end with a literal double-quote character; the contained file name is interpreted as a C-style string, i.e. the backslash is interpreted as escape character. The path must be quoted if it contains a colon, to avoid the colon from being misinterpreted as the separator between the path and the contents, or if the path begins or ends with a double-quote character.
zh_HANS-CN: `<路径>` 参数可以以字面的双引号字符开始和结束；包含的文件名被解释为 C 风格的字符串，即反斜杠被解释为转义字符。如果路径包含一个冒号，则必须加引号，以避免冒号被误解为路径和内容之间的分隔符，或者如果路径以双引号字符开始或结束。

note: type: Plain text
en: The file mode is limited to a regular file, and the option may be subject to platform-dependent command-line limits. For non-trivial cases, write an untracked file and use `--add-file` instead.
zh_HANS-CN: 文件模式被限制为普通文件，该选项可能会受到依赖平台的命令行的限制。对于非复杂的情况，写一个非跟踪的文件并使用 `--add-file` 代替。

note: type: Plain text
en: Look for attributes in .gitattributes files in the working tree as well (see <<ATTRIBUTES>>).
zh_HANS-CN: 也可以在工作区中的 .gitattributes 文件中寻找属性（见 <<ATTRIBUTES>>）。

note: type: Plain text
en: Set modification time of archive entries.  Without this option the committer time is used if `<tree-ish>` is a commit or tag, and the current time if it is a tree.
zh_HANS-CN: 设置存档条目的修改时间。 如果没有这个选项，如果 `<树状对象>` 是一个提交或标签，则使用提交者的时间，如果是一个树，则使用当前时间。

note: type: Plain text
en: This can be any options that the archiver backend understands.  See next section.
zh_HANS-CN: 这可以是存档器后端能理解的任何选项。 见下一节。

note: type: Plain text
en: Instead of making a tar archive from the local repository, retrieve a tar archive from a remote repository. Note that the remote repository may place restrictions on which sha1 expressions may be allowed in `<tree-ish>`. See linkgit:git-upload-archive[1] for details.
zh_HANS-CN: 与其从本地版本库制作一个 tar 归档，不如从远程版本库检索一个 tar 归档。注意，远程仓库可能会对 `<树状对象>` 中允许的 sha1 表达式进行限制。详情见 linkgit:git-upload-archive[1]。

note: type: Plain text
en: Used with --remote to specify the path to the 'git-upload-archive' on the remote side.
zh_HANS-CN: 与 --remote 一起使用，指定远程端的 "git-upload-archive" 的路径。

note: type: Plain text
en: The tree or commit to produce an archive for.
zh_HANS-CN: 要制作存档的树目录或提交。

note: type: Plain text
en: Without an optional path parameter, all files and subdirectories of the current working directory are included in the archive.  If one or more paths are specified, only these are included.
zh_HANS-CN: 如果没有可选的路径参数，当前工作目录下的所有文件和子目录都会包括在存档中。  如果指定了一个或多个路径，则只包括这些路径。

note: type: Title -
en: BACKEND EXTRA OPTIONS
zh_HANS-CN: 后台额外选项

note: type: Labeled list
en: -<digit>
zh_HANS-CN: -<数字 0-9>

note: type: Plain text
en: Specify compression level.  Larger values allow the command to spend more time to compress to smaller size.  Supported values are from `-0` (store-only) to `-9` (best ratio).  Default is `-6` if not given.
zh_HANS-CN: 指定压缩级别。 较大的值允许命令花费更多的时间来压缩到较小的尺寸。 支持的值从 `-0`（只存储）到 `-9`（最佳比例）。 如果没有给出，默认为 `-6'。

note: type: Labeled list
en: -<number>
zh_HANS-CN: -<数>

note: type: Plain text
en: Specify compression level. The value will be passed to the compression command configured in `tar.<format>.command`. See manual page of the configured command for the list of supported levels and the default level if this option isn't specified.
zh_HANS-CN: 指定压缩级别。该值将被传递给 `tar.<格式>.command` 中配置的压缩命令。如果没有指定这个选项，请参阅配置的命令的手册页，了解支持的级别和默认级别。

note: type: Plain text
en: This variable can be used to restrict the permission bits of tar archive entries.  The default is 0002, which turns off the world write bit.  The special value "user" indicates that the archiving user's umask will be used instead.  See umask(2) for details.  If `--remote` is used then only the configuration of the remote repository takes effect.
zh_HANS-CN: 这个变量可以用来限制 tar 存档条目的权限位。 默认值是 0002，它关闭了世界写入位。 特殊值 "user" 表示将使用归档用户的 umask 来代替。 详情见 umask(2)。 如果使用 `--remote`，那么只有远程仓库的配置才会生效。

note: type: Labeled list
en: tar.<format>.command
zh_HANS-CN: tar.<格式>.command

note: type: Plain text
en: This variable specifies a shell command through which the tar output generated by `git archive` should be piped. The command is executed using the shell with the generated tar file on its standard input, and should produce the final output on its standard output. Any compression-level options will be passed to the command (e.g., `-9`).
zh_HANS-CN: 这个变量指定了一个 shel l命令，由 `git archive` 产生的 tar 输出应该通过管道。该命令使用 shell 执行，在其标准输入中生成 tar 文件，并应在其标准输出中产生最终输出。任何压缩级别的选项将被传递给该命令（例如，`-9'）。

note: type: Plain text
en: The `tar.gz` and `tgz` formats are defined automatically and use the magic command `git archive gzip` by default, which invokes an internal implementation of gzip.
zh_HANS-CN: `tar.gz` 和 `tgz` 格式是自动定义的，默认使用神奇的命令 `git archive gzip`，它调用了 gzip 的内部实现。

note: type: Plain text
en: If true, enable the format for use by remote clients via linkgit:git-upload-archive[1]. Defaults to false for user-defined formats, but true for the `tar.gz` and `tgz` formats.
zh_HANS-CN: 如果为真，则通过 linkgit:git-upload-archive[1] 启用该格式供远程客户端使用。对于用户定义的格式，默认为 false，但对于 `tar.gz` 和 `tgz` 格式为 true。

note: type: Plain text
en: Files and directories with the attribute export-ignore won't be added to archive files.  See linkgit:gitattributes[5] for details.
zh_HANS-CN: 带有 export-ignore 属性的文件和目录不会被添加到存档文件中。 详情见 linkgit:gitattributes[5]。

note: type: Plain text
en: If the attribute export-subst is set for a file then Git will expand several placeholders when adding this file to an archive.  See linkgit:gitattributes[5] for details.
zh_HANS-CN: 如果为一个文件设置了 export-subst 属性，那么当把这个文件添加到存档时，Git 会展开几个占位符。 详情见 linkgit:gitattributes[5]。

note: type: Plain text
en: Note that attributes are by default taken from the `.gitattributes` files in the tree that is being archived.  If you want to tweak the way the output is generated after the fact (e.g. you committed without adding an appropriate export-ignore in its `.gitattributes`), adjust the checked out `.gitattributes` file as necessary and use `--worktree-attributes` option.  Alternatively you can keep necessary attributes that should apply while archiving any tree in your `$GIT_DIR/info/attributes` file.
zh_HANS-CN: 注意，默认情况下，属性来自被归档的树中的 `.gitattributes` 文件。 如果你想在事后调整输出的方式（例如，你提交时没有在其 `.gitattributes` 中添加适当的 export-ignore ），请根据需要调整检查出来的 `.gitattributes` 文件并使用 `--worktreeattributes` 选项。 另外，你也可以在你的 `$GIT_DIR/info/attributes` 文件中保留归档任何树时应该适用的必要属性。

note: type: Plain text
en: Create a tar archive that contains the contents of the latest commit on the current branch, and extract it in the `/var/tmp/junk` directory.
zh_HANS-CN: 创建一个包含当前分支上最新提交内容的 tar 归档文件，并将其解压到 `/var/tmp/junk` 目录中。

note: type: Plain text
en: Create a compressed tarball for v1.4.0 release.
zh_HANS-CN: 为 v1.4.0 版本创建一个压缩的压缩包。

note: type: Plain text
en: Same as above, but using the builtin tar.gz handling.
zh_HANS-CN: 和上面一样，但使用内置的 tar.gz 处理。

note: type: Plain text
en: Same as above, but the format is inferred from the output file.
zh_HANS-CN: 与上述相同，但格式是从输出文件中推断出来的。

note: type: Plain text
en: Create a compressed tarball for v1.4.0 release, but without a global extended pax header.
zh_HANS-CN: 为 v1.4.0 版本创建一个压缩的 tarball，但没有全局扩展的 pax 头。

note: type: Plain text
en: Put everything in the current head's Documentation/ directory into 'git-1.4.0-docs.zip', with the prefix 'git-docs/'.
zh_HANS-CN: 将当前头文件或目录下的所有内容放入 'git-1.4.0-docs.zip'，前缀为 'git-docs/'。

note: type: Plain text
en: Create a Zip archive that contains the contents of the latest commit on the current branch. Note that the output format is inferred by the extension of the output file.
zh_HANS-CN: 创建一个包含当前分支上最新提交内容的 Zip 档案。注意，输出格式是由输出文件的扩展名推断出来的。

note: type: Plain text
en: Creates a tar archive that contains the contents of the latest commit on the current branch with no prefix and the untracked file 'configure' with the prefix 'build/'.
zh_HANS-CN: 创建一个 tar 归档文件，其中包含当前分支上的最新提交内容，无前缀，以及无跟踪的文件 'configure'，前缀为 'build/'。

note: type: Plain text
en: Configure a "tar.xz" format for making LZMA-compressed tarfiles.  You can use it specifying `--format=tar.xz`, or by creating an output file like `-o foo.tar.xz`.
zh_HANS-CN: 配置一个 "tar.xz" 格式来制作 LZMA 压缩的 tarf 文件。 你可以指定 `--format=tar.xz` 来使用它，或者通过创建一个像 `-o foo.tar.xz` 这样的输出文件。

note: type: Plain text
en: git-bisect - Use binary search to find the commit that introduced a bug
zh_HANS-CN: git-bisect - 使用二进制搜索查找引入错误的提交。

note: type: Plain text
en: The command takes various subcommands, and different options depending on the subcommand:
zh_HANS-CN: 该命令采取不同的子命令，并根据子命令有不同的选项：

note: type: Plain text
en: This command uses a binary search algorithm to find which commit in your project's history introduced a bug. You use it by first telling it a "bad" commit that is known to contain the bug, and a "good" commit that is known to be before the bug was introduced. Then `git bisect` picks a commit between those two endpoints and asks you whether the selected commit is "good" or "bad". It continues narrowing down the range until it finds the exact commit that introduced the change.
zh_HANS-CN: 这个命令使用二分搜索算法来查找项目历史中哪个提交引入了一个错误。使用该命令时，首先告诉它一个已知包含错误的 "坏" 提交，以及一个已知在错误出现之前的 "好" 提交。然后 `git bisect` 在这两个端点之间挑选一个提交，并询问你所选的提交是 "好" 还是 "坏"。它继续缩小范围，直到找到引入该修改的确切提交。

note: type: Plain text
en: In fact, `git bisect` can be used to find the commit that changed *any* property of your project; e.g., the commit that fixed a bug, or the commit that caused a benchmark's performance to improve. To support this more general usage, the terms "old" and "new" can be used in place of "good" and "bad", or you can choose your own terms. See section "Alternate terms" below for more information.
zh_HANS-CN: 事实上，`git bisect` 可以用来查找改变项目 *任何* 属性的提交；例如，修复了一个 bug 的提交，或者使一个基准的性能得到改善的提交。为了支持这种更普遍的用法，可以用 "old" 和 "new" 来代替 "good" 和 "bad"，或者您可以选择自己的术语。更多信息见下文 "替代术语 "一节。

note: type: Title ~
en: Basic bisect commands: start, bad, good
zh_HANS-CN: 基本的二分命令：start, bad, good

note: type: Plain text
en: As an example, suppose you are trying to find the commit that broke a feature that was known to work in version `v2.6.13-rc2` of your project. You start a bisect session as follows:
zh_HANS-CN: 举个例子，假设你想找到破坏了一个已知在你的项目的 `v2.6.13-rc2` 版本中工作的特性的提交。你启动了一个 bisect 会话，如下所示：

note: type: Plain text
en: Once you have specified at least one bad and one good commit, `git bisect` selects a commit in the middle of that range of history, checks it out, and outputs something similar to the following:
zh_HANS-CN: 一旦你指定了至少一个坏的和一个好的提交，`git bisect` 就会在这个历史范围的中间选择一个提交，检查它，并输出类似于以下的内容：

note: type: delimited block -
en: Bisecting: 675 revisions left to test after this (roughly 10 steps)
zh_HANS-CN: Bisecting: 675 revisions left to test after this (roughly 10 steps) | 在这之后，还有675次修订需要测试（大约10步）

note: type: Plain text
en: You should now compile the checked-out version and test it. If that version works correctly, type
zh_HANS-CN: 你现在应该编译检出的版本并进行测试。如果该版本工作正常，请输入

note: type: Plain text
en: If that version is broken, type
zh_HANS-CN: 如果该版本被破坏，请输入

note: type: Plain text
en: Then `git bisect` will respond with something like
zh_HANS-CN: 然后，`git bisect`会做出如下反应

note: type: delimited block -
en: Bisecting: 337 revisions left to test after this (roughly 9 steps)
zh_HANS-CN: Bisecting: 337 revisions left to test after this (roughly 9 steps) | 在这之后还有337个修订要测试（大约9个步骤）。

note: type: Plain text
en: Keep repeating the process: compile the tree, test it, and depending on whether it is good or bad run `git bisect good` or `git bisect bad` to ask for the next commit that needs testing.
zh_HANS-CN: 不断重复这个过程：编译树，测试它，根据它是好是坏，运行 `git bisect good` 或 `git bisect bad` 来要求下一个需要测试的提交。

note: type: Plain text
en: Eventually there will be no more revisions left to inspect, and the command will print out a description of the first bad commit. The reference `refs/bisect/bad` will be left pointing at that commit.
zh_HANS-CN: 最终，将没有更多的修订可以检查，该命令将打印出第一个坏提交的描述。引用 `refs/bisect/bad` 将被留在该提交处。

note: type: Title ~
en: Bisect reset
zh_HANS-CN: 重置二分查找

note: type: Plain text
en: After a bisect session, to clean up the bisection state and return to the original HEAD, issue the following command:
zh_HANS-CN: 在一个二分查找会话之后，要清理二分查找状态并返回到原来的 HEAD，请发出以下命令：

note: type: Plain text
en: By default, this will return your tree to the commit that was checked out before `git bisect start`.  (A new `git bisect start` will also do that, as it cleans up the old bisection state.)
zh_HANS-CN: 默认情况下，这将使你的树返回到 `git bisect start` 之前检查出来的提交。 (新的 `git bisect start` 也会这样做，因为它清理了旧的分界状态）

note: type: Plain text
en: With an optional argument, you can return to a different commit instead:
zh_HANS-CN: 通过一个可选参数，你可以返回到一个不同的提交，而不是：

note: type: Plain text
en: For example, `git bisect reset bisect/bad` will check out the first bad revision, while `git bisect reset HEAD` will leave you on the current bisection commit and avoid switching commits at all.
zh_HANS-CN: 例如，`git bisect reset bisect/bad` 会检查出第一个坏的修订，而 `git bisect reset HEAD` 会让你停留在当前的分界提交上，完全避免切换提交。

note: type: Title ~
en: Alternate terms
zh_HANS-CN: 替代条款

note: type: Plain text
en: Sometimes you are not looking for the commit that introduced a breakage, but rather for a commit that caused a change between some other "old" state and "new" state. For example, you might be looking for the commit that introduced a particular fix. Or you might be looking for the first commit in which the source-code filenames were finally all converted to your company's naming standard. Or whatever.
zh_HANS-CN: 有时，您要找的不是引入断裂的提交，而是在其他 "旧" 状态和 "新" 状态之间引起变化的提交。例如，你可能要找的是引入某项修复的提交。或者你想找的是第一次提交，在这次提交中，源代码文件名最终都被转换为你公司的命名标准。或者其他什么。

note: type: Plain text
en: In such cases it can be very confusing to use the terms "good" and "bad" to refer to "the state before the change" and "the state after the change". So instead, you can use the terms "old" and "new", respectively, in place of "good" and "bad". (But note that you cannot mix "good" and "bad" with "old" and "new" in a single session.)
zh_HANS-CN: 在这种情况下，用 "好" 和 "坏" 来指代 "变化前的状态" 和 "变化后的状态" 会非常混乱。因此，你可以用 "旧 "和 "新" 来代替 "好" 和 "坏"。(但要注意，你不能在一个会话中把 "好"和 "坏" 与 "旧"和 "新" 混在一起）。

note: type: Plain text
en: In this more general usage, you provide `git bisect` with a "new" commit that has some property and an "old" commit that doesn't have that property. Each time `git bisect` checks out a commit, you test if that commit has the property. If it does, mark the commit as "new"; otherwise, mark it as "old". When the bisection is done, `git bisect` will report which commit introduced the property.
zh_HANS-CN: 在这种更普遍的用法中，你向 `git bisect` 提供了一个具有某种属性的 "新" 提交和一个不具有该属性的 "旧" 提交。每次 `git bisect` 检查一个提交时，都要测试该提交是否具有该属性。如果有，则将该提交标记为 "新"；否则，标记为 "旧"。分割完成后，`git bisect` 会报告哪个提交引入了该属性。

note: type: Plain text
en: To use "old" and "new" instead of "good" and bad, you must run `git bisect start` without commits as argument and then run the following commands to add the commits:
zh_HANS-CN: 要使用 "旧" 和 "新"，而不是 "好" 和 "坏"，你必须运行 `git bisect start`，而不以提交为参数，然后运行以下命令来添加提交：

note: type: Plain text
en: to indicate that a commit was before the sought change, or
zh_HANS-CN: 表明提交时间在所寻求的变更之前，或

note: type: Plain text
en: to indicate that it was after.
zh_HANS-CN: 以表明它是在之后。

note: type: Plain text
en: To get a reminder of the currently used terms, use
zh_HANS-CN: 要获得当前使用的术语的提醒，请使用

note: type: Plain text
en: You can get just the old (respectively new) term with `git bisect terms --term-old` or `git bisect terms --term-good`.
zh_HANS-CN: 你可以用 `git bisect terms --term-old` 或 `git bisect terms --term-good` 只得到旧的（分别是新的）术语。

note: type: Plain text
en: For example, if you are looking for a commit that introduced a performance regression, you might use
zh_HANS-CN: 例如，如果你要找一个引入性能回归的提交，你可以用

note: type: Plain text
en: Or if you are looking for the commit that fixed a bug, you might use
zh_HANS-CN: 或者，如果你要找的是修复了某个错误的提交，你可以使用

note: type: Plain text
en: Then, use `git bisect <term-old>` and `git bisect <term-new>` instead of `git bisect good` and `git bisect bad` to mark commits.
zh_HANS-CN: 然后，用`git bisect <term-old>` 和 `git bisect <term-new>` 代替 `git bisect good` 和`git bisect bad` 来标记提交。

note: type: Title ~
en: Bisect visualize/view
zh_HANS-CN: 视觉化/视图的二分查找

note: type: Plain text
en: To see the currently remaining suspects in 'gitk', issue the following command during the bisection process (the subcommand `view` can be used as an alternative to `visualize`):
zh_HANS-CN: 要查看 'gitk' 中当前剩余的嫌疑人，在二分查找过程中发出以下命令（子命令`view`可以用来替代`visualize`）：

note: type: Plain text
en: If the `DISPLAY` environment variable is not set, 'git log' is used instead.  You can also give command-line options such as `-p` and `--stat`.
zh_HANS-CN: 如果没有设置 `DISPLAY` 环境变量，则使用 'git log' 代替。 你也可以给出命令行选项，如 `-p` 和 `-stat`。

note: type: Title ~
en: Bisect log and bisect replay
zh_HANS-CN: 二分查找日志和重放二分查找

note: type: Plain text
en: After having marked revisions as good or bad, issue the following command to show what has been done so far:
zh_HANS-CN: 在将修订标记为好的或坏的之后，发出以下命令来显示到目前为止所做的事情：

note: type: Plain text
en: If you discover that you made a mistake in specifying the status of a revision, you can save the output of this command to a file, edit it to remove the incorrect entries, and then issue the following commands to return to a corrected state:
zh_HANS-CN: 如果你发现你在指定修订版的状态时犯了错误，你可以把这个命令的输出保存到一个文件中，编辑它以删除不正确的条目，然后发出下面的命令来返回到一个正确的状态：

note: type: Title ~
en: Avoiding testing a commit
zh_HANS-CN: 避免测试一个提交

note: type: Plain text
en: If, in the middle of a bisect session, you know that the suggested revision is not a good one to test (e.g. it fails to build and you know that the failure does not have anything to do with the bug you are chasing), you can manually select a nearby commit and test that one instead.
zh_HANS-CN: 如果在二分查找会话中，你知道建议的修订版不是一个好的测试对象（例如，它不能构建，而你知道这个失败与你正在追寻的错误无关），你可以手动选择一个附近的提交，并测试该提交。

note: type: Plain text
en: Then compile and test the chosen revision, and afterwards mark the revision as good or bad in the usual manner.
zh_HANS-CN: 然后编译和测试所选择的修订版，之后以通常的方式将修订版标记为好或坏。

note: type: Title ~
en: Bisect skip
zh_HANS-CN: 跳过二分查找

note: type: Plain text
en: Instead of choosing a nearby commit by yourself, you can ask Git to do it for you by issuing the command:
zh_HANS-CN: 与其自己选择附近的提交，你可以通过发布命令让 Git 为你做这件事：

note: type: delimited block -
en: $ git bisect skip                 # Current version cannot be tested
zh_HANS-CN: $ git bisect skip                                # 当前版本不能被测试

note: type: Plain text
en: However, if you skip a commit adjacent to the one you are looking for, Git will be unable to tell exactly which of those commits was the first bad one.
zh_HANS-CN: 然而，如果你跳过了与你要找的提交相邻的提交，Git 将无法准确判断出哪个提交是第一个坏提交。

note: type: Plain text
en: You can also skip a range of commits, instead of just one commit, using range notation. For example:
zh_HANS-CN: 您也可以使用范围符号跳过一系列的提交，而不仅仅是一个提交。比如说：

note: type: Plain text
en: This tells the bisect process that no commit after `v2.5`, up to and including `v2.6`, should be tested.
zh_HANS-CN: 这告诉二分查找进程，`v2.5` 之后的提交，包括 `v2.6`，都不应该被测试。

note: type: Plain text
en: Note that if you also want to skip the first commit of the range you would issue the command:
zh_HANS-CN: 请注意，如果你也想跳过范围内的第一个提交，你会发出这个命令：

note: type: Plain text
en: This tells the bisect process that the commits between `v2.5` and `v2.6` (inclusive) should be skipped.
zh_HANS-CN: 这告诉二分查找进程，应该跳过 `v2.5` 和 `v2.6`（包括）之间的提交。

note: type: Title ~
en: Cutting down bisection by giving more parameters to bisect start
zh_HANS-CN: 通过提供更多的参数来削减二分查找的起点

note: type: Plain text
en: You can further cut down the number of trials, if you know what part of the tree is involved in the problem you are tracking down, by specifying path parameters when issuing the `bisect start` command:
zh_HANS-CN: 如果你知道你要追踪的问题涉及到树的哪一部分，你可以通过在发出 `bisect start` 命令时指定路径参数来进一步减少试验的数量：

note: type: Plain text
en: If you know beforehand more than one good commit, you can narrow the bisect space down by specifying all of the good commits immediately after the bad commit when issuing the `bisect start` command:
zh_HANS-CN: 如果你事先知道有一个以上的好的提交，你可以在发出 `bisect start ` 命令时，指定坏的提交之后的所有好的提交，从而缩小二分查找的空间：

note: type: Title ~
en: Bisect run
zh_HANS-CN: 运行二分查找

note: type: Plain text
en: If you have a script that can tell if the current source code is good or bad, you can bisect by issuing the command:
zh_HANS-CN: 如果你有一个脚本，可以知道当前的源代码是好是坏，你可以通过发出命令来进行二分查找：

note: type: Plain text
en: Note that the script (`my_script` in the above example) should exit with code 0 if the current source code is good/old, and exit with a code between 1 and 127 (inclusive), except 125, if the current source code is bad/new.
zh_HANS-CN: 注意，如果当前的源代码是好的或是旧的，脚本（上面例子中的 `my_script`）应该以代码 0 退出，如果当前的源代码是坏的或是新的，则以代码 1到 127（包括）之间退出，但 125 除外。

note: type: Plain text
en: Any other exit code will abort the bisect process. It should be noted that a program that terminates via `exit(-1)` leaves $? = 255, (see the exit(3) manual page), as the value is chopped with `& 0377`.
zh_HANS-CN: 任何其他的退出代码都会中止二分查找进程。应该注意的是，通过 `exit(-1)` 终止的程序会留下 $? = 255，（见 exit(3) 手册页），因为这个值是用 `& 0377` 砍掉的。

note: type: Plain text
en: The special exit code 125 should be used when the current source code cannot be tested. If the script exits with this code, the current revision will be skipped (see `git bisect skip` above). 125 was chosen as the highest sensible value to use for this purpose, because 126 and 127 are used by POSIX shells to signal specific error status (127 is for command not found, 126 is for command found but not executable--these details do not matter, as they are normal errors in the script, as far as `bisect run` is concerned).
zh_HANS-CN: 当当前的源代码不能被测试时，应该使用特殊的退出代码 125。如果脚本以这个代码退出，当前的修订版将被跳过（见上面的 `git bisect skip`）。125 被选为用于此目的的最高合理值，因为 126 和 127 被 POSIX shells 用来表示特定的错误状态（127 表示未找到命令，126 表示找到命令但不可执行——这些细节并不重要，因为就 `bisect run` 而言，它们是脚本中的正常错误）。

note: type: Plain text
en: You may often find that during a bisect session you want to have temporary modifications (e.g. s/#define DEBUG 0/#define DEBUG 1/ in a header file, or "revision that does not have this commit needs this patch applied to work around another problem this bisection is not interested in") applied to the revision being tested.
zh_HANS-CN: 你可能经常发现，在一个二分查找会话中，你想让临时的修改（例如，头文件中的 /#define DEBUG 0/#define DEBUG 1/，或者 “没有这个提交的版本需要应用这个补丁来解决这个查找不感兴趣的另一个问题”）应用到正在测试的版本中。

note: type: Plain text
en: To cope with such a situation, after the inner 'git bisect' finds the next revision to test, the script can apply the patch before compiling, run the real test, and afterwards decide if the revision (possibly with the needed patch) passed the test and then rewind the tree to the pristine state.  Finally the script should exit with the status of the real test to let the `git bisect run` command loop determine the eventual outcome of the bisect session.
zh_HANS-CN: 为了应对这种情况，在内部的 'git bisect' 找到要测试的下一个修订版后，脚本可以在编译前应用补丁，运行真正的测试，之后决定该修订版（可能有需要的补丁）是否通过测试，然后将树倒回原始状态。 最后，脚本应该以真实测试的状态退出，让 `git bisect run` 命令循环决定二分查找会话的最终结果。

note: type: Plain text
en: Do not checkout the new working tree at each iteration of the bisection process. Instead just update a special reference named `BISECT_HEAD` to make it point to the commit that should be tested.
zh_HANS-CN: 在二分查找过程的每个迭代中，不要检出新的工作区。相反，只需更新一个名为 `BISECT_HEAD` 的特殊引用，使其指向应被测试的提交。

note: type: Plain text
en: This option may be useful when the test you would perform in each step does not require a checked out tree.
zh_HANS-CN: 当你在每个步骤中执行的测试不需要检查出来的目录树时，这个选项可能很有用。

note: type: Plain text
en: If the repository is bare, `--no-checkout` is assumed.
zh_HANS-CN: 如果版本库是裸仓库，则假定 `--no-checkout`。

note: type: Plain text
en: Follow only the first parent commit upon seeing a merge commit.
zh_HANS-CN: 在看到合并提交时，只跟随第一个父提交。

note: type: Plain text
en: In detecting regressions introduced through the merging of a branch, the merge commit will be identified as introduction of the bug and its ancestors will be ignored.
zh_HANS-CN: 在检测通过合并分支引入的回归时，合并后的提交将被识别为引入了该错误，其祖先将被忽略。

note: type: Plain text
en: This option is particularly useful in avoiding false positives when a merged branch contained broken or non-buildable commits, but the merge itself was OK.
zh_HANS-CN: 这个选项在避免假阳性方面特别有用，当一个合并的分支包含有破损或不可构建的提交，但合并本身是正常的。

note: type: Plain text
en: Automatically bisect a broken build between v1.2 and HEAD:
zh_HANS-CN: 自动将 V1.2 和 HEAD 之间的破损构建二分查找：

note: type: Plain text
en: Automatically bisect a test failure between origin and HEAD:
zh_HANS-CN: 在起源和HEAD之间自动二分查找失败测试：

note: type: Plain text
en: Automatically bisect a broken test case:
zh_HANS-CN: 自动二分查找错误的的测试用例：

note: type: delimited block -
en: $ cat ~/test.sh
    #!/bin/sh
    make || exit 125                     # this skips broken builds
    ~/check_test_case.sh                 # does the test case pass?
    $ git bisect start HEAD HEAD~10 --   # culprit is among the last 10
    $ git bisect run ~/test.sh
    $ git bisect reset                   # quit the bisect session
zh_HANS-CN: $ cat ~/test.sh
    #!/bin/sh
    make || exit 125                     # 跳过了错误构建
    ~/check_test_case.sh                 # 测试案例是否通过？
    $ git bisect start HEAD HEAD~10 --   # 罪魁祸首就在最后10个中
    $ git bisect run ~/test.sh
    $ git bisect reset                   # 退出二分查找会话

note: type: Plain text
en: Here we use a `test.sh` custom script. In this script, if `make` fails, we skip the current commit.  `check_test_case.sh` should `exit 0` if the test case passes, and `exit 1` otherwise.
zh_HANS-CN: 这里我们使用一个 `test.sh `自定义脚本。在这个脚本中，如果 `make` 失败，我们就跳过当前的提交。 `check_test_case.sh` 如果测试用例通过，应该 `exit 0`，否则 `exit 1`。

note: type: Plain text
en: It is safer if both `test.sh` and `check_test_case.sh` are outside the repository to prevent interactions between the bisect, make and test processes and the scripts.
zh_HANS-CN: 如果 `test.sh` 和 `check_test_case.sh `都在仓库之外，以防止 bisect、make 和 test 进程与脚本之间的相互作用，这样会更安全。

note: type: Plain text
en: Automatically bisect with temporary modifications (hot-fix):
zh_HANS-CN: 用临时修改的方式自动二分查找（热修复）：

note: type: delimited block -
en: # tweak the working tree by merging the hot-fix branch
    # and then attempt a build
    if	git merge --no-commit --no-ff hot-fix &&
    	make
    then
    	# run project specific test and report its status
    	~/check_test_case.sh
    	status=$?
    else
    	# tell the caller this is untestable
    	status=125
    fi
zh_HANS-CN: # 通过合并热修复来调整工作区
    # 然后尝试构建
    if	git merge --no-commit --no-ff hot-fix &&
    	make
    then
    	# 运行项目特定的测试并报告其状态
    	~/check_test_case.sh
    	status=$?
    else
    	# 告知发起进程这是不可测试的
    	status=125
    fi

note: type: delimited block -
en: # undo the tweak to allow clean flipping to the next commit
    git reset --hard
zh_HANS-CN: # 撤销调整，以便干净利落地翻转到下一次提交
    git reset --hard

note: type: delimited block -
en: # return control
    exit $status
zh_HANS-CN: # 交回控制权
    exit $status

note: type: Plain text
en: This applies modifications from a hot-fix branch before each test run, e.g. in case your build or test environment changed so that older revisions may need a fix which newer ones have already. (Make sure the hot-fix branch is based off a commit which is contained in all revisions which you are bisecting, so that the merge does not pull in too much, or use `git cherry-pick` instead of `git merge`.)
zh_HANS-CN: 这是在每次测试前应用热修复分支的修改，例如，如果你的构建或测试环境发生变化，老版本可能需要一个新版本的修复。(确保热修复分支是基于一个包含在所有修订版中的提交，这样合并时就不会拉入太多，或者使用 `git cherry-pick` 代替 `git merge`。)

note: type: Plain text
en: This shows that you can do without a run script if you write the test on a single line.
zh_HANS-CN: 这表明，如果你把测试写在一行上，你可以不使用运行脚本。

note: type: Plain text
en: Locate a good region of the object graph in a damaged repository
zh_HANS-CN: 在受损的存储库中找到对象图的一个良好区域

note: type: Plain text
en: In this case, when 'git bisect run' finishes, bisect/bad will refer to a commit that has at least one parent whose reachable graph is fully traversable in the sense required by 'git pack objects'.
zh_HANS-CN: 在这种情况下，当 'git bisect run' 完成时，bisect/bad 将指的是至少有一个父级的提交，其可达图在 'git pack objects' 的意义上是完全可穿越的。

note: type: Plain text
en: Look for a fix instead of a regression in the code
zh_HANS-CN: 在代码中寻找修复而不是回归的方法

note: type: Plain text
en: or:
zh_HANS-CN: 或：

note: type: Title ~
en: Getting help
zh_HANS-CN: 获得帮助

note: type: Plain text
en: Use `git bisect` to get a short usage description, and `git bisect help` or `git bisect -h` to get a long usage description.
zh_HANS-CN: 使用 `git bisect` 获得简短的使用说明，使用 `git bisect help` 或 `git bisect -h` 获得长的使用说明。

note: type: Plain text
en: link:git-bisect-lk2009.html[Fighting regressions with git bisect], linkgit:git-blame[1].
zh_HANS-CN: link:git-bisect-lk2009.html [用 git bisect 对抗回归]，linkgit:git-blame[1]。

note: type: Plain text
en: Annotates each line in the given file with information from the revision which last modified the line. Optionally, start annotating from the given revision.
zh_HANS-CN: 用最后一次修改该行的修订版的信息来注释给定文件中的每一行。可以选择从给定的修订版开始做注释。

note: type: Plain text
en: When specified one or more times, `-L` restricts annotation to the requested lines.
zh_HANS-CN: 当指定一次或多次时，`-L` 将注释限制在要求的行中。

note: type: Plain text
en: The origin of lines is automatically followed across whole-file renames (currently there is no option to turn the rename-following off). To follow lines moved from one file to another, or to follow lines that were copied and pasted from another file, etc., see the `-C` and `-M` options.
zh_HANS-CN: 在整个文件的重命名过程中，行的起源被自动跟踪（目前没有选项可以关闭重命名跟踪）。要跟踪从一个文件移到另一个文件的行，或者跟踪从另一个文件复制和粘贴的行，等等，请参见 `-C` 和 `-M` 选项。

note: type: Plain text
en: The report does not tell you anything about lines which have been deleted or replaced; you need to use a tool such as 'git diff' or the "pickaxe" interface briefly mentioned in the following paragraph.
zh_HANS-CN: 报告不会告诉你任何关于被删除或替换的行的信息；你需要使用一个工具，如 'git diff' 或下段中简要提到的 'pickaxe' 接口。

note: type: Plain text
en: Apart from supporting file annotation, Git also supports searching the development history for when a code snippet occurred in a change. This makes it possible to track when a code snippet was added to a file, moved or copied between files, and eventually deleted or replaced. It works by searching for a text string in the diff. A small example of the pickaxe interface that searches for `blame_usage`:
zh_HANS-CN: 除了支持文件注释外，Git 还支持在开发历史中搜索代码片段何时发生变化。这使得追踪一个代码片段何时被添加到一个文件，在文件之间移动或复制，以及最终被删除或替换成为可能。它的工作原理是在差异中搜索一个文本字符串。一个搜索 `blame_usage` 的 pickaxe 界面的小例子：

note: type: Plain text
en: Include debugging information related to the movement of lines between files (see `-C`) and lines moved within a file (see `-M`).  The first number listed is the score.  This is the number of alphanumeric characters detected as having been moved between or within files.  This must be above a certain threshold for 'git blame' to consider those lines of code to have been moved.
zh_HANS-CN: 包括与文件之间行的移动（见 `-C`）和文件内行的移动（见 `-M`）有关的调试信息。 列出的第一个数字是分数。 这是检测到的在文件间或文件内移动的字母数字字符的数量。 这个数字必须超过一定的阈值，'git blame' 才会认为这些代码行被移动了。

note: type: Plain text
en: Show the filename in the original commit.  By default the filename is shown if there is any line that came from a file with a different name, due to rename detection.
zh_HANS-CN: 显示原始提交中的文件名。 默认情况下，如果有任何一行来自不同名字的文件，由于重名检测，文件名会显示出来。

note: type: Plain text
en: Show the line number in the original commit (Default: off).
zh_HANS-CN: 显示原始提交中的行号（默认：off）。

note: type: Plain text
en: Suppress the author name and timestamp from the output.
zh_HANS-CN: 抑制输出中的作者姓名和时间戳。

note: type: Plain text
en: Show the author email instead of author name (Default: off).  This can also be controlled via the `blame.showEmail` config option.
zh_HANS-CN: 显示作者的电子邮件而不是作者的名字（默认：off）。 这也可以通过 `blame.showEmail` 配置选项来控制。

note: type: Plain text
en: Ignore whitespace when comparing the parent's version and the child's to find where the lines came from.
zh_HANS-CN: 在比较父本和子本的版本时，忽略空白，以找到行的来源。

note: type: Plain text
en: Instead of using the default 7+1 hexadecimal digits as the abbreviated object name, use <m>+1 digits, where <m> is at least <n> but ensures the commit object names are unique.  Note that 1 column is used for a caret to mark the boundary commit.
zh_HANS-CN: 不要使用默认的7+1个十六进制数字作为对象的缩写，而是使用 <m>+1 个数字，其中 <m> 至少是 <n>，但确保提交对象的名称是唯一的。 请注意，有1列是用来标记边界提交的关健词。

note: type: Plain text
en: When neither `--porcelain` nor `--incremental` option is specified, `git blame` will output annotation for each line with:
zh_HANS-CN: 当既没有指定`--porcelain` 也没有指定`--incremental` 选项时，`git blame` 将为每一行输出注释：

note: type: Plain text
en: abbreviated object name for the commit the line came from;
zh_HANS-CN: 该行来自的提交的缩写对象名称；

note: type: Plain text
en: author ident (by default author name and date, unless `-s` or `-e` is specified); and
zh_HANS-CN: 作者身份（默认为作者姓名和日期，除非指定`s`或`e`）；以及

note: type: Plain text
en: before the line contents.
zh_HANS-CN: 在该行内容之前。

note: type: Title -
en: THE PORCELAIN FORMAT
zh_HANS-CN: 上层命令格式

note: type: Plain text
en: In this format, each line is output after a header; the header at the minimum has the first line which has:
zh_HANS-CN: 在这种格式中，每一行都是在页眉之后输出的；页眉至少有第一行，它有：

note: type: Plain text
en: 40-byte SHA-1 of the commit the line is attributed to;
zh_HANS-CN: 该行所归属的提交的 40 字节 SHA-1；

note: type: Plain text
en: the line number of the line in the original file;
zh_HANS-CN: 原始文件中该行的行号；

note: type: Plain text
en: the line number of the line in the final file;
zh_HANS-CN: 最后文件中该行的行号；

note: type: Plain text
en: on a line that starts a group of lines from a different commit than the previous one, the number of lines in this group.  On subsequent lines this field is absent.
zh_HANS-CN: 在开始一组与前一次不同的提交的行上，该组的行数。 在随后的行中，这个字段是不存在的。

note: type: Plain text
en: This header line is followed by the following information at least once for each commit:
zh_HANS-CN: 这个标题行后面是以下信息，每次提交至少有一次：

note: type: Plain text
en: the author name ("author"), email ("author-mail"), time ("author-time"), and time zone ("author-tz"); similarly for committer.
zh_HANS-CN: 作者姓名（"author"）、电子邮件（"author-mail"）、时间（"author-time"）和时区（"author-tz"）；对提交者也是如此。

note: type: Plain text
en: the filename in the commit that the line is attributed to.
zh_HANS-CN: 该行归属的提交中的文件名。

note: type: Plain text
en: the first line of the commit log message ("summary").
zh_HANS-CN: 提交日志信息的第一行（"摘要"）。

note: type: Plain text
en: The contents of the actual line is output after the above header, prefixed by a TAB. This is to allow adding more header elements later.
zh_HANS-CN: 实际行的内容会在上述标题之后输出，前缀为 TAB。这是为了允许以后添加更多的标题元素。

note: type: Plain text
en: The porcelain format generally suppresses commit information that has already been seen. For example, two lines that are blamed to the same commit will both be shown, but the details for that commit will be shown only once. This is more efficient, but may require more state be kept by the reader. The `--line-porcelain` option can be used to output full commit information for each line, allowing simpler (but less efficient)  usage like:
zh_HANS-CN: 上层命令格式通常会抑制已经看过的提交信息。例如，两行归咎于同一个提交的内容都会被显示出来，但该提交的细节只会被显示一次。这样做更有效率，但可能需要读者保存更多的状态：

note: type: Title -
en: SPECIFYING RANGES
zh_HANS-CN: 指定范围

note: type: Plain text
en: Unlike 'git blame' and 'git annotate' in older versions of git, the extent of the annotation can be limited to both line ranges and revision ranges. The `-L` option, which limits annotation to a range of lines, may be specified multiple times.
zh_HANS-CN: 与旧版本的 "git blame" 和 "git annotate" 不同，注释的范围可以限制在行的范围和修订范围。`-L` 选项将注释限制在一个行的范围内，可以多次指定。

note: type: Plain text
en: When you are interested in finding the origin for lines 40-60 for file `foo`, you can use the `-L` option like so (they mean the same thing -- both ask for 21 lines starting at line 40):
zh_HANS-CN: 当你对查找文件 `foo` 的第 40-60 行的原点感兴趣时，你可以像这样使用 `-L` 选项（它们的意思是一样的--都要求从第 40 行开始的 21 行）：

note: type: Plain text
en: Also you can use a regular expression to specify the line range:
zh_HANS-CN: 你也可以使用正则表达式来指定行的范围：

note: type: Plain text
en: which limits the annotation to the body of the `hello` subroutine.
zh_HANS-CN: 它将注释限制在 `hello` 子程序的主体中。

note: type: Plain text
en: When you are not interested in changes older than version v2.6.18, or changes older than 3 weeks, you can use revision range specifiers similar to 'git rev-list':
zh_HANS-CN: 当你对超过 v2.6.18 版本的修改不感兴趣，或者超过 3 周的修改不感兴趣时，你可以使用类似于 `git rev-list` 的修订范围指定器：

note: type: Plain text
en: When revision range specifiers are used to limit the annotation, lines that have not changed since the range boundary (either the commit v2.6.18 or the most recent commit that is more than 3 weeks old in the above example) are blamed for that range boundary commit.
zh_HANS-CN: 当修订范围指定符被用来限制注释时，自范围边界（在上面的例子中，提交 v2.6.18 或超过 3 周的最新提交）以来没有改变的行被指责为该范围边界提交。

note: type: Plain text
en: A particularly useful way is to see if an added file has lines created by copy-and-paste from existing files.  Sometimes this indicates that the developer was being sloppy and did not refactor the code properly.  You can first find the commit that introduced the file with:
zh_HANS-CN: 一个特别有用的方法是看一个新增的文件是否有从现有文件中复制和粘贴的行。 有时，这表明开发人员很马虎，没有正确地重构代码。 你可以首先找到引入该文件的提交：

note: type: Plain text
en: and then annotate the change between the commit and its parents, using `commit^!` notation:
zh_HANS-CN: 然后用 'commit^!' 符号来注释该提交和其父辈之间的变化：

note: type: Title -
en: INCREMENTAL OUTPUT
zh_HANS-CN: 增量输出

note: type: Plain text
en: When called with `--incremental` option, the command outputs the result as it is built.  The output generally will talk about lines touched by more recent commits first (i.e. the lines will be annotated out of order) and is meant to be used by interactive viewers.
zh_HANS-CN: 当调用 `--incremental` 选项时，该命令在构建过程中输出结果。 一般来说，输出结果会先谈及最近提交的行（也就是说，这些行会被不按顺序的注释），并且是为了给交互式浏览者使用。

note: type: Plain text
en: The output format is similar to the Porcelain format, but it does not contain the actual lines from the file that is being annotated.
zh_HANS-CN: 输出格式类似于上层命令格式，但它不包含被注释的文件的实际行数。

note: type: Plain text
en: Each blame entry always starts with a line of:
zh_HANS-CN: 每个历史追溯条目总是以一行字开始：

note: type: Plain text
en: Line numbers count from 1.
zh_HANS-CN: 行数从 1 开始计算。

note: type: Plain text
en: The first time that a commit shows up in the stream, it has various other information about it printed out with a one-word tag at the beginning of each line describing the extra commit information (author, email, committer, dates, summary, etc.).
zh_HANS-CN: 当一个提交首次出现在数据流中时，它的各种其他信息会被打印出来，每一行的开头都有一个单字标签，描述额外的提交信息（作者、电子邮件、提交者、日期、摘要等）。

note: type: Plain text
en: Unlike the Porcelain format, the filename information is always given and terminates the entry:
zh_HANS-CN: 与上层命令格式不同，文件名信息总是给定的，并终止条目：

note: type: Plain text
en: and thus it is really quite easy to parse for some line- and word-oriented parser (which should be quite natural for most scripting languages).
zh_HANS-CN: 因此，对于一些面向行和字的解析器来说，它确实很容易解析（这对于大多数脚本语言来说应该是很自然的）。

note: type: Plain text
en: For people who do parsing: to make it more robust, just ignore any lines between the first and last one ("<sha1>" and "filename" lines)  where you do not recognize the tag words (or care about that particular one) at the beginning of the "extended information" lines. That way, if there is ever added information (like the commit encoding or extended commit commentary), a blame viewer will not care.
zh_HANS-CN: 对于做解析的人来说：为了使它更健壮，只要忽略第一和最后一个（"<sha1>" 和 "filename" 行）之间的任何行，在 "扩展信息" 行的开头，你不认识标签词（或关心那个特定的）。这样一来，如果有一天增加了信息（比如提交编码或扩展的提交注释），历史追溯查看者就不会在意。

note: type: Title -
en: MAPPING AUTHORS
zh_HANS-CN: 制图作者

note: type: Plain text
en: git-branch - List, create, or delete branches
zh_HANS-CN: git-branch - 列出、创建或删除分支

note: type: Plain text
en: 'git branch' [--color[=<when>] | --no-color] [--show-current]
    	[-v [--abbrev=<n> | --no-abbrev]]
    	[--column[=<options>] | --no-column] [--sort=<key>]
    	[--merged [<commit>]] [--no-merged [<commit>]]
    	[--contains [<commit>]] [--no-contains [<commit>]]
    	[--points-at <object>] [--format=<format>]
    	[(-r | --remotes) | (-a | --all)]
    	[--list] [<pattern>...]
    'git branch' [--track[=(direct|inherit)] | --no-track] [-f]
    	[--recurse-submodules] <branchname> [<start-point>]
    'git branch' (--set-upstream-to=<upstream> | -u <upstream>) [<branchname>]
    'git branch' --unset-upstream [<branchname>]
    'git branch' (-m | -M) [<oldbranch>] <newbranch>
    'git branch' (-c | -C) [<oldbranch>] <newbranch>
    'git branch' (-d | -D) [-r] <branchname>...
    'git branch' --edit-description [<branchname>]
zh_HANS-CN: 'git branch' [--color[=<when>] | --no-color] [--show-current]
    	[-v [--abbrev=<n> | --no-abbrev]]
    	[--column[=<options>] | --no-column] [--sort=<key>]
    	[--merged [<commit>]] [--no-merged [<commit>]]
    	[--contains [<commit>]] [--no-contains [<commit>]]
    	[--points-at <object>] [--format=<format>]
    	[(-r | --remotes) | (-a | --all)]
    	[--list] [<pattern>...]
    'git branch' [--track[=(direct|inherit)] | --no-track] [-f]
    	[--recurse-submodules] <分支名> [<起始点>]
    'git branch' (--set-upstream-to=<上游> | -u <上游>) [<分支名>]
    'git branch' --unset-upstream [<分支名>]
    'git branch' (-m | -M) [<旧分支>] <新分支>
    'git branch' (-c | -C) [<旧分支>] <新分支>
    'git branch' (-d | -D) [-r] <分支名>...
    'git branch' --edit-description [<分支名>]

note: type: Plain text
en: If `--list` is given, or if there are no non-option arguments, existing branches are listed; the current branch will be highlighted in green and marked with an asterisk.  Any branches checked out in linked worktrees will be highlighted in cyan and marked with a plus sign. Option `-r` causes the remote-tracking branches to be listed, and option `-a` shows both local and remote branches.
zh_HANS-CN: 如果给了`--list`，或者没有非选项参数，现有的分支将被列出；当前的分支将以绿色突出显示，并标有星号。  在链接的工作树中检查出来的任何分支将以青色突出显示，并标有加号。选项`-r`导致远程跟踪的分支被列出，选项`-a`显示本地和远程分支。

note: type: Plain text
en: If a `<pattern>` is given, it is used as a shell wildcard to restrict the output to matching branches. If multiple patterns are given, a branch is shown if it matches any of the patterns.
zh_HANS-CN: 如果给出了`<pattern>`，它被用作shell通配符，将输出限制在匹配的分支上。如果给出多个模式，如果一个分支与任何模式相匹配，就会显示出来。

note: type: Plain text
en: Note that when providing a `<pattern>`, you must use `--list`; otherwise the command may be interpreted as branch creation.
zh_HANS-CN: 注意，当提供"<pattern>"时，必须使用"--list"；否则命令可能被解释为创建分支。

note: type: Plain text
en: With `--contains`, shows only the branches that contain the named commit (in other words, the branches whose tip commits are descendants of the named commit), `--no-contains` inverts it. With `--merged`, only branches merged into the named commit (i.e. the branches whose tip commits are reachable from the named commit) will be listed.  With `--no-merged` only branches not merged into the named commit will be listed.  If the <commit> argument is missing it defaults to `HEAD` (i.e. the tip of the current branch).
zh_HANS-CN: 使用 `--contains` 时，只显示包含指定提交的分支（换句话说，尖端提交是指定提交的后裔的分支），`--no-contains` 会反过来。如果使用 `--merged`，则只列出被合并到指定提交的分支（即其顶端提交可以从指定提交处到达的分支）。  如果使用"--no-merged"，则只列出未被合并到指定提交的分支。  如果缺少<commit>参数，则默认为`HEAD`（即当前分支的顶端）。

note: type: Plain text
en: The command's second form creates a new branch head named <branchname> which points to the current `HEAD`, or <start-point> if given. As a special case, for <start-point>, you may use `"A...B"` as a shortcut for the merge base of `A` and `B` if there is exactly one merge base. You can leave out at most one of `A` and `B`, in which case it defaults to `HEAD`.
zh_HANS-CN: 该命令的第二种形式是创建一个名为<branchname>的新分支头，该分支头指向当前的`HEAD`，如果给定的话，则指向<start-point>。作为一种特殊情况，对于<start-point>，你可以使用`"A...B "作为`A`和`B`的合并基础的快捷方式，如果正好有一个合并基础。你最多可以省略`A`和`B`中的一个，在这种情况下，它默认为`HEAD`。

note: type: Plain text
en: Note that this will create the new branch, but it will not switch the working tree to it; use "git switch <newbranch>" to switch to the new branch.
zh_HANS-CN: 注意，这将创建新的分支，但不会将工作树切换到它；使用 "git switch <newbranch>"来切换到新的分支。

note: type: Plain text
en: When a local branch is started off a remote-tracking branch, Git sets up the branch (specifically the `branch.<name>.remote` and `branch.<name>.merge` configuration entries) so that 'git pull' will appropriately merge from the remote-tracking branch. This behavior may be changed via the global `branch.autoSetupMerge` configuration flag. That setting can be overridden by using the `--track` and `--no-track` options, and changed later using `git branch --set-upstream-to`.
zh_HANS-CN: 当一个本地分支从远程跟踪的分支开始时，Git 会设置该分支（特别是 `branch.<name>.remote` 和 `branch.<name>.merge` 配置项），以便 "git pull "能适当地从远程跟踪的分支合并。这种行为可以通过全局的 `branch.autoSetupMerge` 配置标志来改变。该设置可以通过使用`--track`和`--no-track`选项来覆盖，并在之后使用`git branch --set-upstream-to`来改变。

note: type: Plain text
en: With a `-m` or `-M` option, <oldbranch> will be renamed to <newbranch>.  If <oldbranch> had a corresponding reflog, it is renamed to match <newbranch>, and a reflog entry is created to remember the branch renaming. If <newbranch> exists, -M must be used to force the rename to happen.
zh_HANS-CN: 使用`-m`或`-M`选项，<oldbranch>将被重命名为<newbranch>。  如果 <oldbranch> 有相应的 reflog，它将被重命名以匹配 <newbranch>，并创建一个 reflog 条目以记住分支重命名。如果 <newbranch> 存在，必须使用 -M 来强制重命名。

note: type: Plain text
en: The `-c` and `-C` options have the exact same semantics as `-m` and `-M`, except instead of the branch being renamed, it will be copied to a new name, along with its config and reflog.
zh_HANS-CN: `-c`和`-C`选项的语义与`-m`和`-M`完全相同，只不过不是对分支进行重命名，而是将其连同其配置和日志一起复制到一个新的名称。

note: type: Plain text
en: With a `-d` or `-D` option, `<branchname>` will be deleted.  You may specify more than one branch for deletion.  If the branch currently has a reflog then the reflog will also be deleted.
zh_HANS-CN: 使用`-d`或`-D`选项，`<branchname>`将被删除。  你可以指定一个以上的分支进行删除。  如果该分支目前有一个reflog，那么reflog也将被删除。

note: type: Plain text
en: Use `-r` together with `-d` to delete remote-tracking branches. Note, that it only makes sense to delete remote-tracking branches if they no longer exist in the remote repository or if 'git fetch' was configured not to fetch them again. See also the 'prune' subcommand of linkgit:git-remote[1] for a way to clean up all obsolete remote-tracking branches.
zh_HANS-CN: 使用 `-r` 和 `-d` 来删除远程跟踪的分支。注意，只有当远程分支不再存在于远程仓库或 "git fetch "被配置为不再获取它们时，删除远程跟踪分支才有意义。参见 linkgit:git-remote[1] 的 "prune "子命令，它可以清理所有过时的远程跟踪分支。

note: type: Plain text
en: Delete a branch. The branch must be fully merged in its upstream branch, or in `HEAD` if no upstream was set with `--track` or `--set-upstream-to`.
zh_HANS-CN: 删除一个分支。该分支必须完全合并在其上游分支中，如果没有用`--track`或`--set-upstream-to`设置的上游分支，则必须在`HEAD`中。

note: type: Plain text
en: Shortcut for `--delete --force`.
zh_HANS-CN: `--delete --force`的快捷方式。

note: type: Plain text
en: Create the branch's reflog.  This activates recording of all changes made to the branch ref, enabling use of date based sha1 expressions such as "<branchname>@\{yesterday}".  Note that in non-bare repositories, reflogs are usually enabled by default by the `core.logAllRefUpdates` config option.  The negated form `--no-create-reflog` only overrides an earlier `--create-reflog`, but currently does not negate the setting of `core.logAllRefUpdates`.
zh_HANS-CN: 创建该分支的 reflog。  这将激活对该分支参考文献所做的所有修改的记录，使其能够使用基于日期的sha1表达式，如"<branchname>@{yesterday}"。  请注意，在非空白仓库中， reflogs通常由`core.logAllRefUpdates`配置选项默认启用。  否定的形式`--no-create-reflog`只覆盖先前的`--create-reflog`，但目前并不否定`core.logAllRefUpdates`的设置。

note: type: Plain text
en: Note that 'git branch -f <branchname> [<start-point>]', even with '-f', refuses to change an existing branch `<branchname>` that is checked out in another worktree linked to the same repository.
zh_HANS-CN: 请注意，"git branch -f <branchname> [<start-point>]"命令，即使添加"-f"选项，该命令也会拒绝改变一个在链接到同一仓库的另一个工作树中被检查出来的现有分支`<branchname>`。

note: type: Plain text
en: Shortcut for `--move --force`.
zh_HANS-CN: `--move --force`的快捷方式。

note: type: Plain text
en: Shortcut for `--copy --force`.
zh_HANS-CN: `--copy --force`的快捷方式。

note: type: Plain text
en: Color branches to highlight current, local, and remote-tracking branches.  The value must be always (the default), never, or auto.
zh_HANS-CN: 给分支着色，以突出当前、本地和远程跟踪的分支。  该值必须是始终（默认）、从不或自动。

note: type: Plain text
en: Turn off branch colors, even when the configuration file gives the default to color output.  Same as `--color=never`.
zh_HANS-CN: 关闭分支的颜色，即使在配置文件中默认为彩色输出。  与`--color=never`相同。

note: type: Plain text
en: Sorting and filtering branches are case insensitive.
zh_HANS-CN: 排序和过滤分支是不分大小写的。

note: type: Plain text
en: Do not print a newline after formatted refs where the format expands to the empty string.
zh_HANS-CN: 在格式化的引用后不打印换行，因为格式化的引用会扩展为空字符串。

note: type: Labeled list
en: --column[=<options>]
zh_HANS-CN: --column[=<选项>]

note: type: Plain text
en: Display branch listing in columns. See configuration variable `column.branch` for option syntax. `--column` and `--no-column` without options are equivalent to 'always' and 'never' respectively.
zh_HANS-CN: 在列中显示分支列表。选项语法见配置变量`column.branch`。`--column`和`--no-column`没有选项，分别相当于'always'和'never'。

note: type: Plain text
en: This option is only applicable in non-verbose mode.
zh_HANS-CN: 这个选项只适用于非粗话模式。

note: type: Plain text
en: List or delete (if used with -d) the remote-tracking branches.  Combine with `--list` to match the optional pattern(s).
zh_HANS-CN: 列出或删除（如果与-d一起使用）远程跟踪的分支。  与`--list`结合使用，以匹配可选的模式（s）。

note: type: Plain text
en: List both remote-tracking branches and local branches.  Combine with `--list` to match optional pattern(s).
zh_HANS-CN: 列出远程跟踪的分支和本地分支。  与`--list`组合，以匹配可选的模式。

note: type: Plain text
en: List branches.  With optional `<pattern>...`, e.g. `git branch --list 'maint-*'`, list only the branches that match the pattern(s).
zh_HANS-CN: 列出分支。  使用可选的"<pattern>..."，例如 "git branch --list 'maint-*'"，只列出符合该模式的分支。

note: type: Plain text
en: Print the name of the current branch. In detached HEAD state, nothing is printed.
zh_HANS-CN: 打印当前分支的名称。在分离的HEAD状态下，不打印任何东西。

note: type: Plain text
en: When in list mode, show sha1 and commit subject line for each head, along with relationship to upstream branch (if any). If given twice, print the path of the linked worktree (if any) and the name of the upstream branch, as well (see also `git remote show <remote>`).  Note that the current worktree's HEAD will not have its path printed (it will always be your current directory).
zh_HANS-CN: 当在列表模式下，显示每个头的sha1和提交主题行，以及与上游分支的关系（如果有的话）。如果给了两次，也会打印链接的工作树的路径（如果有的话）和上游分支的名称（也见 `git remote show <remote>`）。  请注意，当前工作树的HEAD不会打印其路径（它总是你的当前目录）。

note: type: Plain text
en: Be more quiet when creating or deleting a branch, suppressing non-error messages.
zh_HANS-CN: 在创建或删除一个分支时更加安静，抑制非错误信息。

note: type: Plain text
en: In the verbose listing that show the commit object name, show the shortest prefix that is at least '<n>' hexdigits long that uniquely refers the object.  The default value is 7 and can be overridden by the `core.abbrev` config option.
zh_HANS-CN: 在显示提交对象名称的冗长列表中，显示至少有'<n>'个六位数的最短前缀，以唯一地指代该对象。  默认值是7，可以通过`core.abbrev`配置选项覆盖。

note: type: Plain text
en: Display the full sha1s in the output listing rather than abbreviating them.
zh_HANS-CN: 在输出列表中显示完整的sha1，而不是缩写它们。

note: type: Plain text
en: The branch.autoSetupMerge configuration variable specifies how `git switch`, `git checkout` and `git branch` should behave when neither `--track` nor `--no-track` are specified:
zh_HANS-CN: branch.autoSetupMerge配置变量指定了当既不指定`--track`也不指定`--no-track`时，`git switch`、`git checkout`和`git branch`应如何运行：

note: type: Plain text
en: The default option, `true`, behaves as though `--track=direct` were given whenever the start-point is a remote-tracking branch.  `false` behaves as if `--no-track` were given. `always` behaves as though `--track=direct` were given. `inherit` behaves as though `--track=inherit` were given. `simple` behaves as though `--track=direct` were given only when the start-point is a remote-tracking branch and the new branch has the same name as the remote branch.
zh_HANS-CN: 默认选项 "true"，在起点是远程跟踪分支的情况下，就像给了 "track=direct"。  `false`的行为就像给了`--no-track`一样。`always`的行为就像给了`--track=direct`一样。继承(inherit)的行为就像给了`--track=inherit'一样。`simple`的行为就像给了`--track=direct`一样，只有当起点是远程跟踪的分支，并且新的分支与远程分支有相同的名字时，才会有这种行为。

note: type: Plain text
en: THIS OPTION IS EXPERIMENTAL! Causes the current command to recurse into submodules if `submodule.propagateBranches` is enabled. See `submodule.propagateBranches` in linkgit:git-config[1]. Currently, only branch creation is supported.
zh_HANS-CN: 这个选项是实验性的！！！如果 `submodule.propagateBranches` 被启用，会导致当前命令递归到子模块。参见 linkgit:git-config[1] 中的 `submodule.propagateBranches`。目前，只支持创建分支。

note: type: Plain text
en: When used in branch creation, a new branch <branchname> will be created in the superproject and all of the submodules in the superproject's <start-point>. In submodules, the branch will point to the submodule commit in the superproject's <start-point> but the branch's tracking information will be set up based on the submodule's branches and remotes e.g. `git branch --recurse-submodules topic origin/main` will create the submodule branch "topic" that points to the submodule commit in the superproject's "origin/main", but tracks the submodule's "origin/main".
zh_HANS-CN: 当在分支创建中使用时，一个新的分支<branchname>将在父项目和父项目的<start-point>中的所有子模块中创建。在子模块中，该分支将指向超级项目的<start-point>中的子模块提交，但该分支的跟踪信息将根据子模块的分支和远程来设置，例如`git branch --recurse-submodules topic origin/main`将创建一个子模块分支 "topic"，指向父项目的 "origin/main "中的子模块提交，但跟踪子模块的 "origin/main"。

note: type: Plain text
en: As this option had confusing syntax, it is no longer supported.  Please use `--track` or `--set-upstream-to` instead.
zh_HANS-CN: 由于这个选项的语法混乱，不再支持。  请使用`--track`或`--set-upstream-to`代替。

note: type: Labeled list
en: -u <upstream>
zh_HANS-CN: -u <上行>

note: type: Plain text
en: Set up <branchname>'s tracking information so <upstream> is considered <branchname>'s upstream branch. If no <branchname> is specified, then it defaults to the current branch.
zh_HANS-CN: 设置<branchname>的跟踪信息，使<upstream>被视为<branchname>的上游分支。如果没有指定<branchname>，则默认为当前分支。

note: type: Plain text
en: Remove the upstream information for <branchname>. If no branch is specified it defaults to the current branch.
zh_HANS-CN: 删除<branchname>的上游信息。如果没有指定分支，则默认为当前分支。

note: type: Plain text
en: Open an editor and edit the text to explain what the branch is for, to be used by various other commands (e.g. `format-patch`, `request-pull`, and `merge` (if enabled)). Multi-line explanations may be used.
zh_HANS-CN: 打开一个编辑器，编辑文本，解释该分支的用途，以便被其他各种命令（如`format-patch`、`request-pull`和`merge`（如果启用））使用。可以使用多行解释。

note: type: Plain text
en: Only list branches which contain the specified commit (HEAD if not specified). Implies `--list`.
zh_HANS-CN: 只列出包含指定提交的分支（如果没有指定则为HEAD）。意味着 `--list`。

note: type: Plain text
en: Only list branches which don't contain the specified commit (HEAD if not specified). Implies `--list`.
zh_HANS-CN: 只列出不包含指定提交的分支（如果不指定则为HEAD）。意味着 `--list`。

note: type: Plain text
en: Only list branches whose tips are reachable from the specified commit (HEAD if not specified). Implies `--list`.
zh_HANS-CN: 只列出从指定的提交（如果没有指定，则为HEAD）可以到达的分支的提示。意味着 `--list`。

note: type: Plain text
en: Only list branches whose tips are not reachable from the specified commit (HEAD if not specified). Implies `--list`.
zh_HANS-CN: 只列出从指定的提交（如果没有指定，则为HEAD）中无法到达的分支。意味着 `--list`。

note: type: Plain text
en: The name of the branch to create or delete.  The new branch name must pass all checks defined by linkgit:git-check-ref-format[1].  Some of these checks may restrict the characters allowed in a branch name.
zh_HANS-CN: 要创建或删除的分支的名称。  新的分支名必须通过 linkgit:git-check-ref-format[1] 定义的所有检查。  其中一些检查可能会限制分支名称中允许的字符。

note: type: Labeled list
en: <start-point>
zh_HANS-CN: <起始点

note: type: Plain text
en: The new branch head will point to this commit.  It may be given as a branch name, a commit-id, or a tag.  If this option is omitted, the current HEAD will be used instead.
zh_HANS-CN: 新的分支头将指向这个提交。  它可以是一个分支名，一个提交号，或者一个标签。  如果省略此选项，将使用当前的HEAD来代替。

note: type: Plain text
en: The name of an existing branch to rename.
zh_HANS-CN: 要重命名的现有分支的名称。

note: type: Plain text
en: The new name for an existing branch. The same restrictions as for <branchname> apply.
zh_HANS-CN: 现有分支的新名称。与<branchname>的限制相同。

note: type: Labeled list
en: --sort=<key>
zh_HANS-CN: --排序=<键>

note: type: Plain text
en: Sort based on the key given. Prefix `-` to sort in descending order of the value. You may use the --sort=<key> option multiple times, in which case the last key becomes the primary key. The keys supported are the same as those in `git for-each-ref`. Sort order defaults to the value configured for the `branch.sort` variable if exists, or to sorting based on the full refname (including `refs/...` prefix). This lists detached HEAD (if present) first, then local branches and finally remote-tracking branches. See linkgit:git-config[1].
zh_HANS-CN: 根据给定的键进行排序。前缀"-"表示按照数值的降序排序。你可以多次使用--sort=<key>选项，在这种情况下，最后一个键成为主键。支持的键与`git for-each-ref`中的键相同。排序顺序默认为`branch.sort`变量的配置值（如果存在），或者基于完整的 refname（包括 `refs/...` 前缀）进行排序。这将首先列出分离的 HEAD（如果存在），然后是本地分支，最后是远程跟踪分支。参见 linkgit:git-config[1]。

note: type: Plain text
en: Only list branches of the given object.
zh_HANS-CN: 只列出给定对象的分支。

note: type: Plain text
en: A string that interpolates `%(fieldname)` from a branch ref being shown and the object it points at.  The format is the same as that of linkgit:git-for-each-ref[1].
zh_HANS-CN: 一个字符串，从正在显示的分支参考文献和它所指向的对象中插值`%(fieldname)'。  其格式与linkgit:git-for-each-ref[1]的格式相同。

note: type: Plain text
en: `pager.branch` is only respected when listing branches, i.e., when `--list` is used or implied. The default is to use a pager.  See linkgit:git-config[1].
zh_HANS-CN: `pager.branch`只在列出分支时被尊重，即使用或暗示使用`--list`时。默认情况是使用 pager。  参见 linkgit:git-config[1]。

note: type: Labeled list
en: Start development from a known tag
zh_HANS-CN: 从一个已知的标签开始开发

note: type: delimited block -
en: $ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6
    $ cd my2.6
    $ git branch my2.6.14 v2.6.14   <1>
    $ git switch my2.6.14
zh_HANS-CN: $ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6
    $ cd my2.6
    $ git branch my2.6.14 v2.6.14 <1>.
    $ git switch my2.6.14

note: type: Plain text
en: This step and the next one could be combined into a single step with "checkout -b my2.6.14 v2.6.14".
zh_HANS-CN: 这一步和下一步可以用 "checkout -b my2.6.14 v2.6.14 "合并为一个步骤。

note: type: Labeled list
en: Delete an unneeded branch
zh_HANS-CN: 删除一个不需要的分支

note: type: Plain text
en: Delete the remote-tracking branches "todo", "html" and "man". The next 'fetch' or 'pull' will create them again unless you configure them not to.  See linkgit:git-fetch[1].
zh_HANS-CN: 删除远程跟踪的分支 "todo"、"html "和 "man"。下一次的 "fetch "或 "pull "会再次创建它们，除非你配置它们不这样做。  参见 linkgit:git-fetch[1]。

note: type: Plain text
en: Delete the "test" branch even if the "master" branch (or whichever branch is currently checked out) does not have all commits from the test branch.
zh_HANS-CN: 删除 "测试 "分支，即使 "主 "分支（或当前签出的任何一个分支）没有测试分支的所有提交。

note: type: Labeled list
en: Listing branches from a specific remote
zh_HANS-CN: 从一个特定的远端列出分支

note: type: Plain text
en: Using `-a` would conflate <remote> with any local branches you happen to have been prefixed with the same <remote> pattern.
zh_HANS-CN: 使用`-a`会将<remote>与任何你碰巧以相同的<remote>模式为前缀的本地分支混淆。

note: type: Plain text
en: `for-each-ref` can take a wide range of options. See linkgit:git-for-each-ref[1]
zh_HANS-CN: `for-each-ref`可以接受一系列的选项。参见 linkgit:git-for-each-ref[1] 。

note: type: Plain text
en: Patterns will normally need quoting.
zh_HANS-CN: 图案通常需要引证。

note: type: Plain text
en: If you are creating a branch that you want to switch to immediately, it is easier to use the "git switch" command with its `-c` option to do the same thing with a single command.
zh_HANS-CN: 如果你正在创建一个你想立即切换到的分支，使用 "git switch "命令及其`-c`选项，用一条命令做同样的事情，会更容易。

note: type: Plain text
en: The options `--contains`, `--no-contains`, `--merged` and `--no-merged` serve four related but different purposes:
zh_HANS-CN: 选项`--包含`、`--不包含`、`--合并`和`--不合并`有四个相关但不同的目的。

note: type: Plain text
en: `--contains <commit>` is used to find all branches which will need special attention if <commit> were to be rebased or amended, since those branches contain the specified <commit>.
zh_HANS-CN: `--contains <commit>`用于查找所有在<commit>被重新编译或修改时需要特别关注的分支，因为这些分支包含指定的<commit>。

note: type: Plain text
en: `--no-contains <commit>` is the inverse of that, i.e. branches that don't contain the specified <commit>.
zh_HANS-CN: `--no-contains <commit>`是其反义词，即不包含指定<commit>的分支。

note: type: Plain text
en: `--merged` is used to find all branches which can be safely deleted, since those branches are fully contained by HEAD.
zh_HANS-CN: `--merged`用于查找所有可以安全删除的分支，因为这些分支被HEAD完全包含。

note: type: Plain text
en: `--no-merged` is used to find branches which are candidates for merging into HEAD, since those branches are not fully contained by HEAD.
zh_HANS-CN: `--no-merged`是用来寻找可以合并到HEAD的候选分支，因为这些分支没有被HEAD完全包含。

note: type: Plain text
en: linkgit:git-check-ref-format[1], linkgit:git-fetch[1], linkgit:git-remote[1], link:user-manual.html#what-is-a-branch[``Understanding history: What is a branch?''] in the Git User's Manual.
zh_HANS-CN: linkgit:git-check-ref-format[1], linkgit:git-fetch[1], linkgit:git-remote[1], link:user-manual.html#what-is-a-branch[``了解历史：什么是分支？'] 在 Git User's Manual。

note: type: Plain text
en: git-bugreport - Collect information for user to file a bug report
zh_HANS-CN: git-bugreport - 收集用户提交错误报告的信息

note: type: Plain text
en: 'git bugreport' [(-o | --output-directory) <path>] [(-s | --suffix) <format>]
    		[--diagnose[=<mode>]]
zh_HANS-CN: 'git bugreport' [(-o | --output-directory) <path>] [(-s | --suffix) <格式>]
    		[--diagnose[=<模式>]]

note: type: Plain text
en: Captures information about the user's machine, Git client, and repository state, as well as a form requesting information about the behavior the user observed, into a single text file which the user can then share, for example to the Git mailing list, in order to report an observed bug.
zh_HANS-CN: 捕获关于用户的机器、Git 客户端和仓库状态的信息，以及要求提供用户观察到的行为信息的表格，并将其放入一个文本文件中，然后用户可以分享该文件，例如分享到 Git 邮件列表，以便报告观察到的错误。

note: type: Plain text
en: The following information is requested from the user:
zh_HANS-CN: 要求用户提供以下信息：

note: type: Plain text
en: Reproduction steps
zh_HANS-CN: 再生产步骤

note: type: Plain text
en: Expected behavior
zh_HANS-CN: 预期的行为

note: type: Plain text
en: Actual behavior
zh_HANS-CN: 实际行为

note: type: Plain text
en: The following information is captured automatically:
zh_HANS-CN: 以下信息是自动采集的：

note: type: Plain text
en: Compiler-specific info string
zh_HANS-CN: 编译器特定信息字符串

note: type: Plain text
en: A list of enabled hooks
zh_HANS-CN: 启用的钩子的列表

note: type: Plain text
en: Additional information may be gathered into a separate zip archive using the `--diagnose` option, and can be attached alongside the bugreport document to provide additional context to readers.
zh_HANS-CN: 额外的信息可以使用 `--diagnose` 选项收集到一个单独的压缩文件中，并可以与 bugreport 文件一起附上，为读者提供额外的上下文。

note: type: Plain text
en: This tool is invoked via the typical Git setup process, which means that in some cases, it might not be able to launch - for example, if a relevant config file is unreadable. In this kind of scenario, it may be helpful to manually gather the kind of information listed above when manually asking for help.
zh_HANS-CN: 这个工具是通过典型的 Git 设置过程调用的，这意味着在某些情况下，它可能无法启动——例如，如果相关的配置文件无法读取。在这种情况下，在手动请求帮助时，手动收集上面列出的那种信息可能会有帮助。

note: type: Plain text
en: Place the resulting bug report file in `<path>` instead of the current directory.
zh_HANS-CN: 将产生的错误报告文件放在 `<路径>` 而不是当前目录中。

note: type: Plain text
en: Specify an alternate suffix for the bugreport name, to create a file named 'git-bugreport-<formatted suffix>'. This should take the form of a strftime(3) format string; the current local time will be used.
zh_HANS-CN: 为 bugreport 名称指定一个备用后缀，以创建一个名为 "git-bugreport-<格式化后缀>"的文件。这应该采取 strftime(3) 格式字符串的形式；将使用当前的本地时间。

note: type: Plain text
en: Create a zip archive of supplemental information about the user's machine, Git client, and repository state. The archive is written to the same output directory as the bug report and is named 'git-diagnostics-<formatted suffix>'.
zh_HANS-CN: 创建一个包含用户机器、Git 客户端和仓库状态等补充信息的 zip 档案。该归档文件与错误报告写入同一输出目录，并命名为 'git-diagnostics-<格式化后缀>'。

note: type: Plain text
en: Without `mode` specified, the diagnostic archive will contain the default set of statistics reported by `git diagnose`. An optional `mode` value may be specified to change which information is included in the archive. See linkgit:git-diagnose[1] for the list of valid values for `mode` and details about their usage.
zh_HANS-CN: 如果没有指定`mode'，诊断档案将包含 `git diagnose` 报告的默认统计信息。可以指定一个可选的 `mode` 值来改变存档中包含的信息。参见 linkgit:git-diagnose[1]，了解 `mode` 的有效值列表及其使用细节。

note: type: Plain text
en: 'git bundle' create [-q | --quiet | --progress]
    		    [--version=<version>] <file> <git-rev-list-args>
    'git bundle' verify [-q | --quiet] <file>
    'git bundle' list-heads <file> [<refname>...]
    'git bundle' unbundle [--progress] <file> [<refname>...]
zh_HANS-CN: 'git bundle' create [-q | --quiet | --progress]
    		    [--version=<版本>] <文件> <git-rev-list-args>
    'git bundle' verify [-q | --quiet] <文件>
    'git bundle' list-heads <文件> [<引用名>...]
    'git bundle' unbundle [--progress] <文件> [<引用名>...]

note: type: Plain text
en: Create, unpack, and manipulate "bundle" files. Bundles are used for the "offline" transfer of Git objects without an active "server" sitting on the other side of the network connection.
zh_HANS-CN: 创建、解包和操作 “打包” 文件。捆绑文件用于 Git 对象的 “离线” 传输，而不需要在网络连接的另一端有一个活跃的 “服务器”。

note: type: Plain text
en: They can be used to create both incremental and full backups of a repository, and to relay the state of the references in one repository to another.
zh_HANS-CN: 它们可以用来创建仓库的增量和完全备份，并将一个仓库中的引用状态传递给另一个版本库。

note: type: Plain text
en: Git commands that fetch or otherwise "read" via protocols such as `ssh://` and `https://` can also operate on bundle files. It is possible linkgit:git-clone[1] a new repository from a bundle, to use linkgit:git-fetch[1] to fetch from one, and to list the references contained within it with linkgit:git-ls-remote[1]. There's no corresponding "write" support, i.e.a 'git push' into a bundle is not supported.
zh_HANS-CN: 通过 `ssh://` 和 `https://` 等协议获取或以其他方式 “读取” 的 Git 命令也可以对打包文件进行操作。它可以通过 linkgit:git-clone[1] 从打包中建立新的仓库，用 linkgit:git-fetch[1] 从其中获取，并通过 linkgit:git-ls-remote[1] 列出其中的引用。没有相应的 "写" 支持，也就是说，不支持 'git push' 捆绑包。

note: type: Plain text
en: See the "EXAMPLES" section below for examples of how to use bundles.
zh_HANS-CN: 关于如何使用捆绑包的例子，见下面的 “实例” 部分。

note: type: Plain text
en: Bundles are `.pack` files (see linkgit:git-pack-objects[1]) with a header indicating what references are contained within the bundle.
zh_HANS-CN: 捆绑包是 `.pack` 文件（见 linkgit:git-pack-objects[1]），有一个标头说明捆绑包中包含哪些引用。

note: type: Plain text
en: Like the packed archive format itself bundles can either be self-contained, or be created using exclusions.  See the "OBJECT PREREQUISITES" section below.
zh_HANS-CN: 就像打包的归档格式本身一样，捆绑包既可以是独立的，也可以使用排除法创建。 参见下面的 "目标前提" 部分。

note: type: Plain text
en: Bundles created using revision exclusions are "thin packs" created using the `--thin` option to linkgit:git-pack-objects[1], and unbundled using the `--fix-thin` option to linkgit:git-index-pack[1].
zh_HANS-CN: 使用修订版排除法创建的捆绑包是使用 linkgit:git-pack-objects[1] 的 `--thin` 选项创建的 “轻量包”，并使用 linkgit:git-index-pack[1] 的 `--fix-thin` 选项解除捆绑。

note: type: Plain text
en: There is no option to create a "thick pack" when using revision exclusions, and users should not be concerned about the difference. By using "thin packs", bundles created using exclusions are smaller in size. That they're "thin" under the hood is merely noted here as a curiosity, and as a reference to other documentation.
zh_HANS-CN: 在使用修订排除法时，没有创建 “复杂包” 的选项，用户不应该担心这种差异。通过使用 “轻量包”，使用排除法创建的捆绑文件尺寸较小。它们在引擎盖下是 “薄” 的，在此只是作为一种好奇，并作为其他文档的参考。

note: type: Plain text
en: See linkgit:gitformat-bundle[5] for more details and the discussion of "thin pack" in linkgit:gitformat-pack[5] for further details.
zh_HANS-CN: 更多细节见 linkgit:gitformat-bundle[5] ，以及 linkgit:gitformat-pack[5] 中关于 “轻量包” 的讨论。

note: type: Plain text
en: Used to create a bundle named 'file'.  This requires the '<git-rev-list-args>' arguments to define the bundle contents.  'options' contains the options specific to the 'git bundle create' subcommand. If 'file' is `-`, the bundle is written to stdout.
zh_HANS-CN: 用来创建一个名为 '<文件>' 的捆绑包。 这需要 '<git-rev-list-args>' 参数来定义包的内容。 '选项' 包含 'git bundle create' 子命令的特定选项。如果 'file' 是 '-'，捆绑内容将被写入标准输出流。

note: type: Labeled list
en: verify <file>
zh_HANS-CN: verify <文件>

note: type: Plain text
en: Used to check that a bundle file is valid and will apply cleanly to the current repository.  This includes checks on the bundle format itself as well as checking that the prerequisite commits exist and are fully linked in the current repository.  Then, 'git bundle' prints a list of missing commits, if any.  Finally, information about additional capabilities, such as "object filter", is printed. See "Capabilities" in linkgit:gitformat-bundle[5] for more information. The exit code is zero for success, but will be nonzero if the bundle file is invalid. If 'file' is `-`, the bundle is read from stdin.
zh_HANS-CN: 用于检查捆绑包文件是否有效，是否能干净地应用到当前仓库。 这包括对捆绑包格式本身的检查，以及检查前提提交是否存在，并在当前版本库中被完全链接。 然后，'git bundle' 会打印出一个缺失提交的列表，如果有的话。 最后，打印出关于额外能力的信息，比如 “对象过滤器”。更多信息见 linkgit:gitformat-bundle[5] 中的 “能力”。成功时退出代码为零，但如果捆绑包文件无效，退出代码将为非零。如果 'file' 是 `-`，则从标准输入流读取捆绑包文件。

note: type: Labeled list
en: list-heads <file>
zh_HANS-CN: list-heads <文件>

note: type: Plain text
en: Lists the references defined in the bundle.  If followed by a list of references, only references matching those given are printed out. If 'file' is `-`, the bundle is read from stdin.
zh_HANS-CN: 列出捆绑中定义的引用。 如果后面是引用列表，则只打印出与之匹配的引用。如果 'file' 是 `-`，则从标准输入流中读取捆绑包文件。

note: type: Labeled list
en: unbundle <file>
zh_HANS-CN: unbundle <文件>

note: type: Plain text
en: Passes the objects in the bundle to 'git index-pack' for storage in the repository, then prints the names of all defined references. If a list of references is given, only references matching those in the list are printed. This command is really plumbing, intended to be called only by 'git fetch'.  If 'file' is `-`, the bundle is read from stdin.
zh_HANS-CN: 将捆绑包中的对象传递给 'git index-pack' 以存储在仓库中，然后打印出所有定义的引用的名称。如果给了一个引用列表，则只打印列表中匹配的引用。这个命令是真正的管道，只打算由 'git fetch' 调用。 如果 'file' 是 `-`，则从标准输入流读取捆绑包文件。

note: type: Plain text
en: A list of arguments, acceptable to 'git rev-parse' and 'git rev-list' (and containing a named ref, see SPECIFYING REFERENCES below), that specifies the specific objects and references to transport.  For example, `master~10..master` causes the current master reference to be packaged along with all objects added since its 10th ancestor commit.  There is no explicit limit to the number of references and objects that may be packaged.
zh_HANS-CN: 一个参数列表，可以被 'git rev-parse' 和 'git rev-list' 接受（并包含一个命名的引用，见下面的 指定引用），它指定了要传送的特定对象和引用。 例如，`master~10...master` 会导致当前的主引用与自其第 10 次祖先提交后添加的所有对象一起被打包。 对于可以打包的引用和对象的数量没有明确的限制。

note: type: Labeled list
en: [<refname>...]
zh_HANS-CN: [<引用名>...]

note: type: Plain text
en: A list of references used to limit the references reported as available. This is principally of use to 'git fetch', which expects to receive only those references asked for and not necessarily everything in the pack (in this case, 'git bundle' acts like 'git fetch-pack').
zh_HANS-CN: 用于限制报告的可用引用的列表。这主要是对 'git fetch' 有用，它希望只收到那些要求的引用，而不一定是包中的所有内容（在这种情况下， 'git bundle' 就像 'git fetch-pack'）。

note: type: Plain text
en: Specify the bundle version.  Version 2 is the older format and can only be used with SHA-1 repositories; the newer version 3 contains capabilities that permit extensions. The default is the oldest supported format, based on the hash algorithm in use.
zh_HANS-CN: 指定捆绑包的版本。 版本 2 是较老的格式，只能用于 SHA-1 仓库；较新的版本 3 包含允许扩展的功能。默认是最古老的支持格式，基于使用中的哈希算法。

note: type: Plain text
en: This flag makes the command not to report its progress on the standard error stream.
zh_HANS-CN: 这个标志使命令不在标准错误流中报告其进度。

note: type: Title -
en: SPECIFYING REFERENCES
zh_HANS-CN: 指定引用

note: type: Plain text
en: Revisions must be accompanied by reference names to be packaged in a bundle.
zh_HANS-CN: 修订必须附有引用名称，才能打包成捆绑包。

note: type: Plain text
en: More than one reference may be packaged, and more than one set of prerequisite objects can be specified.  The objects packaged are those not contained in the union of the prerequisites.
zh_HANS-CN: 可以打包一个以上的引用，也可以指定一组以上的先决条件对象。 被打包的对象是那些不包含在先决条件组合中的对象。

note: type: Plain text
en: The 'git bundle create' command resolves the reference names for you using the same rules as `git rev-parse --abbrev-ref=loose`. Each prerequisite can be specified explicitly (e.g. `^master~10`), or implicitly (e.g. `master~10..master`, `--since=10.days.ago master`).
zh_HANS-CN: 'git bundle create' 命令使用与 `git rev-parse --abbrev-ref=loose' 相同的规则为您解析引用名称。每个先决条件都可以明确指定（例如`^master~10`），或者隐含地指定（例如 `master~10...master`，`--since=10.day.after master`）。

note: type: Plain text
en: All of these simple cases are OK (assuming we have a "master" and "next" branch):
zh_HANS-CN: 所有这些简单的情况都没有问题（假设我们有一个 "master" 和 "next" 分支）：

note: type: Plain text
en: And so are these (and the same but omitted `--stdin` examples):
zh_HANS-CN: 这些也是如此（还有相同的但省略了 `--stdin` 的例子）：

note: type: Plain text
en: A revision name or a range whose right-hand-side cannot be resolved to a reference is not accepted:
zh_HANS-CN: 不接受修订名称或其右侧不能被解析为引用的范围：

note: type: Plain text
en: When creating bundles it is possible to create a self-contained bundle that can be unbundled in a repository with no common history, as well as providing negative revisions to exclude objects needed in the earlier parts of the history.
zh_HANS-CN: 在创建捆绑包时，可以创建一个独立的捆绑包，可以在没有共同历史的版本库中解绑，也可以提供负修订，以排除历史早期部分所需的对象。

note: type: Plain text
en: Feeding a revision such as `new` to `git bundle create` will create a bundle file that contains all the objects reachable from the revision `new`. That bundle can be unbundled in any repository to obtain a full history that leads to the revision `new`:
zh_HANS-CN: 向 `git bundle create` 输入诸如`new'这样的修订版将创建一个捆绑包文件，其中包含所有从 `new` 修订版可以到达的对象。捆绑文件可以在任何版本库中解绑，以获得通往 `new` 版本的完整历史：

note: type: Plain text
en: A revision range such as `old..new` will produce a bundle file that will require the revision `old` (and any objects reachable from it)  to exist for the bundle to be "unbundle"-able:
zh_HANS-CN: 向`git bundle create` 输入诸如 `new` 这样的修订版将创建一个捆绑包文件，其中包含所有从 `new` 修订版可以到达的对象。捆绑包文件可以在任何仓库中解绑，以获得通往 `new` 版本的完整历史：

note: type: Plain text
en: A self-contained bundle without any prerequisites can be extracted into anywhere, even into an empty repository, or be cloned from (i.e., `new`, but not `old..new`).
zh_HANS-CN: 一个没有任何先决条件的独立软件包可以被提取到任何地方，甚至可以提取到一个空的仓库中，或者被克隆出来（即 `new`，但不是 `old..new`）。

note: type: Plain text
en: It is okay to err on the side of caution, causing the bundle file to contain objects already in the destination, as these are ignored when unpacking at the destination.
zh_HANS-CN: 谨慎行事是可以的，使捆绑文件包含已经在目的地的对象，因为在目的地解包时这些对象会被忽略。

note: type: Plain text
en: If you want to match `git clone --mirror`, which would include your refs such as `refs/remotes/*`, use `--all`.  If you want to provide the same set of refs that a clone directly from the source repository would get, use `--branches --tags` for the `<git-rev-list-args>`.
zh_HANS-CN: 如果你想匹配 `git clone --mirror`，这将包括你的 refs 如 `refs/remotes/*`，使用 `--all`。 如果你想提供与直接从源码库克隆得到的相同的引用，使用 `--branches --tags` 作为 `<git-rev-list-args>`。

note: type: Plain text
en: The 'git bundle verify' command can be used to check whether your recipient repository has the required prerequisite commits for a bundle.
zh_HANS-CN: 'git bundle verify' 命令可以用来检查你的接收库是否有一个捆绑包所需的先决条件提交。

note: type: Plain text
en: Assume you want to transfer the history from a repository R1 on machine A to another repository R2 on machine B.  For whatever reason, direct connection between A and B is not allowed, but we can move data from A to B via some mechanism (CD, email, etc.).  We want to update R2 with development made on the branch master in R1.
zh_HANS-CN: 假设你想把 A 机器上的版本库 R1 的历史记录转移到 B 机器上的另一个版本库 R2。由于某种原因，A 和 B 之间不允许直接连接，但我们可以通过某种机制（CD、电子邮件等）把数据从 A 转移到 B。 我们想用 R1 中的分支 master 上的开发来更新 R2。

note: type: Plain text
en: To bootstrap the process, you can first create a bundle that does not have any prerequisites. You can use a tag to remember up to what commit you last processed, in order to make it easy to later update the other repository with an incremental bundle:
zh_HANS-CN: 为了启动这个过程，你可以先创建一个没有任何先决条件的捆绑包。你可以使用一个标签来记住你最后处理的提交，以方便以后用增量的捆绑包来更新其他仓库：

note: type: Plain text
en: Then you transfer file.bundle to the target machine B. Because this bundle does not require any existing object to be extracted, you can create a new repository on machine B by cloning from it:
zh_HANS-CN: 然后你把 file.bundle 传输到目标机器 B。因为这个捆绑包不需要提取任何现有的对象，你可以通过克隆它在机器 B 上创建一个新的仓库：

note: type: delimited block -
en: machineB$ git clone -b master /home/me/tmp/file.bundle R2
zh_HANS-CN: 机器 B $ git clone -b master /home/me/tmp/file.bundle R2

note: type: Plain text
en: This will define a remote called "origin" in the resulting repository that lets you fetch and pull from the bundle. The $GIT_DIR/config file in R2 will have an entry like this:
zh_HANS-CN: 这将在生成的版本库中定义一个名为 "origin" 的远程，让你从捆绑包中获取和拉取。R2 中的 $GIT_DIR/config 文件将有一个这样的条目：

note: type: Plain text
en: To update the resulting mine.git repository, you can fetch or pull after replacing the bundle stored at /home/me/tmp/file.bundle with incremental updates.
zh_HANS-CN: 要更新产生的 mine.git 仓库，你可以在用增量更新替换存储在 /home/me/tmp/file.bundle 的捆绑包后取用或拉取。

note: type: Plain text
en: After working some more in the original repository, you can create an incremental bundle to update the other repository:
zh_HANS-CN: 在原始仓库中再工作一段时间后，你可以创建一个增量包来更新另一个版本库：

note: type: delimited block -
en: machineA$ cd R1
    machineA$ git bundle create file.bundle lastR2bundle..master
    machineA$ git tag -f lastR2bundle master
zh_HANS-CN: 机器 A $ cd R1
    机器 A $ git bundle create file.bundle lastR2bundle..master
    机器 A $ git tag -f lastR2bundle master

note: type: Plain text
en: You then transfer the bundle to the other machine to replace /home/me/tmp/file.bundle, and pull from it.
zh_HANS-CN: 然后你把捆绑包转移到另一台机器上，以取代 /home/me/tmp/file.bundle，并从其中提取。

note: type: delimited block -
en: machineB$ cd R2
    machineB$ git pull
zh_HANS-CN: 机器 B $ cd R2
    机器 B $ git pull

note: type: Plain text
en: If you know up to what commit the intended recipient repository should have the necessary objects, you can use that knowledge to specify the prerequisites, giving a cut-off point to limit the revisions and objects that go in the resulting bundle. The previous example used the lastR2bundle tag for this purpose, but you can use any other options that you would give to the linkgit:git-log[1] command. Here are more examples:
zh_HANS-CN: 如果你知道预期的接收库应该在哪次提交中拥有必要的对象，你可以用这些知识来指定先决条件，给出一个截止点来限制产生的捆绑包中的修订和对象。前面的例子为此使用了 lastR2bundle 标签，但你也可以使用任何其他选项，就像你给 linkgit:git-log[1] 命令的那样。这里有更多的例子：

note: type: Plain text
en: You can use a tag that is present in both:
zh_HANS-CN: 你可以使用一个在两者中都存在的标签：

note: type: Plain text
en: You can use a prerequisite based on time:
zh_HANS-CN: 你可以使用基于时间的先决条件：

note: type: Plain text
en: You can use the number of commits:
zh_HANS-CN: 你可以使用提交的数量：

note: type: Plain text
en: You can run `git-bundle verify` to see if you can extract from a bundle that was created with a prerequisite:
zh_HANS-CN: 你可以运行 `git-bundle verify` 来看看你是否可以从一个用先决条件创建的包中提取：

note: type: Plain text
en: This will list what commits you must have in order to extract from the bundle and will error out if you do not have them.
zh_HANS-CN: 这将列出你必须有哪些提交才能从捆绑包中提取，如果你没有这些提交就会出错。

note: type: Plain text
en: A bundle from a recipient repository's point of view is just like a regular repository which it fetches or pulls from. You can, for example, map references when fetching:
zh_HANS-CN: 从接收者仓库的角度来看，一个捆绑包就像一个普通的仓库，它从那里获取或拉取。例如，你可以在获取的时候映射引用：

note: type: Plain text
en: You can also see what references it offers:
zh_HANS-CN: 你也可以看看它提供哪些引用：

note: type: Labeled list
en: <object>
zh_HANS-CN: <对象>

note: type: Labeled list
en: <type>
zh_HANS-CN: <类型>

note: type: Title -
en: OUTPUT
zh_HANS-CN: 输出

note: type: Title -
en: CAVEATS
zh_HANS-CN: 注意事项

note: type: Plain text
en: git-check-attr - Display gitattributes information
zh_HANS-CN: git-check-attr - 显示 gitattributes 信息

note: type: Plain text
en: 'git check-attr' [--source <tree-ish>] [-a | --all | <attr>...] [--] <pathname>...
    'git check-attr' --stdin [-z] [--source <tree-ish>] [-a | --all | <attr>...]
zh_HANS-CN: 'git check-attr' [--source <树状对象>] [-a | --all | <属性>...] [--] <路径名>...
    'git check-attr' --stdin [-z] [--source <树状对象>] [-a | --all | <属性>...]

note: type: Plain text
en: For every pathname, this command will list if each attribute is 'unspecified', 'set', or 'unset' as a gitattribute on that pathname.
zh_HANS-CN: 对于每个路径名，该命令将列出每个属性是否为 “未指定”、“已设置” 或 “未设置”，作为该路径名的 gitattribute。

note: type: Plain text
en: List all attributes that are associated with the specified paths.  If this option is used, then 'unspecified' attributes will not be included in the output.
zh_HANS-CN: 列出与指定路径相关的所有属性。 如果使用这个选项，那么 “未指定的” 属性将不包括在输出中。

note: type: Plain text
en: Consider `.gitattributes` in the index only, ignoring the working tree.
zh_HANS-CN: 只考虑索引中的 `.gitattributes`，忽略工作区。

note: type: Plain text
en: Read pathnames from the standard input, one per line, instead of from the command-line.
zh_HANS-CN: 从标准输入中读取路径名，每行一个，而不是从命令行读取。

note: type: Plain text
en: The output format is modified to be machine-parsable.  If `--stdin` is also given, input paths are separated with a NUL character instead of a linefeed character.
zh_HANS-CN: 输出格式被修改为机器可解析的。 如果同时给出 `--stdin`，输入路径将用 NUL 字符而不是换行符来分隔。

note: type: Plain text
en: Interpret all preceding arguments as attributes and all following arguments as path names.
zh_HANS-CN: 将前面的所有参数解释为属性，后面的所有参数解释为路径名称。

note: type: Plain text
en: If none of `--stdin`, `--all`, or `--` is used, the first argument will be treated as an attribute and the rest of the arguments as pathnames.
zh_HANS-CN: 如果没有使用 `--stdin`、`--all` 或 `--`，第一个参数将被视为一个属性，其余的参数将被视为路径名。

note: type: Plain text
en: The output is of the form: <path> COLON SP <attribute> COLON SP <info> LF
zh_HANS-CN: 输出的形式是： <路径> COLON SP <属性> COLON SP <信息> LF

note: type: Plain text
en: unless `-z` is in effect, in which case NUL is used as delimiter: <path> NUL <attribute> NUL <info> NUL
zh_HANS-CN: 除非 `-z` 生效，在这种情况下，使用 NUL 作为分隔符： <路径> NUL <属性> NUL <信息> NUL

note: type: Plain text
en: <path> is the path of a file being queried, <attribute> is an attribute being queried and <info> can be either:
zh_HANS-CN: <路径> 是被查询的文件的路径，<属性> 是被查询的属性，<信息> 可以是任何一种：

note: type: Plain text
en: when the attribute is not defined for the path.
zh_HANS-CN: 当该属性未被定义为路径时。

note: type: Plain text
en: when the attribute is defined as false.
zh_HANS-CN: 当该属性被定义为 false 时。

note: type: Plain text
en: when the attribute is defined as true.
zh_HANS-CN: 当该属性被定义为真时。

note: type: Labeled list
en: <value>
zh_HANS-CN: <值>

note: type: Plain text
en: when a value has been assigned to the attribute.
zh_HANS-CN: 当一个值被分配给该属性时。

note: type: Plain text
en: Buffering happens as documented under the `GIT_FLUSH` option in linkgit:git[1].  The caller is responsible for avoiding deadlocks caused by overfilling an input buffer or reading from an empty output buffer.
zh_HANS-CN: 缓冲发生在 linkgit:git[1] 中的 `GIT_FLUSH` 选项下的记录。 调用者负责避免因过度填充输入缓冲区或从空的输出缓冲区读取而造成的死锁。

note: type: Plain text
en: In the examples, the following '.gitattributes' file is used:
zh_HANS-CN: 在例子中，使用了以下 '.gitattributes' 文件：

note: type: Plain text
en: Listing a single attribute:
zh_HANS-CN: 列出一个单一属性：

note: type: Plain text
en: Listing multiple attributes for a file:
zh_HANS-CN: 列出一个文件的多个属性：

note: type: Plain text
en: Listing all attributes for a file:
zh_HANS-CN: 列出一个文件的所有属性：

note: type: Plain text
en: Listing an attribute for multiple files:
zh_HANS-CN: 为多个文件列出一个属性：

note: type: Plain text
en: Not all values are equally unambiguous:
zh_HANS-CN: 并非所有的价值观都是同样明确的：

note: type: Title -
en: EXIT STATUS
zh_HANS-CN: 退出状态码

note: type: Plain text
en: git-check-mailmap - Show canonical names and email addresses of contacts
zh_HANS-CN: git-check-mailmap - 显示联系人的规范名称和电子邮件地址

note: type: Plain text
en: For each ``Name $$<user@host>$$'' or ``$$<user@host>$$'' from the command-line or standard input (when using `--stdin`), look up the person's canonical name and email address (see "Mapping Authors" below). If found, print them; otherwise print the input as-is.
zh_HANS-CN: 对于每一个来自命令行或标准输入（当使用 `--stdin` 时）的 ``Name $$<user@host>$$" 或 ``$$<user@host>$$'，查找该人的规范名称和电子邮件地址（见下面的 “映射作者”）。如果找到了，就打印出来；否则就按原样打印输入。

note: type: Plain text
en: Read contacts, one per line, from the standard input after exhausting contacts provided on the command-line.
zh_HANS-CN: 在用完命令行上提供的联系人后，从标准输入中读取联系人，每行一个。

note: type: Plain text
en: For each contact, a single line is output, terminated by a newline.  If the name is provided or known to the 'mailmap', ``Name $$<user@host>$$'' is printed; otherwise only ``$$<user@host>$$'' is printed.
zh_HANS-CN: 对于每个联系人，都会输出一行，以换行结束。 如果名字被提供或被 'mailmap' 知道，``Name $$<user@host>$$'' 被打印；否则只有 ``$$<user@host>$$'' 被打印。

note: type: Plain text
en: See `mailmap.file` and `mailmap.blob` in linkgit:git-config[1] for how to specify a custom `.mailmap` target file or object.
zh_HANS-CN: 参见 linkgit:git-config[1] 中的 `mailmap.file` 和 `mailmap.blob`，了解如何指定一个自定义的 `.mailmap` 目标文件或对象。

note: type: Plain text
en: Do not interpret any more arguments as options.
zh_HANS-CN: 不将之后的参数解释为选项。

note: type: Plain text
en: 'git checkout' [-q] [-f] [-m] [<branch>]
    'git checkout' [-q] [-f] [-m] --detach [<branch>]
    'git checkout' [-q] [-f] [-m] [--detach] <commit>
    'git checkout' [-q] [-f] [-m] [[-b|-B|--orphan] <new-branch>] [<start-point>]
    'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <pathspec>...
    'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] --pathspec-from-file=<file> [--pathspec-file-nul]
    'git checkout' (-p|--patch) [<tree-ish>] [--] [<pathspec>...]
zh_HANS-CN: 'git checkout' [-q] [-f] [-m] [<分支>]
    'git checkout' [-q] [-f] [-m] --detach [<分支>]
    'git checkout' [-q] [-f] [-m] [--detach] <提交>
    'git checkout' [-q] [-f] [-m] [[-b|-B|--orphan] <新分支>] [<起点>]
    'git checkout' [-f|--ours|--theirs|-m|--conflict=<样式>] [<树状对象>] [--] <修饰符>...
    'git checkout' [-f|--ours|--theirs|-m|--conflict=<样式>] [<树状对象>] --pathspec-from-file=<文件> [--pathspec-file-nul]
    'git checkout' (-p|--patch) [<树状对象>] [--] [<修饰符>...]

note: type: Plain text
en: Updates files in the working tree to match the version in the index or the specified tree.  If no pathspec was given, 'git checkout' will also update `HEAD` to set the specified branch as the current branch.
zh_HANS-CN: 更新工作区中的文件，使其与索引或指定的树中的版本一致。  如果没有给出pathspec，'git checkout'也将更新`HEAD`，将指定的分支设为当前分支。

note: type: Labeled list
en: 'git checkout' [<branch>]
zh_HANS-CN: 'git checkout' [<分支>]

note: type: Plain text
en: To prepare for working on `<branch>`, switch to it by updating the index and the files in the working tree, and by pointing `HEAD` at the branch. Local modifications to the files in the working tree are kept, so that they can be committed to the `<branch>`.
zh_HANS-CN: 要准备在`<分支>`上工作，需要更新索引和工作区中的文件，以及将`HEAD`指向该分支来切换到该分支。对工作区中文件的本地修改会被保留，以便修改可以被提交到`<分支>`。

note: type: Plain text
en: If `<branch>` is not found but there does exist a tracking branch in exactly one remote (call it `<remote>`) with a matching name and `--no-guess` is not specified, treat as equivalent to
zh_HANS-CN: 如果没有找到该`<分支>`，但正好一个远程（称其为`<远程仓库>`）中确实存在一个名称相匹配的已跟踪分支，并且没有指定`--no-guess`，则视为等同于

note: type: Plain text
en: Specifying `-b` causes a new branch to be created as if linkgit:git-branch[1] were called and then checked out.  In this case you can use the `--track` or `--no-track` options, which will be passed to 'git branch'.  As a convenience, `--track` without `-b` implies branch creation; see the description of `--track` below.
zh_HANS-CN: 指定 `-b` 会导致一个新的分支被创建，就像调用 linkgit:git-branch[1] 然后签出一样。  在这种情况下，你可以使用 `--track` 或 `--no-track` 选项，它们将被传递给 'git branch'。  为方便起见，`--track`不加`-b`意味着创建分支；见下文对`--track`的描述。

note: type: Plain text
en: If `-B` is given, `<new-branch>` is created if it doesn't exist; otherwise, it is reset. This is the transactional equivalent of
zh_HANS-CN: 如果给定了`-B'，如果不存在`<新分支>`，就会创建；否则，就会重置。这在事务上等同于

note: type: Plain text
en: that is to say, the branch is not reset/created unless "git checkout" is successful.
zh_HANS-CN: 也就是说，除非 "git checkout "执行成功，否则该分支不会被重置/创建。

note: type: Labeled list
en: 'git checkout' --detach [<branch>]
zh_HANS-CN: 'git checkout' --detach [<分支>]

note: type: Labeled list
en: 'git checkout' [--detach] <commit>
zh_HANS-CN: 'git checkout' [--detach] <提交>

note: type: Plain text
en: Prepare to work on top of `<commit>`, by detaching `HEAD` at it (see "DETACHED HEAD" section), and updating the index and the files in the working tree.  Local modifications to the files in the working tree are kept, so that the resulting working tree will be the state recorded in the commit plus the local modifications.
zh_HANS-CN: 准备在 `<提交>` 上工作，通过分离 `HEAD` 来实现（参见 "DETACHED HEAD" 部分），并更新工作区中的索引和文件。  对工作区中的文件的本地修改会被保留，所以最终的工作区将是提交时记录的状态加上本地的修改。

note: type: Plain text
en: When the `<commit>` argument is a branch name, the `--detach` option can be used to detach `HEAD` at the tip of the branch (`git checkout <branch>` would check out that branch without detaching `HEAD`).
zh_HANS-CN: 当`<提交>`参数是一个分支名称时，`--detach`选项可以用来分离分支顶端的`HEAD`（`git checkout <分支>`会签出该分支而不分离`HEAD`）。

note: type: Plain text
en: Omitting `<branch>` detaches `HEAD` at the tip of the current branch.
zh_HANS-CN: 省略`<分支>`会在当前分支的顶端分离`HEAD`。

note: type: Labeled list
en: 'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] --pathspec-from-file=<file> [--pathspec-file-nul]
zh_HANS-CN: 'git checkout' [-f|--our|--theirs|-m|--conflict=<样式>] [<树状对象>] --pathspec-from-file=<文件> [--pathspec-file-nul]

note: type: Plain text
en: Overwrite the contents of the files that match the pathspec.  When the `<tree-ish>` (most often a commit) is not given, overwrite working tree with the contents in the index.  When the `<tree-ish>` is given, overwrite both the index and the working tree with the contents at the `<tree-ish>`.
zh_HANS-CN: 覆盖符合路径对范文件的内容。  当没有给出`<树状对象>`（最常见的是提交），用索引中的内容覆盖工作区。  当`<树状对象>`被给出时，用`<树状对象>`处的内容覆盖索引和工作区。

note: type: Plain text
en: The index may contain unmerged entries because of a previous failed merge.  By default, if you try to check out such an entry from the index, the checkout operation will fail and nothing will be checked out.  Using `-f` will ignore these unmerged entries.  The contents from a specific side of the merge can be checked out of the index by using `--ours` or `--theirs`.  With `-m`, changes made to the working tree file can be discarded to re-create the original conflicted merge result.
zh_HANS-CN: 索引可能包含因之前合并失败导致的未合并条目。  默认情况下，如果你试图从索引中签出这样的条目，签出操作将失败，没有任何东西被签出。  使用`-f`将忽略这些未合并的条目。  通过使用`--ours"或`--theirs"选项，可以从索引中检出合并的特定一方的内容。  使用`-m`，对工作区文件的修改可以被丢弃，以重新创建原冲突合并的结果。

note: type: Labeled list
en: 'git checkout' (-p|--patch) [<tree-ish>] [--] [<pathspec>...]
zh_HANS-CN: 'git checkout' (-p|--patch) [<树状对象>] [--] [<路径规范>...]

note: type: Plain text
en: This is similar to the previous mode, but lets you use the interactive interface to show the "diff" output and choose which hunks to use in the result.  See below for the description of `--patch` option.
zh_HANS-CN: 这与前面的模式类似，但让你使用交互式界面来显示 "diff "输出，并选择在结果中使用哪些代码块。  关于`--patch`选项的描述，见下文。

note: type: Plain text
en: Quiet, suppress feedback messages.
zh_HANS-CN: 静默，压制反馈信息。

note: type: Plain text
en: Progress status is reported on the standard error stream by default when it is attached to a terminal, unless `--quiet` is specified. This flag enables progress reporting even if not attached to a terminal, regardless of `--quiet`.
zh_HANS-CN: 当它附加到终端时，除非指定 `--quiet`，否则默认情况下会在标准错误流中报告进度状态。这个标志可以启用进度报告，即使没有附在到终端，而不管 `--quiet`。

note: type: Plain text
en: When switching branches, proceed even if the index or the working tree differs from `HEAD`, and even if there are untracked files in the way.  This is used to throw away local changes and any untracked files or directories that are in the way.
zh_HANS-CN: 当切换分支时，即使索引或工作区与`HEAD`不同，即使有未追踪的文件挡住去路，也要继续。  这是用来丢弃本地修改和任何碍事的未追踪文件或目录的。

note: type: Plain text
en: When checking out paths from the index, do not fail upon unmerged entries; instead, unmerged entries are ignored.
zh_HANS-CN: 当从索引中检查出路径时，不将未合并条目视为失败；相反，忽略未合并条目。

note: type: Plain text
en: When checking out paths from the index, check out stage #2 ('ours') or #3 ('theirs') for unmerged paths.
zh_HANS-CN: 当从索引中检查出路径时，要检查第二阶段（'ours'）或第三阶段（'theirs'）的未合并路径。

note: type: Plain text
en: Note that during `git rebase` and `git pull --rebase`, 'ours' and 'theirs' may appear swapped; `--ours` gives the version from the branch the changes are rebased onto, while `--theirs` gives the version from the branch that holds your work that is being rebased.
zh_HANS-CN: 注意在 "git rebase "和 "git pull --rebase "过程中，"ours"和 "theirs"可能会互换；"--ours "给出了分支变基后的版本，而"--theirs"则给出你即将变基的分支版本。

note: type: Plain text
en: This is because `rebase` is used in a workflow that treats the history at the remote as the shared canonical one, and treats the work done on the branch you are rebasing as the third-party work to be integrated, and you are temporarily assuming the role of the keeper of the canonical history during the rebase.  As the keeper of the canonical history, you need to view the history from the remote as `ours` (i.e. "our shared canonical history"), while what you did on your side branch as `theirs` (i.e. "one contributor's work on top of it").
zh_HANS-CN: 这是因为 "rebase"在工作流程中使用，它将远程的历史视为共享的规范历史，并将在你重命名的分支上所做的工作视为需要整合的第三方工作，而你在重命名过程中暂时承担了规范历史守护者的角色。 作为规范历史的守护者，你需要将远程的历史视为 "ours"（即 "我们共享的规范历史"），而将你在侧边分支上的工作视为 "their"（即 "一个贡献者在上面所作的工作"）。

note: type: Plain text
en: Create a new branch named `<new-branch>`, start it at `<start-point>`, and check the resulting branch out; see linkgit:git-branch[1] for details.
zh_HANS-CN: 创建一个名为"<新分支>"的新分支，从"<起点>"开始，并检出产生的分支；详情见 linkgit:git-branch[1]。

note: type: Labeled list
en: -B <new-branch>
zh_HANS-CN: -B <新分支>

note: type: Plain text
en: Creates the branch `<new-branch>`, start it at `<start-point>`; if it already exists, then reset it to `<start-point>`. And then check the resulting branch out.  This is equivalent to running "git branch" with "-f" followed by "git checkout" of that branch; see linkgit:git-branch[1] for details.
zh_HANS-CN: 从`<起点>`开始，创建分支`<新分支>`；如果分支已经存在，则重置为`<起点>`。然后检出生成的分支。这相当于用 "-f"选项 运行 "git branch" ，然后用 "git checkout" 检出该分支；详见 linkgit:git-branch[1]。

note: type: Plain text
en: When creating a new branch, set up "upstream" configuration. See "--track" in linkgit:git-branch[1] for details.
zh_HANS-CN: 创建新分支时，要设置 "上游"配置。详情见 linkgit:git-branch[1] 中的 "--track"。

note: type: Plain text
en: If no `-b` option is given, the name of the new branch will be derived from the remote-tracking branch, by looking at the local part of the refspec configured for the corresponding remote, and then stripping the initial part up to the "*".  This would tell us to use `hack` as the local branch when branching off of `origin/hack` (or `remotes/origin/hack`, or even `refs/remotes/origin/hack`).  If the given name has no slash, or the above guessing results in an empty name, the guessing is aborted.  You can explicitly give a name with `-b` in such a case.
zh_HANS-CN: 如果没有给出`-b`选项，新分支的名称将从远程跟踪分支中推导出来，方法是查看为相应的远程配置引用规范的本地部分，然后剥离初始部分，直至 "*"。由上述可得出，在从`origin/hack`（或`remotes/origin/hack`，甚至`refs/remotes/origin/hack`）分支时，将使用`hack`作为本地分支。如果给定的名字没有斜线，或者上述推测的结果是一个空名，则会终止推测。在这种情况下，你可以用`-b`明确地给出一个名字。

note: type: Plain text
en: Do not set up "upstream" configuration, even if the `branch.autoSetupMerge` configuration variable is true.
zh_HANS-CN: 不设置 "上游 "配置，即使`branch.autoSetupMerge`配置变量为true。

note: type: Plain text
en: If `<branch>` is not found but there does exist a tracking branch in exactly one remote (call it `<remote>`) with a matching name, treat as equivalent to
zh_HANS-CN: 如果没有找到`<分支>`，但确实有一个远程分支（称为`<远程分支>`）的跟踪分支存在，且名称匹配，则视为等同于

note: type: Plain text
en: If the branch exists in multiple remotes and one of them is named by the `checkout.defaultRemote` configuration variable, we'll use that one for the purposes of disambiguation, even if the `<branch>` isn't unique across all remotes. Set it to e.g. `checkout.defaultRemote=origin` to always checkout remote branches from there if `<branch>` is ambiguous but exists on the 'origin' remote. See also `checkout.defaultRemote` in linkgit:git-config[1].
zh_HANS-CN: 如果该分支存在于多个远程，并且其中一个是由`checkout.defaultRemote`配置变量命名的，为了消除歧义，我们将使用该变量，即使`<分支>`在所有远程中并不唯一。将其设置为例如 `checkout.defaultRemote=origin`，以便在`<分支>`不明确但存在于'origin'远程时，总是从那里签出远程分支。参见 linkgit:git-config[1] 中的 `checkout.defaultRemote`。

note: type: Plain text
en: `--guess` is the default behavior. Use `--no-guess` to disable it.
zh_HANS-CN: `--guess`是默认行为。使用`--no-guess`来禁用它。

note: type: Plain text
en: The default behavior can be set via the `checkout.guess` configuration variable.
zh_HANS-CN: 默认行为可以通过`checkout.guess`配置变量设置。

note: type: Plain text
en: Create the new branch's reflog; see linkgit:git-branch[1] for details.
zh_HANS-CN: 创建新分支的引用日志；详见 linkgit:git-branch[1]。

note: type: Plain text
en: Rather than checking out a branch to work on it, check out a commit for inspection and discardable experiments.  This is the default behavior of `git checkout <commit>` when `<commit>` is not a branch name.  See the "DETACHED HEAD" section below for details.
zh_HANS-CN: 与其签出一个分支来工作，不如签出一个提交来进行检查和可放弃的实验。当`<提交>`不是一个分支名时， 这是`git checkout <提交>`的默认行为，。 详见下面的 "游离状态（DETACHED HEAD）"部分。

note: type: Plain text
en: Create a new 'orphan' branch, named `<new-branch>`, started from `<start-point>` and switch to it.  The first commit made on this new branch will have no parents and it will be the root of a new history totally disconnected from all the other branches and commits.
zh_HANS-CN: 从"<起点>"开始，创建一个新的 "孤儿"分支，命名为"<新分支>"，并切换到该分支。 在这个新分支上的第一次提交将没有父分支，它将是一个新的历史起点，与所有其他的分支和提交完全断开。

note: type: Plain text
en: The index and the working tree are adjusted as if you had previously run `git checkout <start-point>`.  This allows you to start a new history that records a set of paths similar to `<start-point>` by easily running `git commit -a` to make the root commit.
zh_HANS-CN: 索引和工作区的调整就像你之前运行`git checkout <起点>`一样。 这允许你轻松地通过运行`git commit -a`来启动一个新的历史，记录一组类似于`<新起点>`的路径，进行根提交。

note: type: Plain text
en: This can be useful when you want to publish the tree from a commit without exposing its full history. You might want to do this to publish an open source branch of a project whose current tree is "clean", but whose full history contains proprietary or otherwise encumbered bits of code.
zh_HANS-CN: 当你想发布一个提交树而不暴露其完整的历史时，这就很有用。你可能想这样做来发布一个项目的开源分支，这个分支的当前树是 "干净的"，但其完整的历史包含了专有的或其他一些代码。

note: type: Plain text
en: If you want to start a disconnected history that records a set of paths that is totally different from the one of `<start-point>`, then you should clear the index and the working tree right after creating the orphan branch by running `git rm -rf .` from the top level of the working tree.  Afterwards you will be ready to prepare your new files, repopulating the working tree, by copying them from elsewhere, extracting a tarball, etc.
zh_HANS-CN: 如果你想启动一个断开的历史，记录一组完全不同于`<起点>`的路径，那么你应该在创建孤儿分支后立即清除索引和工作区，从工作区的顶层运行`git rm -rf .`。 之后你就可以准备你的新文件了，重新填充工作区，办法是从其他地方复制它们，提取一个包，等等。

note: type: Plain text
en: In sparse checkout mode, `git checkout -- <paths>` would update only entries matched by `<paths>` and sparse patterns in `$GIT_DIR/info/sparse-checkout`. This option ignores the sparse patterns and adds back any files in `<paths>`.
zh_HANS-CN: 在稀疏签出模式下，`git checkout -- <路径>`将只更新由`<路径>`和`$GIT_DIR/info/sparse-checkout`中的稀疏模式匹配的条目。这个选项忽略了稀疏模式，并添加回`<路径>`中的任何文件。

note: type: Plain text
en: When switching branches, if you have local modifications to one or more files that are different between the current branch and the branch to which you are switching, the command refuses to switch branches in order to preserve your modifications in context.  However, with this option, a three-way merge between the current branch, your working tree contents, and the new branch is done, and you will be on the new branch.
zh_HANS-CN: 在切换分支时，如果你对一个或多个文件的本地修改在当前分支和你要切换的分支之间是不同的，命令会拒绝切换分支，以保留你的修改内容。 然而，使用这个选项后，就会在当前分支、你的工作区内容和新的分支之间进行三方合并，之后，你会处于新分支。

note: type: Plain text
en: When a merge conflict happens, the index entries for conflicting paths are left unmerged, and you need to resolve the conflicts and mark the resolved paths with `git add` (or `git rm` if the merge should result in deletion of the path).
zh_HANS-CN: 当合并冲突发生时，冲突路径的索引条目会被留下，你需要解决冲突，并用`git add`标记已解决的路径（如果合并应导致删除路径，则用`git rm`）。

note: type: Plain text
en: When checking out paths from the index, this option lets you recreate the conflicted merge in the specified paths.
zh_HANS-CN: 当从索引中检查出路径时，这个选项让你在指定的路径中重新创建冲突的合并。

note: type: Plain text
en: When switching branches with `--merge`, staged changes may be lost.
zh_HANS-CN: 当用`--merge`切换分支时，可能会丢失阶段性修改。

note: type: Plain text
en: Interactively select hunks in the difference between the `<tree-ish>` (or the index, if unspecified) and the working tree.  The chosen hunks are then applied in reverse to the working tree (and if a `<tree-ish>` was specified, the index).
zh_HANS-CN: 在`<树状对象>`（或索引，如果没有指定）和工作区之间的差异中，交互式地选择目标。 选择的目标会被反向应用到工作区上（如果指定了`<树状对象>`，则是索引）。

note: type: Plain text
en: This means that you can use `git checkout -p` to selectively discard edits from your current working tree. See the ``Interactive Mode'' section of linkgit:git-add[1] to learn how to operate the `--patch` mode.
zh_HANS-CN: 这意味着你可以使用 `git checkout -p` 来有选择地丢弃当前工作区上的编辑内容。参见 linkgit:git-add[1] 的 "互动模式''部分，了解`--patch`模式如何操作。

note: type: Plain text
en: Note that this option uses the no overlay mode by default (see also `--overlay`), and currently doesn't support overlay mode.
zh_HANS-CN: 注意，这个选项默认使用无覆盖模式（另见`--overlay`），目前不支持覆盖模式。

note: type: Plain text
en: `git checkout` refuses when the wanted ref is already checked out by another worktree. This option makes it check the ref out anyway. In other words, the ref can be held by more than one worktree.
zh_HANS-CN: `git checkout`在想要的引用已经被另一个工作区签出时拒绝。这个选项让它无论如何都要签出这个引用。换句话说，这个引用可能被多个工作区持有。

note: type: Plain text
en: Silently overwrite ignored files when switching branches. This is the default behavior. Use `--no-overwrite-ignore` to abort the operation when the new branch contains ignored files.
zh_HANS-CN: 在切换分支时静默地覆盖被忽略的文件。这是默认行为。使用 `--no-overwrite-ignore` 可以在新的分支包含被忽略的文件时中止操作。

note: type: Plain text
en: Using `--recurse-submodules` will update the content of all active submodules according to the commit recorded in the superproject. If local modifications in a submodule would be overwritten the checkout will fail unless `-f` is used. If nothing (or `--no-recurse-submodules`)  is used, submodules working trees will not be updated.  Just like linkgit:git-submodule[1], this will detach `HEAD` of the submodule.
zh_HANS-CN: 使用`--recurse-submodules`将根据父项目的提交记录更新所有活动的子模块的内容。如果子模块中的本地修改会被覆盖，除非使用`-f`，则会签出将失败。如果什么都不使用（或`--no-recurse-submodules`），子模块的工作区将不会被更新。  就像linkgit:git-submodule[1]，这将分离子模块的`HEAD`。

note: type: Plain text
en: In the default overlay mode, `git checkout` never removes files from the index or the working tree.  When specifying `--no-overlay`, files that appear in the index and working tree, but not in `<tree-ish>` are removed, to make them match `<tree-ish>` exactly.
zh_HANS-CN: 在默认的覆盖模式下，`git checkout`不会从索引或工作区中删除文件。  当指定`--no-overlay`时，出现在索引和工作区中，但不在`<树状对象>`中的文件会被删除，以使它们与`<树状对象>`完全匹配。

note: type: Plain text
en: Branch to checkout; if it refers to a branch (i.e., a name that, when prepended with "refs/heads/", is a valid ref), then that branch is checked out. Otherwise, if it refers to a valid commit, your `HEAD` becomes "detached" and you are no longer on any branch (see below for details).
zh_HANS-CN: 签出的分支；如果它指的是一个分支（即一个名字，在前面加上 "refs/heads/"时，是一个有效的 引用），那么这个分支就被签出。否则，如果它指的是一个有效的提交，你的`HEAD`就会"分离"，此时，你就不再在任何一个分支上了（详见下文）。

note: type: Plain text
en: You can use the `@{-N}` syntax to refer to the N-th last branch/commit checked out using "git checkout" operation. You may also specify `-` which is synonymous to `@{-1}`.
zh_HANS-CN: 你可以使用`@{-N}`语法来指代使用 "git checkout "操作检查出来的第N个最后的分支或是提交。你也可以指定`-`，它与`@{-1}`同义。

note: type: Plain text
en: As a special case, you may use `A...B` as a shortcut for the merge base of `A` and `B` if there is exactly one merge base. You can leave out at most one of `A` and `B`, in which case it defaults to `HEAD`.
zh_HANS-CN: 作为一种特殊情况，如果正好有一个合并基础，你可以使用`A...B`作为`A`和`B`的合并基础的快捷方式。你最多可以省略在`A`和`B`中默认为`HEAD`的一个分支。

note: type: Labeled list
en: <new-branch>
zh_HANS-CN: <新分支>

note: type: Plain text
en: Name for the new branch.
zh_HANS-CN: 新分支的名称。

note: type: Plain text
en: The name of a commit at which to start the new branch; see linkgit:git-branch[1] for details. Defaults to `HEAD`.
zh_HANS-CN: 启动新分支的提交名称；详见 linkgit:git-branch[1]。默认为 `HEAD`。

note: type: Plain text
en: As a special case, you may use `"A...B"` as a shortcut for the merge base of `A` and `B` if there is exactly one merge base. You can leave out at most one of `A` and `B`, in which case it defaults to `HEAD`.
zh_HANS-CN: 作为一种特殊情况，如果正好有一个合并基数，你可以使用`"A...B "作为`A`和`B`的合并基数的快捷方式。你最多可以漏掉`A`和`B`中的一个，在这种情况下，它默认为`HEAD`。

note: type: Plain text
en: Tree to checkout from (when paths are given). If not specified, the index will be used.
zh_HANS-CN: 签出的树（当路径给定时）。如果没有指定，将使用索引。

note: type: Plain text
en: Limits the paths affected by the operation.
zh_HANS-CN: 限制受操作影响的路径。

note: type: Plain text
en: For more details, see the 'pathspec' entry in linkgit:gitglossary[7].
zh_HANS-CN: 更多细节请参见 linkgit:gitglossary[7] 中的 '路径规范' 条目。

note: type: Title -
en: DETACHED HEAD
zh_HANS-CN: 游离状态（DETACHED HEAD）

note: type: Plain text
en: `HEAD` normally refers to a named branch (e.g. `master`). Meanwhile, each branch refers to a specific commit. Let's look at a repo with three commits, one of them tagged, and with branch `master` checked out:
zh_HANS-CN: `HEAD`通常指的是一个分支的引用（例如`master`）。同时，每个分支指的是一个特定的提交。让我们看看一个有三个提交的仓库，其中一个被标记了，并且分支`master`被检出：

note: type: delimited block -
en:            HEAD (refers to branch 'master')
                |
                v
    a---b---c  branch 'master' (refers to commit 'c')
        ^
        |
      tag 'v2.0' (refers to commit 'b')
zh_HANS-CN:            HEAD（'master'分支的引用）
                |
                v
    a---b---c  branch 'master'（'c' 提交的引用）
        ^
        |
      tag 'v2.0' （'b' 提交的引用）

note: type: Plain text
en: When a commit is created in this state, the branch is updated to refer to the new commit. Specifically, 'git commit' creates a new commit `d`, whose parent is commit `c`, and then updates branch `master` to refer to new commit `d`. `HEAD` still refers to branch `master` and so indirectly now refers to commit `d`:
zh_HANS-CN: 当在这种状态下创建一个提交时，分支会被更新以引用新的提交。具体来说，'git commit'创建了一个新的提交`d`，其父级是提交`c`，然后更新分支`master`以引用新的提交`d`。`HEAD'仍指向`master'，所以现在间接地指向提交`d`：

note: type: delimited block -
en:                HEAD (refers to branch 'master')
                    |
                    v
    a---b---c---d  branch 'master' (refers to commit 'd')
        ^
        |
      tag 'v2.0' (refers to commit 'b')
zh_HANS-CN:                HEAD （指向'master'分支）
                    |
                    v
    a---b---c---d  分支'master' （指向提交'd'）
        ^
        |
      tag 'v2.0' (指向提交'b')

note: type: Plain text
en: It is sometimes useful to be able to checkout a commit that is not at the tip of any named branch, or even to create a new commit that is not referenced by a named branch. Let's look at what happens when we checkout commit `b` (here we show two ways this may be done):
zh_HANS-CN: 有时能够签出一个不在任何命名分支顶端的提交，甚至创建一个不被命名分支引用的新提交，是很有用的。让我们来看看当我们签出提交 `b`时会发生什么（这里我们展示了两种方法）：

note: type: delimited block -
en:    HEAD (refers to commit 'b')
        |
        v
    a---b---c---d  branch 'master' (refers to commit 'd')
        ^
        |
      tag 'v2.0' (refers to commit 'b')
zh_HANS-CN:    HEAD （指向提交'b'）
        |
        v
    a---b---c---d  分支'master'（指向提交'd'）
        ^
        |
      tag 'v2.0' (指向提交'b')

note: type: Plain text
en: Notice that regardless of which checkout command we use, `HEAD` now refers directly to commit `b`. This is known as being in detached `HEAD` state.  It means simply that `HEAD` refers to a specific commit, as opposed to referring to a named branch. Let's see what happens when we create a commit:
zh_HANS-CN: 请注意，无论我们使用哪条结账命令，`HEAD`现在都直接指向提交`b`。这就是所谓的分离的`HEAD'状态。  这意味着，`HEAD`指向一个特定的提交，而不是指向一个命名的分支。让我们看看创建提交时发生了什么：

note: type: delimited block -
en:      HEAD (refers to commit 'e')
          |
          v
          e
         /
    a---b---c---d  branch 'master' (refers to commit 'd')
        ^
        |
      tag 'v2.0' (refers to commit 'b')
zh_HANS-CN:      HEAD （指向提交'e'）
          |
          v
          e
         /
    a---b---c---d  branch 'master' （指向提交'd'）
        ^
        |
      tag 'v2.0' （指向提交'b'）

note: type: Plain text
en: There is now a new commit `e`, but it is referenced only by `HEAD`. We can of course add yet another commit in this state:
zh_HANS-CN: 现在有一个新的提交`e`，但它只被`HEAD`所引用。当然，我们可以在这个状态下再增加一个提交：

note: type: delimited block -
en: 	 HEAD (refers to commit 'f')
    	  |
    	  v
          e---f
         /
    a---b---c---d  branch 'master' (refers to commit 'd')
        ^
        |
      tag 'v2.0' (refers to commit 'b')
zh_HANS-CN: 	 HEAD（指向提交'f'）。
    	  |
    	  v
          e--f
         /
    a--b--c--d 分支"master"（指向提交'd'）。
        ^
        |
      tag 'v2.0'（指向提交'b'）。

note: type: Plain text
en: In fact, we can perform all the normal Git operations. But, let's look at what happens when we then checkout `master`:
zh_HANS-CN: 事实上，我们可以执行所有正常的 Git 操作。但是，让我们看看当我们签出`master`时会发生什么：

note: type: delimited block -
en:                HEAD (refers to branch 'master')
          e---f     |
         /          v
    a---b---c---d  branch 'master' (refers to commit 'd')
        ^
        |
      tag 'v2.0' (refers to commit 'b')
zh_HANS-CN:                HEAD（指向分支 'master'）
          e---f     |
         /          v
    a---b---c---d  branch 'master' （指向提交 'd'）
        ^
        |
      tag 'v2.0' (指向提交 'b')

note: type: Plain text
en: It is important to realize that at this point nothing refers to commit `f`. Eventually commit `f` (and by extension commit `e`) will be deleted by the routine Git garbage collection process, unless we create a reference before that happens. If we have not yet moved away from commit `f`, any of these will create a reference to it:
zh_HANS-CN: 重要的是要意识到，在这一点上，没有任何引用是指向提交`f`的。最终，提交 `f`（以及提交 `e`）会被 Git 的例行垃圾回收程序删除，除非我们在这之前创建一个引用。如果我们还没有离开提交 `f`，以下任何一个操作都会创建一个对它的引用：

note: type: Plain text
en: creates a new branch `foo`, which refers to commit `f`, and then updates `HEAD` to refer to branch `foo`. In other words, we'll no longer be in detached `HEAD` state after this command.
zh_HANS-CN: 创建一个新的分支`foo`，指向提交`f`，然后更新`HEAD`，指向分支`foo`。换句话说，这条命令之后，我们将不再处于分离的`HEAD`状态。

note: type: Plain text
en: similarly creates a new branch `foo`, which refers to commit `f`, but leaves `HEAD` detached.
zh_HANS-CN: 类似的，创建一个新的分支`foo`，它指向提交`f`，但将`HEAD`分离出来。

note: type: Plain text
en: creates a new tag `foo`, which refers to commit `f`, leaving `HEAD` detached.
zh_HANS-CN: 创建一个新的标签`foo`，指向提交`f`，让`HEAD`处于分离状态。

note: type: Plain text
en: If we have moved away from commit `f`, then we must first recover its object name (typically by using git reflog), and then we can create a reference to it. For example, to see the last two commits to which `HEAD` referred, we can use either of these commands:
zh_HANS-CN: 如果我们已经离开了`f'的提交，那么我们必须首先恢复它的对象名称（通常使用git reflog），然后我们可以创建一个对它的引用。例如，要查看`HEAD`指向的最后两个提交，我们可以使用以下任一命令：

note: type: Plain text
en: When there is only one argument given and it is not `--` (e.g. `git checkout abc`), and when the argument is both a valid `<tree-ish>` (e.g. a branch `abc` exists) and a valid `<pathspec>` (e.g. a file or a directory whose name is "abc" exists), Git would usually ask you to disambiguate.  Because checking out a branch is so common an operation, however, `git checkout abc` takes "abc" as a `<tree-ish>` in such a situation.  Use `git checkout -- <pathspec>` if you want to checkout these paths out of the index.
zh_HANS-CN: 当只有一个参数且不是`--`时（例如`git checkout abc`），当参数既是有效的`<树状对象>`（例如分支`abc`存在）又是有效的`<路径规范>`（例如文件或目录的名称为 "abc "存在），Git通常会要求你进行区分。  因为签出分支是很常见的操作，`git checkout abc`在这种情况下把 "abc "作为`<树状对象>`。  如果你想从索引中签出这些路径，请使用`git checkout --<路径规范>`。

note: type: Title ===
en: 1. Paths
zh_HANS-CN: 1.路径

note: type: Plain text
en: The following sequence checks out the `master` branch, reverts the `Makefile` to two revisions back, deletes `hello.c` by mistake, and gets it back from the index.
zh_HANS-CN: 下面的序列检查了 "master "分支，将 "Makefile "恢复到两个修订版，错误地删除了 "hello.c"，并从索引中取回它。

note: type: Plain text
en: switch branch
zh_HANS-CN: 选择分支

note: type: Plain text
en: take a file out of another commit
zh_HANS-CN: 将一个文件从另一个提交中取出

note: type: Plain text
en: restore `hello.c` from the index
zh_HANS-CN: 从索引中恢复`hello.c`

note: type: Plain text
en: If you want to check out _all_ C source files out of the index, you can say
zh_HANS-CN: 如果你想从索引中检出_所有_的C源文件，你可以这样

note: type: Plain text
en: Note the quotes around `*.c`.  The file `hello.c` will also be checked out, even though it is no longer in the working tree, because the file globbing is used to match entries in the index (not in the working tree by the shell).
zh_HANS-CN: 注意 `*.c `周围的引号。  文件`hello.c`也将被检出，尽管它已经不在工作树中了，因为文件通配符被用来匹配索引中的条目（不是工作区中的shell）。

note: type: Plain text
en: If you have an unfortunate branch that is named `hello.c`, this step would be confused as an instruction to switch to that branch.  You should instead write:
zh_HANS-CN: 如果不幸你有一个分支被命名为 "hello.c"，这一步会误认为切换到该分支的指令。  你应该这样写：

note: type: Plain text
en: After working in the wrong branch, switching to the correct branch would be done using:
zh_HANS-CN: 在错误的分支工作后，切换到正确的分支将使用：

note: type: Plain text
en: However, your "wrong" branch and correct `mytopic` branch may differ in files that you have modified locally, in which case the above checkout would fail like this:
zh_HANS-CN: 然而，你的 "错误"分支和正确的`mytopic`分支可能在你本地修改的文件中存在差异，在这种情况下，上述检出会失败，像这样：

note: type: Plain text
en: You can give the `-m` flag to the command, which would try a three-way merge:
zh_HANS-CN: 你可以给命令加上 `-m`标志，这样就可以尝试三方合并了：

note: type: Plain text
en: After this three-way merge, the local modifications are _not_ registered in your index file, so `git diff` would show you what changes you made since the tip of the new branch.
zh_HANS-CN: 在这个三方合并之后，本地的修改并「没有」登记在你的索引文件中，所以`git diff`会显示你在新分支的提示下做了哪些修改。

note: type: Plain text
en: When a merge conflict happens during switching branches with the `-m` option, you would see something like this:
zh_HANS-CN: 当使用`-m`选项切换分支时发生合并冲突，你会看到类似这样的情况：

note: type: Plain text
en: At this point, `git diff` shows the changes cleanly merged as in the previous example, as well as the changes in the conflicted files.  Edit and resolve the conflict and mark it resolved with `git add` as usual:
zh_HANS-CN: 在这一点上，`git diff`显示了与前面的例子一样干净地合并的修改，以及冲突文件中的修改。  编辑并解决冲突，让后像往常一样用`git add`标记已解决：

note: type: Plain text
en: git-check-ref-format - Ensures that a reference name is well formed
zh_HANS-CN: git-check-ref-format - 确保引用名称的格式正确

note: type: Plain text
en: 'git check-ref-format' [--normalize]
           [--[no-]allow-onelevel] [--refspec-pattern]
           <refname>
    'git check-ref-format' --branch <branchname-shorthand>
zh_HANS-CN: 'git check-ref-format' [--normalize]
           [--[no-]allow-onelevel] [--refspec-pattern]
           <引用名>
    'git check-ref-format' --branch <branchname-shorthand>

note: type: Plain text
en: Checks if a given 'refname' is acceptable, and exits with a non-zero status if it is not.
zh_HANS-CN: 检查给定的 ‘引用名’ 是否可接受，如果不可接受，则以非零状态退出。

note: type: Plain text
en: A reference is used in Git to specify branches and tags.  A branch head is stored in the `refs/heads` hierarchy, while a tag is stored in the `refs/tags` hierarchy of the ref namespace (typically in `$GIT_DIR/refs/heads` and `$GIT_DIR/refs/tags` directories or, as entries in file `$GIT_DIR/packed-refs` if refs are packed by `git gc`).
zh_HANS-CN: 在 Git 中，引用被用来指定分支和标签。 分支头存储在 `refs/heads` 层次结构中，而标签存储在引用命名空间的 `refs/tags` 层次结构中（通常在 `$GIT_DIR/refs/heads` 和 `$GIT_DIR/refs/tags` 目录中，或者，如果引用是由 `git gc` 打包的，则作为文件 `$GIT_DIR/packed-refs` 的条目）。

note: type: Plain text
en: Git imposes the following rules on how references are named:
zh_HANS-CN: Git 对引用的命名方式有以下规则：

note: type: Plain text
en: They can include slash `/` for hierarchical (directory)  grouping, but no slash-separated component can begin with a dot `.` or end with the sequence `.lock`.
zh_HANS-CN: 它们可以包括斜线`/`，用于分层（目录）分组，但任何斜线分隔的组件都不能以点`.`开头或以序列`.lock`结尾。

note: type: Plain text
en: They must contain at least one `/`. This enforces the presence of a category like `heads/`, `tags/` etc. but the actual names are not restricted.  If the `--allow-onelevel` option is used, this rule is waived.
zh_HANS-CN: 它们可以包括斜线 `/`，用于分层（目录）分组，但任何斜线分隔的组件都不能以点 `.` 开头或以序列 `.lock` 结尾。

note: type: Plain text
en: They cannot have two consecutive dots `..` anywhere.
zh_HANS-CN: 他们不能在任何地方有两个连续的点 `..`。

note: type: Plain text
en: They cannot have ASCII control characters (i.e. bytes whose values are lower than \040, or \177 `DEL`), space, tilde `~`, caret `^`, or colon `:` anywhere.
zh_HANS-CN: 它们不能有 ASCII 控制字符（即数值低于 \040，或 177 `DEL` 的字节）、空格、斜体字 `~`、省略号 `^`，或冒号 `:` 的任何一个。

note: type: Plain text
en: They cannot have question-mark `?`, asterisk `*`, or open bracket `[` anywhere.  See the `--refspec-pattern` option below for an exception to this rule.
zh_HANS-CN: 它们不能有问号 `?`，星号 `*`，或大括号 `[`的地方。 参见下面的 `--refspec-pattern` 选项，以了解这一规则的例外情况。

note: type: Plain text
en: They cannot begin or end with a slash `/` or contain multiple consecutive slashes (see the `--normalize` option below for an exception to this rule)
zh_HANS-CN: 它们不能以斜线 `/` 开头或结尾，也不能包含多个连续的斜线（参见下面的 `--normalize` 选项，该规则的一个例外）

note: type: Plain text
en: They cannot end with a dot `.`.
zh_HANS-CN: 它们不能以点 `.` 结尾。

note: type: Plain text
en: They cannot contain a sequence `@{`.
zh_HANS-CN: 它们不能包含一个序列 `@{`。

note: type: Plain text
en: They cannot be the single character `@`.
zh_HANS-CN: 它们不能是单个字符 `@`。

note: type: Plain text
en: They cannot contain a `\`.
zh_HANS-CN: 它们不能包含一个 `\`。

note: type: Plain text
en: These rules make it easy for shell script based tools to parse reference names, pathname expansion by the shell when a reference name is used unquoted (by mistake), and also avoid ambiguities in certain reference name expressions (see linkgit:gitrevisions[7]):
zh_HANS-CN: 这些规则使基于 shell 脚本的工具很容易解析引用名，当引用名未加引号（错误地）使用时由 shell 进行路径名扩展，同时也避免了某些引用名表达的歧义（见 linkgit:gitrevisions[7]）：

note: type: Plain text
en: A double-dot `..` is often used as in `ref1..ref2`, and in some contexts this notation means `^ref1 ref2` (i.e. not in `ref1` and in `ref2`).
zh_HANS-CN: 双点 `..` 经常被用作 `ref1..ref2`，在某些情况下，这个符号意味着 `^ref1 ref2`（即不在 `ref1` 和 `ref2` 中）。

note: type: Plain text
en: A tilde `~` and caret `^` are used to introduce the postfix 'nth parent' and 'peel onion' operation.
zh_HANS-CN: 省略号 `~` 和 `^` 符号用于介绍后缀 ‘第 n 个父亲’ 和 ‘剥洋葱’ 操作。

note: type: Plain text
en: A colon `:` is used as in `srcref:dstref` to mean "use srcref\'s value and store it in dstref" in fetch and push operations.  It may also be used to select a specific object such as with 'git cat-file': "git cat-file blob v1.3.3:refs.c".
zh_HANS-CN: 冒号 `:` 在获取和推送操作中被用于 `srcref:dstref`，表示 `使用 srcref（源引用）的值并将其存储在 dstref（目标引用）中。 它也可以用来选择一个特定的对象，如 'git cat-file': "git cat-file blob v1.3.3:refs.c"。

note: type: Plain text
en: at-open-brace `@{` is used as a notation to access a reflog entry.
zh_HANS-CN: `@{` 被用来作为访问一个引用日志条目的符号。

note: type: Plain text
en: With the `--branch` option, the command takes a name and checks if it can be used as a valid branch name (e.g. when creating a new branch). But be cautious when using the previous checkout syntax that may refer to a detached HEAD state.  The rule `git check-ref-format --branch $name` implements may be stricter than what `git check-ref-format refs/heads/$name` says (e.g. a dash may appear at the beginning of a ref component, but it is explicitly forbidden at the beginning of a branch name).  When run with `--branch` option in a repository, the input is first expanded for the ``previous checkout syntax'' `@{-n}`.  For example, `@{-1}` is a way to refer the last thing that was checked out using "git switch" or "git checkout" operation.  This option should be used by porcelains to accept this syntax anywhere a branch name is expected, so they can act as if you typed the branch name. As an exception note that, the ``previous checkout operation'' might result in a commit object name when the N-th last thing checked out was not a branch.
zh_HANS-CN: 使用 `--branch` 选项，该命令接收一个名字，并检查它是否可以作为一个有效的分支名称（例如在创建新的分支时）。但在使用之前的检查语法时要谨慎，因为它可能指的是一个分离的 HEAD 状态。 `git check-ref-format --branch $name` 实现的规则可能比` git check-ref-format refs/heads/$name` 说的更严格（例如，破折号可以出现在引用组件的开头，但在分支名的开头是明确禁止的）。 当在仓库中使用 `--branch` 选项运行时，输入的内容首先被扩展为 ``以前的检出语法" `@{-n}`。 例如，`@{-1}` 是指使用 "git switch" 或 "git checkout" 操作签出的最后一件东西。 这个选项应该被上层命令用来在任何需要分支名的地方接受这个语法，这样他们就可以像你输入分支名一样行事。作为一个例外，请注意，当最后签出的第 N 个东西不是一个分支时，"以前的签出操作" 可能会导致一个提交对象的名字。

note: type: Plain text
en: Controls whether one-level refnames are accepted (i.e., refnames that do not contain multiple `/`-separated components).  The default is `--no-allow-onelevel`.
zh_HANS-CN: 控制是否接受单级参考名称（即不包含多个 `/` 分隔的参考名称）。 默认值是 `--no-allow-onelevel`。

note: type: Plain text
en: Interpret <refname> as a reference name pattern for a refspec (as used with remote repositories).  If this option is enabled, <refname> is allowed to contain a single `*` in the refspec (e.g., `foo/bar*/baz` or `foo/bar*baz/` but not `foo/bar*/baz*`).
zh_HANS-CN: 将 <引用名> 解释为引用规范的参考名称模式（如用于远程仓库）。 如果这个选项被启用，<引用名> 允许在引用规范中包含一个 `*`（例如， `foo/bar*/baz` 或 `foo/bar*baz/`，但不允许 `foo/bar*/baz*`）。

note: type: Plain text
en: Normalize 'refname' by removing any leading slash (`/`)  characters and collapsing runs of adjacent slashes between name components into a single slash.  If the normalized refname is valid then print it to standard output and exit with a status of 0, otherwise exit with a non-zero status.  (`--print` is a deprecated way to spell `--normalize`.)
zh_HANS-CN: 将 ‘引用名’ 规范化，去掉任何前导斜线（`/`）字符，并将名称成分之间的相邻斜线折叠成一个斜线。 如果规范化后的引用名有效，则将其打印到标准输出，并以 0 的状态退出，否则以非零状态退出。 (`--print` 是 `--normalize` 的一种废弃的拼写方式。)

note: type: Plain text
en: Print the name of the previous thing checked out:
zh_HANS-CN: 打印前一个检出的东西的名称：

note: type: Plain text
en: Determine the reference name to use for a new branch:
zh_HANS-CN: 确定新分支要使用的引用名称：

note: type: Plain text
en: Given one or more existing commits, apply the change each one introduces, recording a new commit for each.  This requires your working tree to be clean (no modifications from the HEAD commit).
zh_HANS-CN: 给出一个或多个现有的提交，应用每个提交所带来的变化，为每个提交记录一个新的提交。 这需要您的工作区是干净的（没有对 HEAD 提交的修改）。

note: type: Plain text
en: When it is not obvious how to apply a change, the following happens:
zh_HANS-CN: 当如何应用一个变化不明显时，会发生以下情况：

note: type: Plain text
en: The current branch and `HEAD` pointer stay at the last commit successfully made.
zh_HANS-CN: 当前的分支和 `HEAD` 指针保持在最后一次成功提交的位置。

note: type: Plain text
en: The `CHERRY_PICK_HEAD` ref is set to point at the commit that introduced the change that is difficult to apply.
zh_HANS-CN: `CHERRY_PICK_HEAD` 引用被设置为指向引入难以应用的修改的提交。

note: type: Plain text
en: Paths in which the change applied cleanly are updated both in the index file and in your working tree.
zh_HANS-CN: 在索引文件和你的工作区中，更改应用得很干净的路径都被更新。

note: type: Plain text
en: No other modifications are made.
zh_HANS-CN: 不做其他修改。

note: type: Plain text
en: See linkgit:git-merge[1] for some hints on resolving such conflicts.
zh_HANS-CN: 参见 linkgit:git-merge[1] 以了解一些解决此类冲突的提示。

note: type: Plain text
en: Commits to cherry-pick.  For a more complete list of ways to spell commits, see linkgit:gitrevisions[7].  Sets of commits can be passed but no traversal is done by default, as if the `--no-walk` option was specified, see linkgit:git-rev-list[1]. Note that specifying a range will feed all <commit>... arguments to a single revision walk (see a later example that uses 'maint master..next').
zh_HANS-CN: 拣选（cherry-pick）的提交。 更完整的拼写提交的方法列表，见 linkgit:gitrevisions[7]。 可以传递提交集，但默认不做遍历，就像指定了 `--no-walk` 选项一样，见 linkgit:git-rev-list[1]。注意，指定一个范围会把所有 <提交>... 参数送入一个单一的修订版（见后面的例子，使用 'maint master...next'）。

note: type: Plain text
en: With this option, 'git cherry-pick' will let you edit the commit message prior to committing.
zh_HANS-CN: 有了这个选项，'git cherry-pick' 会让你在提交前编辑提交信息。

note: type: Labeled list
en: --cleanup=<mode>
zh_HANS-CN: --cleanup=<模式>

note: type: Plain text
en: This option determines how the commit message will be cleaned up before being passed on to the commit machinery. See linkgit:git-commit[1] for more details. In particular, if the '<mode>' is given a value of `scissors`, scissors will be appended to `MERGE_MSG` before being passed on in the case of a conflict.
zh_HANS-CN: 这个选项决定了提交信息在传递给提交机制之前将如何进行清理。更多细节见 linkgit:git-commit[1]。特别是，如果 '<模式>' 的值为 `scissors`，那么在发生冲突时，`scissors` 将被附加到 `MERGE_MSG` 上。

note: type: Plain text
en: When recording the commit, append a line that says "(cherry picked from commit ...)" to the original commit message in order to indicate which commit this change was cherry-picked from.  This is done only for cherry picks without conflicts.  Do not use this option if you are cherry-picking from your private branch because the information is useless to the recipient.  If on the other hand you are cherry-picking between two publicly visible branches (e.g. backporting a fix to a maintenance branch for an older release from a development branch), adding this information can be useful.
zh_HANS-CN: 在记录提交时，在原始提交信息中添加一行 "(cherry picked from commit ...)"，以表明这个改动是从哪个提交中拣选的。 这只适用于没有冲突的拣选。 如果你是从自己的私有分支中偷梁换柱，请不要使用这个选项，因为这个信息对接收者来说是无用的。 另一方面，如果您是在两个公开可见的分支之间进行拣选（例如，从开发分支向维护分支回传一个旧版本的修正），添加这一信息会很有用。

note: type: Plain text
en: It used to be that the command defaulted to do `-x` described above, and `-r` was to disable it.  Now the default is not to do `-x` so this option is a no-op.
zh_HANS-CN: 过去，该命令默认为做上述的 `-x`，`-r` 是禁用它。 现在默认是不做 `-x` ，所以这个选项是一个无用的选项。

note: type: Plain text
en: Usually you cannot cherry-pick a merge because you do not know which side of the merge should be considered the mainline.  This option specifies the parent number (starting from 1) of the mainline and allows cherry-pick to replay the change relative to the specified parent.
zh_HANS-CN: 通常你不能对一个合并进行拣选，因为你不知道合并的哪一边应该被视为主线。 这个选项指定了主线的父号（从 1 开始），允许拣选相对于指定的父号重放修改。

note: type: Plain text
en: Usually the command automatically creates a sequence of commits.  This flag applies the changes necessary to cherry-pick each named commit to your working tree and the index, without making any commit.  In addition, when this option is used, your index does not have to match the HEAD commit.  The cherry-pick is done against the beginning state of your index.
zh_HANS-CN: 通常该命令会自动创建一连串的提交。 这个标志会对您的工作树和索引进行必要的修改，以摘取每个命名的提交，而不做任何提交。 此外，使用这个选项时，您的索引不需要与 HEAD 提交相匹配。 挑拣是针对你的索引的起始状态进行的。

note: type: Plain text
en: This is useful when cherry-picking more than one commits' effect to your index in a row.
zh_HANS-CN: 这在连续摘取多个提交的效果给你的索引时很有用。

note: type: Plain text
en: Add a `Signed-off-by` trailer at the end of the commit message.  See the signoff option in linkgit:git-commit[1] for more information.
zh_HANS-CN: 在提交信息的末尾添加一个 `Signed-off-by` 的尾注。 更多信息见 linkgit:git-commit[1] 中的 signoff 选项。

note: type: Plain text
en: If the current HEAD is the same as the parent of the cherry-pick'ed commit, then a fast forward to this commit will be performed.
zh_HANS-CN: 如果当前的 HEAD 与拣选的提交的父本相同，那么将执行快速合并到这个提交。

note: type: Plain text
en: By default, cherry-picking an empty commit will fail, indicating that an explicit invocation of `git commit --allow-empty` is required. This option overrides that behavior, allowing empty commits to be preserved automatically in a cherry-pick. Note that when "--ff" is in effect, empty commits that meet the "fast-forward" requirement will be kept even without this option.  Note also, that use of this option only keeps commits that were initially empty (i.e. the commit recorded the same tree as its parent).  Commits which are made empty due to a previous commit are dropped.  To force the inclusion of those commits use `--keep-redundant-commits`.
zh_HANS-CN: 默认情况下，对空提交的偷取会失败，表明需要明确调用 `git commit --allow-empty`。这个选项覆盖了这一行为，允许在偷取时自动保留空的提交。注意，当 "--ff" 生效时，即使没有这个选项，符合 “快速合并” 要求的空提交也会被保留。 还要注意的是，使用这个选项只保留最初为空的提交（即提交与它的父级记录在同一目录苏上）。 由于之前的提交而导致的空的提交会被放弃。 如果要强制包含这些提交，请使用 `--keep-redundant-commits`。

note: type: Plain text
en: By default, cherry-picking a commit with an empty message will fail.  This option overrides that behavior, allowing commits with empty messages to be cherry picked.
zh_HANS-CN: 默认情况下，对空信息的提交进行拣选会失败。 这个选项覆盖了这一行为，允许对空信息的提交进行拣选。

note: type: Plain text
en: If a commit being cherry picked duplicates a commit already in the current history, it will become empty.  By default these redundant commits cause `cherry-pick` to stop so the user can examine the commit. This option overrides that behavior and creates an empty commit object.  Implies `--allow-empty`.
zh_HANS-CN: 如果被摘取的提交与当前历史中已有的提交重复，它将变成空的。 默认情况下，这些多余的提交会导致 `cherry-pick` 停止，以便用户能够检查提交。这个选项覆盖了这一行为，并创建一个空的提交对象。暗含 `--allow-empty`。

note: type: Plain text
en: Use the given merge strategy.  Should only be used once.  See the MERGE STRATEGIES section in linkgit:git-merge[1] for details.
zh_HANS-CN: 使用给定的合并策略。 应该只使用一次。 详见 linkgit:git-merge[1] 中的合并策略部分。

note: type: Plain text
en: Pass the merge strategy-specific option through to the merge strategy.  See linkgit:git-merge[1] for details.
zh_HANS-CN: 将合并策略特有的选项传递给合并策略。 详见 linkgit:git-merge[1]。

note: type: Title -
en: SEQUENCER SUBCOMMANDS
zh_HANS-CN: 序列器子命令

note: type: Plain text
en: Apply the change introduced by the commit at the tip of the master branch and create a new commit with this change.
zh_HANS-CN: 应用主分支顶端的提交所引入的修改，并以这个修改创建一个新的提交。

note: type: Plain text
en: Apply the changes introduced by all commits that are ancestors of master but not of HEAD to produce new commits.
zh_HANS-CN: 应用所有属于 master 但不属于 HEAD 的祖先的提交所带来的变化，产生新的提交。

note: type: Plain text
en: Apply the changes introduced by all commits that are ancestors of maint or next, but not master or any of its ancestors.  Note that the latter does not mean `maint` and everything between `master` and `next`; specifically, `maint` will not be used if it is included in `master`.
zh_HANS-CN: 应用所有属于 maint 或 next 的祖先的提交所带来的变化，但不包括 master 或其任何祖先。 注意，后者不是指 `maint` 和 `master` 与 `next` 之间的一切；具体来说，如果 `maint` 包含在 `master` 中，则不会被使用。

note: type: Plain text
en: Apply the changes introduced by the fifth and third last commits pointed to by master and create 2 new commits with these changes.
zh_HANS-CN: 应用 master 指向的第五次和最后第三次提交所带来的变化，并根据这些变化创建两个新的提交。

note: type: Plain text
en: Apply to the working tree and the index the changes introduced by the second last commit pointed to by master and by the last commit pointed to by next, but do not create any commit with these changes.
zh_HANS-CN: 在工作区和索引中应用 master 指向的倒数第二个提交和 next 指向的最后一个提交所带来的变化，但不要用这些变化创建任何提交。

note: type: Plain text
en: If history is linear and HEAD is an ancestor of next, update the working tree and advance the HEAD pointer to match next.  Otherwise, apply the changes introduced by those commits that are in next but not HEAD to the current branch, creating a new commit for each new change.
zh_HANS-CN: 如果历史是线性的，并且 HEAD 是 next 的祖先，则更新工作区并将 HEAD 指针向前推进以匹配 next。 否则，将那些在 next 但不在 HEAD 中的提交所带来的变化应用到当前分支，为每个新变化创建一个新的提交。

note: type: Plain text
en: Apply the changes introduced by all commits on the master branch that touched README to the working tree and index, so the result can be inspected and made into a single new commit if suitable.
zh_HANS-CN: 将主干分支上所有触及 README 的提交所带来的变化应用到工作区和索引中，这样就可以检查结果，并在合适的时候做成一个新的提交。

note: type: Plain text
en: The following sequence attempts to backport a patch, bails out because the code the patch applies to has changed too much, and then tries again, this time exercising more care about matching up context lines.
zh_HANS-CN: 下面的序列试图回传一个补丁，因为补丁所适用的代码变化太大，所以放弃了，然后再试一次，这次对上下文行的匹配更加谨慎。

note: type: Plain text
en: apply the change that would be shown by `git show topic^`.  In this example, the patch does not apply cleanly, so information about the conflict is written to the index and working tree and no new commit results.
zh_HANS-CN: 应用将由 `git show topic^` 显示的变化。 在这个例子中，补丁没有干净地应用，所以冲突的信息被写入索引和工作树，没有新的提交结果。

note: type: Plain text
en: summarize changes to be reconciled
zh_HANS-CN: 总结需要调节的变化

note: type: Plain text
en: cancel the cherry-pick.  In other words, return to the pre-cherry-pick state, preserving any local modifications you had in the working tree.
zh_HANS-CN: 取消 cherry-pick。 换句话说，返回到 cherry-pick 前的状态，保留你在工作区上的任何本地修改。

note: type: Plain text
en: try to apply the change introduced by `topic^` again, spending extra time to avoid mistakes based on incorrectly matching context lines.
zh_HANS-CN: 尝试再次应用由 `topic^` 引入的修改，花费额外的时间来避免基于不正确匹配的上下文行的错误。

note: type: Plain text
en: git-cherry - Find commits yet to be applied to upstream
zh_HANS-CN: git-cherry - 查找尚未应用于上游的提交内容

note: type: Plain text
en: Determine whether there are commits in `<head>..<upstream>` that are equivalent to those in the range `<limit>..<head>`.
zh_HANS-CN: 确定 `<head>...<upstream>` 中是否有与 `<limit>...<head>` 范围内的提交相等。

note: type: Plain text
en: The equivalence test is based on the diff, after removing whitespace and line numbers.  git-cherry therefore detects when commits have been "copied" by means of linkgit:git-cherry-pick[1], linkgit:git-am[1] or linkgit:git-rebase[1].
zh_HANS-CN: 因此，git-cherry 通过 linkgit:git-cherry-pick[1]、linkgit:git-am[1] 或 linkgit:git-rebase[1] 来检测提交是否被 “复制” 了。

note: type: Plain text
en: Outputs the SHA1 of every commit in `<limit>..<head>`, prefixed with `-` for commits that have an equivalent in <upstream>, and `+` for commits that do not.
zh_HANS-CN: 输出 `<limit>...<head>` 中每个提交的 SHA1，对于在 <upstream> 中有对应的提交，以 `-` 为前缀，对于没有对应的提交，以 `+` 为前缀。

note: type: Plain text
en: Show the commit subjects next to the SHA1s.
zh_HANS-CN: 在 SHA1 旁边显示提交主题。

note: type: Plain text
en: Upstream branch to search for equivalent commits.  Defaults to the upstream branch of HEAD.
zh_HANS-CN: 在 SHA1 旁边显示提交主题。

note: type: Plain text
en: Working branch; defaults to HEAD.
zh_HANS-CN: 工作分支；默认为 HEAD。

note: type: Plain text
en: Do not report commits up to (and including) limit.
zh_HANS-CN: 不报告达到（和包括）极限的提交。

note: type: Title ~
en: Patch workflows
zh_HANS-CN: 补丁工作流程

note: type: Plain text
en: git-cherry is frequently used in patch-based workflows (see linkgit:gitworkflows[7]) to determine if a series of patches has been applied by the upstream maintainer.  In such a workflow you might create and send a topic branch like this:
zh_HANS-CN: git-cherry 常用于基于补丁的工作流程（见 linkgit:gitworkflows[7]），以确定一系列补丁是否已被上游维护者应用。 在这样的工作流程中，你可能会创建并发送一个类似这样的主题分支：

note: type: Plain text
en: Later, you can see whether your changes have been applied by saying (still on `topic`):
zh_HANS-CN: 后来，你可以通过说（仍然是在 `topic`上）看到你的修改是否被应用：

note: type: Plain text
en: In a situation where topic consisted of three commits, and the maintainer applied two of them, the situation might look like:
zh_HANS-CN: 如果话题由三个提交组成，而维护者应用了其中的两个提交，情况可能是这样的：

note: type: Plain text
en: In such cases, git-cherry shows a concise summary of what has yet to be applied:
zh_HANS-CN: 在这种情况下，git-cherry 会显示一个简明的摘要，说明还有哪些地方需要应用：

note: type: Plain text
en: Here, we see that the commits A and C (marked with `-`) can be dropped from your `topic` branch when you rebase it on top of `origin/master`, while the commit B (marked with `+`) still needs to be kept so that it will be sent to be applied to `origin/master`.
zh_HANS-CN: 在这里，我们看到，当你在 `origin/master` 之上重新建立分支时，可以从 `topic` 分支中删除 A 和 C（标有 `-`），而 B（标有 `+`）仍然需要保留，这样它就会被发送到 `origin/master `上应用。

note: type: Title ~
en: Using a limit
zh_HANS-CN: 使用一个限制

note: type: Plain text
en: The optional <limit> is useful in cases where your topic is based on other work that is not in upstream.  Expanding on the previous example, this might look like:
zh_HANS-CN: 可选的 <限制> 在你的主题是基于其他不在上游的工作的情况下很有用。 在前面的例子基础上扩展，这可能看起来像：

note: type: Plain text
en: By specifying `base` as the limit, you can avoid listing commits between `base` and `topic`:
zh_HANS-CN: 通过指定 `base` 作为限制，你可以避免列出 `base` 和 `topic` 之间的提交：

note: type: Plain text
en: git-citool - Graphical alternative to git-commit
zh_HANS-CN: git-citool —— 替代 git-commit 的图形化工具

note: type: Plain text
en: A Tcl/Tk based graphical interface to review modified files, stage them into the index, enter a commit message and record the new commit onto the current branch.  This interface is an alternative to the less interactive 'git commit' program.
zh_HANS-CN: 一个基于 Tcl/Tk 的图形界面，用于查看修改过的文件，将其放入索引，输入提交信息，并将新的提交记录到当前分支。 这个界面是对互动性较差的 'git commit' 程序的一种替代。

note: type: Plain text
en: Cleans the working tree by recursively removing files that are not under version control, starting from the current directory.
zh_HANS-CN: 从当前目录开始，通过递归删除不在版本控制之下的文件来清理工作区。

note: type: Plain text
en: Normally, only files unknown to Git are removed, but if the `-x` option is specified, ignored files are also removed. This can, for example, be useful to remove all build products.
zh_HANS-CN: 通常情况下，只有 Git 未知的文件会被删除，但如果指定了 `-x` 选项，被忽略的文件也会被删除。例如，这对删除所有构建产品很有用。

note: type: Plain text
en: If any optional `<pathspec>...` arguments are given, only those paths that match the pathspec are affected.
zh_HANS-CN: 如果给出任何可选的`<路径规范>...`参数，只有那些与路径规范相匹配的路径会受到影响。

note: type: Plain text
en: Normally, when no <pathspec> is specified, git clean will not recurse into untracked directories to avoid removing too much.  Specify -d to have it recurse into such directories as well.  If a <pathspec> is specified, -d is irrelevant; all untracked files matching the specified paths (with exceptions for nested git directories mentioned under `--force`) will be removed.
zh_HANS-CN: 通常，当没有指定 <路径规范> 时，git clean 不会递归到未追踪的目录，以避免删除太多。 指定 -d 可以让它也递归到这些目录。 如果指定了<路径规范>，-d 就不重要了；所有符合指定路径的未追踪文件（`--force` 下提到的嵌套的 git 目录除外）将被删除。

note: type: Plain text
en: If the Git configuration variable clean.requireForce is not set to false, 'git clean' will refuse to delete files or directories unless given -f or -i.  Git will refuse to modify untracked nested git repositories (directories with a .git subdirectory)  unless a second -f is given.
zh_HANS-CN: 如果 Git 配置变量 clean.requireForce 没有设置为 false，'git clean' 将拒绝删除文件或目录，除非给出 -f 或 -i。 除非给出第二个 -f，否则 Git 将拒绝修改未跟踪的嵌套 git 仓库（有.git子目录的目录）。

note: type: Plain text
en: Show what would be done and clean files interactively. See ``Interactive mode'' for details.
zh_HANS-CN: 显示会做什么，并以交互方式清理文件。详见 “交互模式”。

note: type: Plain text
en: Don't actually remove anything, just show what would be done.
zh_HANS-CN: 实际上不要删除任何东西，只是显示会做什么。

note: type: Plain text
en: Be quiet, only report errors, but not the files that are successfully removed.
zh_HANS-CN: 要安静，只报告错误，但不报告成功删除的文件。

note: type: Plain text
en: Use the given exclude pattern in addition to the standard ignore rules (see linkgit:gitignore[5]).
zh_HANS-CN: 在标准的忽略规则之外，使用给定的排除模式（见 linkgit:gitignore[5]）。

note: type: Plain text
en: Don't use the standard ignore rules (see linkgit:gitignore[5]), but still use the ignore rules given with `-e` options from the command line.  This allows removing all untracked files, including build products.  This can be used (possibly in conjunction with 'git restore' or 'git reset') to create a pristine working directory to test a clean build.
zh_HANS-CN: 不要使用标准的忽略规则（见linkgit:gitignore[5]），但仍然使用命令行中用 `-e` 选项给出的忽略规则。 这允许删除所有未跟踪的文件，包括构建产品。 这可以用来（可能与 'git restore' 或 'git reset' 一起使用）创建一个原始的工作目录来测试一个干净的构建。

note: type: Plain text
en: Remove only files ignored by Git.  This may be useful to rebuild everything from scratch, but keep manually created files.
zh_HANS-CN: 只删除被 Git 忽略的文件。 这对于从头开始重建一切，但保留手动创建的文件可能很有用。

note: type: Title -
en: Interactive mode
zh_HANS-CN: 交互模式

note: type: Plain text
en: When the command enters the interactive mode, it shows the files and directories to be cleaned, and goes into its interactive command loop.
zh_HANS-CN: 当命令进入交互式模式时，它会显示要清理的文件和目录，并进入其交互式命令循环。

note: type: Plain text
en: You also could say `c` or `clean` above as long as the choice is unique.
zh_HANS-CN: 你也可以在上面输入 `c` 或 `clean`，只要选择是唯一的。

note: type: Plain text
en: The main command loop has 6 subcommands.
zh_HANS-CN: 主命令循环有 6 个子命令。

note: type: Plain text
en: Start cleaning files and directories, and then quit.
zh_HANS-CN: 开始清理文件和目录，然后退出。

note: type: Labeled list
en: filter by pattern
zh_HANS-CN: 按模式过滤

note: type: Plain text
en: This shows the files and directories to be deleted and issues an "Input ignore patterns>>" prompt. You can input space-separated patterns to exclude files and directories from deletion.  E.g. "*.c *.h" will excludes files end with ".c" and ".h" from deletion. When you are satisfied with the filtered result, press ENTER (empty) back to the main menu.
zh_HANS-CN: 这将显示要删除的文件和目录，并发出 "Input ignore patterns>>（输入忽略模式）" 提示。你可以输入以空格分隔的模式来排除文件和目录的删除。 例如，"*.c *.h " 将排除以 ".c " 和 ".h" 结尾的文件不被删除。当你对过滤后的结果满意时，按回车（空）键回到主菜单。

note: type: Labeled list
en: select by numbers
zh_HANS-CN: 按数字选择

note: type: Plain text
en: This shows the files and directories to be deleted and issues an "Select items to delete>>" prompt. When the prompt ends with double '>>' like this, you can make more than one selection, concatenated with whitespace or comma.  Also you can say ranges.  E.g. "2-5 7,9" to choose 2,3,4,5,7,9 from the list.  If the second number in a range is omitted, all remaining items are selected.  E.g. "7-" to choose 7,8,9 from the list.  You can say '*' to choose everything.  Also when you are satisfied with the filtered result, press ENTER (empty) back to the main menu.
zh_HANS-CN: 这显示了要删除的文件和目录，并发出 "Select items to delete>>（选择要删除的项目）"提示。当提示像这样以双 '>>' 结束时，你可以做一个以上的选择，用空格或逗号连接起来。 你也可以说范围。 例如，"2-5 7,9" 可以从列表中选择 2,3,4,5,7,9。 如果一个范围内的第二个数字被省略了，所有剩下的项目都会被选中。 例如："7-" 从列表中选择 7、8、9。 你可以输入 '*' 来选择所有项目。 另外，当你对过滤后的结果满意时，按回车（空）键回到主菜单。

note: type: Labeled list
en: ask each
zh_HANS-CN: 逐一询问

note: type: Plain text
en: This will start to clean, and you must confirm one by one in order to delete items. Please note that this action is not as efficient as the above two actions.
zh_HANS-CN: 这将开始进行清理，你必须逐一确认，以便删除项目。请注意，这个动作没有上述两个动作那么有效。

note: type: Plain text
en: This lets you quit without do cleaning.
zh_HANS-CN: 这让你不用做清理就可以退出。

note: type: Plain text
en: Show brief usage of interactive git-clean.
zh_HANS-CN: 显示交互式 git-clean 的简要用法。

note: type: Plain text
en: git-clone - Clone a repository into a new directory
zh_HANS-CN: git-clone - 克隆一个仓库到新目录

note: type: Plain text
en: If the repository's `$GIT_DIR/objects` has symbolic links or is a symbolic link, the clone will fail. This is a security measure to prevent the unintentional copying of files by dereferencing the symbolic links.
zh_HANS-CN: 如果仓库的 `$GIT_DIR/objects` 有符号链接或者它就是符号链接，克隆将会失败。这是一项安全措施，以防止通过解读符号链接意外地复制文件。

note: type: Plain text
en: *NOTE*: this operation can race with concurrent modification to the
    source repository, similar to running `cp -r src dst` while modifying
    `src`.
zh_HANS-CN: *注意*：该操作可能与并发的源仓库修改产生产竞争，类似于在运行 `cp -r src dst` 时同时修改 `src`。

note: type: Plain text
en: Force the cloning process from a repository on a local filesystem to copy the files under the `.git/objects` directory instead of using hardlinks. This may be desirable if you are trying to make a back-up of your repository.
zh_HANS-CN: 从本地文件系统上的存储库进行克隆时，强制复制 `.git / objects` 目录下的文件，而不使用硬链接。如果您要备份存储库，则可能需要这样做。

note: type: Plain text
en: When the repository to clone is on the local machine, instead of using hard links, automatically setup `.git/objects/info/alternates` to share the objects with the source repository.  The resulting repository starts out without any object of its own.
zh_HANS-CN: 当要克隆的存储库位于本地计算机上时，不使用硬链接，而是自动设置 `.git/objects/info/alternates` 与源存储库共享对象。生成的存储库开始时没有其自己的任何对象。

note: type: Plain text
en: Fail if the source repository is a shallow repository.  The 'clone.rejectShallow' configuration variable can be used to specify the default.
zh_HANS-CN: 如果源版本库是一个浅层版本库，则失败。  clone.rejectShallow "配置变量可以用来指定默认值。

note: type: Labeled list
en: --filter=<filter-spec>
zh_HANS-CN: --filter=<过滤器定义>

note: type: Plain text
en: Also apply the partial clone filter to any submodules in the repository.  Requires `--filter` and `--recurse-submodules`. This can be turned on by default by setting the `clone.filterSubmodules` config option.
zh_HANS-CN: 同时对版本库中的任何子模块应用部分克隆过滤器。  需要`--fliter`和`--recurse-submodules`。这可以通过设置 `clone.filterSubmodules` 配置项来默认开启。

note: type: Plain text
en: Set up a mirror of the source repository.  This implies `--bare`.  Compared to `--bare`, `--mirror` not only maps local branches of the source to local branches of the target, it maps all refs (including remote-tracking branches, notes etc.) and sets up a refspec configuration such that all these refs are overwritten by a `git remote update` in the target repository.
zh_HANS-CN: 建立源存储库的镜像。这默认包含 `--bare` 选项。与 `--bare` 相比，`--mirror` 不仅将源的本地分支映射到目标的本地分支，还映射所有引用（包括远程跟踪分支，注释等）并设置了引用规范，因而在目标存储库中执行 `git remote update` 时，所有这些引用都会被覆盖。

note: type: Labeled list
en: -o <name>
zh_HANS-CN: -o <名称>

note: type: Labeled list
en: --origin <name>
zh_HANS-CN: --origin <名称>

note: type: Plain text
en: Instead of using the remote name `origin` to keep track of the upstream repository, use `<name>`.  Overrides `clone.defaultRemoteName` from the config.
zh_HANS-CN: 不使用远程名称`origin`来跟踪远程仓库，而使用`<name>`值。  这会覆盖配置中`clone.defaultRemoteName`的设置。

note: type: Labeled list
en: -b <name>
zh_HANS-CN: -b <名称>

note: type: Plain text
en: Don't clone any tags, and set `remote.<remote>.tagOpt=--no-tags` in the config, ensuring that future `git pull` and `git fetch` operations won't follow any tags. Subsequent explicit tag fetches will still work, (see linkgit:git-fetch[1]).
zh_HANS-CN: 不克隆任何标签，并在配置中设置 `remote.<remote>.tagOpt=--no-tags` ，确保将来的`git pull`和`git fetch`操作不会跟随任何标签。随后的显式标签抓取仍将起作用（参阅 linkgit:git-fetch[1]）。

note: type: Plain text
en: Before fetching from the remote, fetch a bundle from the given `<uri>` and unbundle the data into the local repository. The refs in the bundle will be stored under the hidden `refs/bundle/*` namespace. This option is incompatible with `--depth`, `--shallow-since`, and `--shallow-exclude`.
zh_HANS-CN: 在从远程获取之前，从给定的`<uri>`中获取一个捆绑包，并将数据解绑到本地资源库中。捆绑包中的引用将被存储在隐藏的 `refs/bundle/*` 命名空间下。该选项不与`--depth`、`--shallow--scince`、`--shallow--exclude`兼容。

note: type: Plain text
en: git-column - Display data in columns
zh_HANS-CN: git-column - 以列展示数据

note: type: Plain text
en: 'git column' [--command=<name>] [--[raw-]mode=<mode>] [--width=<width>]
    	     [--indent=<string>] [--nl=<string>] [--padding=<n>]
zh_HANS-CN: 'git column' [--command=<名称>] [--[raw-]mode=<模式>] [--width=<宽度>]
    	     [--indent=<字符串>] [--nl=<字符串>] [--padding=<n>]

note: type: Plain text
en: This command formats the lines of its standard input into a table with multiple columns. Each input line occupies one cell of the table. It is used internally by other git commands to format output into columns.
zh_HANS-CN: 该命令将其标准输入的行格式化为一个多列表格。每个输入行占据表格的一个单元。它被其他Git命令内部使用，以将输出信息格式化为列。

note: type: Labeled list
en: --command=<name>
zh_HANS-CN: --command=<名称>

note: type: Plain text
en: Look up layout mode using configuration variable column.<name> and column.ui.
zh_HANS-CN: 使用配置变量column.<名称>和column.ui查询布局模式。

note: type: Labeled list
en: --mode=<mode>
zh_HANS-CN: --mode=<模式>

note: type: Plain text
en: Specify layout mode. See configuration variable column.ui for option syntax in linkgit:git-config[1].
zh_HANS-CN: 指定布局模式。选项的语法见 linkgit:git-config[1] 中column.ui变量的配置。

note: type: Plain text
en: Same as --mode but take mode encoded as a number. This is mainly used by other commands that have already parsed layout mode.
zh_HANS-CN: 与--模式选项相同，但该选项将模式编码为一个数字。这主要是被其他已经解析了布局模式的命令使用。

note: type: Labeled list
en: --width=<width>
zh_HANS-CN: --width=<宽度>

note: type: Plain text
en: Specify the terminal width. By default 'git column' will detect the terminal width, or fall back to 80 if it is unable to do so.
zh_HANS-CN: 指定终端的宽度。默认情况下，'git column'会检测终端宽度，如果无法检测，则会将其宽度设置为80。

note: type: Labeled list
en: --indent=<string>
zh_HANS-CN: --indent=<字符串>

note: type: Plain text
en: String to be printed at the beginning of each line.
zh_HANS-CN: 设置要在每一行的开头打印的字符串。

note: type: Labeled list
en: --nl=<string>
zh_HANS-CN: --indent=<字符串>

note: type: Plain text
en: String to be printed at the end of each line, including newline character.
zh_HANS-CN: 在每一行的末尾要打印的字符串，包括换行符。

note: type: Plain text
en: The number of spaces between columns. One space by default.
zh_HANS-CN: 列之间的空格数，默认为一个空格。

note: type: Plain text
en: Format data by columns:
zh_HANS-CN: 按列格式化数据：

note: type: Plain text
en: Format data by rows:
zh_HANS-CN: 按行格式化数据：

note: type: Plain text
en: List some tags in a table with unequal column widths:
zh_HANS-CN: 在一个列宽不等的表格中列出一些标签：

note: type: Labeled list
en: -m <message>
zh_HANS-CN: -m <信息>

note: type: Labeled list
en: -F <file>
zh_HANS-CN: -F <文件>

note: type: Title -
en: FILES
zh_HANS-CN: 文件

note: type: Plain text
en: git-commit - Record changes to the repository
zh_HANS-CN: git-commit - 记录仓库的修改

note: type: Plain text
en: 'git commit' [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend]
    	   [--dry-run] [(-c | -C | --squash) <commit> | --fixup [(amend|reword):]<commit>)]
    	   [-F <file> | -m <msg>] [--reset-author] [--allow-empty]
    	   [--allow-empty-message] [--no-verify] [-e] [--author=<author>]
    	   [--date=<date>] [--cleanup=<mode>] [--[no-]status]
    	   [-i | -o] [--pathspec-from-file=<file> [--pathspec-file-nul]]
    	   [(--trailer <token>[(=|:)<value>])...] [-S[<keyid>]]
    	   [--] [<pathspec>...]
zh_HANS-CN: 'git commit' [-a | --interactive | --patch] [-s] [-v] [-u<模式>] [--amend]
    	   [--dry-run] [(-c | -C | --squash) <提交> | --fixup [(amend|reword):]<提交>)]
    	   [-F <文件> | -m <消息>] [--reset-author] [--allow-empty]
    	   [--allow-empty-message] [--no-verify] [-e] [--author=<提交人>]
    	   [--date=<日期>] [--cleanup=<模式>] [--[no-]status]
    	   [-i | -o] [--pathspec-from-file=<文件> [--pathspec-file-nul]]
    	   [(--trailer <token>[(=|:)<value>])...] [-S[<keyid>]]
    	   [--] [<路径>...]

note: type: Plain text
en: Create a new commit containing the current contents of the index and the given log message describing the changes. The new commit is a direct child of HEAD, usually the tip of the current branch, and the branch is updated to point to it (unless no branch is associated with the working tree, in which case HEAD is "detached" as described in linkgit:git-checkout[1]).
zh_HANS-CN: 创建一个新的提交，包含索引的当前内容和描述变化的给定日志信息。新的提交是 HEAD 的直接子节点，通常是当前分支的顶端，分支会被更新以指向它（除非工作树上没有分支，在这种情况下 HEAD 会被 "分离"，如 linkgit:git-checkout[1] 所述）。

note: type: Plain text
en: The content to be committed can be specified in several ways:
zh_HANS-CN: 可以用几种方式指定要提交的内容：

note: type: Plain text
en: by using linkgit:git-add[1] to incrementally "add" changes to the index before using the 'commit' command (Note: even modified files must be "added");
zh_HANS-CN: 通过使用linkgit:git-add[1]，在使用'commit'命令之前，逐步将修改内容 "添加"到索引中（注意:即使是修改过的文件也必须被 "添加" ）；

note: type: Plain text
en: by using linkgit:git-rm[1] to remove files from the working tree and the index, again before using the 'commit' command;
zh_HANS-CN: 通过使用 linkgit:git-rm[1] ，在再次使用“提交”命令之前从工作树和索引中删除文件；

note: type: Plain text
en: by listing files as arguments to the 'commit' command (without --interactive or --patch switch), in which case the commit will ignore changes staged in the index, and instead record the current content of the listed files (which must already be known to Git);
zh_HANS-CN: 通过将文件列为“commit”命令的参数(不带--interactive或--patch switch)，在这种情况下，提交将忽略索引中的更改，而是记录所列文件的当前内容(Git必须已经知道);

note: type: Plain text
en: by using the -a switch with the 'commit' command to automatically "add" changes from all known files (i.e. all files that are already listed in the index) and to automatically "rm" files in the index that have been removed from the working tree, and then perform the actual commit;
zh_HANS-CN: 通过在'commit'命令中使用-a开关，自动 "添加 "所有已知文件的修改（即所有已经列在索引中的文件），并自动 "清除 "索引中已经从工作树中删除的文件，然后执行实际的提交；

note: type: Plain text
en: by using the --interactive or --patch switches with the 'commit' command to decide one by one which files or hunks should be part of the commit in addition to contents in the index, before finalizing the operation. See the ``Interactive Mode'' section of linkgit:git-add[1] to learn how to operate these modes.
zh_HANS-CN: 通过在'commit'命令中使用 --interactive 或 --patch 开关，在最终完成操作之前，逐一决定哪些文件或块应该成为提交的一部分，而不是索引中的内容。参见 linkgit:git-add[1] 的 ``交互式模式'一节，了解如何操作这些模式。

note: type: Plain text
en: The `--dry-run` option can be used to obtain a summary of what is included by any of the above for the next commit by giving the same set of parameters (options and paths).
zh_HANS-CN: `--dry-run`选项可以用来获得上述任何一个选项为下一次提交所包含的内容的摘要，只要给出相同的参数（选项和路径）即可。

note: type: Plain text
en: If you make a commit and then find a mistake immediately after that, you can recover from it with 'git reset'.
zh_HANS-CN: 如果你做了一个提交，然后紧接着发现了一个错误，你可以用'git reset'来恢复它。

note: type: Plain text
en: Tell the command to automatically stage files that have been modified and deleted, but new files you have not told Git about are not affected.
zh_HANS-CN: 告诉命令自动阶段化已经被修改和删除的文件，但你没有告诉 Git 的新文件不受影响。

note: type: Labeled list
en: -C <commit>
zh_HANS-CN: -C <提交>

note: type: Labeled list
en: --reuse-message=<commit>
zh_HANS-CN: --reuse-message=<提交>

note: type: Plain text
en: Take an existing commit object, and reuse the log message and the authorship information (including the timestamp)  when creating the commit.
zh_HANS-CN: 取一个现有的提交对象，并在创建提交时重新使用日志信息和作者信息（包括时间戳）。

note: type: Plain text
en: Like '-C', but with `-c` the editor is invoked, so that the user can further edit the commit message.
zh_HANS-CN: 和'-C'一样，但用`-c'会调用编辑器，这样用户可以进一步编辑提交信息。

note: type: Plain text
en: Create a new commit which "fixes up" `<commit>` when applied with `git rebase --autosquash`. Plain `--fixup=<commit>` creates a "fixup!" commit which changes the content of `<commit>` but leaves its log message untouched. `--fixup=amend:<commit>` is similar but creates an "amend!" commit which also replaces the log message of `<commit>` with the log message of the "amend!" commit.  `--fixup=reword:<commit>` creates an "amend!" commit which replaces the log message of `<commit>` with its own log message but makes no changes to the content of `<commit>`.
zh_HANS-CN: 创建一个新的提交，在使用 `git rebase --autosquash` 时，"修复"`<commit>`。普通的`--fixup=<commit>`会创建一个 "fixup!"的提交，改变`<commit>`的内容，但不改变其日志信息。`--fixup=amend:<commit>`类似，但会创建一个 "修正！"的提交，同时用 "修正！"的提交的日志信息替换`<commit>`的日志信息。  `--fixup=reword:<commit>`创建一个 "修正！"提交，用自己的日志信息替换`<commit>`的日志信息，但不对`<commit>`的内容做任何修改。

note: type: Plain text
en: The commit created by plain `--fixup=<commit>` has a subject composed of "fixup!" followed by the subject line from <commit>, and is recognized specially by `git rebase --autosquash`. The `-m` option may be used to supplement the log message of the created commit, but the additional commentary will be thrown away once the "fixup!" commit is squashed into `<commit>` by `git rebase --autosquash`.
zh_HANS-CN: 由普通的`--fixup=<commit>`创建的提交，其主题由 "fixup!"和<commit>的主题行组成，并被`git rebase --autosquash`特别识别。`-m`选项可以用来补充创建提交的日志信息，但一旦 "fixup!"提交被`git rebase --autosquash`压入`<commit>`，额外的注释就会被扔掉。

note: type: Plain text
en: The commit created by `--fixup=amend:<commit>` is similar but its subject is instead prefixed with "amend!". The log message of <commit> is copied into the log message of the "amend!" commit and opened in an editor so it can be refined. When `git rebase --autosquash` squashes the "amend!" commit into `<commit>`, the log message of `<commit>` is replaced by the refined log message from the "amend!" commit. It is an error for the "amend!" commit's log message to be empty unless `--allow-empty-message` is specified.
zh_HANS-CN: 由`--fixup=amend:<commit>`创建的提交与此类似，但其主题前缀为 "amend!"。<commit>的日志信息会被复制到 "amend!"提交的日志信息中，并在编辑器中打开，以便对其进行修改。当`git rebase --autosquash`将 "amend!"提交压入`<commit>`时，`<commit>`的日志信息会被 "amend!"提交的精炼日志信息所取代。如果 "修正！"提交的日志信息为空，则是一个错误，除非指定`--allow-empty-message`。

note: type: Plain text
en: `--fixup=reword:<commit>` is shorthand for `--fixup=amend:<commit> --only`. It creates an "amend!" commit with only a log message (ignoring any changes staged in the index). When squashed by `git rebase --autosquash`, it replaces the log message of `<commit>` without making any other changes.
zh_HANS-CN: `--fixup=reword:<commit>`是`--fixup=amend:<commit>--only`的简写。它创建一个只有日志信息的 "修正！"提交（忽略索引中的任何修改）。当被`git rebase --autosquash`压制时，它会替换`<commit>`的日志信息而不做任何其他改动。

note: type: Plain text
en: Neither "fixup!" nor "amend!" commits change authorship of `<commit>` when applied by `git rebase --autosquash`.  See linkgit:git-rebase[1] for details.
zh_HANS-CN: 当被 `git rebase --autosquash` 应用时，"fixup!"和 "amend!"提交都不会改变 `<commit>` 的作者身份。  详情见 linkgit:git-rebase[1]。

note: type: Labeled list
en: --squash=<commit>
zh_HANS-CN: --squash=<提交>

note: type: Plain text
en: Construct a commit message for use with `rebase --autosquash`.  The commit message subject line is taken from the specified commit with a prefix of "squash! ".  Can be used with additional commit message options (`-m`/`-c`/`-C`/`-F`). See linkgit:git-rebase[1] for details.
zh_HANS-CN: 构建一条提交信息，供`rebase --autosquash`使用。  提交信息的主题行取自指定的提交，前缀为 "squash!".  可以和其他提交信息选项（`-m`/`-c`/`-C`/`-F`）一起使用。详情见 linkgit:git-rebase[1]。

note: type: Plain text
en: When used with -C/-c/--amend options, or when committing after a conflicting cherry-pick, declare that the authorship of the resulting commit now belongs to the committer. This also renews the author timestamp.
zh_HANS-CN: 当与-C/-c/--amend选项一起使用时，或者当在一个冲突的cherry-pick之后提交时，声明所产生的提交的作者身份现在属于提交者。这也是对作者时间戳的更新。

note: type: Plain text
en: When doing a dry-run, give the output in the short-format. See linkgit:git-status[1] for details. Implies `--dry-run`.
zh_HANS-CN: 当做干运行的时候，以简短的形式给出输出。详见 linkgit:git-status[1]。意味着 `--干运行`。

note: type: Plain text
en: Show the branch and tracking info even in short-format.
zh_HANS-CN: 即使在短文中也要显示分支和跟踪信息。

note: type: Plain text
en: When doing a dry-run, give the output in a porcelain-ready format. See linkgit:git-status[1] for details. Implies `--dry-run`.
zh_HANS-CN: 在做干运行的时候，要把输出结果以可瓷器的格式给出。详见 linkgit:git-status[1]。意味着 `--干运行`。

note: type: Plain text
en: When doing a dry-run, give the output in the long-format.  Implies `--dry-run`.
zh_HANS-CN: 当做干运行时，以长格式给出输出。  意味着"--干运行"。

note: type: Plain text
en: When showing `short` or `porcelain` status output, print the filename verbatim and terminate the entries with NUL, instead of LF.  If no format is given, implies the `--porcelain` output format.  Without the `-z` option, filenames with "unusual" characters are quoted as explained for the configuration variable `core.quotePath` (see linkgit:git-config[1]).
zh_HANS-CN: 当显示 "short "或 "porcelain "状态输出时，逐字打印文件名，用NUL而不是LF来结束条目。  如果没有给出格式，就意味着是`--porcelain`输出格式。  如果没有`-z`选项，带有 "不寻常 "字符的文件名将被引用，正如对配置变量`core.quotePath`的解释（见linkgit:git-config[1]）。

note: type: Labeled list
en: --file=<file>
zh_HANS-CN: --file=<文件>

note: type: Plain text
en: Take the commit message from the given file.  Use '-' to read the message from the standard input.
zh_HANS-CN: 从给定文件中获取提交信息。  使用'-'可以从标准输入中读取信息。

note: type: Labeled list
en: --author=<author>
zh_HANS-CN: --author=<提交人>

note: type: Plain text
en: Override the commit author. Specify an explicit author using the standard `A U Thor <author@example.com>` format. Otherwise <author> is assumed to be a pattern and is used to search for an existing commit by that author (i.e. rev-list --all -i --author=<author>); the commit author is then copied from the first such commit found.
zh_HANS-CN: 覆盖提交者。使用标准的`A U Thor <author@example.com>`格式指定一个明确的作者。否则，<author>将被假定为一个模式，用于搜索该作者的现有提交（即 rev-list --all -i --author=<author>）；然后从找到的第一个此类提交中复制提交作者。

note: type: Labeled list
en: --date=<date>
zh_HANS-CN: --date=<日期>

note: type: Plain text
en: Override the author date used in the commit.
zh_HANS-CN: 覆盖提交中使用的作者日期。

note: type: Labeled list
en: -m <msg>
zh_HANS-CN: -m <消息>

note: type: Plain text
en: Use the given <msg> as the commit message.  If multiple `-m` options are given, their values are concatenated as separate paragraphs.
zh_HANS-CN: 使用给定的<msg>作为提交信息。  如果给定了多个`-m`选项，它们的值会作为单独的段落串联起来。

note: type: Plain text
en: The `-m` option is mutually exclusive with `-c`, `-C`, and `-F`.
zh_HANS-CN: m "选项与 "c"、"C "和 "F "相互排斥。

note: type: Labeled list
en: -t <file>
zh_HANS-CN: -t <文件>

note: type: Labeled list
en: --template=<file>
zh_HANS-CN: --template=<文件>

note: type: Plain text
en: When editing the commit message, start the editor with the contents in the given file.  The `commit.template` configuration variable is often used to give this option implicitly to the command.  This mechanism can be used by projects that want to guide participants with some hints on what to write in the message in what order.  If the user exits the editor without editing the message, the commit is aborted.  This has no effect when a message is given by other means, e.g. with the `-m` or `-F` options.
zh_HANS-CN: 编辑提交信息时，以给定文件中的内容启动编辑器。  `commit.template`配置变量经常被用来给命令隐含这个选项。  这个机制可以被那些希望通过一些提示来指导参与者在消息中以何种顺序书写的项目所使用。  如果用户在没有编辑消息的情况下退出编辑器，提交将被中止。  当用其他方式给出消息时，例如用`-m`或`-F`选项时，这没有影响。

note: type: Labeled list
en: --trailer <token>[(=|:)<value>]
zh_HANS-CN: --trailer <令牌>[(=|:)<值>]

note: type: Plain text
en: Specify a (<token>, <value>) pair that should be applied as a trailer. (e.g. `git commit --trailer "Signed-off-by:C O Mitter \ <committer@example.com>" --trailer "Helped-by:C O Mitter \ <committer@example.com>"` will add the "Signed-off-by" trailer and the "Helped-by" trailer to the commit message.)  The `trailer.*` configuration variables (linkgit:git-interpret-trailers[1]) can be used to define if a duplicated trailer is omitted, where in the run of trailers each trailer would appear, and other details.
zh_HANS-CN: 指定一个（<token>, <value>）对，应该作为拖车应用。(例如，`git commit --trailer "Signed-off-by:C O Mitter / <committer@example.com>" --trailer "Helped-by:C O Mitter / <committer@example.com>"`将在提交信息中加入 "Signed-off-by "预告片和 "Helped-by "预告片。)  `trailer.*`配置变量（linkgit:git-interpret-trailers[1]）可以用来定义是否省略重复的拖车，每个拖车会出现在拖车运行的哪个位置，以及其他细节。

note: type: Plain text
en: By default, the pre-commit and commit-msg hooks are run.  When any of `--no-verify` or `-n` is given, these are bypassed.  See also linkgit:githooks[5].
zh_HANS-CN: 默认情况下，会运行 pre-commit 和 commit-msg 钩子。当给出任何 `--no-verify` 或 `-n` 时，这些都会被绕过。参见链接git:githooks[5]。

note: type: Plain text
en: Usually recording a commit that has the exact same tree as its sole parent commit is a mistake, and the command prevents you from making such a commit.  This option bypasses the safety, and is primarily for use by foreign SCM interface scripts.
zh_HANS-CN: 通常情况下，记录一个与唯一的父级提交的树完全相同的提交是一个错误，该命令会阻止你做出这样的提交。  这个选项绕过了安全问题，主要供国外SCM接口脚本使用。

note: type: Plain text
en: Like --allow-empty this command is primarily for use by foreign SCM interface scripts. It allows you to create a commit with an empty commit message without using plumbing commands like linkgit:git-commit-tree[1].
zh_HANS-CN: 和 --allow-empty 一样，这条命令主要是给国外的 SCM 接口脚本使用的。它允许你在不使用linkgit:git-commit-tree[1]等管道命令的情况下创建一个带有空提交信息的提交。

note: type: Plain text
en: This option determines how the supplied commit message should be cleaned up before committing.  The '<mode>' can be `strip`, `whitespace`, `verbatim`, `scissors` or `default`.
zh_HANS-CN: 这个选项决定了在提交前如何清理所提供的提交信息。  <mode>可以是`strip`、`whitespace`、`verbatim`、`scissors`或`default`。

note: type: Labeled list
en: strip
zh_HANS-CN: 剥离

note: type: Plain text
en: Strip leading and trailing empty lines, trailing whitespace, commentary and collapse consecutive empty lines.
zh_HANS-CN: 剥离前面和后面的空行、后面的空白、注释和折叠的连续空行。

note: type: Labeled list
en: whitespace
zh_HANS-CN: 空白字符

note: type: Plain text
en: Same as `strip` except #commentary is not removed.
zh_HANS-CN: 与 "strip "相同，只是#commentary不被删除。

note: type: Labeled list
en: verbatim
zh_HANS-CN: 逐字逐句

note: type: Plain text
en: Do not change the message at all.
zh_HANS-CN: 完全不要改变信息。

note: type: Plain text
en: Same as `whitespace` except that everything from (and including)  the line found below is truncated, if the message is to be edited.  "`#`" can be customized with core.commentChar.
zh_HANS-CN: 与 "whitespace "相同，但如果要编辑信息，从下面一行开始（包括）的所有内容都被截断。  "`#`"可以用core.commentChar自定义。

note: type: Plain text
en: Same as `strip` if the message is to be edited.  Otherwise `whitespace`.
zh_HANS-CN: 如果要编辑信息，与`strip`相同。  否则就是`whitespace'。

note: type: Plain text
en: The default can be changed by the `commit.cleanup` configuration variable (see linkgit:git-config[1]).
zh_HANS-CN: 默认值可以通过 `commit.cleanup` 配置变量来改变（见linkgit:git-config[1]）。

note: type: Plain text
en: The message taken from file with `-F`, command line with `-m`, and from commit object with `-C` are usually used as the commit log message unmodified. This option lets you further edit the message taken from these sources.
zh_HANS-CN: 用`-F`从文件中获取的信息，用`-m`从命令行中获取的信息，以及用`-C`从提交对象中获取的信息，通常都是未经修改的提交日志信息。这个选项可以让你进一步编辑从这些来源获取的信息。

note: type: Plain text
en: Use the selected commit message without launching an editor.  For example, `git commit --amend --no-edit` amends a commit without changing its commit message.
zh_HANS-CN: 使用选定的提交信息而不启动编辑器。  例如，`git commit --amend --no-edit`修改一个提交，但不改变其提交信息。

note: type: Plain text
en: Replace the tip of the current branch by creating a new commit. The recorded tree is prepared as usual (including the effect of the `-i` and `-o` options and explicit pathspec), and the message from the original commit is used as the starting point, instead of an empty message, when no other message is specified from the command line via options such as `-m`, `-F`, `-c`, etc.  The new commit has the same parents and author as the current one (the `--reset-author` option can countermand this).
zh_HANS-CN: 通过创建一个新的提交来替换当前分支的顶端。记录的树像往常一样准备（包括`-i`和`-o`选项和显式pathspec的效果），当命令行没有通过`-m`、`-F`、`-c`等选项指定其他信息时，原始提交的信息会被用作起点，而不是空信息。  新的提交与当前的提交具有相同的父辈和作者（`--reset-author`选项可以反驳）。

note: type: Plain text
en: but can be used to amend a merge commit.
zh_HANS-CN: 但可以用来修改合并提交。

note: type: Plain text
en: You should understand the implications of rewriting history if you amend a commit that has already been published.  (See the "RECOVERING FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
zh_HANS-CN: 如果你修改了一个已经发布的提交，你应该明白重写历史的意义。  参见 linkgit:git-rebase[1]中的 "RECOVERING FROM UPSTREAM REBASE" 部分）。

note: type: Plain text
en: Bypass the post-rewrite hook.
zh_HANS-CN: 绕过post-rewrite钩子。

note: type: Plain text
en: Before making a commit out of staged contents so far, stage the contents of paths given on the command line as well.  This is usually not what you want unless you are concluding a conflicted merge.
zh_HANS-CN: 在对迄今为止的暂存内容进行提交之前，对命令行上给出的路径内容也进行暂存。  这通常不是你想要的，除非你正在结束一个冲突的合并。

note: type: Plain text
en: Make a commit by taking the updated working tree contents of the paths specified on the command line, disregarding any contents that have been staged for other paths. This is the default mode of operation of 'git commit' if any paths are given on the command line, in which case this option can be omitted.  If this option is specified together with `--amend`, then no paths need to be specified, which can be used to amend the last commit without committing changes that have already been staged. If used together with `--allow-empty` paths are also not required, and an empty commit will be created.
zh_HANS-CN: 在提交时，只取命令行上指定的工作树的最新内容，而不考虑其他路径上的缓存内容。这是'git commit'的默认操作模式，如果在命令行中给出了任何路径，在这种情况下可以省略该选项。  如果该选项与`--amend`一起指定，则不需要指定路径，可以用来修改最后的提交，而不提交已经被暂存的修改。如果和`--allow-empty`一起使用，也不需要指定路径，将创建一个空的提交。

note: type: Labeled list
en: -u[<mode>]
zh_HANS-CN: -u[<模式>]

note: type: Labeled list
en: --untracked-files[=<mode>]
zh_HANS-CN: --untracked-files[=<模式>]

note: type: Plain text
en: Show untracked files.
zh_HANS-CN: 显示未追踪文件。

note: type: Plain text
en: The mode parameter is optional (defaults to 'all'), and is used to specify the handling of untracked files; when -u is not used, the default is 'normal', i.e. show untracked files and directories.
zh_HANS-CN: 模式参数是可选的（默认为 "所有"），用于指定对未追踪文件的处理；当没有使用-u时，默认为 "正常"，即显示未追踪的文件和目录。

note: type: Plain text
en: The possible options are:
zh_HANS-CN: 可选项：

note: type: Plain text
en: 'no'     - Show no untracked files
zh_HANS-CN: 'no' - 不显示未被追踪的文件

note: type: Plain text
en: 'normal' - Shows untracked files and directories
zh_HANS-CN: 'normal' - 显示未被追踪的文件和目录

note: type: Plain text
en: 'all'    - Also shows individual files in untracked directories.
zh_HANS-CN: 'all' - 也显示未被追踪的目录中的单个文件。

note: type: Plain text
en: The default can be changed using the status.showUntrackedFiles configuration variable documented in linkgit:git-config[1].
zh_HANS-CN: 默认值可以用linkgit:git-config[1]中记载的 status.showUntrackedFiles 配置变量来改变。

note: type: Plain text
en: Show unified diff between the HEAD commit and what would be committed at the bottom of the commit message template to help the user describe the commit by reminding what changes the commit has.  Note that this diff output doesn't have its lines prefixed with '#'. This diff will not be a part of the commit message. See the `commit.verbose` configuration variable in linkgit:git-config[1].
zh_HANS-CN: 在提交信息模板的底部显示HEAD提交和将要提交的内容之间的统一差异，通过提醒提交有哪些变化来帮助用户描述提交。  请注意，这个差异输出的行数不会以'#'为前缀。这个差异不会成为提交信息的一部分。参见 linkgit:git-config[1] 中的 `commit.verbose` 配置变量。

note: type: Plain text
en: If specified twice, show in addition the unified diff between what would be committed and the worktree files, i.e. the unstaged changes to tracked files.
zh_HANS-CN: 如果指定了两次，则另外显示将被提交的文件和工作树文件之间的统一差异，即对已跟踪文件的非阶段性修改。

note: type: Plain text
en: Suppress commit summary message.
zh_HANS-CN: 抑制提交摘要信息。

note: type: Plain text
en: Do not create a commit, but show a list of paths that are to be committed, paths with local changes that will be left uncommitted and paths that are untracked.
zh_HANS-CN: 不创建提交，但显示要提交的路径列表，有局部改动的路径将不提交，以及未跟踪的路径。

note: type: Plain text
en: Include the output of linkgit:git-status[1] in the commit message template when using an editor to prepare the commit message.  Defaults to on, but can be used to override configuration variable commit.status.
zh_HANS-CN: 在使用编辑器准备提交信息时，在提交信息模板中包含linkgit:git-status[1]的输出。  默认为开，但可以用来覆盖配置变量commit.status。

note: type: Plain text
en: Do not include the output of linkgit:git-status[1] in the commit message template when using an editor to prepare the default commit message.
zh_HANS-CN: 当使用编辑器准备默认的提交信息时，不要将 linkgit:git-status[1] 的输出包含在提交信息模板中。

note: type: Plain text
en: When pathspec is given on the command line, commit the contents of the files that match the pathspec without recording the changes already added to the index. The contents of these files are also staged for the next commit on top of what have been staged before.
zh_HANS-CN: 当命令行中给出pathspec时，提交符合pathspec的文件内容，而不记录已经添加到索引中的修改。这些文件的内容也会在下一次提交时在之前的文件基础上被暂存。

note: type: Plain text
en: Instead of staging files after each individual change, you can tell `git commit` to notice the changes to the files whose contents are tracked in your working tree and do corresponding `git add` and `git rm` for you.  That is, this example does the same as the earlier example if there is no other change in your working tree:
zh_HANS-CN: 你可以告诉`git commit`注意到工作树中内容被跟踪的文件的变化，并为你做相应的`git add`和`git rm`，而不是在每个单独的变化后暂存文件。  也就是说，如果你的工作树中没有其他变化，这个例子的做法与前面的例子相同。

note: type: Plain text
en: The command `git commit -a` first looks at your working tree, notices that you have modified hello.c and removed goodbye.c, and performs necessary `git add` and `git rm` for you.
zh_HANS-CN: 命令`git commit -a`首先查看你的工作树，注意到你修改了hello.c并删除了goodbye.c，并为你执行必要的`git add`和`git rm`。

note: type: Plain text
en: After staging changes to many files, you can alter the order the changes are recorded in, by giving pathnames to `git commit`.  When pathnames are given, the command makes a commit that only records the changes made to the named paths:
zh_HANS-CN: 在对许多文件进行分期修改后，你可以通过给`git commit`提供路径名来改变修改的顺序。  给出路径名后，该命令就会进行提交，只记录对指定路径的修改。

note: type: Plain text
en: This makes a commit that records the modification to `Makefile`.  The changes staged for `hello.c` and `hello.h` are not included in the resulting commit.  However, their changes are not lost -- they are still staged and merely held back.  After the above sequence, if you do:
zh_HANS-CN: 这将产生一个提交，记录对`Makefile`的修改。  为`hello.c`和`hello.h`所做的修改不包括在这次提交中。  然而，它们的修改并没有丢失 -- 它们仍然被暂存，只是被保留了下来。  在上述顺序之后，如果你做

note: type: Plain text
en: this second commit would record the changes to `hello.c` and `hello.h` as expected.
zh_HANS-CN: 第二次提交会记录下对`hello.c`和`hello.h`的修改，正如预期的那样。

note: type: Plain text
en: After a merge (initiated by 'git merge' or 'git pull') stops because of conflicts, cleanly merged paths are already staged to be committed for you, and paths that conflicted are left in unmerged state.  You would have to first check which paths are conflicting with 'git status' and after fixing them manually in your working tree, you would stage the result as usual with 'git add':
zh_HANS-CN: 在一次合并（由'git merge'或'git pull'发起）因冲突而停止后，干净的合并路径已经被分阶段提交给你了，而发生冲突的路径则被留在未合并状态。  你必须先用'git status'检查哪些路径有冲突，然后在工作树上手动修复它们，再像往常一样用'git add'将结果分阶段。

note: type: Plain text
en: After resolving conflicts and staging the result, `git ls-files -u` would stop mentioning the conflicted path.  When you are done, run `git commit` to finally record the merge:
zh_HANS-CN: 在解决冲突并将结果归档后，`git ls-files -u`将不再提及冲突的路径。  完成后，运行`git commit`来最终记录合并的结果。

note: type: Plain text
en: As with the case to record your own changes, you can use `-a` option to save typing.  One difference is that during a merge resolution, you cannot use `git commit` with pathnames to alter the order the changes are committed, because the merge should be recorded as a single commit.  In fact, the command refuses to run when given pathnames (but see `-i` option).
zh_HANS-CN: 和记录自己的修改的情况一样，你可以使用`-a`选项来节省打字。  有一点不同的是，在解决合并的过程中，你不能使用`git commit`和路径名来改变修改的提交顺序，因为合并应该被记录为一次提交。  事实上，该命令在给定路径名时拒绝运行（但见`-i`选项）。

note: type: Title -
en: COMMIT INFORMATION
zh_HANS-CN: 承诺信息

note: type: Plain text
en: Author and committer information is taken from the following environment variables, if set:
zh_HANS-CN: 作者和提交者的信息取自以下环境变量，如果设置了的话。

note: type: Plain text
en: (nb "<", ">" and "\n"s are stripped)
zh_HANS-CN: （注意"<"、">" 和 "\n" 被剥离）

note: type: Plain text
en: The author and committer names are by convention some form of a personal name (that is, the name by which other humans refer to you), although Git does not enforce or require any particular form. Arbitrary Unicode may be used, subject to the constraints listed above. This name has no effect on authentication; for that, see the `credential.username` variable in linkgit:git-config[1].
zh_HANS-CN: 作者和提交者的名字按惯例是某种形式的人名（也就是其他人称呼你的名字），尽管Git并不强制或要求任何特定的形式。可以使用任意的Unicode，但要遵守上述的限制。这个名字对认证没有影响；关于这一点，请看linkgit:git-config[1]中的`credential.username`变量。

note: type: Plain text
en: In case (some of) these environment variables are not set, the information is taken from the configuration items `user.name` and `user.email`, or, if not present, the environment variable EMAIL, or, if that is not set, system user name and the hostname used for outgoing mail (taken from `/etc/mailname` and falling back to the fully qualified hostname when that file does not exist).
zh_HANS-CN: 如果这些环境变量（其中一些）没有设置，信息来自配置项`user.name`和`user.email`，或者，如果不存在，环境变量EMAIL，或者，如果没有设置，系统用户名和用于发送邮件的主机名（取自`/etc/mailname`，如果该文件不存在，则返回到完全合格的主机名）。

note: type: Plain text
en: The `author.name` and `committer.name` and their corresponding email options override `user.name` and `user.email` if set and are overridden themselves by the environment variables.
zh_HANS-CN: 如果设置了`author.name`和`committer.name`及其相应的email选项，将覆盖`user.name`和`user.email`，并由环境变量自行覆盖。

note: type: Plain text
en: The typical usage is to set just the `user.name` and `user.email` variables; the other options are provided for more complex use cases.
zh_HANS-CN: 典型的用法是只设置 "user.name "和 "user.email "变量；其他选项是为更复杂的使用情况提供的。

note: type: Plain text
en: Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description.  The text up to the first blank line in a commit message is treated as the commit title, and that title is used throughout Git.  For example, linkgit:git-format-patch[1] turns a commit into email, and it uses the title on the Subject line and the rest of the commit in the body.
zh_HANS-CN: 虽然不是必须的，但在提交信息的开头用一行简短（少于50个字符）的文字来概括修改内容是个好主意，接下来是空白行，然后是更详尽的描述。  提交信息中第一个空行之前的文字被视为提交标题，并且该标题在整个 Git 中使用。  例如，linkgit:git-format-patch[1] 把提交变成了电子邮件，它在主题行使用标题，在正文中使用提交的其他内容。

note: type: Title -
en: ENVIRONMENT AND CONFIGURATION VARIABLES
zh_HANS-CN: 环境和配置变量

note: type: Plain text
en: The editor used to edit the commit log message will be chosen from the `GIT_EDITOR` environment variable, the core.editor configuration variable, the `VISUAL` environment variable, or the `EDITOR` environment variable (in that order).  See linkgit:git-var[1] for details.
zh_HANS-CN: 用于编辑提交日志信息的编辑器将从`GIT_EDITOR`环境变量、core.editor配置变量、`VISUAL`环境变量或`EDITOR`环境变量中选择（按顺序）。  详情见linkgit:git-var[1]。

note: type: Plain text
en: This command can run `commit-msg`, `prepare-commit-msg`, `pre-commit`, `post-commit` and `post-rewrite` hooks.  See linkgit:githooks[5] for more information.
zh_HANS-CN: 这个命令可以运行`commit-msg`、`prepare-commit-msg`、`pre-commit`、`post-commit`和`post-rewrite`钩子。  更多信息见linkgit:githooks[5]。

note: type: Labeled list
en: `$GIT_DIR/COMMIT_EDITMSG`
zh_HANS-CN: `$git_dir/commit_editmsg`。

note: type: Plain text
en: This file contains the commit message of a commit in progress.  If `git commit` exits due to an error before creating a commit, any commit message that has been provided by the user (e.g., in an editor session) will be available in this file, but will be overwritten by the next invocation of `git commit`.
zh_HANS-CN: 该文件包含正在进行的提交的提交信息。  如果`git commit`在创建提交前因错误而退出，任何由用户提供的提交信息（例如在编辑器会话中）都会在此文件中出现，但会被下次调用`git commit`时覆盖。

note: type: Plain text
en: git-config - Get and set repository or global options
zh_HANS-CN: git-config - 获取和设置仓库或全局选项

note: type: Plain text
en: You can query/set/replace/unset options with this command. The name is actually the section and the key separated by a dot, and the value will be escaped.
zh_HANS-CN: 你可以用这个命令查询/设置/替换/取消选项。名称(name)实际上是用点隔开的节和键，值(value)会被转义。

note: type: Plain text
en: Multiple lines can be added to an option by using the `--add` option.  If you want to update or unset an option which can occur on multiple lines, a `value-pattern` (which is an extended regular expression, unless the `--fixed-value` option is given) needs to be given.  Only the existing values that match the pattern are updated or unset.  If you want to handle the lines that do *not* match the pattern, just prepend a single exclamation mark in front (see also <<EXAMPLES>>), but note that this only works when the `--fixed-value` option is not in use.
zh_HANS-CN: 通过使用`--add`选项，可以为一个选项添加多行。  如果你想更新或取消一个可以出现在多行的选项，需要给出一个`value-pattern`（这是一个扩展的正则表达式，除非给出`--fixed-value`选项）。  只有符合该模式的现有值被更新或取消设置。  如果你想处理不符合模式的行，只需在前面加上一个感叹号（参见<<例子>>），但注意这只在没有使用`--fixed-value`选项时有效。

note: type: Plain text
en: The `--type=<type>` option instructs 'git config' to ensure that incoming and outgoing values are canonicalize-able under the given <type>.  If no `--type=<type>` is given, no canonicalization will be performed. Callers may unset an existing `--type` specifier with `--no-type`.
zh_HANS-CN: `--type=<类型>`选项指示'git config'确保传入和传出的值在给定的<类型>下是可以被规范化的。  如果没有给定`--type=<类型>`，将不执行规范化。调用者可以用`--no-type`取消现有的`--type`指定器。

note: type: Plain text
en: When reading, the values are read from the system, global and repository local configuration files by default, and options `--system`, `--global`, `--local`, `--worktree` and `--file <filename>` can be used to tell the command to read from only that location (see <<FILES>>).
zh_HANS-CN: 读取配置时，默认从系统、全局和资源库的本地配置文件中读取数值，选项`--系统(system)`、`--全局(global)`、`--(local)`、`--工作区(worktree)`和`--文件(file)<文件名>`可以用来告诉命令只从选定的位置读取（见<<文件>>）。

note: type: Plain text
en: When writing, the new value is written to the repository local configuration file by default, and options `--system`, `--global`, `--worktree`, `--file <filename>` can be used to tell the command to write to that location (you can say `--local` but that is the default).
zh_HANS-CN: 写入时，新值默认写入版本库的本地配置文件，选项`--system(系统)`、`--global(全局)`、`--worktree(工作区)`、`--file(文件) <filename>`可以用来告诉命令写到那个位置（你可以给出`--local(本地)`选项，但是默认选项就是本地(local)）。

note: type: Plain text
en: This command will fail with non-zero status upon error.  Some exit codes are:
zh_HANS-CN: 该命令出错时将以非零状态失败。  以下是一些退出代码：

note: type: Plain text
en: The section or key is invalid (ret=1),
zh_HANS-CN: 该节或键无效（退出代码为1），

note: type: Plain text
en: no section or name was provided (ret=2),
zh_HANS-CN: 没有提供节或键（退出值为2），

note: type: Plain text
en: the config file is invalid (ret=3),
zh_HANS-CN: 配置文件无效（退出代码为3），

note: type: Plain text
en: the config file cannot be written (ret=4),
zh_HANS-CN: 配置文件无法写入（退出代码为4），

note: type: Plain text
en: you try to unset an option which does not exist (ret=5),
zh_HANS-CN: 你试图取消一个不存在的选项（退出代码为5），

note: type: Plain text
en: you try to unset/set an option for which multiple lines match (ret=5), or
zh_HANS-CN: 你试图取消/设置一个多行匹配的选项（退出代码为5），或

note: type: Plain text
en: you try to use an invalid regexp (ret=6).
zh_HANS-CN: 试图使用一个无效的正则表达式（退出代码为6）。

note: type: Plain text
en: On success, the command returns the exit code 0.
zh_HANS-CN: 执行成功时，该命令返回退出代码0。

note: type: Plain text
en: A list of all available configuration variables can be obtained using the `git help --config` command.
zh_HANS-CN: 所有可用配置变量的列表可以通过`git help --config`命令获取。

note: type: Plain text
en: Default behavior is to replace at most one line. This replaces all lines matching the key (and optionally the `value-pattern`).
zh_HANS-CN: 默认行为是最多替换一行。这将会替换所有与键（以及可选的`value-pattern`）匹配的行。

note: type: Plain text
en: Adds a new line to the option without altering any existing values.  This is the same as providing '^$' as the `value-pattern` in `--replace-all`.
zh_HANS-CN: 不改变任何现有的值的情况下，在选项中增加一个新的行。  这与在`--replace-all`中提供'^$'作为`value-pattern` 是一样的。

note: type: Plain text
en: Get the value for a given key (optionally filtered by a regex matching the value). Returns error code 1 if the key was not found and the last value if multiple key values were found.
zh_HANS-CN: 获取一个给定的键的值（可选择通过与该值相匹配的正则表达式进行过滤）。如果没有找到键值，返回错误代码1；如果找到多个键值，则返回最后一个值。

note: type: Plain text
en: Like get, but returns all values for a multi-valued key.
zh_HANS-CN: 和--get一样，但是返回一个多值键的所有值。

note: type: Plain text
en: Like --get-all, but interprets the name as a regular expression and writes out the key names.  Regular expression matching is currently case-sensitive and done against a canonicalized version of the key in which section and variable names are lowercased, but subsection names are not.
zh_HANS-CN: 像 --get-all 一样，但是用正则表达式作为，并写出键名。  正则表达式匹配目前是区分大小写的，并且是针对一个规范化的键的版本进行的，其中节(section)和变量名称是小写的，但子节名称不是小写的。

note: type: Labeled list
en: --get-urlmatch <name> <URL>
zh_HANS-CN: --get-urlmatch <名称> <URL>

note: type: Plain text
en: When given a two-part name section.key, the value for section.<URL>.key whose <URL> part matches the best to the given URL is returned (if no such key exists, the value for section.key is used as a fallback).  When given just the section as name, do so for all the keys in the section and list them.  Returns error code 1 if no value is found.
zh_HANS-CN: 当给定一个由两部分组成的名称section.key时，返回section.<URL>.key的值，其<URL>部分是给定的最相匹配的URL（如果没有这样的键存在，section.key的值将作为备用值）。  当只给出section的名称时，对section中的所有key进行处理，并将其列出。  如果没有找到值，返回错误代码1（section: 节，key:键；在配置文件中是这样的[section]  key=value）。

note: type: Plain text
en: For writing options: write to global `~/.gitconfig` file rather than the repository `.git/config`, write to `$XDG_CONFIG_HOME/git/config` file if this file exists and the `~/.gitconfig` file doesn't.
zh_HANS-CN: 对于写入选项：写入全局的`~/.gitconfig`文件而不是仓库的`.git/config`文件，如果该文件存在而`~/.gitconfig`文件不存在，则写入`$XDG_CONFIG_HOME/git/config`文件。

note: type: Plain text
en: For reading options: read only from global `~/.gitconfig` and from `$XDG_CONFIG_HOME/git/config` rather than from all available files.
zh_HANS-CN: 对于读取选项：只从全局的`~/.gitconfig`和`$XDG_CONFIG_HOME/git/config`中读取，而不是从所有可用文件中读取。

note: type: Plain text
en: See also <<FILES>>.
zh_HANS-CN: 另请参见<<文件>>。

note: type: Plain text
en: For writing options: write to system-wide `$(prefix)/etc/gitconfig` rather than the repository `.git/config`.
zh_HANS-CN: 对于写选项：写到系统范围内的`$(prefix)/etc/gitconfig`文件中，而不是仓库中的`.git/config`文件。

note: type: Plain text
en: For reading options: read only from system-wide `$(prefix)/etc/gitconfig` rather than from all available files.
zh_HANS-CN: 对于读取选项：只从系统范围内的`$(prefix)/etc/gitconfig`读取，而不是从所有可用文件中读取。

note: type: Plain text
en: For writing options: write to the repository `.git/config` file.  This is the default behavior.
zh_HANS-CN: 对于写选项：写到版本库的`.git/config`文件中。  这是默认行为。

note: type: Plain text
en: For reading options: read only from the repository `.git/config` rather than from all available files.
zh_HANS-CN: 对于读取选项：只从存储库`.git/config`中读取，而不是从所有可用文件中读取。

note: type: Plain text
en: Similar to `--local` except that `$GIT_DIR/config.worktree` is read from or written to if `extensions.worktreeConfig` is enabled. If not it's the same as `--local`. Note that `$GIT_DIR` is equal to `$GIT_COMMON_DIR` for the main working tree, but is of the form `$GIT_DIR/worktrees/<id>/` for other working trees. See linkgit:git-worktree[1] to learn how to enable `extensions.worktreeConfig`.
zh_HANS-CN: 与`--local`类似，只是如果启用了`extensions.worktreeConfig`，则从`$GIT_DIR/config.worktree`读取或写入。如果没有，则与`--local`相同。注意，对于主工作区，`$GIT_DIR`等于`$GIT_COMMON_DIR`，但对于其他工作区，它的形式是`$GIT_DIR/worktrees/<id>/`。了解如何启用 `extensions.worktreeConfig`，参见 linkgit:git-worktree[1] 。

note: type: Labeled list
en: -f <config-file>
zh_HANS-CN: -f <配置文件>

note: type: Labeled list
en: --file <config-file>
zh_HANS-CN: --file <配置文件>

note: type: Plain text
en: For writing options: write to the specified file rather than the repository `.git/config`.
zh_HANS-CN: 对于写入选项：写到指定的文件，而不是仓库`.git/config`。

note: type: Plain text
en: For reading options: read only from the specified file rather than from all available files.
zh_HANS-CN: 对于读取选项：只从指定的文件而不是从所有可用的文件中读取。

note: type: Labeled list
en: --blob <blob>
zh_HANS-CN: --blob <二进制对象>

note: type: Plain text
en: Similar to `--file` but use the given blob instead of a file. E.g.  you can use 'master:.gitmodules' to read values from the file '.gitmodules' in the master branch. See "SPECIFYING REVISIONS" section in linkgit:gitrevisions[7] for a more complete list of ways to spell blob names.
zh_HANS-CN: 类似于`--file`，但使用指定的二进制对象而不是文件。例如，你可以使用'master:.gitmodules'来读取主分支中'.gitmodules'文件中的值。参见 linkgit:gitrevisions[7] 中的 "指定的修正"部分，以获得更完整的二进制对象名称拼写方式。

note: type: Plain text
en: Remove the given section from the configuration file.
zh_HANS-CN: 从配置文件中删除了该节。

note: type: Plain text
en: Rename the given section to a new name.
zh_HANS-CN: 将给定的节重命名为一个新的名称。

note: type: Plain text
en: Remove the line matching the key from config file.
zh_HANS-CN: 从配置文件中删除与该键匹配的行。

note: type: Plain text
en: Remove all lines matching the key from config file.
zh_HANS-CN: 从配置文件中删除所有匹配该键的行。

note: type: Plain text
en: List all variables set in config file, along with their values.
zh_HANS-CN: 列出配置文件中设置的所有变量，以及它们的值。

note: type: Plain text
en: When used with the `value-pattern` argument, treat `value-pattern` as an exact string instead of a regular expression. This will restrict the name/value pairs that are matched to only those where the value is exactly equal to the `value-pattern`.
zh_HANS-CN: 当与`value-pattern`参数一起使用时，将`value-pattern`视为精确的字符串，而不是正则表达式。这将使得被匹配的名称/值对，只有那些值与`value-pattern'完全相等的名称/值对。

note: type: Labeled list
en: --type <type>
zh_HANS-CN: --type <类型>

note: type: Plain text
en: 'git config' will ensure that any input or output is valid under the given type constraint(s), and will canonicalize outgoing values in `<type>`'s canonical form.
zh_HANS-CN: 'git config' 将确保任何输入或输出在给定的类型约束下是有效的，并将以 `<类型>` 的规范形式将输出的值规范化。

note: type: Plain text
en: Valid `<type>`'s include:
zh_HANS-CN: 有效的 `<类型>` 包括：

note: type: Plain text
en: 'bool': canonicalize values as either "true" or "false".
zh_HANS-CN: 'bool'：将数值规范化为 "true" 或 "false"。

note: type: Plain text
en: 'int': canonicalize values as simple decimal numbers. An optional suffix of 'k', 'm', or 'g' will cause the value to be multiplied by 1024, 1048576, or 1073741824 upon input.
zh_HANS-CN: 'int'：将数值规范化为简单的十进制数字。可选的后缀 'k'、'm' 或 'g'将导致输入的值被乘以 1024、1048576 或 1073741824。

note: type: Plain text
en: 'bool-or-int': canonicalize according to either 'bool' or 'int', as described above.
zh_HANS-CN: 'bool-or-int'：如上所述，根据 'bool '或 'int' 进行规范化。

note: type: Plain text
en: 'expiry-date': canonicalize by converting from a fixed or relative date-string to a timestamp. This specifier has no effect when setting the value.
zh_HANS-CN: 'expiry-date'：通过将固定或相对日期字符串转换为时间戳进行规范化。这个指定符在设置值时没有影响。

note: type: Plain text
en: 'color': When getting a value, canonicalize by converting to an ANSI color escape sequence. When setting a value, a sanity-check is performed to ensure that the given value is canonicalize-able as an ANSI color, but it is written as-is.
zh_HANS-CN: 'color'： 当获得一个值时，通过转换为 ANSI 颜色转义序列进行规范化。当设置一个值时，会进行理智检查，以确保给定的值可以被规范化为 ANSI 颜色，但它会按原样写入。

note: type: Plain text
en: Historical options for selecting a type specifier. Prefer instead `--type` (see above).
zh_HANS-CN: 选择类型指定器的历史选项。更倾向于选择 `--type`（见上文）。

note: type: Plain text
en: Un-sets the previously set type specifier (if one was previously set). This option requests that 'git config' not canonicalize the retrieved variable.  `--no-type` has no effect without `--type=<type>` or `--<type>`.
zh_HANS-CN: 取消先前设置的类型指定器（如果先前有的话）。这个选项要求 'git config' 不对检索的变量进行规范化处理。 `--no-type` 在没有 `--type=<类型>` 或 `--<类型>` 的情况下没有作用。

note: type: Plain text
en: For all options that output values and/or keys, always end values with the null character (instead of a newline). Use newline instead as a delimiter between key and value. This allows for secure parsing of the output without getting confused e.g. by values that contain line breaks.
zh_HANS-CN: 对于所有输出值和/或键的选项，总是用空字符（而不是换行）结束值。使用换行符作为键和值之间的分隔符。这样可以安全地解析输出，而不会被包含换行的值所混淆。

note: type: Plain text
en: Output only the names of config variables for `--list` or `--get-regexp`.
zh_HANS-CN: 只输出 `--list` 或 `--get-regexp` 的配置变量的名称。

note: type: Plain text
en: Augment the output of all queried config options with the origin type (file, standard input, blob, command line) and the actual origin (config file path, ref, or blob id if applicable).
zh_HANS-CN: 用来源类型（文件、标准输入、blob、命令行）和实际来源（配置文件路径、引用或 blob id（如适用））对所有查询到的配置选项的输出进行扩充。

note: type: Plain text
en: Similar to `--show-origin` in that it augments the output of all queried config options with the scope of that value (worktree, local, global, system, command).
zh_HANS-CN: 类似于 `--show-origin`，它用该值的范围（工作树、本地、全局、系统、命令）来增加所有查询的配置选项的输出。

note: type: Plain text
en: Find the color setting for `<name>` (e.g. `color.diff`) and output "true" or "false".  `<stdout-is-tty>` should be either "true" or "false", and is taken into account when configuration says "auto".  If `<stdout-is-tty>` is missing, then checks the standard output of the command itself, and exits with status 0 if color is to be used, or exits with status 1 otherwise.  When the color setting for `name` is undefined, the command uses `color.ui` as fallback.
zh_HANS-CN: 找到 `<名称>` 的颜色设置（例如 `color.diff`），并输出 "true" 或 "false"。 `<stdout-is-tty>` 应该是 "true" 或 "false"，当配置为 "auto" 时将被考虑。 如果 `<stdout-is-tty>` 缺失，则检查命令本身的标准输出，如果要使用颜色则以状态 0 退出，否则以状态 1 退出。 当 `name` 的颜色设置未被定义时，该命令使用 `color.ui` 作为回退。

note: type: Plain text
en: Find the color configured for `name` (e.g. `color.diff.new`) and output it as the ANSI color escape sequence to the standard output.  The optional `default` parameter is used instead, if there is no color configured for `name`.
zh_HANS-CN: 找到为 `name` 配置的颜色（例如：`color.diff.new`），并将其作为 ANSI 颜色转义序列输出到标准输出。 如果没有为 `name` 配置的颜色，则使用可选的 `default` 参数来代替。

note: type: Plain text
en: `--type=color [--default=<default>]` is preferred over `--get-color` (but note that `--get-color` will omit the trailing newline printed by `--type=color`).
zh_HANS-CN: `--type=color [--default=<默认>]` 比 `--get-color` 更受欢迎（但注意 `--get-color` 会省略 `--type=color` 打印的尾部换行）。

note: type: Plain text
en: Opens an editor to modify the specified config file; either `--system`, `--global`, or repository (default).
zh_HANS-CN: 打开一个编辑器来修改指定的配置文件；可以是 `--system`，`--global`，也可以是仓库（默认）。

note: type: Plain text
en: Respect `include.*` directives in config files when looking up values. Defaults to `off` when a specific file is given (e.g., using `--file`, `--global`, etc) and `on` when searching all config files.
zh_HANS-CN: 在查找数值时尊重配置文件中的 `include.*` 指令。当给出一个特定的文件时，默认为 `off`（例如，使用 `--file`、`--global` 等），当搜索所有配置文件时，默认为 `on`。

note: type: Labeled list
en: --default <value>
zh_HANS-CN: --default <值>

note: type: Plain text
en: When using `--get`, and the requested variable is not found, behave as if <value> were the value assigned to the that variable.
zh_HANS-CN: 当使用 `--get` 时，如果没有找到所要求的变量，则表现为 <值> 是分配给该变量的值。

note: type: Plain text
en: `pager.config` is only respected when listing configuration, i.e., when using `--list` or any of the `--get-*` which may return multiple results.  The default is to use a pager.
zh_HANS-CN: `pager.config` 只在列出配置时被尊重，即在使用 `--list` 或任何可能返回多个结果的 `--get-*` 时。 默认情况下是使用 pager。

note: type: Plain text
en: By default, 'git config' will read configuration options from multiple files:
zh_HANS-CN: 默认情况下，'git config' 会从多个文件中读取配置选项：

note: type: Plain text
en: System-wide configuration file.
zh_HANS-CN: 全系统的配置文件。

note: type: Plain text
en: User-specific configuration files. When the XDG_CONFIG_HOME environment variable is not set or empty, $HOME/.config/ is used as $XDG_CONFIG_HOME.
zh_HANS-CN: 用户特定的配置文件。当 XDG_CONFIG_HOME 环境变量没有设置或为空时，$HOME/.config/ 被用作 $XDG_CONFIG_HOME。

note: type: Plain text
en: These are also called "global" configuration files. If both files exist, both files are read in the order given above.
zh_HANS-CN: 这些文件也被称为 “全局” 配置文件。如果这两个文件都存在，就按照上面的顺序读取这两个文件。

note: type: Plain text
en: Repository specific configuration file.
zh_HANS-CN: 仓库特定的配置文件。

note: type: Plain text
en: This is optional and is only searched when `extensions.worktreeConfig` is present in $GIT_DIR/config.
zh_HANS-CN: 这是可选的，只有当 $GIT_DIR/config 中存在 `extensions.worktreeConfig` 时才会被搜索到。

note: type: Plain text
en: You may also provide additional configuration parameters when running any git command by using the `-c` option. See linkgit:git[1] for details.
zh_HANS-CN: 你也可以在运行任何 git 命令时通过使用 `-c` 选项提供额外的配置参数。详情见 linkgit:git[1]。

note: type: Plain text
en: Options will be read from all of these files that are available. If the global or the system-wide configuration files are missing or unreadable they will be ignored. If the repository configuration file is missing or unreadable, 'git config' will exit with a non-zero error code. An error message is produced if the file is unreadable, but not if it is missing.
zh_HANS-CN: 选项将从所有这些可用的文件中读取。如果全局或全系统的配置文件丢失或不可读，它们将被忽略。如果版本库的配置文件丢失或不可读，'git config' 将以非零的错误代码退出。如果文件不可读，会产生一个错误信息，但如果文件丢失，则不会产生错误信息。

note: type: Plain text
en: The files are read in the order given above, with last value found taking precedence over values read earlier.  When multiple values are taken then all values of a key from all files will be used.
zh_HANS-CN: 文件是按照上述顺序读取的，最后发现的值优先于之前读取的值。 当有多个值时，将使用所有文件中某个键的所有值。

note: type: Plain text
en: By default, options are only written to the repository specific configuration file. Note that this also affects options like `--replace-all` and `--unset`. *'git config' will only ever change one file at a time*.
zh_HANS-CN: 默认情况下，选项只被写入版本库特定的配置文件中。请注意，这也会影响到 `--replace-all` 和 `--unset` 等选项。*'git config' 一次只能改变一个文件*。

note: type: Plain text
en: You can limit which configuration sources are read from or written to by specifying the path of a file with the `--file` option, or by specifying a configuration scope with `--system`, `--global`, `--local`, or `--worktree`.  For more, see <<OPTIONS>> above.
zh_HANS-CN: 你可以通过使用 `--file` 选项指定文件路径，或者使用 `--system`、`--global`、`--local` 或 `--worktree` 指定配置范围，来限制从哪些配置源读取或写入。 更多内容请参见上面的 <<OPTIONS>>。

note: type: Title -
en: SCOPES
zh_HANS-CN: 范围

note: type: Plain text
en: Each configuration source falls within a configuration scope. The scopes are:
zh_HANS-CN: 每个配置源都属于一个配置范围。这些范围包括：

note: type: Labeled list
en: worktree
zh_HANS-CN: 工作区

note: type: Plain text
en: GIT_CONFIG_{COUNT,KEY,VALUE} environment variables (see <<ENVIRONMENT>> below)
zh_HANS-CN: GIT_CONFIG_{COUNT,KEY,VALUE} 环境变量（见下文 <<ENVIRONMENT>>）

note: type: Plain text
en: With the exception of 'command', each scope corresponds to a command line option: `--system`, `--global`, `--local`, `--worktree`.
zh_HANS-CN: 除了 'command' 之外，每个范围都对应于一个命令行选项：`--system`、`--global`、`--local`、`--worktree`。

note: type: Plain text
en: When reading options, specifying a scope will only read options from the files within that scope. When writing options, specifying a scope will write to the files within that scope (instead of the repository specific configuration file). See <<OPTIONS>> above for a complete description.
zh_HANS-CN: 当读取选项时，指定一个范围将只从该范围内的文件读取选项。当写选项时，指定一个范围将写到该范围内的文件（而不是仓库的特定配置文件）。参见上面的<<OPTIONS >>以获得完整的描述。

note: type: Plain text
en: Most configuration options are respected regardless of the scope it is defined in, but some options are only respected in certain scopes. See the respective option's documentation for the full details.
zh_HANS-CN: 大多数配置选项无论在哪个作用域中定义都会被尊重，但有些选项只在某些作用域中被尊重。完整的细节请参见相应选项的文档。

note: type: Plain text
en: Protected configuration refers to the 'system', 'global', and 'command' scopes.  For security reasons, certain options are only respected when they are specified in protected configuration, and ignored otherwise.
zh_HANS-CN: 受保护的配置指的是 'system'、'global' 和 'command' 范围。 出于安全考虑，某些选项只有在受保护的配置中指定时才会被尊重，否则会被忽略。

note: type: Plain text
en: Git treats these scopes as if they are controlled by the user or a trusted administrator. This is because an attacker who controls these scopes can do substantial harm without using Git, so it is assumed that the user's environment protects these scopes against attackers.
zh_HANS-CN: Git 将这些作用域视为由用户或可信的管理员控制。这是因为控制这些作用域的攻击者可以在不使用 Git 的情况下造成实质性的伤害，所以假定用户的环境会保护这些作用域免受攻击。

note: type: Title -
en: ENVIRONMENT
zh_HANS-CN: 环境变量

note: type: Plain text
en: Take the configuration from the given files instead from global or system-level configuration. See linkgit:git[1] for details.
zh_HANS-CN: 从给定的文件中获取配置，而不是从全局或系统级配置中获取。详情见 linkgit:git[1]。

note: type: Plain text
en: Whether to skip reading settings from the system-wide $(prefix)/etc/gitconfig file. See linkgit:git[1] for details.
zh_HANS-CN: 是否跳过从全系统 $(prefix)/etc/gitconfig 文件中读取设置。详见 linkgit:git[1]。

note: type: Plain text
en: If GIT_CONFIG_COUNT is set to a positive number, all environment pairs GIT_CONFIG_KEY_<n> and GIT_CONFIG_VALUE_<n> up to that number will be added to the process's runtime configuration. The config pairs are zero-indexed. Any missing key or value is treated as an error. An empty GIT_CONFIG_COUNT is treated the same as GIT_CONFIG_COUNT=0, namely no pairs are processed. These environment variables will override values in configuration files, but will be overridden by any explicit options passed via `git -c`.
zh_HANS-CN: 如果 GIT_CONFIG_COUNT 被设置为一个正数，所有环境对 GIT_CONFIG_KEY_<n> 和 GIT_CONFIG_VALUE_<n> 到这个数字都将被添加到进程的运行时配置中。配置对是零索引的。任何缺失的键或值都被视为一个错误。空的 GIT_CONFIG_COUNT 与 GIT_CONFIG_COUNT=0 的处理方式相同，即不处理配置对。这些环境变量将覆盖配置文件中的值，但会被通过 `git -c` 传递的任何明确选项所覆盖。

note: type: Plain text
en: This is useful for cases where you want to spawn multiple git commands with a common configuration but cannot depend on a configuration file, for example when writing scripts.
zh_HANS-CN: 这在你想用一个共同的配置催生多个 git 命令，但又不能依赖一个配置文件的情况下很有用，例如在编写脚本时。

note: type: Plain text
en: If no `--file` option is provided to `git config`, use the file given by `GIT_CONFIG` as if it were provided via `--file`. This variable has no effect on other Git commands, and is mostly for historical compatibility; there is generally no reason to use it instead of the `--file` option.
zh_HANS-CN: 如果 `git config` 没有提供 `--file` 选项，则使用 `GIT_CONFIG` 提供的文件，就像通过 `--file` 提供的一样。这个变量对其他 Git 命令没有影响，主要是为了历史兼容性；通常没有理由用它来代替 `--file` 选项。

note: type: Plain text
en: Given a .git/config like this:
zh_HANS-CN: 给出一个这样的 .git/config：

note: type: delimited block -
en: #
    # This is the config file, and
    # a '#' or ';' character indicates
    # a comment
    #
zh_HANS-CN: #
    # 这就是配置文件，并且
    # 一个'#'或';'字符表示
    # 一个注释
    #

note: type: delimited block -
en: ; core variables
    [core]
    	; Don't trust file modes
    	filemode = false
zh_HANS-CN: ; 核心变量
    [core]
    	; 不信任文件模式
    	filemode = false

note: type: delimited block -
en: ; Our diff algorithm
    [diff]
    	external = /usr/local/bin/diff-wrapper
    	renames = true
zh_HANS-CN: ; 我们的差异算法
    [diff]
    	external = /usr/local/bin/diff-wrapper
    	rename = true

note: type: delimited block -
en: ; Proxy settings
    [core]
    	gitproxy=proxy-command for kernel.org
    	gitproxy=default-proxy ; for all the rest
zh_HANS-CN: ; 代理设置
    [core]
    	gitproxy=proxy-command for kernel.org
    	gitproxy=default-proxy ; 适用于其他所有网站

note: type: delimited block -
en: ; HTTP
    [http]
    	sslVerify
    [http "https://weak.example.com"]
    	sslVerify = false
    	cookieFile = /tmp/cookie.txt
zh_HANS-CN: ; HTTP
    [http]
    	sslVerify
    [http "https://weak.example.com"]
    	sslVerify = false
    	cookiFile= /tmp/cookie.txt

note: type: Plain text
en: you can set the filemode to true with
zh_HANS-CN: 你可以用以下方法将文件模式设置为真

note: type: Plain text
en: The hypothetical proxy command entries actually have a postfix to discern what URL they apply to. Here is how to change the entry for kernel.org to "ssh".
zh_HANS-CN: 假设的代理命令条目实际上有一个后缀来辨别它们适用于什么URL。下面是如何将 kernel.org 的条目改为 "ssh"。

note: type: Plain text
en: This makes sure that only the key/value pair for kernel.org is replaced.
zh_HANS-CN: 这确保了只有 kernel.org 的键/值对被替换。

note: type: Plain text
en: To delete the entry for renames, do
zh_HANS-CN: 要删除重名的条目，请执行

note: type: Plain text
en: If you want to delete an entry for a multivar (like core.gitproxy above), you have to provide a regex matching the value of exactly one line.
zh_HANS-CN: 如果你想删除一个多变量的条目（如上面的 core.gitproxy），你必须提供一个与恰好一行的值相匹配的正则表达式。

note: type: Plain text
en: To query the value for a given key, do
zh_HANS-CN: 要查询一个给定键的值，请做

note: type: Plain text
en: or, to query a multivar:
zh_HANS-CN: 或者，要查询一个多变量：

note: type: Plain text
en: If you want to know all the values for a multivar, do:
zh_HANS-CN: 如果你想知道一个多变量的所有值，请做：

note: type: Plain text
en: If you like to live dangerously, you can replace *all* core.gitproxy by a new one with
zh_HANS-CN: 如果你喜欢危险的生活，你可以用一个新的核心.gitproxy来取代 *所有* 的核心 .gitproxy，用的是

note: type: Plain text
en: However, if you really only want to replace the line for the default proxy, i.e. the one without a "for ..." postfix, do something like this:
zh_HANS-CN: 然而，如果你真的只想替换默认代理，即没有 "for ..." 后缀的那一行，可以这样做：

note: type: Plain text
en: To actually match only values with an exclamation mark, you have to
zh_HANS-CN: 为了真正地只匹配带有感叹号的值，你必须

note: type: Plain text
en: To add a new proxy, without altering any of the existing ones, use
zh_HANS-CN: 要添加一个新的代理，而不改变任何现有的代理，使用

note: type: Plain text
en: An example to use customized color from the configuration in your script:
zh_HANS-CN: 一个例子是在你的脚本中使用配置的自定义颜色：

note: type: Plain text
en: For URLs in `https://weak.example.com`, `http.sslVerify` is set to false, while it is set to `true` for all others:
zh_HANS-CN: 对于 `https://weak.example.com` 中的 URL，`http.sslVerify` 被设置为 false，而对于所有其他的 URL，它被设置为 `true`：

note: type: Title -
en: BUGS
zh_HANS-CN: 漏洞

note: type: Plain text
en: When using the deprecated `[section.subsection]` syntax, changing a value will result in adding a multi-line key instead of a change, if the subsection is given with at least one uppercase character. For example when the config looks like
zh_HANS-CN: 当使用废弃的 `[section.subsection]` 语法时，如果 subsection 至少有一个大写字母，改变一个值将导致添加一个多行键而不是改变。例如，当配置看起来像

note: type: Plain text
en: and running `git config section.Subsection.key value2` will result in
zh_HANS-CN: 并运行 `git config section.Subsection.key value2` 将导致

note: type: Plain text
en: Print sizes in human readable format
zh_HANS-CN: 以人类可读的格式打印对象大小

note: type: Plain text
en: git-credential-cache--daemon - Temporarily store user credentials in memory
zh_HANS-CN: git-credential-cache--daemon - 在内存中临时存储用户证书

note: type: Plain text
en: You probably don't want to invoke this command yourself; it is started automatically when you use linkgit:git-credential-cache[1].
zh_HANS-CN: 您可能不想自己调用这条命令；当您使用 linkgit:git-credential-cache[1] 时，它会自动启动。

note: type: Plain text
en: This command listens on the Unix domain socket specified by `<socket-path>` for `git-credential-cache` clients. Clients may store and retrieve credentials. Each credential is held for a timeout specified by the client; once no credentials are held, the daemon exits.
zh_HANS-CN: 此命令通过 `<套接字路径>` 指定的 Unix 域套接字监听 `git-credential-cache` 客户端。客户端可以存储和检索证书。每个凭据的保留时间由客户端指定；一旦没有凭据保留，守护进程就会退出。

note: type: Plain text
en: If the `--debug` option is specified, the daemon does not close its stderr stream, and may output extra diagnostics to it even after it has begun listening for clients.
zh_HANS-CN: 如果指定了 `--debug` 选项，守护进程不会关闭标准错误流，甚至在开始监听客户端后仍可能向其输出额外的诊断信息。

note: type: delimited block -
en: git config credential.helper 'cache [<options>]'
zh_HANS-CN: git config credential.helper 'cache [<多个选项>]'

note: type: Plain text
en: This command caches credentials for use by future Git programs.  The stored credentials are kept in memory of the cache-daemon process (instead of written to a file) and are forgotten after a configurable timeout. Credentials are forgotten sooner if the cache-daemon dies, for example if the system restarts. The cache is accessible over a Unix domain socket, restricted to the current user by filesystem permissions.
zh_HANS-CN: 该命令会缓存凭证，供未来的 Git 程序使用。  存储的凭据保存在 cache-daemon 进程的内存中（而不是写入文件），并在可配置的超时后被遗忘。如果 cache-daemon 死机，例如系统重启，证书会更快被遗忘。缓存可通过 Unix 域套接字访问，并通过文件系统权限限制为当前用户访问。

note: type: Plain text
en: You probably don't want to invoke this command directly; it is meant to be used as a credential helper by other parts of Git. See linkgit:gitcredentials[7] or `EXAMPLES` below.
zh_HANS-CN: 你可能不想直接调用这条命令；它的目的是作为 Git 其他部分的凭证助手。请参阅 linkgit:gitcredentials[7] 或下面的 `例子`。

note: type: Plain text
en: Number of seconds to cache credentials (default: 900).
zh_HANS-CN: 缓存证书的秒数（默认值：900）。

note: type: Labeled list
en: --socket <path>
zh_HANS-CN: --socket <路径>

note: type: Plain text
en: Use `<path>` to contact a running cache daemon (or start a new cache daemon if one is not started).  Defaults to `$XDG_CACHE_HOME/git/credential/socket` unless `~/.git-credential-cache/` exists in which case `~/.git-credential-cache/socket` is used instead.  If your home directory is on a network-mounted filesystem, you may need to change this to a local filesystem. You must specify an absolute path.
zh_HANS-CN: 使用 `<路径>` 联系正在运行的缓存守护进程（或在未启动缓存守护进程的情况下启动新的缓存守护进程）。  默认路径是 `$XDG_CACHE_HOME/git/credential/socket`，除非存在 `~/.git-credential-cache/`，在这种情况下会使用 `~/.git-credential-cache/socket`。  如果您的主目录位于网络挂载的文件系统上，可能需要将其更改为本地文件系统。必须指定绝对路径。

note: type: Title -
en: CONTROLLING THE DAEMON
zh_HANS-CN: 控制守护进程

note: type: Plain text
en: If you would like the daemon to exit early, forgetting all cached credentials before their timeout, you can issue an `exit` action:
zh_HANS-CN: 如果希望守护进程提前退出，在超时前忘记所有缓存的凭据，可以发出 `exit`操作：

note: type: Plain text
en: The point of this helper is to reduce the number of times you must type your username or password. For example:
zh_HANS-CN: 这个助手的意义在于减少你必须输入用户名或密码的次数。比如说：

note: type: delimited block -
en: $ git config credential.helper cache
    $ git push http://example.com/repo.git
    Username: <type your username>
    Password: <type your password>
zh_HANS-CN: $ git config credential.helper cache
    $ git push http://example.com/repo.git
    Username: <输入你的用户名>
    Password: <输入你的密码>

note: type: Plain text
en: You can provide options via the credential.helper configuration variable (this example increases the cache time to 1 hour):
zh_HANS-CN: 您可以通过 credential.helper 配置变量提供选项（本例将缓存时间增加到 1 小时）：

note: type: delimited block -
en: git config credential.helper 'store [<options>]'
zh_HANS-CN: git config credential.helper 'store [<选项>]'

note: type: Plain text
en: Using this helper will store your passwords unencrypted on disk, protected only by filesystem permissions. If this is not an acceptable security tradeoff, try linkgit:git-credential-cache[1], or find a helper that integrates with secure storage provided by your operating system.
zh_HANS-CN: 使用这个助手会将你的密码未加密地存储在磁盘上，只受文件系统权限的保护。如果这不是一个可接受的安全权衡，请尝试 linkgit:git-credential-cache[1]，或者找一个能与你的操作系统提供的安全存储整合的助手。

note: type: Plain text
en: This command stores credentials indefinitely on disk for use by future Git programs.
zh_HANS-CN: 该命令在磁盘上无限期地存储凭证，供未来的 Git 程序使用。

note: type: Plain text
en: You probably don't want to invoke this command directly; it is meant to be used as a credential helper by other parts of git. See linkgit:gitcredentials[7] or `EXAMPLES` below.
zh_HANS-CN: 你可能不想直接调用这个命令；它是作为 git 其他部分的凭证助手来使用的。参见 linkgit:gitcredentials[7] 或下面的 `EXAMPLES`。

note: type: Labeled list
en: --file=<path>
zh_HANS-CN: --file=<路径>

note: type: Plain text
en: Use `<path>` to lookup and store credentials. The file will have its filesystem permissions set to prevent other users on the system from reading it, but will not be encrypted or otherwise protected. If not specified, credentials will be searched for from `~/.git-credentials` and `$XDG_CONFIG_HOME/git/credentials`, and credentials will be written to `~/.git-credentials` if it exists, or `$XDG_CONFIG_HOME/git/credentials` if it exists and the former does not. See also <<FILES>>.
zh_HANS-CN: 使用 `<路径>` 来查询和存储证书。该文件将设置其文件系统权限，以防止系统中的其他用户读取它，但不会被加密或其他保护。如果没有指定，将从 `~/.git-credentials` 和 `$XDG_CONFIG_HOME/git/credentials` 中搜索证书，如果证书存在，将被写入 `~/.git-credentials`，如果证书存在而前者不存在，则写入 `$XDG_CONFIG_HOME/git/credentials`。参见 <<FILES>>。

note: type: Plain text
en: If not set explicitly with `--file`, there are two files where git-credential-store will search for credentials in order of precedence:
zh_HANS-CN: 如果没有用 `--file` 明确设置，有两个文件，git-credential-store 将按照优先顺序搜索证书：

note: type: Plain text
en: User-specific credentials file.
zh_HANS-CN: 用户特定的凭证文件。

note: type: Plain text
en: Second user-specific credentials file. If '$XDG_CONFIG_HOME' is not set or empty, `$HOME/.config/git/credentials` will be used. Any credentials stored in this file will not be used if `~/.git-credentials` has a matching credential as well. It is a good idea not to create this file if you sometimes use older versions of Git that do not support it.
zh_HANS-CN: 第二个用户专用的证书文件。如果 '$XDG_CONFIG_HOME' 没有设置或为空，`$HOME/.config/git/credentials` 将被使用。如果 `~/.git-credentials` 也有匹配的凭证，那么存储在该文件中的任何凭证将不会被使用。如果你有时使用不支持该文件的旧版本的 Git，那么不创建该文件是个好主意。

note: type: Plain text
en: For credential lookups, the files are read in the order given above, with the first matching credential found taking precedence over credentials found in files further down the list.
zh_HANS-CN: 对于凭证查询，文件按上述顺序读取，发现的第一个匹配凭证优先于在列表后面的文件中发现的凭证。

note: type: Plain text
en: Credential storage will by default write to the first existing file in the list. If none of these files exist, `~/.git-credentials` will be created and written to.
zh_HANS-CN: 凭证存储将默认写到列表中的第一个现有文件。如果这些文件都不存在，`~/.git-credentials` 将被创建并写入。

note: type: Plain text
en: When erasing credentials, matching credentials will be erased from all files.
zh_HANS-CN: 擦除证书时，匹配的证书将从所有文件中擦除。

note: type: Title -
en: STORAGE FORMAT
zh_HANS-CN: 存储格式

note: type: Plain text
en: The `.git-credentials` file is stored in plaintext. Each credential is stored on its own line as a URL like:
zh_HANS-CN: `.git-credentials` 文件是以明文存储的。每个凭证都以 URL 的形式存储在自己的一行中，比如：

note: type: Plain text
en: No other kinds of lines (e.g. empty lines or comment lines) are allowed in the file, even though some may be silently ignored. Do not view or edit the file with editors.
zh_HANS-CN: 文件中不允许有其他类型的行（如空行或注释行），尽管有些行可能被默默地忽略了。不要用编辑器查看或编辑该文件。

note: type: Plain text
en: When Git needs authentication for a particular URL context, credential-store will consider that context a pattern to match against each entry in the credentials file.  If the protocol, hostname, and username (if we already have one) match, then the password is returned to Git. See the discussion of configuration in linkgit:gitcredentials[7] for more information.
zh_HANS-CN: 当 Git 需要对某个特定的 URL 上下文进行认证时，credential-store 会将该上下文视为一种模式，与凭证文件中的每个条目进行匹配。 如果协议、主机名和用户名（如果我们已经有了）相匹配，那么密码就会返回给 Git。更多信息见 linkgit:gitcredentials[7] 中关于配置的讨论。

note: type: Plain text
en: git-credential - Retrieve and store user credentials
zh_HANS-CN: git-credential - 检索和存储用户证书

note: type: Plain text
en: Git has an internal interface for storing and retrieving credentials from system-specific helpers, as well as prompting the user for usernames and passwords. The git-credential command exposes this interface to scripts which may want to retrieve, store, or prompt for credentials in the same manner as Git. The design of this scriptable interface models the internal C API; see credential.h for more background on the concepts.
zh_HANS-CN: Git 有一个内部接口，用于存储和检索来自系统特定帮助器的凭证，以及提示用户输入用户名和密码。git-credential 命令将这个接口暴露给脚本，这些脚本可能希望以与 Git 相同的方式检索、存储或提示凭证。这个脚本接口的设计仿照了内部的 C 语言应用程序接口；更多概念的背景见 credential.h。

note: type: Plain text
en: If the action is `fill`, git-credential will attempt to add "username" and "password" attributes to the description by reading config files, by contacting any configured credential helpers, or by prompting the user. The username and password attributes of the credential description are then printed to stdout together with the attributes already provided.
zh_HANS-CN: 如果动作是 `fill`，git-credential 将尝试通过读取配置文件、联系任何已配置的凭证助手或提示用户来向描述中添加 “用户名” 和 “密码” 属性。然后，凭证描述中的用户名和密码属性会和已经提供的属性一起打印到标准输出流。

note: type: Plain text
en: If the action is `approve`, git-credential will send the description to any configured credential helpers, which may store the credential for later use.
zh_HANS-CN: 如果动作是 `approve`，git-credential 将把描述发送给任何配置的凭证助手，它们可以存储凭证供以后使用。

note: type: Plain text
en: If the action is `approve` or `reject`, no output should be emitted.
zh_HANS-CN: 如果动作是 `approve` 或 `reject`，就不应该有输出。

note: type: Title -
en: TYPICAL USE OF GIT CREDENTIAL
zh_HANS-CN: git 凭证的典型用途

note: type: Plain text
en: An application using git-credential will typically use `git credential` following these steps:
zh_HANS-CN: 使用 git-credential 的应用程序通常会按照以下步骤使用 `git credential`：

note: type: Plain text
en: Generate a credential description based on the context.
zh_HANS-CN: 根据上下文生成一个凭证描述。

note: type: Plain text
en: For example, if we want a password for `https://example.com/foo.git`, we might generate the following credential description (don't forget the blank line at the end; it tells `git credential` that the application finished feeding all the information it has):
zh_HANS-CN: 例如，如果我们想要一个 `https://example.com/foo.git` 的密码，我们可能会生成下面的凭证描述（别忘了最后的空行；它告诉 `git credential`，应用程序已经完成了所有信息的输入）：

note: type: Plain text
en: Ask git-credential to give us a username and password for this description. This is done by running `git credential fill`, feeding the description from step (1) to its standard input. The complete credential description (including the credential per se, i.e. the login and password) will be produced on standard output, like:
zh_HANS-CN: 要求 git-credential 为这个描述提供一个用户名和密码。这可以通过运行 `git credential fill` 来实现，将步骤（1）中的描述输入到其标准输入中。完整的凭证描述（包括凭证本身，即登录名和密码）将在标准输出中产生，比如：

note: type: Plain text
en: In most cases, this means the attributes given in the input will be repeated in the output, but Git may also modify the credential description, for example by removing the `path` attribute when the protocol is HTTP(s) and `credential.useHttpPath` is false.
zh_HANS-CN: 在大多数情况下，这意味着输入中给出的属性将在输出中重复出现，但Git也可以修改凭证描述，例如，当协议是HTTP(s)且 `credential.useHttpPath` 为假时，删除 `path` 属性。

note: type: Plain text
en: If the `git credential` knew about the password, this step may not have involved the user actually typing this password (the user may have typed a password to unlock the keychain instead, or no user interaction was done if the keychain was already unlocked) before it returned `password=secr3t`.
zh_HANS-CN: 如果`git credential` 知道密码，在返回 `password=secr3t` 之前，这一步可能不涉及用户实际输入这个密码（用户可能输入了一个密码来代替解锁钥匙串，或者如果钥匙串已经被解锁，则没有进行用户交互）。

note: type: Plain text
en: Use the credential (e.g., access the URL with the username and password from step (2)), and see if it's accepted.
zh_HANS-CN: 使用该证书（例如，用步骤（2）中的用户名和密码访问 URL），看看是否被接受。

note: type: Plain text
en: Report on the success or failure of the password. If the credential allowed the operation to complete successfully, then it can be marked with an "approve" action to tell `git credential` to reuse it in its next invocation. If the credential was rejected during the operation, use the "reject" action so that `git credential` will ask for a new password in its next invocation. In either case, `git credential` should be fed with the credential description obtained from step (2) (which also contain the ones provided in step (1)).
zh_HANS-CN: 报告密码的成功或失败。如果凭证允许操作成功完成，那么可以用 "approve" 动作标记，告诉 `git credential` 在下一次调用中重新使用它。如果操作过程中证书被拒绝，使用 "reject" 动作，这样 `git credential` 将在下一次调用中要求一个新的密码。在这两种情况下，`git credential` 应该被输入从步骤 (2) 中获得的凭证描述（其中也包含步骤(1)中提供的描述）。

note: type: Title -
en: INPUT/OUTPUT FORMAT
zh_HANS-CN: 输入/输出格式

note: type: Plain text
en: `git credential` reads and/or writes (depending on the action used)  credential information in its standard input/output. This information can correspond either to keys for which `git credential` will obtain the login information (e.g. host, protocol, path), or to the actual credential data to be obtained (username/password).
zh_HANS-CN: `git credential` 在其标准输入/输出中读取和/或写入（取决于使用的操作）凭证信息。这些信息可以对应于 `git credential` 将获得登录信息的键（如主机、协议、路径），或者对应于要获得的实际凭证数据（用户名/密码）。

note: type: Plain text
en: The credential is split into a set of named attributes, with one attribute per line. Each attribute is specified by a key-value pair, separated by an `=` (equals) sign, followed by a newline.
zh_HANS-CN: 凭证被分割成一组命名的属性，每行一个属性。每个属性由一个键值对指定，用一个 `=`（等号）分隔，后面是换行。

note: type: Plain text
en: The key may contain any bytes except `=`, newline, or NUL. The value may contain any bytes except newline or NUL.
zh_HANS-CN: 键可以包含任何字节，除了 `=`、换行或 NUL。值可以包含除换行或 NUL 之外的任何字节。

note: type: Plain text
en: Attributes with keys that end with C-style array brackets `[]` can have multiple values. Each instance of a multi-valued attribute forms an ordered list of values - the order of the repeated attributes defines the order of the values. An empty multi-valued attribute (`key[]=\n`)  acts to clear any previous entries and reset the list.
zh_HANS-CN: 键值以 C 型数组括号 `[]` 结尾的属性可以有多个值。一个多值属性的每个实例形成一个有序的值列表--重复属性的顺序决定了值的顺序。一个空的多值属性（`key[]=\n`）的作用是清除之前的任何条目并重置列表。

note: type: Plain text
en: In all cases, all bytes are treated as-is (i.e., there is no quoting, and one cannot transmit a value with newline or NUL in it). The list of attributes is terminated by a blank line or end-of-file.
zh_HANS-CN: 在所有情况下，所有字节都按原样处理（即没有引号，也不能传输带有换行或NUL的值）。属性列表以空行或文件结束来结束。

note: type: Plain text
en: The protocol over which the credential will be used (e.g., `https`).
zh_HANS-CN: 将使用证书的协议（例如，`https`）。

note: type: Plain text
en: The remote hostname for a network credential.  This includes the port number if one was specified (e.g., "example.com:8088").
zh_HANS-CN: 网络凭证的远程主机名。 如果指定了端口号，这包括端口号（例如，"example.com:8088"）。

note: type: Plain text
en: The path with which the credential will be used. E.g., for accessing a remote https repository, this will be the repository's path on the server.
zh_HANS-CN: 证书将被使用的路径。例如，对于访问远程 https 版本库，这将是服务器上版本库的路径。

note: type: Plain text
en: The credential's username, if we already have one (e.g., from a URL, the configuration, the user, or from a previously run helper).
zh_HANS-CN: 证书的用户名，如果我们已经有了一个（例如，从URL、配置、用户，或从先前运行的帮助器）。

note: type: Plain text
en: The credential's password, if we are asking it to be stored.
zh_HANS-CN: 凭证的密码，如果我们要求它被存储。

note: type: Plain text
en: Generated passwords such as an OAuth access token may have an expiry date.  When reading credentials from helpers, `git credential fill` ignores expired passwords. Represented as Unix time UTC, seconds since 1970.
zh_HANS-CN: 生成的密码，如 OAuth 访问令牌，可能有一个过期日期。 当从助手那里读取凭证时，`git credential fill` 会忽略过期的密码。表示为 Unix 时间 UTC，自 1970 年以来的秒数。

note: type: Plain text
en: An OAuth refresh token may accompany a password that is an OAuth access token. Helpers must treat this attribute as confidential like the password attribute. Git itself has no special behaviour for this attribute.
zh_HANS-CN: 一个 OAuth 刷新令牌可以伴随着一个 OAuth 访问令牌的密码。帮助者必须像密码属性一样，将此属性视为机密。Git 本身对这个属性没有特殊行为。

note: type: Plain text
en: When this special attribute is read by `git credential`, the value is parsed as a URL and treated as if its constituent parts were read (e.g., `url=https://example.com` would behave as if `protocol=https` and `host=example.com` had been provided). This can help callers avoid parsing URLs themselves.
zh_HANS-CN: 当这个特殊属性被 `git credential` 读取时，该值被解析为一个 URL，并被当作其组成部分来处理（例如，`url=_00` 的行为就如同提供了 `protocol=https` 和 `host=example.com`）。这可以帮助调用者避免自己解析 URL。

note: type: Plain text
en: Note that specifying a protocol is mandatory and if the URL doesn't specify a hostname (e.g., "cert:///path/to/file") the credential will contain a hostname attribute whose value is an empty string.
zh_HANS-CN: 请注意，指定协议是强制性的，如果 URL 没有指定主机名（例如，"cert:///path/to/file"），证书将包含一个主机名属性，其值是一个空字符串。

note: type: Plain text
en: Components which are missing from the URL (e.g., there is no username in the example above) will be left unset.
zh_HANS-CN: URL 中缺少的组件（例如，上面的例子中没有用户名）将不被设置。

note: type: Plain text
en: When an HTTP response is received by Git that includes one or more 'WWW-Authenticate' authentication headers, these will be passed by Git to credential helpers.
zh_HANS-CN: 当 Git 收到包含一个或多个 "WWW-Authenticate" 认证头的 HTTP 响应时，这些头将被 Git 传递给证书助手。

note: type: Plain text
en: Each 'WWW-Authenticate' header value is passed as a multi-valued attribute 'wwwauth[]', where the order of the attributes is the same as they appear in the HTTP response. This attribute is 'one-way' from Git to pass additional information to credential helpers.
zh_HANS-CN: 每个 'WWW-Authenticate' 头的值都以多值属性 'wwwauth[]' 的形式传递，其中属性的顺序与它们在 HTTP 响应中出现的一样。这个属性是 Git 的 'one-way' 属性，用于传递额外的信息给证书助手。

note: type: Plain text
en: Unrecognised attributes are silently discarded.
zh_HANS-CN: 未识别的属性会被默默地丢弃。

note: type: Plain text
en: git-cvsexportcommit - Export a single commit to a CVS checkout
zh_HANS-CN: git-cvsexportcommit - 将单个提交导出为 CVS 检出

note: type: Plain text
en: 'git cvsexportcommit' [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d <cvsroot>]
    	[-w <cvs-workdir>] [-W] [-f] [-m <msgprefix>] [<parent-commit>] <commit-id>
zh_HANS-CN: 'git cvsexportcommit' [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d <CVS 根>]
    	[-w <CVS 工作目录>] [-W] [-f] [-m <消息前缀>] [<父提交>] <提交 ID>

note: type: Plain text
en: Exports a commit from Git to a CVS checkout, making it easier to merge patches from a Git repository into a CVS repository.
zh_HANS-CN: 将提交从 Git 导出到 CVS 检出，从而更轻松地将补丁从 Git 仓库合并到 CVS 仓库。

note: type: Plain text
en: Specify the name of a CVS checkout using the -w switch or execute it from the root of the CVS working copy. In the latter case GIT_DIR must be defined. See examples below.
zh_HANS-CN: 使用 -w 开关指定 CVS 检出的名称，或从 CVS 工作副本的根目录执行。在后一种情况下，必须定义 GIT_DIR。请参阅下面的示例。

note: type: Plain text
en: It does its best to do the safe thing, it will check that the files are unchanged and up to date in the CVS checkout, and it will not autocommit by default.
zh_HANS-CN: 它会尽最大努力做到安全，它会检查文件是否在 CVS 签出中保持不变且是最新的，而且默认情况下不会自动提交。

note: type: Plain text
en: Supports file additions, removals, and commits that affect binary files.
zh_HANS-CN: 支持影响二进制文件的文件添加、删除和提交。

note: type: Plain text
en: If the commit is a merge commit, you must tell 'git cvsexportcommit' what parent the changeset should be done against.
zh_HANS-CN: 如果该提交是合并提交，则必须告诉 'git cvsexportcommit' 该变更集应针对哪个父级提交。

note: type: Plain text
en: Commit automatically if the patch applied cleanly. It will not commit if any hunks fail to apply or there were other problems.
zh_HANS-CN: 如果补丁应用无误，则自动提交。如果有任何缺口未能应用或出现其他问题，则不会提交。

note: type: Plain text
en: Be pedantic (paranoid) when applying patches. Invokes patch with --fuzz=0
zh_HANS-CN: 打补丁时要迂腐（偏执）。以 --fuzz=0 调用补丁

note: type: Plain text
en: Add authorship information. Adds Author line, and Committer (if different from Author) to the message.
zh_HANS-CN: 添加作者信息。在邮件中添加作者行和提交者（如果与作者不同）。

note: type: Plain text
en: Set an alternative CVSROOT to use.  This corresponds to the CVS -d parameter.  Usually users will not want to set this, except if using CVS in an asymmetric fashion.
zh_HANS-CN: 设置要使用的另一个 CVSROOT。  这相当于 CVS -d 参数。  通常情况下，除非以非对称方式使用 CVS，否则用户不会希望设置该参数。

note: type: Plain text
en: Force the merge even if the files are not up to date.
zh_HANS-CN: 即使文件不是最新的，也可强制合并。

note: type: Plain text
en: Force the parent commit, even if it is not a direct parent.
zh_HANS-CN: 强制父提交，即使它不是直接父代。

note: type: Plain text
en: Prepend the commit message with the provided prefix.  Useful for patch series and the like.
zh_HANS-CN: 用提供的前缀作为提交信息的前缀。  适用于补丁系列等。

note: type: Plain text
en: Update affected files from CVS repository before attempting export.
zh_HANS-CN: 在尝试导出之前，更新 CVS 仓库中受影响的文件。

note: type: Plain text
en: Reverse CVS keyword expansion (e.g. $Revision: 1.2.3.4$ becomes $Revision$) in working CVS checkout before applying patch.
zh_HANS-CN: 在应用补丁之前，在工作的 CVS 签出中反转 CVS 关键字扩展（例如，$Revision: 1.2.3.4$ 变为 $Revision$）。

note: type: Plain text
en: Specify the location of the CVS checkout to use for the export. This option does not require GIT_DIR to be set before execution if the current directory is within a Git repository.  The default is the value of 'cvsexportcommit.cvsdir'.
zh_HANS-CN: 指定用于导出的 CVS 签出位置。如果当前目录位于 Git 仓库中，则执行前无需设置 GIT_DIR。  默认值为 'cvsexportcommit.cvsdir'。

note: type: Plain text
en: Tell cvsexportcommit that the current working directory is not only a Git checkout, but also the CVS checkout.  Therefore, Git will reset the working directory to the parent commit before proceeding.
zh_HANS-CN: 告诉 cvsexportcommit 当前工作目录不仅是 Git 签出目录，也是 CVS 签出目录。  因此，Git 会在继续之前将工作目录重置为父提交。

note: type: Plain text
en: The default location of the CVS checkout to use for the export.
zh_HANS-CN: 用于导出的 CVS 签出的默认位置。

note: type: Labeled list
en: Merge one patch into CVS (-c and -w options). The working directory is within the Git Repo
zh_HANS-CN: 将一个补丁合并到 CVS（-c 和 -w 选项）。工作目录在 Git 仓库中

note: type: Labeled list
en: Merge pending patches into CVS automatically -- only if you really know what you are doing
zh_HANS-CN: 自动将待处理的补丁合并到 CVS ——只有当你真正了解自己在做什么时才会这样做

note: type: Plain text
en: git-cvsimport - Salvage your data out of another SCM people love to hate
zh_HANS-CN: git-cvsimport - 从另一个让人由爱生恨的 SCM 中获取数据

note: type: Plain text
en: 'git cvsimport' [-o <branch-for-HEAD>] [-h] [-v] [-d <CVSROOT>]
    	      [-A <author-conv-file>] [-p <options-for-cvsps>] [-P <file>]
    	      [-C <git-repository>] [-z <fuzz>] [-i] [-k] [-u] [-s <subst>]
    	      [-a] [-m] [-M <regex>] [-S <regex>] [-L <commit-limit>]
    	      [-r <remote>] [-R] [<CVS-module>]
zh_HANS-CN: 'git cvsimport' [-o <HEAD 分支>] [-h] [-v] [-d <CVSROOT>]
    	      [-A <author-conv-file>] [-p <options-for-cvsps>] [-P <文件>]
    	      [-C <Git 仓库>] [-z <fuzz>] [-i] [-k] [-u] [-s <subst>]
    	      [-a] [-m] [-M <正则表达式>] [-S <正则表达式>] [-L <提交范围>]
    	      [-r <远程仓库>] [-R] [<CVS 模块>]

note: type: Plain text
en: *WARNING:* `git cvsimport` uses cvsps version 2, which is considered
    deprecated; it does not work with cvsps version 3 and later.  If you are
    performing a one-shot import of a CVS repository consider using
    http://cvs2svn.tigris.org/cvs2git.html[cvs2git] or
    http://www.catb.org/esr/cvs-fast-export/[cvs-fast-export].
zh_HANS-CN: *警告：* `git cvsimport` 使用 cvsps 第 2 版，该版本已被视为弃用；
    它不能用于 cvsps 第 3 版及更高版本。  
    如果要一次性导入 CVS 仓库，
    请考虑使用 http://cvs2svn.tigris.org/cvs2git.html[cvs2git] 
    或 http://www.catb.org/esr/cvs-fast-export/[cvs-fast-export]。

note: type: Plain text
en: Imports a CVS repository into Git. It will either create a new repository, or incrementally import into an existing one.
zh_HANS-CN: 将 CVS 仓库导入 Git。它既可以创建一个新的仓库，也可以增量导入现有仓库。

note: type: Plain text
en: Splitting the CVS log into patch sets is done by 'cvsps'.  At least version 2.1 is required.
zh_HANS-CN: 将 CVS 日志分割成补丁集由 'cvsps' 完成。  至少需要 2.1 版本。

note: type: Plain text
en: *WARNING:* for certain situations the import leads to incorrect results.
    Please see the section <<issues,ISSUES>> for further reference.
zh_HANS-CN: *警告：* 在某些情况下，导入会导致不正确的结果。
    请参阅 <<issue,ISSUES>> 部分以获取更多参考。

note: type: Plain text
en: You should *never* do any work of your own on the branches that are created by 'git cvsimport'.  By default initial import will create and populate a "master" branch from the CVS repository's main branch which you're free to work with; after that, you need to 'git merge' incremental imports, or any CVS branches, yourself.  It is advisable to specify a named remote via -r to separate and protect the incoming branches.
zh_HANS-CN: 您*绝对不*应该在 'git cvsimport' 创建的分支上做任何自己的工作。  默认情况下，初始导入会从 CVS 仓库的主分支创建并填充一个 "master" 分支，您可以自由使用该分支；之后，您需要自己 'git merge' 增量导入或任何 CVS 分支。  建议通过 -r 指定一个命名的远程分支，以分隔和保护导入的分支。

note: type: Plain text
en: If you intend to set up a shared public repository that all developers can read/write, or if you want to use linkgit:git-cvsserver[1], then you probably want to make a bare clone of the imported repository, and use the clone as the shared repository.  See linkgit:gitcvs-migration[7].
zh_HANS-CN: 如果你打算建立一个所有开发者都能读写的共享公共仓库，或者如果你想使用 linkgit:git-cvsserver[1]，那么你可能想做一个导入仓库的裸克隆，并将该克隆作为共享仓库。  参见 linkgit:gitcvs-migration[7]。

note: type: Plain text
en: Verbosity: let 'cvsimport' report what it is doing.
zh_HANS-CN: Verbosity: 让 'cvsimport' 报告他正在做什么。

note: type: Plain text
en: The root of the CVS archive. May be local (a simple path) or remote; currently, only the :local:, :ext: and :pserver: access methods are supported. If not given, 'git cvsimport' will try to read it from `CVS/Root`. If no such file exists, it checks for the `CVSROOT` environment variable.
zh_HANS-CN: CVS 存档的根目录。可以是本地（简单路径）或远程；目前只支持 :local:、:ext: 和 :pserver: 访问方法。如果没有给出，'git cvsimport' 将尝试从 'CVS/Root' 中读取。如果没有此类文件，则会检查 `CVSROOT` 环境变量。

note: type: Plain text
en: The CVS module you want to import. Relative to <CVSROOT>.  If not given, 'git cvsimport' tries to read it from `CVS/Repository`.
zh_HANS-CN: 要导入的 CVS 模块。相对于 <CVSROOT>。  如果没有给出，/git cvsimport' 会尝试从 `CVS/Repository` 中读取。

note: type: Plain text
en: The Git remote to import this CVS repository into.  Moves all CVS branches into remotes/<remote>/<branch> akin to the way 'git clone' uses 'origin' by default.
zh_HANS-CN: 要导入此 CVS 仓库的 Git 远程仓库。  将所有 CVS 分支移至 remotes/<远程仓库>/<分支>，类似于 'git clone' 默认使用 'origin' 的方式。

note: type: Plain text
en: When no remote is specified (via -r) the `HEAD` branch from CVS is imported to the 'origin' branch within the Git repository, as `HEAD` already has a special meaning for Git.  When a remote is specified the `HEAD` branch is named remotes/<remote>/master mirroring 'git clone' behaviour.  Use this option if you want to import into a different branch.
zh_HANS-CN: 如果没有指定远程分支（通过 -r），CVS 中的 `HEAD` 分支会被导入 Git 仓库中的 'origin' 分支，因为 `HEAD` 对 Git 已经有了特殊含义。  如果指定了一个远程分支，`HEAD` 分支就会被命名为 remotes/<远程仓库>/master，以反映 'git clone' 行为。  如果要导入不同的分支，请使用此选项。

note: type: Plain text
en: Use '-o master' for continuing an import that was initially done by the old cvs2git tool.
zh_HANS-CN: 使用 '-o master' 继续导入最初由旧版 cvs2git 工具完成的导入。

note: type: Plain text
en: Import-only: don't perform a checkout after importing.  This option ensures the working directory and index remain untouched and will not create them if they do not exist.
zh_HANS-CN: 仅导入：导入后不执行检出。  该选项可确保工作目录和索引保持不变，如果不存在也不会创建。

note: type: Plain text
en: Kill keywords: will extract files with '-kk' from the CVS archive to avoid noisy changesets. Highly recommended, but off by default to preserve compatibility with early imported trees.
zh_HANS-CN: 杀死关键字：将从 CVS 存档中提取带有 '-kk' 的文件，以避免出现嘈杂的更改集。强烈建议使用，但默认为关闭，以保持与早期导入树的兼容性。

note: type: Plain text
en: Convert underscores in tag and branch names to dots.
zh_HANS-CN: 将标记和分支名称中的下划线转换为点。

note: type: Plain text
en: Substitute the character "/" in branch names with <subst>
zh_HANS-CN: 用 <subst> 代替分支名称中的字符"/"

note: type: Plain text
en: Additional options for cvsps.  The options `-u` and '-A' are implicit and should not be used here.
zh_HANS-CN: cvsps 的附加选项。  选项 `-u` 和 '-A' 是隐含的，不应在此使用。

note: type: Plain text
en: If you need to pass multiple options, separate them with a comma.
zh_HANS-CN: 如果需要传递多个选项，请用逗号分隔。

note: type: Plain text
en: Pass the timestamp fuzz factor to cvsps, in seconds. If unset, cvsps defaults to 300s.
zh_HANS-CN: 向 cvsps 传递时间戳模糊因子，单位为秒。如果未设置，cvsps 默认为 300 秒。

note: type: Labeled list
en: -P <cvsps-output-file>
zh_HANS-CN: -P <cvsps 输出文件>

note: type: Plain text
en: Instead of calling cvsps, read the provided cvsps output file. Useful for debugging or when cvsps is being handled outside cvsimport.
zh_HANS-CN: 不调用 cvsps，而是读取提供的 cvsps 输出文件。在调试或在 cvsimport 之外处理 cvsps 时非常有用。

note: type: Plain text
en: Attempt to detect merges based on the commit message. This option will enable default regexes that try to capture the source branch name from the commit message.
zh_HANS-CN: 尝试根据提交信息检测合并。该选项将启用默认的 regexes，尝试从提交信息中捕捉源分支名称。

note: type: Plain text
en: Attempt to detect merges based on the commit message with a custom regex. It can be used with `-m` to enable the default regexes as well. You must escape forward slashes.
zh_HANS-CN: 尝试使用自定义正则表达式根据提交信息检测合并。也可与 `-m` 搭配使用，启用默认的 regexes。必须转义为正斜杠。

note: type: Plain text
en: The regex must capture the source branch name in $1.
zh_HANS-CN: 正则表达式必须在 $1 中捕获源分支名称。

note: type: Plain text
en: This option can be used several times to provide several detection regexes.
zh_HANS-CN: 该选项可多次使用，以提供多个检测 regexes。

note: type: Labeled list
en: -S <regex>
zh_HANS-CN: -S <正则表达式>

note: type: Plain text
en: Skip paths matching the regex.
zh_HANS-CN: 跳过与正则表达式匹配的路径。

note: type: Plain text
en: Import all commits, including recent ones. cvsimport by default skips commits that have a timestamp less than 10 minutes ago.
zh_HANS-CN: cvsimport 默认跳过时间戳少于 10 分钟的提交。

note: type: Plain text
en: Limit the number of commits imported. Workaround for cases where cvsimport leaks memory.
zh_HANS-CN: 限制导入的提交次数。针对 cvsimport 泄露内存情况的解决方法。

note: type: Labeled list
en: -A <author-conv-file>
zh_HANS-CN: -A <作者的 conv 文件>

note: type: Plain text
en: CVS by default uses the Unix username when writing its commit logs. Using this option and an author-conv-file maps the name recorded in CVS to author name, e-mail and optional time zone:
zh_HANS-CN: CVS 在编写提交日志时默认使用 Unix 用户名。使用此选项和 author-conv 文件可将 CVS 中记录的姓名映射为作者姓名、电子邮件和可选的时区：

note: type: Plain text
en: For convenience, this data is saved to `$GIT_DIR/cvs-authors` each time the '-A' option is provided and read from that same file each time 'git cvsimport' is run.
zh_HANS-CN: 为方便起见，每次提供 '-A' 选项时，这些数据都会被保存到 `$GIT_DIR/cvs-authors` 中，每次运行 'git cvsimport' 时，都会从同一文件中读取这些数据。

note: type: Plain text
en: It is not recommended to use this feature if you intend to export changes back to CVS again later with 'git cvsexportcommit'.
zh_HANS-CN: 如果您打算稍后再用 'git cvsexportcommit' 将更改导出回 CVS，则不建议使用此功能。

note: type: Plain text
en: Generate a `$GIT_DIR/cvs-revisions` file containing a mapping from CVS revision numbers to newly-created Git commit IDs.  The generated file will contain one line for each (filename, revision) pair imported; each line will look like
zh_HANS-CN: 生成一个 `$GIT_DIR/cvs-revisions` 文件，其中包含从 CVS 版本号到新创建的 Git 提交 ID 的映射。  生成的文件将为导入的每一对（文件名、修订版）包含一行；每行看起来像

note: type: Plain text
en: The revision data is appended to the file if it already exists, for use when doing incremental imports.
zh_HANS-CN: 如果已存在修订数据，则会将其附加到文件中，以便在进行增量导入时使用。

note: type: Plain text
en: This option may be useful if you have CVS revision numbers stored in commit messages, bug-tracking systems, email archives, and the like.
zh_HANS-CN: 如果在提交信息、错误跟踪系统、电子邮件归档等中存储了 CVS 版本号，该选项可能会很有用。

note: type: Plain text
en: Print a short usage message and exit.
zh_HANS-CN: 打印简短的使用信息并退出。

note: type: Plain text
en: If `-v` is specified, the script reports what it is doing.
zh_HANS-CN: 如果指定了 `-v`，脚本会报告它正在做什么。

note: type: Plain text
en: Otherwise, success is indicated the Unix way, i.e. by simply exiting with a zero exit status.
zh_HANS-CN: 否则，将以 Unix 的方式表示成功，即直接以零退出状态退出。

note: type: Title -
en: ISSUES
zh_HANS-CN: 问题

note: type: Plain text
en: Problems related to timestamps:
zh_HANS-CN: 与时间戳有关的问题：

note: type: Plain text
en: If timestamps of commits in the CVS repository are not stable enough to be used for ordering commits changes may show up in the wrong order.
zh_HANS-CN: 如果 CVS 存储库中提交的时间戳不够稳定，无法用于对提交进行排序，则更改可能会以错误的顺序显示。

note: type: Plain text
en: If any files were ever "cvs import"ed more than once (e.g., import of more than one vendor release) the HEAD contains the wrong content.
zh_HANS-CN: 如果任何文件曾被多次 "cvs import"（如导入多个供应商发布的版本），则 HEAD 包含错误的内容。

note: type: Plain text
en: If the timestamp order of different files cross the revision order within the commit matching time window the order of commits may be wrong.
zh_HANS-CN: 如果在提交匹配时间窗口内，不同文件的时间戳顺序与修订顺序不一致，提交顺序可能会出错。

note: type: Plain text
en: Problems related to branches:
zh_HANS-CN: 与分支机构有关的问题:

note: type: Plain text
en: Branches on which no commits have been made are not imported.
zh_HANS-CN: 未提交的分支不会被导入。

note: type: Plain text
en: All files from the branching point are added to a branch even if never added in CVS.
zh_HANS-CN: 分支点的所有文件都会添加到分支中，即使从未在 CVS 中添加过。

note: type: Plain text
en: This applies to files added to the source branch *after* a daughter branch was created: if previously no commit was made on the daughter branch they will erroneously be added to the daughter branch in git.
zh_HANS-CN: 这适用于在创建子分支*之后*添加到源分支的文件：如果之前没有在子分支上提交，这些文件就会在 git 中被错误地添加到子分支上。

note: type: Plain text
en: Problems related to tags:
zh_HANS-CN: 与标签有关的问题：

note: type: Plain text
en: Multiple tags on the same revision are not imported.
zh_HANS-CN: 不会导入同一修订版上的多个标记。

note: type: Plain text
en: If you suspect that any of these issues may apply to the repository you want to import, consider using cvs2git:
zh_HANS-CN: 如果您怀疑要导入的仓库可能存在上述问题，请考虑使用 cvs2git：

note: type: Plain text
en: cvs2git (part of cvs2svn), `http://subversion.apache.org/`
zh_HANS-CN: cvs2git（cvs2svn 的一部分），`http://subversion.apache.org/`

note: type: Plain text
en: SSH:
zh_HANS-CN: {BASH_GNLV3_AMP}

note: type: Plain text
en: export CVS_SERVER="git cvsserver"
    'cvs' -d :ext:user@server/path/repo.git co <HEAD_name>
zh_HANS-CN: export CVS_SERVER="git cvsserver"
    'cvs' -d :ext:user@server/path/repo.git co <HEAD 名称>

note: type: Plain text
en: 'git-cvsserver' [<options>] [pserver|server] [<directory> ...]
zh_HANS-CN: 'git-cvsserver' [<多个选项>] [pserver|server] [<目录> ...]

note: type: Plain text
en: This application is a CVS emulation layer for Git.
zh_HANS-CN: 该程序是 Git 的 CVS 仿真层。

note: type: Plain text
en: It is highly functional. However, not all methods are implemented, and for those methods that are implemented, not all switches are implemented.
zh_HANS-CN: 它的功能性很强。然而，并非所有方法都能实现，而对于那些已实现的方法，并非所有开关都能实现。

note: type: Plain text
en: Testing has been done using both the CLI CVS client, and the Eclipse CVS plugin. Most functionality works fine with both of these clients.
zh_HANS-CN: 测试使用 CLI CVS 客户端和 Eclipse CVS 插件进行。大多数功能在这两个客户端上都能正常运行。

note: type: Plain text
en: All these options obviously only make sense if enforced by the server side.  They have been implemented to resemble the linkgit:git-daemon[1] options as closely as possible.
zh_HANS-CN: 所有这些选项显然只有在服务器端执行时才有意义。  这些选项的实现尽可能与 linkgit:git-daemon[1] 选项相似。

note: type: Plain text
en: Prepend 'path' to requested CVSROOT
zh_HANS-CN: 在请求的 CVSROOT 前加上 ‘路径’

note: type: Plain text
en: Don't allow recursing into subdirectories
zh_HANS-CN: 不允许递归到子目录中

note: type: Plain text
en: Don't check for `gitcvs.enabled` in config. You also have to specify a list of allowed directories (see below) if you want to use this option.
zh_HANS-CN: 不要在配置中检查 `gitcvs.enabled`。如果要使用此选项，还必须指定允许使用的目录列表（见下文）。

note: type: Plain text
en: Print usage information and exit
zh_HANS-CN: 打印使用信息并退出

note: type: Plain text
en: The remaining arguments provide a list of directories. If no directories are given, then all are allowed. Repositories within these directories still require the `gitcvs.enabled` config option, unless `--export-all` is specified.
zh_HANS-CN: 其余参数提供了一个目录列表。如果没有给出目录，则允许所有目录。除非指定了 `--export-all`，否则这些目录中的仓库仍需要使用 `gitcvs.enabled` 配置选项。

note: type: Title -
en: LIMITATIONS
zh_HANS-CN: 局限

note: type: Plain text
en: CVS clients cannot tag, branch or perform Git merges.
zh_HANS-CN: CVS 客户端不能标记、分支或执行 Git 合并。

note: type: Plain text
en: If you are going to offer CVS access via pserver, add a line in /etc/inetd.conf like
zh_HANS-CN: 如果要通过 pserver 提供 CVS 访问，请在 /etc/inetd.conf 中添加一行，如

note: type: Plain text
en: Note: Some inetd servers let you specify the name of the executable independently of the value of argv[0] (i.e. the name the program assumes it was executed with). In this case the correct line in /etc/inetd.conf looks like
zh_HANS-CN: 注意：有些 inetd 服务器允许您独立于 argv[0] 的值（即程序假定执行的名称）指定可执行文件的名称。在这种情况下，/etc/inetd.conf 中的正确行应如下所示

note: type: Plain text
en: Only anonymous access is provided by pserver by default. To commit you will have to create pserver accounts, simply add a gitcvs.authdb setting in the config file of the repositories you want the cvsserver to allow writes to, for example:
zh_HANS-CN: pserver 默认只提供匿名访问。要提交您必须创建的 pserver 账户，只需在您希望 cvsserver 允许写入的软件源的配置文件中添加 gitcvs.authdb 设置即可，例如:

note: type: Plain text
en: The format of these files is username followed by the encrypted password, for example:
zh_HANS-CN: 例如，这些文件的格式是用户名，然后是加密密码:

note: type: Plain text
en: You can use the 'htpasswd' facility that comes with Apache to make these files, but only with the -d option (or -B if your system supports it).
zh_HANS-CN: 您可以使用 Apache 自带的 'htpasswd' 工具来创建这些文件，但只能使用 -d 选项（如果您的系统支持 -B）。

note: type: Plain text
en: Preferably use the system specific utility that manages password hash creation in your platform (e.g. mkpasswd in Linux, encrypt in OpenBSD or pwhash in NetBSD) and paste it in the right location.
zh_HANS-CN: 最好使用在您的平台上管理密码哈希创建的特定系统实用程序（例如 Linux 中的 mkpasswd、OpenBSD 中的 encrypt 或 NetBSD 中的 pwhash），然后将其粘贴到正确的位置。

note: type: Plain text
en: Then provide your password via the pserver method, for example:
zh_HANS-CN: 然后通过 pserver 方法提供密码，例如:

note: type: Plain text
en: No special setup is needed for SSH access, other than having Git tools in the PATH. If you have clients that do not accept the CVS_SERVER environment variable, you can rename 'git-cvsserver' to `cvs`.
zh_HANS-CN: SSH 访问无需特殊设置，只需在 PATH 中安装 Git 工具即可。如果客户端不接受 CVS_SERVER 环境变量，可以将 'git-cvsserver' 更名为 `cvs`。

note: type: Plain text
en: Note: Newer CVS versions (>= 1.12.11) also support specifying CVS_SERVER directly in CVSROOT like
zh_HANS-CN: 注意：较新的 CVS 版本（>= 1.12.11）也支持直接在 CVSROOT 中指定 CVS_SERVER，如

note: type: Plain text
en: This has the advantage that it will be saved in your 'CVS/Root' files and you don't need to worry about always setting the correct environment variable.  SSH users restricted to 'git-shell' don't need to override the default with CVS_SERVER (and shouldn't) as 'git-shell' understands `cvs` to mean 'git-cvsserver' and pretends that the other end runs the real 'cvs' better.
zh_HANS-CN: 这样做的好处是，它将保存在你的 'CVS/Root' 文件中，你不必担心总是设置正确的环境变量。  受限于 'git-shell' 的 SSH 用户不需要（也不应该）用 CVS_SERVER 覆盖默认值，因为 'git-shell' 会将 `cvs` 理解为 'git-cvsserver'，并假装另一端运行的是真正的 'cvs'。

note: type: Plain text
en: For each repo that you want accessible from CVS you need to edit config in the repo and add the following section.
zh_HANS-CN: 对于希望从 CVS 访问的每个仓库，都需要在仓库中编辑配置并添加以下部分。

note: type: Plain text
en: Note: you need to ensure each user that is going to invoke 'git-cvsserver' has write access to the log file and to the database (see <<dbbackend,Database Backend>>. If you want to offer write access over SSH, the users of course also need write access to the Git repository itself.
zh_HANS-CN: 注意：需要确保每个调用 'git-cvsserver' 的用户都有写入日志文件和数据库的权限（参见 <<dbbackend,数据库后台>>）。如果要通过 SSH 提供写访问权限，用户当然也需要有写访问 Git 仓库本身的权限。

note: type: Plain text
en: You also need to ensure that each repository is "bare" (without a Git index file) for `cvs commit` to work. See linkgit:gitcvs-migration[7].
zh_HANS-CN: 你还需要确保每个仓库都是 "裸仓库"（没有 Git 索引文件），这样 `cvs commit` 才能工作。参见 linkgit:gitcvs-migration[7]。

note: type: Plain text
en: All configuration variables can also be overridden for a specific method of access. Valid method names are "ext" (for SSH access) and "pserver". The following example configuration would disable pserver access while still allowing access over SSH.
zh_HANS-CN: 所有配置变量都可以针对特定的访问方法进行重载。有效的方法名称是 "ext"（用于 SSH 访问）和 "pserver"。下面的配置示例将禁止 pserver 访问，但仍允许通过 SSH 访问。

note: type: Plain text
en: If you didn't specify the CVSROOT/CVS_SERVER directly in the checkout command, automatically saving it in your 'CVS/Root' files, then you need to set them explicitly in your environment.  CVSROOT should be set as per normal, but the directory should point at the appropriate Git repo.  As above, for SSH clients _not_ restricted to 'git-shell', CVS_SERVER should be set to 'git-cvsserver'.
zh_HANS-CN: 如果您没有在签出命令中直接指定 CVSROOT/CVS_SERVER，而是将其自动保存在 'CVS/Root' 文件中，那么您就需要在环境中明确设置它们。  CVSROOT 应按常规设置，但目录应指向相应的 Git 仓库。  如上所述，对于不受限于 'git-shell' 的 SSH 客户端，CVS_SERVER 应设置为 'git-cvsserver'。

note: type: Plain text
en: For SSH clients that will make commits, make sure their server-side .ssh/environment files (or .bashrc, etc., according to their specific shell)  export appropriate values for GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_COMMITTER_NAME, and GIT_COMMITTER_EMAIL.  For SSH clients whose login shell is bash, .bashrc may be a reasonable alternative.
zh_HANS-CN: 对于会进行提交的 SSH 客户端，请确保其服务器端的 .ssh/environment 文件（或 .bashrc 等，根据其特定的 shell）导出了适当的 GIT_AUTHOR_NAME、GIT_AUTHOR_EMAIL、GIT_COMMITTER_NAME 和 GIT_COMMITTER_EMAIL 值。  对于登录 shell 为 bash 的 SSH 客户端，.bashrc 可能是一个合理的替代方案。

note: type: Plain text
en: Clients should now be able to check out the project. Use the CVS 'module' name to indicate what Git 'head' you want to check out.  This also sets the name of your newly checked-out directory, unless you tell it otherwise with `-d <dir_name>`.  For example, this checks out 'master' branch to the `project-master` directory:
zh_HANS-CN: 客户现在应该可以签出项目了。使用 CVS 'module'（模块）名称来指明你要签出的 Git 'head'（头）。  这也会设置新签出目录的名称，除非你用 `-d <目录名>` 另作说明。  例如，这将签出 'master' 分支到 `project-master` 目录：

note: type: Title -
en: DATABASE BACKEND
zh_HANS-CN: 数据库后台

note: type: Plain text
en: If the commit is done directly by using `git` (as opposed to using 'git-cvsserver') the update will need to happen on the next repository access by 'git-cvsserver', independent of access method and requested operation.
zh_HANS-CN: 如果直接使用 `git`（而不是使用 'git-cvsserver'）提交，则更新需要在下一次使用 'git-cvsserver' 访问仓库时进行，与访问方式和请求的操作无关。

note: type: Plain text
en: That means that even if you offer only read access (e.g. by using the pserver method), 'git-cvsserver' should have write access to the database to work reliably (otherwise you need to make sure that the database is up to date any time 'git-cvsserver' is executed).
zh_HANS-CN: 这就意味着，即使只提供读取访问权限（例如使用 pserver 方法），'git-cvsserver' 也必须拥有对数据库的写入访问权限，才能可靠地工作（否则就需要确保在执行 'git-cvsserver' 的任何时候数据库都是最新的）。

note: type: Plain text
en: By default it uses SQLite databases in the Git directory, named `gitcvs.<module_name>.sqlite`. Note that the SQLite backend creates temporary files in the same directory as the database file on write so it might not be enough to grant the users using 'git-cvsserver' write access to the database file without granting them write access to the directory, too.
zh_HANS-CN: 默认情况下，它使用 Git 目录中的 SQLite 数据库，名为 `gitcvs.<模块名>.sqlite`。请注意，SQLite 后端在写入时会在与数据库文件相同的目录下创建临时文件，因此只授予使用 'git-cvsserver' 的用户对数据库文件的写入权限，而不授予他们对目录的写入权限可能是不够的。

note: type: Plain text
en: The database cannot be reliably regenerated in a consistent form after the branch it is tracking has changed.  Example: For merged branches, 'git-cvsserver' only tracks one branch of development, and after a 'git merge' an incrementally updated database may track a different branch than a database regenerated from scratch, causing inconsistent CVS revision numbers. `git-cvsserver` has no way of knowing which branch it would have picked if it had been run incrementally pre-merge. So if you have to fully or partially (from old backup) regenerate the database, you should be suspicious of pre-existing CVS sandboxes.
zh_HANS-CN: 跟踪的分支发生变化后，数据库无法以一致的形式可靠地重新生成。  例如对于合并的分支，'git-cvsserver' 只能跟踪一个开发分支，而在 'git merge' 之后，增量更新的数据库可能会与从头开始生成的数据库跟踪不同的分支，从而导致 CVS 版本号不一致。如果在合并前增量运行，`git-cvsserver` 无法知道自己会选择哪个分支。因此，如果你必须全部或部分（从旧备份）重新生成数据库，你就应该对已经存在的 CVS 沙箱有所怀疑。

note: type: Plain text
en: You can configure the database backend with the following configuration variables:
zh_HANS-CN: 您可以使用以下配置变量配置数据库后台：

note: type: Title ~
en: Configuring database backend
zh_HANS-CN: 配置数据库后台

note: type: Plain text
en: Database name. The exact meaning depends on the selected database driver, for SQLite this is a filename.  Supports variable substitution (see below). May not contain semicolons (`;`).  Default: '%Ggitcvs.%m.sqlite'
zh_HANS-CN: 数据库名称。具体含义取决于所选的数据库驱动程序，对于 SQLite，这是一个文件名。  支持变量替换（见下文）。不得包含分号 (`;`)。  默认：'%Ggitcvs.%m.sqlite'

note: type: Plain text
en: Used DBI driver. You can specify any available driver for this here, but it might not work. cvsserver is tested with 'DBD::SQLite', reported to work with 'DBD::Pg', and reported *not* to work with 'DBD::mysql'.  Please regard this as an experimental feature. May not contain colons (`:`).  Default: 'SQLite'
zh_HANS-CN: 使用的 DBI 驱动程序。cvsserver 已使用 'DBD::SQLite' 进行了测试，据报告可使用 'DBD::Pg'，但*不*能使用 'DBD::mysql'。  请将其视为试验性功能。不得包含冒号 (`:`)。  默认：'SQLite'

note: type: Plain text
en: Database user. Only useful if setting `dbDriver`, since SQLite has no concept of database users. Supports variable substitution (see below).
zh_HANS-CN: 数据库用户。只有在设置 `dbDriver` 时才有用，因为 SQLite 没有数据库用户的概念。支持变量替换（见下文）。

note: type: Plain text
en: Database password.  Only useful if setting `dbDriver`, since SQLite has no concept of database passwords.
zh_HANS-CN: 数据库密码。  只有在设置 `dbDriver` 时才有用，因为 SQLite 没有数据库密码的概念。

note: type: Plain text
en: Database table name prefix.  Supports variable substitution (see below).  Any non-alphabetic characters will be replaced with underscores.
zh_HANS-CN: 数据库表名前缀。  支持变量替换（见下文）。  任何非字母字符都将用下划线代替。

note: type: Plain text
en: All variables can also be set per access method, see <<configaccessmethod,above>>.
zh_HANS-CN: 所有变量也可按访问方法设置，请参阅<<configaccessmethod,上文>>。

note: type: Title ^
en: Variable substitution
zh_HANS-CN: 变量替换

note: type: Plain text
en: In `dbDriver` and `dbUser` you can use the following variables:
zh_HANS-CN: 在 `dbDriver` 和 `dbUser` 中，可以使用以下变量：

note: type: Plain text
en: Git directory name
zh_HANS-CN: Git 目录名称

note: type: Plain text
en: Git directory name, where all characters except for alphanumeric ones, `.`, and `-` are replaced with `_` (this should make it easier to use the directory name in a filename if wanted)
zh_HANS-CN: Git 目录名称，其中除字母数字、`.` 和 `-` 之外的所有字符均替换为 `_`（这样可以方便在文件名中使用该目录名称）

note: type: Plain text
en: CVS module/Git head name
zh_HANS-CN: CVS 模块/Git 头名称

note: type: Plain text
en: access method (one of "ext" or "pserver")
zh_HANS-CN: 访问方法（"ext" 或 "pserver" 之一）

note: type: Plain text
en: Name of the user running 'git-cvsserver'.  If no name can be determined, the numeric uid is used.
zh_HANS-CN: 运行 'git-cvsserver' 的用户名。  如果无法确定用户名，则使用数字 uid。

note: type: Plain text
en: These variables obviate the need for command-line options in some circumstances, allowing easier restricted usage through git-shell.
zh_HANS-CN: 在某些情况下，这些变量省去了命令行选项，从而可以通过 git-shell 更方便地限制使用。

note: type: Plain text
en: This variable replaces the argument to --base-path.
zh_HANS-CN: 该变量取代 --base-path 的参数。

note: type: Plain text
en: This variable specifies a single directory, replacing the `<directory>...` argument list. The repository still requires the `gitcvs.enabled` config option, unless `--export-all` is specified.
zh_HANS-CN: 该变量指定了一个单一目录，取代了 `<目录>...` 参数列表。除非指定了 `--export-all`，否则仓库仍需要使用 `gitcvs.enabled` 配置选项。

note: type: Plain text
en: When these environment variables are set, the corresponding command-line arguments may not be used.
zh_HANS-CN: 设置这些环境变量后，可能无法使用相应的命令行参数。

note: type: Title -
en: ECLIPSE CVS CLIENT NOTES
zh_HANS-CN: ECLIPSE CVS 客户端说明

note: type: Plain text
en: To get a checkout with the Eclipse CVS client:
zh_HANS-CN: 使用 Eclipse CVS 客户端进行签出：

note: type: Plain text
en: Select "Create a new project -> From CVS checkout"
zh_HANS-CN: 选择 "创建新项目 -> 从 CVS 签出"

note: type: Plain text
en: Create a new location. See the notes below for details on how to choose the right protocol.
zh_HANS-CN: 创建新位置。有关如何选择正确协议的详细信息，请参阅下面的说明。

note: type: Plain text
en: Browse the 'modules' available. It will give you a list of the heads in the repository. You will not be able to browse the tree from there. Only the heads.
zh_HANS-CN: 浏览可用的 "模块"。它将为你提供一份软件源中的模块头列表。在这里，你无法浏览模块树。只能浏览头部。

note: type: Plain text
en: Pick `HEAD` when it asks what branch/tag to check out. Untick the "launch commit wizard" to avoid committing the .project file.
zh_HANS-CN: 在询问要签出哪个分支/标记时，选择 `HEAD`。取消勾选 "launch commit wizard" （登录后提交）以避免提交 .project 文件。

note: type: Plain text
en: Protocol notes: If you are using anonymous access via pserver, just select that.  Those using SSH access should choose the 'ext' protocol, and configure 'ext' access on the Preferences->Team->CVS->ExtConnection pane. Set CVS_SERVER to "`git cvsserver`". Note that password support is not good when using 'ext', you will definitely want to have SSH keys setup.
zh_HANS-CN: 协议说明：如果通过 pserver 使用匿名访问，只需选择该协议即可。  使用 SSH 访问的用户应选择 'ext' 协议，并在 偏好设置->团队->CVS->外部连接 窗格中配置 'ext' 访问。将 CVS_SERVER 设置为 "`git cvsserver`"。请注意，使用 'ext' 时不支持密码，因此一定要设置 SSH 密钥。

note: type: Plain text
en: Alternatively, you can just use the non-standard extssh protocol that Eclipse offer. In that case CVS_SERVER is ignored, and you will have to replace the cvs utility on the server with 'git-cvsserver' or manipulate your `.bashrc` so that calling 'cvs' effectively calls 'git-cvsserver'.
zh_HANS-CN: 或者，你也可以使用 Eclipse 提供的非标准 extssh 协议。在这种情况下，CVS_SERVER 会被忽略，你必须用 'git-cvsserver' 替换服务器上的 cvs 工具，或者修改你的 `.bashrc` 以便调用 'cvs' 时能有效地调用 'git-cvsserver'。

note: type: Title -
en: CLIENTS KNOWN TO WORK
zh_HANS-CN: 已知工作的客户

note: type: Plain text
en: CVS 1.12.9 on Debian
zh_HANS-CN: 在 Debian 上的 CVS 1.12.9

note: type: Plain text
en: CVS 1.11.17 on MacOSX (from Fink package)
zh_HANS-CN: MacOSX 上的 CVS 1.11.17（来自 Fink 软件包）

note: type: Plain text
en: Eclipse 3.0, 3.1.2 on MacOSX (see Eclipse CVS Client Notes)
zh_HANS-CN: MacOSX 上的 Eclipse 3.0、3.1.2（参见 Eclipse CVS 客户端说明）

note: type: Title -
en: OPERATIONS SUPPORTED
zh_HANS-CN: 支持的业务

note: type: Plain text
en: All the operations required for normal use are supported, including checkout, diff, status, update, log, add, remove, commit.
zh_HANS-CN: 支持正常使用所需的所有操作，包括签出、差异、状态、更新、日志、添加、删除、提交。

note: type: Plain text
en: Most CVS command arguments that read CVS tags or revision numbers (typically -r) work, and also support any git refspec (tag, branch, commit ID, etc).  However, CVS revision numbers for non-default branches are not well emulated, and cvs log does not show tags or branches at all.  (Non-main-branch CVS revision numbers superficially resemble CVS revision numbers, but they actually encode a git commit ID directly, rather than represent the number of revisions since the branch point.)
zh_HANS-CN: 大多数 CVS 命令参数都能读取 CVS 标签或版本号（通常是 -r），而且还支持任何 git refspec（标签、分支、提交 ID 等）。  不过，非默认分支的 CVS 版本号并不能很好地模拟，而且 cvs log 根本不会显示标签或分支。  (非主分支的 CVS 版本号表面上与 CVS 版本号相似，但实际上它们直接编码了 git 的提交 ID，而不是代表自分支点以来的修订次数。）

note: type: Plain text
en: Note that there are two ways to checkout a particular branch.  As described elsewhere on this page, the "module" parameter of cvs checkout is interpreted as a branch name, and it becomes the main branch.  It remains the main branch for a given sandbox even if you temporarily make another branch sticky with cvs update -r.  Alternatively, the -r argument can indicate some other branch to actually checkout, even though the module is still the "main" branch.  Tradeoffs (as currently implemented): Each new "module" creates a new database on disk with a history for the given module, and after the database is created, operations against that main branch are fast.  Or alternatively, -r doesn't take any extra disk space, but may be significantly slower for many operations, like cvs update.
zh_HANS-CN: 请注意，有两种方法可以检出特定分支。  正如本页其他地方所述，cvs checkout 的 "模型" 参数会被解释为分支名称，并成为主分支。  即使使用 cvs update -r 将另一个分支暂时置为主干分支，它仍是指定沙盒的主干分支。  或者，-r 参数也可以指示实际签出的其他分支，即使模块仍是 "主" 分支。  权衡（目前的实现方式）：每个新的 "模块" 都会在磁盘上创建一个新的数据库，其中包含给定模块的历史记录。  或者，-r 不会占用任何额外的磁盘空间，但在许多操作（如 cvs 更新）上可能会明显慢一些。

note: type: Plain text
en: If you want to refer to a git refspec that has characters that are not allowed by CVS, you have two options.  First, it may just work to supply the git refspec directly to the appropriate CVS -r argument; some CVS clients don't seem to do much sanity checking of the argument.  Second, if that fails, you can use a special character escape mechanism that only uses characters that are valid in CVS tags.  A sequence of 4 or 5 characters of the form (underscore (`"_"`), dash (`"-"`), one or two characters, and dash (`"-"`)) can encode various characters based on the one or two letters: `"s"` for slash (`"/"`), `"p"` for period (`"."`), `"u"` for underscore (`"_"`), or two hexadecimal digits for any byte value at all (typically an ASCII number, or perhaps a part of a UTF-8 encoded character).
zh_HANS-CN: 如果要引用的 git refspec 包含 CVS 不允许的字符，有两种选择。  首先，直接向相应的 CVS -r 参数提供 git refspec 可能行得通；有些 CVS 客户端似乎不会对参数进行太多的正确性检查。  其次，如果方法失败，可以使用一种特殊的字符转义机制，它只使用 CVS 标记中有效的字符。  由 4 或 5 个字符（下划线 (`"_"`) 、破折号 (`"-"`)、一个或两个字符和破折号 (`"-"`)）组成的序列可以根据一个或两个字母编码各种字符：`"s"`表示斜线 (`"/"`)，`"p"`表示句号 (`"."`)，`"u"` 表示下划线 (`"_"`)，或者两个十六进制数字表示任何字节值（通常是 ASCII 数字，也可能是 UTF-8 编码字符的一部分）。

note: type: Plain text
en: Legacy monitoring operations are not supported (edit, watch and related).  Exports and tagging (tags and branches) are not supported at this stage.
zh_HANS-CN: 不支持传统的监控操作（编辑、监视和相关）。  现阶段不支持导出和标记（标记和分支）。

note: type: Title ~
en: CRLF Line Ending Conversions
zh_HANS-CN: CRLF 行尾转换

note: type: Plain text
en: By default the server leaves the `-k` mode blank for all files, which causes the CVS client to treat them as a text files, subject to end-of-line conversion on some platforms.
zh_HANS-CN: 默认情况下，服务器会将所有文件的 `-k` 模式留空，这将导致 CVS 客户端将这些文件视为文本文件，并在某些平台上进行行尾转换。

note: type: Plain text
en: You can make the server use the end-of-line conversion attributes to set the `-k` modes for files by setting the `gitcvs.usecrlfattr` config variable.  See linkgit:gitattributes[5] for more information about end-of-line conversion.
zh_HANS-CN: 通过设置 `gitcvs.usecrlfattr` 配置变量，可以让服务器使用行尾转换属性来设置文件的 `k` 模式。  有关行尾转换的更多信息，请参阅 linkgit:gitattributes[5]。

note: type: Plain text
en: Alternatively, if `gitcvs.usecrlfattr` config is not enabled or the attributes do not allow automatic detection for a filename, then the server uses the `gitcvs.allBinary` config for the default setting.  If `gitcvs.allBinary` is set, then file not otherwise specified will default to '-kb' mode. Otherwise the `-k` mode is left blank. But if `gitcvs.allBinary` is set to "guess", then the correct `-k` mode will be guessed based on the contents of the file.
zh_HANS-CN: 另外，如果未启用 `gitcvs.usecrlfattr` 配置或属性不允许自动检测文件名，则服务器将使用 `gitcvs.allBinary` 配置作为默认设置。  如果设置了 `gitcvs.allBinary`，则未指定的文件将默认为 '-kb' 模式。否则，`-k` 模式将留空。但如果将 `gitcvs.allBinary` 设置为 "guess"（猜测），则将根据文件内容猜测正确的 `k` 模式。

note: type: Plain text
en: For best consistency with 'cvs', it is probably best to override the defaults by setting `gitcvs.usecrlfattr` to true, and `gitcvs.allBinary` to "guess".
zh_HANS-CN: 为了与 'cvs' 保持一致，最好将 `gitcvs.usecrlfattr` 设为 true，将 `gitcvs.allBinary` 设为 "guess"，从而覆盖默认值。

note: type: Title -
en: DEPENDENCIES
zh_HANS-CN: 依赖

note: type: Plain text
en: git-daemon - A really simple server for Git repositories
zh_HANS-CN: git-daemon - 一个非常简单的git存储库服务器。

note: type: Plain text
en: A really simple TCP Git daemon that normally listens on port "DEFAULT_GIT_PORT" aka 9418.  It waits for a connection asking for a service, and will serve that service if it is enabled.
zh_HANS-CN: 一个非常简单的 TCP Git 守护进程，通常在端口 "DEFAULT_GIT_PORT"（即 9418）上进行监听。 它等待一个要求提供服务的连接，如果该服务被启用，它将提供服务。

note: type: Plain text
en: It verifies that the directory has the magic file "git-daemon-export-ok", and it will refuse to export any Git directory that hasn't explicitly been marked for export this way (unless the `--export-all` parameter is specified). If you pass some directory paths as 'git daemon' arguments, the offers are limited to repositories within those directories.
zh_HANS-CN: 它验证该目录是否有神奇的文件 "git-daemon-export-ok"，它将拒绝导出任何没有明确标记为这种方式导出的 Gi t目录（除非指定 `--export-all` 参数）。如果你把一些目录路径作为 "git daemon" 参数传递，那么提供的内容就会被限制在这些目录内的仓库。

note: type: Plain text
en: By default, only `upload-pack` service is enabled, which serves 'git fetch-pack' and 'git ls-remote' clients, which are invoked from 'git fetch', 'git pull', and 'git clone'.
zh_HANS-CN: 默认情况下，只有 "upload-pack "服务被启用，它为 "git fetch-pack" 和 "git ls-remote" 客户端服务，这些客户端是由 "git fetch"、"git pull" 和 "git clone " 调用的。

note: type: Plain text
en: This is ideally suited for read-only updates, i.e., pulling from Git repositories.
zh_HANS-CN: 这非常适合于只读更新，即从 Git 仓库拉取。

note: type: Plain text
en: An `upload-archive` also exists to serve 'git archive'.
zh_HANS-CN: 还存在一个 `upload-archive`，为 'git archive' 服务。

note: type: Plain text
en: Match paths exactly (i.e. don't allow "/foo/repo" when the real path is "/foo/repo.git" or "/foo/repo/.git") and don't do user-relative paths.  'git daemon' will refuse to start when this option is enabled and no directory arguments are provided.
zh_HANS-CN: 准确匹配路径（即不允许 "/foo/repo"，而真正的路径是 "/foo/repo.git " 或 "/foo/repo/.git"），不做与用户相关的路径。 当这个选项被启用并且没有提供目录参数时，"git daemon" 将拒绝启动。

note: type: Plain text
en: Remap all the path requests as relative to the given path.  This is sort of "Git root" - if you run 'git daemon' with '--base-path=/srv/git' on example.com, then if you later try to pull 'git://example.com/hello.git', 'git daemon' will interpret the path as `/srv/git/hello.git`.
zh_HANS-CN: 将所有的路径请求重新映射为相对于给定路径的请求。 这有点像 "Git root"--如果你在 example.com 上用 '-base-path=/srv/git' 运行 'git daemon'，那么如果你以后试图拉 'git://example.com/hello.git'，'git daemon' 将把路径解释为 `/srv/git/hello.git`。

note: type: Plain text
en: If --base-path is enabled and repo lookup fails, with this option 'git daemon' will attempt to lookup without prefixing the base path.  This is useful for switching to --base-path usage, while still allowing the old paths.
zh_HANS-CN: 如果启用了 --base-path，并且 repo 查找失败，使用这个选项，'git daemon' 将尝试在不加前缀的基础路径下进行查找。 这对于切换到 --base-path 的使用很有用，同时仍然允许使用旧的路径。

note: type: Plain text
en: To support virtual hosting, an interpolated path template can be used to dynamically construct alternate paths.  The template supports %H for the target hostname as supplied by the client but converted to all lowercase, %CH for the canonical hostname, %IP for the server's IP address, %P for the port number, and %D for the absolute path of the named repository.  After interpolation, the path is validated against the directory list.
zh_HANS-CN: 为了支持虚拟主机，可以使用插值路径模板来动态地构建备用路径。 该模板支持由客户提供的目标主机名的 %H，但转换为小写字母；支持规范主机名的 %CH；支持服务器 IP 地址的 %IP；支持端口号的 %P；支持命名仓库的绝对路径的 %D。 在插值之后，该路径将根据目录列表进行验证。

note: type: Plain text
en: Allow pulling from all directories that look like Git repositories (have the 'objects' and 'refs' subdirectories), even if they do not have the 'git-daemon-export-ok' file.
zh_HANS-CN: 允许从所有看起来像 Git 仓库的目录（有 'objects' 和 'refs' 子目录）提取，即使它们没有 'git-daemon-export-ok' 文件。

note: type: Plain text
en: Have the server run as an inetd service. Implies --syslog (may be overridden with `--log-destination=`).  Incompatible with --detach, --port, --listen, --user and --group options.
zh_HANS-CN: 让服务器作为一个 inetd 服务运行。暗示 --syslog（可以用 `--log-destination=` 重写）。 与 --detach、--port、--listen、--user 和 --group 选项不兼容。

note: type: Plain text
en: Listen on a specific IP address or hostname.  IP addresses can be either an IPv4 address or an IPv6 address if supported.  If IPv6 is not supported, then --listen=hostname is also not supported and --listen must be given an IPv4 address.  Can be given more than once.  Incompatible with `--inetd` option.
zh_HANS-CN: 在一个特定的 IP 地址或主机名上收听。 IP 地址可以是一个 IPv4 地址，也可以是一个 IPv6 地址（如果支持）。 如果不支持 IPv6，那么 --listen=hostname也不被支持，--listen 必须给出一个 IPv4 地址。 可以多次给出。 与 `--inetd` 选项不兼容。

note: type: Plain text
en: Listen on an alternative port.  Incompatible with `--inetd` option.
zh_HANS-CN: 在另一个端口上监听。 与 `--inetd` 选项不兼容。

note: type: Plain text
en: Timeout (in seconds) between the moment the connection is established and the client request is received (typically a rather low value, since that should be basically immediate).
zh_HANS-CN: 从建立连接到收到客户端请求之间的超时（以秒为单位）（通常是一个相当低的值，因为这基本上应该是即时的）。

note: type: Plain text
en: Timeout (in seconds) for specific client sub-requests. This includes the time it takes for the server to process the sub-request and the time spent waiting for the next client's request.
zh_HANS-CN: 特定客户端子请求的超时（单位：秒）。这包括服务器处理子请求的时间和等待下一个客户端请求的时间。

note: type: Plain text
en: Maximum number of concurrent clients, defaults to 32.  Set it to zero for no limit.
zh_HANS-CN: 最大并发客户数，默认为 32。 设置为零表示没有限制。

note: type: Plain text
en: Short for `--log-destination=syslog`.
zh_HANS-CN: 是 `--log-destination=syslog` 的简称。

note: type: Labeled list
en: --log-destination=<destination>
zh_HANS-CN: --log-destination=<目的>

note: type: Plain text
en: Send log messages to the specified destination.  Note that this option does not imply --verbose, thus by default only error conditions will be logged.  The <destination> must be one of:
zh_HANS-CN: 发送日志信息到指定的目的地。 注意，这个选项并不意味着 --verbose，因此默认情况下只有错误情况会被记录下来。 <目的> 必须是以下之一：

note: type: Plain text
en: Write to standard error.  Note that if `--detach` is specified, the process disconnects from the real standard error, making this destination effectively equivalent to `none`.
zh_HANS-CN: 写入标准错误。 注意，如果指定了 `--detach`，进程就会断开与真正的标准错误的连接，使得这个目的地实际上等同于 `none`。

note: type: Plain text
en: Write to syslog, using the `git-daemon` identifier.
zh_HANS-CN: 写入 syslog，使用 `git-daemon` 标识符。

note: type: Plain text
en: Disable all logging.
zh_HANS-CN: 禁用所有日志记录。

note: type: Plain text
en: The default destination is `syslog` if `--inetd` or `--detach` is specified, otherwise `stderr`.
zh_HANS-CN: 如果指定了 `--inetd` 或 `--detach`，默认的目标是 `syslog`，否则是 `stderr`。

note: type: Plain text
en: Allow {tilde}user notation to be used in requests.  When specified with no parameter, requests to git://host/{tilde}alice/foo is taken as a request to access 'foo' repository in the home directory of user `alice`.  If `--user-path=path` is specified, the same request is taken as a request to access `path/foo` repository in the home directory of user `alice`.
zh_HANS-CN: 允许在请求中使用 {tilde} 用户符号。 当没有指定参数时，对 git://host/{tilde}alice/foo 的请求会被视为访问用户 `alice`的主目录下的 'foo' 仓库的请求。 如果指定了 `--user-path=path`，同样的请求将被视为访问用户 `alice` 的主目录下的 `path/foo`存储库。

note: type: Plain text
en: Log details about the incoming connections and requested files.
zh_HANS-CN: 记录有关传入连接和请求文件的详细信息。

note: type: Plain text
en: Use SO_REUSEADDR when binding the listening socket.  This allows the server to restart without waiting for old connections to time out.
zh_HANS-CN: 在绑定监听套接字时使用 SO_REUSEADDR。 这允许服务器重新启动，而不必等待旧的连接超时。

note: type: Plain text
en: Detach from the shell. Implies --syslog.
zh_HANS-CN: 从 shell 中分离出来。这意味着 --syslog。

note: type: Plain text
en: Save the process id in 'file'.  Ignored when the daemon is run under `--inetd`.
zh_HANS-CN: 在 'file' 中保存进程 ID。 当守护进程在 `--inetd` 下运行时被忽略。

note: type: Labeled list
en: --group=<group>
zh_HANS-CN: --group=<组>

note: type: Plain text
en: Change daemon's uid and gid before entering the service loop.  When only `--user` is given without `--group`, the primary group ID for the user is used.  The values of the option are given to `getpwnam(3)` and `getgrnam(3)` and numeric IDs are not supported.
zh_HANS-CN: 在进入服务循环之前，改变 daemon 的 uid 和 gid。 当只给出 `--user` 而没有 `--group` 时，将使用用户的主要组 ID。 该选项的值是给 `getpwnam(3)` 和 `getgrnam(3)` 的，不支持数字 ID。

note: type: Plain text
en: Giving these options is an error when used with `--inetd`; use the facility of inet daemon to achieve the same before spawning 'git daemon' if needed.
zh_HANS-CN: 当与 `--inetd` 一起使用时，给出这些选项是一个错误；如果需要，在催生 'git daemon' 之前，使用 inet daemon 的设施来实现同样的目的。

note: type: Plain text
en: Like many programs that switch user id, the daemon does not reset environment variables such as `$HOME` when it runs git programs, e.g. `upload-pack` and `receive-pack`. When using this option, you may also want to set and export `HOME` to point at the home directory of `<user>` before starting the daemon, and make sure any Git configuration files in that directory are readable by `<user>`.
zh_HANS-CN: 像许多切换用户 ID 的程序一样，守护进程在运行 git 程序（如 `upload-pack` 和 `receive-pack`）时，不会重置 `$HOME` 之类的环境变量。当使用这个选项时，你可能还想在启动守护进程之前设置并导出 `HOME` 指向 `<user>` 的主目录，并确保该目录下的任何 Git 配置文件是 `<user>` 可以读取的。

note: type: Labeled list
en: --enable=<service>
zh_HANS-CN: --enable=<服务>

note: type: Labeled list
en: --disable=<service>
zh_HANS-CN: --disable=<服务>

note: type: Plain text
en: Enable/disable the service site-wide per default.  Note that a service disabled site-wide can still be enabled per repository if it is marked overridable and the repository enables the service with a configuration item.
zh_HANS-CN: 在全站范围内默认启用/禁用该服务。 请注意，如果一个全站禁用的服务被标记为可重写，并且版本库用配置项启用了该服务，那么它仍然可以在每个版本库中启用。

note: type: Labeled list
en: --forbid-override=<service>
zh_HANS-CN: --forbid-override=<服务>

note: type: Plain text
en: Allow/forbid overriding the site-wide default with per repository configuration.  By default, all the services may be overridden.
zh_HANS-CN: 允许/禁止用每个版本库的配置来覆盖全站的默认值。 默认情况下，所有的服务都可以被覆盖。

note: type: Plain text
en: When informative errors are turned on, git-daemon will report more verbose errors to the client, differentiating conditions like "no such repository" from "repository not exported". This is more convenient for clients, but may leak information about the existence of unexported repositories.  When informative errors are not enabled, all errors report "access denied" to the client. The default is --no-informative-errors.
zh_HANS-CN: 当信息性错误被打开时，git-daemon 会向客户端报告更多详细的错误，区分 "没有这样的仓库" 和 "仓库没有被导出" 这样的情况。这对客户端来说更方便，但可能会泄露未导出版本库的信息。 如果不启用信息性错误，所有错误都会向客户报告 "拒绝访问"。默认情况是 --no-informative-errors。

note: type: Labeled list
en: --access-hook=<path>
zh_HANS-CN: --access-hook=<路径>

note: type: Plain text
en: Every time a client connects, first run an external command specified by the <path> with service name (e.g. "upload-pack"), path to the repository, hostname (%H), canonical hostname (%CH), IP address (%IP), and TCP port (%P) as its command-line arguments. The external command can decide to decline the service by exiting with a non-zero status (or to allow it by exiting with a zero status).  It can also look at the $REMOTE_ADDR and `$REMOTE_PORT` environment variables to learn about the requestor when making this decision.
zh_HANS-CN: 每次客户端连接时，首先运行 <路径> 指定的外部命令，以服务名称（如 "upload-pack"）、仓库的路径、主机名（%H）、规范主机名（%CH）、IP 地址（%IP）和 TCP 端口（%P）作为其命令行参数。外部命令可以通过以非零状态退出来决定拒绝该服务（或通过以零状态退出来允许它）。 在做出这个决定时，它还可以查看 $REMOTE_ADDR 和 `$REMOTE_PORT` 环境变量来了解请求者的情况。

note: type: Plain text
en: The external command can optionally write a single line to its standard output to be sent to the requestor as an error message when it declines the service.
zh_HANS-CN: 外部命令可以选择在其标准输出中写入一行，在拒绝服务时作为错误信息发送给请求者。

note: type: Plain text
en: The remaining arguments provide a list of directories. If any directories are specified, then the `git-daemon` process will serve a requested directory only if it is contained in one of these directories. If `--strict-paths` is specified, then the requested directory must match one of these directories exactly.
zh_HANS-CN: 其余的参数提供了一个目录列表。如果指定了任何目录，那么 `git-daemon` 进程将只在所请求的目录包含在这些目录中时提供服务。如果指定了 `--strict-paths`，那么请求的目录必须与这些目录之一完全匹配。

note: type: Plain text
en: These services can be globally enabled/disabled using the command-line options of this command.  If finer-grained control is desired (e.g. to allow 'git archive' to be run against only in a few selected repositories the daemon serves), the per-repository configuration file can be used to enable or disable them.
zh_HANS-CN: 这些服务可以通过该命令的命令行选项全局启用/禁用。 如果需要更精细的控制（例如，允许 'git archive' 只在守护进程所服务的几个选定的仓库中运行），可以使用每个仓库的配置文件来启用或禁用它们。

note: type: Plain text
en: This serves 'git fetch-pack' and 'git ls-remote' clients.  It is enabled by default, but a repository can disable it by setting `daemon.uploadpack` configuration item to `false`.
zh_HANS-CN: 它为 'git fetch-pack' 和 'git ls-remote' 客户端服务。 它默认是启用的，但仓库可以通过设置 `daemon.uploadpack` 配置项为 `false` 来禁用它。

note: type: Plain text
en: This serves 'git archive --remote'.  It is disabled by default, but a repository can enable it by setting `daemon.uploadarch` configuration item to `true`.
zh_HANS-CN: 这为 'git archive --remote' 服务。 它默认是禁用的，但版本库可以通过设置 `daemon.uploadarch` 配置项为 `true` 来启用它。

note: type: Plain text
en: This serves 'git send-pack' clients, allowing anonymous push.  It is disabled by default, as there is _no_ authentication in the protocol (in other words, anybody can push anything into the repository, including removal of refs).  This is solely meant for a closed LAN setting where everybody is friendly.  This service can be enabled by setting `daemon.receivepack` configuration item to `true`.
zh_HANS-CN: 它为 'git send-pack' 客户端服务，允许匿名推送。 它默认是禁用的，因为协议中没有认证（换句话说，任何人都可以推送任何东西到仓库，包括删除引用）。 这只适用于封闭的局域网环境，大家都很友好。 这个服务可以通过设置 `daemon.receivepack` 配置项为 `true` 来启用。

note: type: Labeled list
en: We assume the following in /etc/services
zh_HANS-CN: 我们在 /etc/services 中假设如下

note: type: Labeled list
en: 'git daemon' as inetd server
zh_HANS-CN: 'git daemon' 作为 inetd 服务器

note: type: Plain text
en: To set up 'git daemon' as an inetd service that handles any repository within `/pub/foo` or `/pub/bar`, place an entry like the following into `/etc/inetd` all on one line:
zh_HANS-CN: 要把 'git daemon' 设置为 inetd 服务，处理 `/pub/foo` 或 `/pub/bar` 内的任何仓库，在 `/etc/inetd` 中放入如下条目，全部放在一行：

note: type: Labeled list
en: 'git daemon' as inetd server for virtual hosts
zh_HANS-CN: 作为虚拟主机的 inetd 服务器的 'git daemon'

note: type: Plain text
en: To set up 'git daemon' as an inetd service that handles repositories for different virtual hosts, `www.example.com` and `www.example.org`, place an entry like the following into `/etc/inetd` all on one line:
zh_HANS-CN: 要将 'git daemon' 设置为 inetd 服务，处理不同的虚拟主机 `www.example.com` 和 `www.example.org` 的仓库，在 `/etc/inetd` 中放置如下条目，全部在一行：

note: type: Plain text
en: In this example, the root-level directory `/pub` will contain a subdirectory for each virtual host name supported.  Further, both hosts advertise repositories simply as `git://www.example.com/software/repo.git`.  For pre-1.4.0 clients, a symlink from `/software` into the appropriate default repository could be made as well.
zh_HANS-CN: 在这个例子中，根级目录 `/pub` 将包含一个子目录，用于支持每个虚拟主机名。 此外，两台主机都简单地以 `git://www.example.com/software/repo.git` 的方式宣传仓库。 对于 1.4.0 之前的客户端，也可以从 `/software` 建立一个符号链接到相应的默认仓库。

note: type: Labeled list
en: 'git daemon' as regular daemon for virtual hosts
zh_HANS-CN: 'git daemon' 作为虚拟主机的常规守护程序

note: type: Plain text
en: To set up 'git daemon' as a regular, non-inetd service that handles repositories for multiple virtual hosts based on their IP addresses, start the daemon like this:
zh_HANS-CN: 要把 'git daemon' 设置成一个普通的、非 inetd 的服务，处理基于 IP 地址的多个虚拟主机的存储库，可以像这样启动 daemon：

note: type: Plain text
en: In this example, the root-level directory `/pub` will contain a subdirectory for each virtual host IP address supported.  Repositories can still be accessed by hostname though, assuming they correspond to these IP addresses.
zh_HANS-CN: 在这个例子中，根级目录 `/pub` 将包含一个支持每个虚拟主机IP地址的子目录。 虽然仓库仍然可以通过主机名访问，但假设它们对应于这些 IP 地址。

note: type: Labeled list
en: selectively enable/disable services per repository
zh_HANS-CN: 选择性地启用/禁用每个仓库的服务

note: type: Plain text
en: To enable 'git archive --remote' and disable 'git fetch' against a repository, have the following in the configuration file in the repository (that is the file 'config' next to `HEAD`, 'refs' and 'objects').
zh_HANS-CN: 要启用 'git archive --remote' 并禁用 'git fetch'，在仓库的配置文件中要有以下内容（也就是在 `HEAD`、'refs' 和 'objects' 旁的 'config'文件）。

note: type: Plain text
en: 'git daemon' will set REMOTE_ADDR to the IP address of the client that connected to it, if the IP address is available. REMOTE_ADDR will be available in the environment of hooks called when services are performed.
zh_HANS-CN: 'git daemon' 将把 REMOTE_ADDR 设置为连接到它的客户端的 IP 地址，如果该 IP 地址是可用的。REMOTE_ADDR 将在执行服务时调用的钩子环境中可用。

note: type: Plain text
en: git-describe - Give an object a human readable name based on an available ref
zh_HANS-CN: git-describe - 根据一个可用的参考文献，给一个对象起一个人类可读的名字。

note: type: Plain text
en: 'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] [<commit-ish>...]
    'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] --dirty[=<mark>]
    'git describe' <blob>
zh_HANS-CN: 'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] [<commit-ish>...]
    'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] --dirty[=<mark>] 。
    'git describe' <blob

note: type: Plain text
en: The command finds the most recent tag that is reachable from a commit.  If the tag points to the commit, then only the tag is shown.  Otherwise, it suffixes the tag name with the number of additional commits on top of the tagged object and the abbreviated object name of the most recent commit. The result is a "human-readable" object name which can also be used to identify the commit to other git commands.
zh_HANS-CN: 该命令找到可从提交中获取的最新标签。  如果标签指向该提交，则只显示该标签。  否则，它会在标签名后面加上附加提交的数量，以及最新提交的缩写对象名。其结果是一个 "人类可读 "的对象名称，也可用于识别其他git命令中的提交。

note: type: Plain text
en: By default (without --all or --tags) `git describe` only shows annotated tags.  For more information about creating annotated tags see the -a and -s options to linkgit:git-tag[1].
zh_HANS-CN: 默认情况下（没有 --all 或 --tags）`git describe`只显示有注释的标签。  关于创建注释标签的更多信息，请参见linkgit:git-tag[1]的-a和-s选项。

note: type: Plain text
en: If the given object refers to a blob, it will be described as `<commit-ish>:<path>`, such that the blob can be found at `<path>` in the `<commit-ish>`, which itself describes the first commit in which this blob occurs in a reverse revision walk from HEAD.
zh_HANS-CN: 如果给定的对象指的是一个blob，它将被描述为`<commit-ish>:<path>`，这样就可以在`<commit-ish>`中的`<path>`找到这个blob，而这个blob本身就描述了从HEAD反向修订中出现的第一个提交。

note: type: Plain text
en: Commit-ish object names to describe.  Defaults to HEAD if omitted.
zh_HANS-CN: 要描述的类似于承诺的对象名称。  如果省略，则默认为HEAD。

note: type: Plain text
en: Describe the state of the working tree.  When the working tree matches HEAD, the output is the same as "git describe HEAD".  If the working tree has local modification "-dirty" is appended to it.  If a repository is corrupt and Git cannot determine if there is local modification, Git will error out, unless `--broken' is given, which appends the suffix "-broken" instead.
zh_HANS-CN: 描述工作树的状态。  当工作树与HEAD匹配时，其输出与 "git describe HEAD "相同。  如果工作树有本地修改，"-dirty "会被附加到它上面。  如果一个仓库被破坏了，而Git不能确定是否有本地修改，Git会出错，除非给了`--broken'，它将附加后缀"-broken"。

note: type: Plain text
en: Instead of using only the annotated tags, use any ref found in `refs/` namespace.  This option enables matching any known branch, remote-tracking branch, or lightweight tag.
zh_HANS-CN: 而不是只使用注释的标签，使用在`refs/`命名空间中发现的任何ref。  这个选项可以匹配任何已知的分支、远程跟踪分支或轻量级标签。

note: type: Plain text
en: Instead of using only the annotated tags, use any tag found in `refs/tags` namespace.  This option enables matching a lightweight (non-annotated) tag.
zh_HANS-CN: 而不是只使用注释过的标签，使用在`refs/tags`命名空间中发现的任何标签。  这个选项可以匹配轻量级（非注释的）标签。

note: type: Plain text
en: Instead of finding the tag that predates the commit, find the tag that comes after the commit, and thus contains it.  Automatically implies --tags.
zh_HANS-CN: 与其寻找提交前的标签，不如寻找提交后的标签，从而包含该标签。  自动暗示--标签。

note: type: Plain text
en: Instead of using the default number of hexadecimal digits (which will vary according to the number of objects in the repository with a default of 7) of the abbreviated object name, use <n> digits, or as many digits as needed to form a unique object name. An <n> of 0 will suppress long format, only showing the closest tag.
zh_HANS-CN: 不要使用缩写对象名称的默认十六进制数字（根据存储库中对象的数量而变化，默认为7），而是使用<n>数字，或根据需要使用任意多的数字来形成唯一的对象名称。<n>为0将抑制长格式，仅显示最近的标记。

note: type: Plain text
en: Instead of considering only the 10 most recent tags as candidates to describe the input commit-ish consider up to <n> candidates.  Increasing <n> above 10 will take slightly longer but may produce a more accurate result.  An <n> of 0 will cause only exact matches to be output.
zh_HANS-CN: 与其只考虑用最近的10个标签来描述输入的commit-ish，不如考虑最多<n>个候选人。  将<n>增加到10以上会花费更长的时间，但可能会产生一个更准确的结果。  <n>为0将导致只输出完全匹配的结果。

note: type: Plain text
en: Only output exact matches (a tag directly references the supplied commit).  This is a synonym for --candidates=0.
zh_HANS-CN: 只输出完全匹配的内容（一个标签直接引用所提供的提交）。  这是 --candidates=0 的同义词。

note: type: Plain text
en: Verbosely display information about the searching strategy being employed to standard error.  The tag name will still be printed to standard out.
zh_HANS-CN: 以粗略的方式向标准错误显示正在使用的搜索策略的信息。  标签名称仍将被打印到标准输出。

note: type: Plain text
en: Always output the long format (the tag, the number of commits and the abbreviated commit name) even when it matches a tag.  This is useful when you want to see parts of the commit object name in "describe" output, even when the commit in question happens to be a tagged version.  Instead of just emitting the tag name, it will describe such a commit as v1.2-0-gdeadbee (0th commit since tag v1.2 that points at object deadbee....).
zh_HANS-CN: 总是输出长格式（标签、提交数量和提交名称的缩写），即使它与一个标签相匹配。  当你想在 "describe "输出中看到提交对象的部分名称时，这很有用，即使相关的提交恰好是一个有标签的版本。  它不会只发出标签名称，而是将这样的提交描述为v1.2-0-gdeadbee（标签v1.2后的第0次提交，指向对象deadbee....）。

note: type: Plain text
en: Only consider tags matching the given `glob(7)` pattern, excluding the "refs/tags/" prefix. If used with `--all`, it also considers local branches and remote-tracking references matching the pattern, excluding respectively "refs/heads/" and "refs/remotes/" prefix; references of other types are never considered. If given multiple times, a list of patterns will be accumulated, and tags matching any of the patterns will be considered.  Use `--no-match` to clear and reset the list of patterns.
zh_HANS-CN: 只考虑与给定的 `glob(7)` 模式匹配的标签，不包括 "refs/tags/" 前缀。如果和`--all`一起使用，它也会考虑匹配该模式的本地分支和远程跟踪引用，分别排除 "refs/heads/"和 "refs/remotes/"前缀；其他类型的引用永远不会被考虑。如果给出多次，将积累一个模式列表，匹配任何模式的标签都会被考虑。  使用`--no-match`来清除和重置模式列表。

note: type: Labeled list
en: --exclude <pattern>
zh_HANS-CN: --排除<pattern>。

note: type: Plain text
en: Do not consider tags matching the given `glob(7)` pattern, excluding the "refs/tags/" prefix. If used with `--all`, it also does not consider local branches and remote-tracking references matching the pattern, excluding respectively "refs/heads/" and "refs/remotes/" prefix; references of other types are never considered. If given multiple times, a list of patterns will be accumulated and tags matching any of the patterns will be excluded. When combined with --match a tag will be considered when it matches at least one --match pattern and does not match any of the --exclude patterns. Use `--no-exclude` to clear and reset the list of patterns.
zh_HANS-CN: 不考虑与给定的 `glob(7)` 模式匹配的标签，排除 "refs/tags/"前缀。如果和`--all`一起使用，也不考虑匹配模式的本地分支和远程跟踪引用，分别排除 "refs/heads/"和 "refs/remotes/"前缀；其他类型的引用从不考虑。如果给定多次，将积累一个模式列表，匹配任何模式的标签将被排除。当与--match结合时，当一个标签至少匹配一个--match模式且不匹配任何--exclude模式时，将被考虑。使用`--no-exclude`来清除和重置模式列表。

note: type: Plain text
en: Show uniquely abbreviated commit object as fallback.
zh_HANS-CN: 显示唯一缩写的提交对象作为后备。

note: type: Plain text
en: Follow only the first parent commit upon seeing a merge commit.  This is useful when you wish to not match tags on branches merged in the history of the target commit.
zh_HANS-CN: 在看到合并提交时，只跟随第一个父提交。  当你希望不匹配目标提交历史中合并的分支上的标签时，这很有用。

note: type: Plain text
en: With something like git.git current tree, I get:
zh_HANS-CN: 用git.git当前树这样的东西，我得到了。

note: type: Plain text
en: i.e. the current head of my "parent" branch is based on v1.0.4, but since it has a few commits on top of that, describe has added the number of additional commits ("14") and an abbreviated object name for the commit itself ("2414721")  at the end.
zh_HANS-CN: 也就是说，我的 "父 "分支的当前头部是基于v1.0.4的，但由于它在此基础上有一些提交，所以describe在最后添加了额外的提交数量（"14"）和提交本身的缩写对象名称（"2414721"）。

note: type: Plain text
en: Doing a 'git describe' on a tag-name will just show the tag name:
zh_HANS-CN: 对一个标签名做 "git describe"，只会显示标签名。

note: type: Plain text
en: With --all, the command can use branch heads as references, so the output shows the reference path as well:
zh_HANS-CN: 使用--all，命令可以使用分支头作为参考，所以输出也会显示参考路径。

note: type: Plain text
en: With --abbrev set to 0, the command can be used to find the closest tagname without any suffix:
zh_HANS-CN: 在--abbrev设置为0的情况下，该命令可以用来寻找最接近的没有任何后缀的tagname。

note: type: Plain text
en: Note that the suffix you get if you type these commands today may be longer than what Linus saw above when he ran these commands, as your Git repository may have new commits whose object names begin with 975b that did not exist back then, and "-g975b" suffix alone may not be sufficient to disambiguate these commits.
zh_HANS-CN: 请注意，如果你今天输入这些命令，得到的后缀可能比上面Linus运行这些命令时看到的要长，因为你的Git仓库可能有新的提交，其对象名称以975b开头，而这些提交在当时并不存在，仅靠"-g975b "后缀可能还不足以区分这些提交。

note: type: Title -
en: SEARCH STRATEGY
zh_HANS-CN: 搜索策略

note: type: Plain text
en: For each commit-ish supplied, 'git describe' will first look for a tag which tags exactly that commit.  Annotated tags will always be preferred over lightweight tags, and tags with newer dates will always be preferred over tags with older dates.  If an exact match is found, its name will be output and searching will stop.
zh_HANS-CN: 对于提供的每个提交，'git describe'将首先寻找一个标签，该标签正是该提交的标签。  有注释的标签总是比轻量级的标签更受欢迎，日期较新的标签总是比日期较老的标签更受欢迎。  如果找到一个完全匹配的标签，它的名字就会被输出，搜索就会停止。

note: type: Plain text
en: If an exact match was not found, 'git describe' will walk back through the commit history to locate an ancestor commit which has been tagged.  The ancestor's tag will be output along with an abbreviation of the input commit-ish's SHA-1. If `--first-parent` was specified then the walk will only consider the first parent of each commit.
zh_HANS-CN: 如果没有找到完全匹配的，'git describe'会回溯提交历史，找到一个已经被标记的祖先提交。  该祖先的标签将与输入的提交的SHA-1的缩写一起被输出。如果指定了 `--first-parent`，那么回溯将只考虑每个提交的第一个父级。

note: type: Plain text
en: If multiple tags were found during the walk then the tag which has the fewest commits different from the input commit-ish will be selected and output.  Here fewest commits different is defined as the number of commits which would be shown by `git log tag..input` will be the smallest number of commits possible.
zh_HANS-CN: 如果在行走过程中发现了多个标签，那么将选择与输入的commit-ish相差最少的标签并输出。  这里，最小的提交差异被定义为 "git log tag...input "所显示的提交数量将是最小的提交数量。

note: type: Plain text
en: git-diff-files - Compares files in the working tree and the index
zh_HANS-CN: git-diff-files - 对比工作区和索引中的文件

note: type: Plain text
en: Compares the files in the working tree and the index.  When paths are specified, compares only those named paths.  Otherwise all entries in the index are compared.  The output format is the same as for 'git diff-index' and 'git diff-tree'.
zh_HANS-CN: 比较工作区和索引中的文件。 当指定路径时，只比较那些命名的路径。 否则就比较索引中的所有条目。 输出格式与 'git diff-index' 和 'git diff-tree' 的相同。

note: type: Labeled list
en: -1 --base
zh_HANS-CN: -1 --基地

note: type: Plain text
en: Diff against the "base" version, "our branch" or "their branch" respectively.  With these options, diffs for merged entries are not shown.
zh_HANS-CN: 分别与 “基础” 版本、“我们的分支” 或 “他们的分支” 进行比较。 有了这些选项，合并后的条目的差异就不会显示。

note: type: Plain text
en: The default is to diff against our branch (-2) and the cleanly resolved paths.  The option -0 can be given to omit diff output for unmerged entries and just show "Unmerged".
zh_HANS-CN: 默认是针对我们的分支 (-2) 和干净的解决路径进行差异比对。 可以给出选项 -0 来省略未合并的条目的差异输出，只显示 "Unmerged"。

note: type: Plain text
en: This compares stage 2 (our branch), stage 3 (their branch) and the working tree file and outputs a combined diff, similar to the way 'diff-tree' shows a merge commit with these flags.
zh_HANS-CN: 这将比较第二阶段（我们的分支）、第三阶段（他们的分支）和工作区文件，并输出一个综合的差异，类似于 'diff-tree' 显示带有这些标志的合并提交。

note: type: Plain text
en: Remain silent even on nonexistent files
zh_HANS-CN: 即使对不存在的文件也保持沉默

note: type: Plain text
en: git-difftool - Show changes using common diff tools
zh_HANS-CN: git-difftool - 使用常见的差异工具显示变化

note: type: Plain text
en: Copy the modified files to a temporary location and perform a directory diff on them. This mode never prompts before launching the diff tool.
zh_HANS-CN: 把修改过的文件复制到一个临时位置，然后对它们进行目录比较。这种模式在启动差异工具之前从不提示。

note: type: Plain text
en: Do not prompt before launching a diff tool.
zh_HANS-CN: 在启动差异工具之前不要提示。

note: type: Plain text
en: Prompt before each invocation of the diff tool.  This is the default behaviour; the option is provided to override any configuration settings.
zh_HANS-CN: 在每次调用差异工具之前提示。 这是默认行为；提供该选项是为了覆盖任何配置设置。

note: type: Plain text
en: Start showing the diff for the given path, the paths before it will move to end and output.
zh_HANS-CN: 开始显示给定路径的差异，在它之前的路径将移动到终点并输出。

note: type: Plain text
en: Start showing the diff for the given path, skipping all the paths before it.
zh_HANS-CN: 开始显示给定路径的差异，跳过前面所有的路径。

note: type: Plain text
en: Use the diff tool specified by <tool>.  Valid values include emerge, kompare, meld, and vimdiff. Run `git difftool --tool-help` for the list of valid <tool> settings.
zh_HANS-CN: 使用由 <工具> 指定的差异工具。 有效值包括 emerge, kompare, meld, 和 vimdiff。运行 `git difftool --tool-help` 以获得有效的 <工具> 设置列表。

note: type: Plain text
en: If a diff tool is not specified, 'git difftool' will use the configuration variable `diff.tool`.  If the configuration variable `diff.tool` is not set, 'git difftool' will pick a suitable default.
zh_HANS-CN: 如果没有指定差异工具，'git difftool' 将使用配置变量 `diff.tool`。 如果配置变量 `diff.tool` 没有设置，'git difftool' 将选择一个合适的默认值。

note: type: Plain text
en: You can explicitly provide a full path to the tool by setting the configuration variable `difftool.<tool>.path`. For example, you can configure the absolute path to kdiff3 by setting `difftool.kdiff3.path`. Otherwise, 'git difftool' assumes the tool is available in PATH.
zh_HANS-CN: 你可以通过设置配置变量 `difftool.<工具>.path` 来明确提供工具的完整路径。例如，你可以通过设置 `difftool.kdiff3.path` 来配置 kdiff3 的绝对路径。否则，'git difftool' 会假定该工具在 PATH 中可用。

note: type: Plain text
en: Instead of running one of the known diff tools, 'git difftool' can be customized to run an alternative program by specifying the command line to invoke in a configuration variable `difftool.<tool>.cmd`.
zh_HANS-CN: 通过在配置变量 `difftool.<工具>.cmd` 中指定要调用的命令行，可以定制 'git difftool'，而不是运行一个已知的比较工具，以运行一个替代程序。

note: type: Plain text
en: When 'git difftool' is invoked with this tool (either through the `-t` or `--tool` option or the `diff.tool` configuration variable)  the configured command line will be invoked with the following variables available: `$LOCAL` is set to the name of the temporary file containing the contents of the diff pre-image and `$REMOTE` is set to the name of the temporary file containing the contents of the diff post-image.  `$MERGED` is the name of the file which is being compared. `$BASE` is provided for compatibility with custom merge tool commands and has the same value as `$MERGED`.
zh_HANS-CN: 当 'git difftool' 与此工具一起调用时（通过 `-t` 或 `--tool` 选项或 `diff.tool` 配置变量），配置的命令行将被调用，以下变量可用： `$LOCAL` 被设置为包含差异比对前图像内容的临时文件名，`$REMOTE` 被设置为包含差异比对后图像内容的临时文件名。 `$MERGED` 是被比较的文件的名称。`$BASE` 是为了与自定义合并工具命令兼容而提供的，其值与 `$MERGED` 相同。

note: type: Plain text
en: Print a list of diff tools that may be used with `--tool`.
zh_HANS-CN: 列出可以和"--tool"命令一起使用的diff工具。

note: type: Plain text
en: Specifying `--no-symlinks` instructs 'git difftool' to create copies instead.  `--no-symlinks` is the default on Windows.
zh_HANS-CN: 指定 `---no-symlinks` 会指示 'git difftool' 创建副本。 `--no-symlinks` 是 Windows 上的默认值。

note: type: Labeled list
en: -x <command>
zh_HANS-CN: -x <命令>

note: type: Plain text
en: Specify a custom command for viewing diffs.  'git-difftool' ignores the configured defaults and runs `$command $LOCAL $REMOTE` when this option is specified.  Additionally, `$BASE` is set in the environment.
zh_HANS-CN: 指定一个用于查看差异的自定义命令。 'git-difftool' 忽略了配置的默认值，当这个选项被指定时，运行`$command $LOCAL $REMOTE`。 此外，`$BASE`在环境中被设置。

note: type: Plain text
en: 'git-difftool' invokes a diff tool individually on each file.  Errors reported by the diff tool are ignored by default.  Use `--trust-exit-code` to make 'git-difftool' exit when an invoked diff tool returns a non-zero exit code.
zh_HANS-CN: 'git-difftool' 在每个文件上单独调用一个差异工具。 默认情况下，差异工具报告的错误会被忽略。 使用 `--trust-exit-code` 使 'git-difftool' 在被调用的差异工具返回非零的退出代码时退出。

note: type: Plain text
en: 'git-difftool' will forward the exit code of the invoked tool when `--trust-exit-code` is used.
zh_HANS-CN: 'git-difftool' 在使用 `--trust-exit-code` 时将转发被调用工具的退出代码。

note: type: Plain text
en: See linkgit:git-diff[1] for the full list of supported options.
zh_HANS-CN: 关于支持的选项的完整列表，见 linkgit:git-diff[1]。

note: type: Plain text
en: 'git difftool' falls back to 'git mergetool' config variables when the difftool equivalents have not been defined.
zh_HANS-CN: 当差异工具等价物没有被定义时，'git difftool' 会返回到 'git mergetool' 配置变量。

note: type: Plain text
en: Show changes between commits, commit and working tree, etc
zh_HANS-CN: 显示提交之间的变化，提交和工作区，等等

note: type: Plain text
en: Run merge conflict resolution tools to resolve merge conflicts
zh_HANS-CN: 运行合并冲突解决工具来解决合并冲突

note: type: Plain text
en: Get and set repository or global options
zh_HANS-CN: 获取和设置仓库或全局选项

note: type: Labeled list
en: <path>...
zh_HANS-CN: <路径>...

note: type: Plain text
en: git-diff - Show changes between commits, commit and working tree, etc
zh_HANS-CN: git-diff - 显示提交和工作区等变化

note: type: Plain text
en: 'git diff' [<options>] [<commit>] [--] [<path>...]
    'git diff' [<options>] --cached [--merge-base] [<commit>] [--] [<path>...]
    'git diff' [<options>] [--merge-base] <commit> [<commit>...] <commit> [--] [<path>...]
    'git diff' [<options>] <commit>...<commit> [--] [<path>...]
    'git diff' [<options>] <blob> <blob>
    'git diff' [<options>] --no-index [--] <path> <path>
zh_HANS-CN: 'git diff' [<options>] [<commit>] [--] [<path>...]。
    'git diff' [<options>] --cached [--merge-base] [<commit>] [--] [<path>...]。
    'git diff' [<options>] [--merge-base] <commit> [<commit>...] <commit> [--] [<path>...]
    'git diff' [<options>] <commit>...<commit> [--] [<path>...]。
    'git diff' [<options>] <blob> <blob
    'git diff' [<options>] --no-index [--] <path> <path>。

note: type: Plain text
en: Show changes between the working tree and the index or a tree, changes between the index and a tree, changes between two trees, changes resulting from a merge, changes between two blob objects, or changes between two files on disk.
zh_HANS-CN: 显示工作树和索引或树之间的变化，索引和树之间的变化，两个树之间的变化，合并产生的变化，两个blob对象之间的变化，或者磁盘上两个文件之间的变化。

note: type: Labeled list
en: 'git diff' [<options>] [--] [<path>...]
zh_HANS-CN: 'git diff' [<options>] [--] [<path>...] 。

note: type: Plain text
en: This form is to view the changes you made relative to the index (staging area for the next commit).  In other words, the differences are what you _could_ tell Git to further add to the index but you still haven't.  You can stage these changes by using linkgit:git-add[1].
zh_HANS-CN: 这个表格是用来查看你相对于索引（下次提交的暂存区域）所做的修改。  换句话说，这些差异是你_可以告诉 Git 进一步添加到索引中，但你仍然没有。  你可以用linkgit:git-add[1]来对这些改动进行分期。

note: type: Plain text
en: This form is to compare the given two paths on the filesystem.  You can omit the `--no-index` option when running the command in a working tree controlled by Git and at least one of the paths points outside the working tree, or when running the command outside a working tree controlled by Git. This form implies `--exit-code`.
zh_HANS-CN: 这种形式是为了比较文件系统上给定的两个路径。  当在一个由Git控制的工作树中运行该命令，并且至少有一个路径指向工作树之外，或者在一个由Git控制的工作树之外运行该命令时，你可以省略`--no-index`选项。这种形式意味着`--exit-code`。

note: type: Plain text
en: This form is to view the changes you staged for the next commit relative to the named <commit>.  Typically you would want comparison with the latest commit, so if you do not give <commit>, it defaults to HEAD.  If HEAD does not exist (e.g. unborn branches) and <commit> is not given, it shows all staged changes.  --staged is a synonym of --cached.
zh_HANS-CN: 这个表单是用来查看你为下一次提交所做的相对于<commit>的修改。  通常情况下，你希望与最新的提交进行比较，所以如果你没有给出 <commit>，它默认为 HEAD。  如果HEAD不存在（例如未出生的分支），并且没有给出<commit>，它将显示所有已缓存的修改。  -staged是-cached的同义词。

note: type: Plain text
en: This form is to view the changes you have in your working tree relative to the named <commit>.  You can use HEAD to compare it with the latest commit, or a branch name to compare with the tip of a different branch.
zh_HANS-CN: 这个表格是用来查看你的工作树中相对于命名为<commit>的修改。  您可以使用 HEAD 来与最新的提交进行比较，或者使用分支名称来与不同分支的顶端进行比较。

note: type: Plain text
en: If --merge-base is given, instead of using <commit>, use the merge base of <commit> and HEAD.  `git diff --merge-base A` is equivalent to `git diff $(git merge-base A HEAD)`.
zh_HANS-CN: 如果给出了 --merge-base，则不使用<commit>，而使用<commit>和HEAD的合并基数。  `git diff --merge-base A`等同于`git diff $(git merge-base A HEAD)`。

note: type: Plain text
en: This is to view the changes between two arbitrary <commit>.
zh_HANS-CN: 这是为了查看两个任意<commit>之间的变化。

note: type: Plain text
en: If --merge-base is given, use the merge base of the two commits for the "before" side.  `git diff --merge-base A B` is equivalent to `git diff $(git merge-base A B) B`.
zh_HANS-CN: 如果给出了 --merge-base，则使用两个提交的合并基础作为 "之前 "的一方。  `git diff --merge-base A B`等同于`git diff $(git merge-base A B) B`。

note: type: Plain text
en: This is synonymous to the earlier form (without the `..`) for viewing the changes between two arbitrary <commit>.  If <commit> on one side is omitted, it will have the same effect as using HEAD instead.
zh_HANS-CN: 这与早期的形式（没有`.`）是同义的，用于查看两个任意<commit>之间的变化。  如果省略了一侧的<commit>，将产生与使用HEAD相同的效果。

note: type: Labeled list
en: 'git diff' [<options>] <commit>\...<commit> [--] [<path>...]
zh_HANS-CN: 'git diff' [<选项>] <提交>\...<提交> [--] [<路径>...]

note: type: Plain text
en: This form is to view the changes on the branch containing and up to the second <commit>, starting at a common ancestor of both <commit>.  `git diff A...B` is equivalent to `git diff $(git merge-base A B) B`.  You can omit any one of <commit>, which has the same effect as using HEAD instead.
zh_HANS-CN: 这种形式是为了查看包含和直到第二个<commit>的分支上的变化，从两个<commit>的共同祖先开始。  `git diff A...B`等同于`git diff $(git merge-base A B) B`。  你可以省略<commit>中的任何一个，这与使用HEAD的效果相同。

note: type: Plain text
en: Just in case you are doing something exotic, it should be noted that all of the <commit> in the above description, except in the `--merge-base` case and in the last two forms that use `..` notations, can be any <tree>. A tree of interest is the one pointed to by the special ref `AUTO_MERGE`, which is written by the 'ort' merge strategy upon hitting merge conflicts (see linkgit:git-merge[1]).  Comparing the working tree with `AUTO_MERGE` shows changes you've made so far to resolve textual conflicts (see the examples below).
zh_HANS-CN: 为了以防万一，需要注意的是，上述描述中的所有 <commit> 都可以是任何 <tree>，除了 `--merge-base` 和最后两种使用 `...` 符号的形式。我们感兴趣的树是由特殊引用 `AUTO_MERGE` 指向的树，它是在遇到合并冲突时由 'ort' 合并策略写入的（参见 linkgit:git-merge[1]）。 将工作树与 `AUTO_MERGE` 进行比较，就能看到迄今为止为解决文本冲突所做的改动（参见下面的示例）。

note: type: Plain text
en: For a more complete list of ways to spell <commit>, see "SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].  However, "diff" is about comparing two _endpoints_, not ranges, and the range notations (`<commit>..<commit>` and `<commit>...<commit>`) do not mean a range as defined in the "SPECIFYING RANGES" section in linkgit:gitrevisions[7].
zh_HANS-CN: 关于<commit>的更完整的拼写方式，见linkgit:gitrevisions[7]中的 "SPECIFYING REVISIONS "部分。  然而，"diff "是关于比较两个_端点，而不是范围，而且范围符号（`<commit>...<commit>`和`<commit>...<commit>`）并不意味着linkgit:gitrevisions[7]中 "SPECIFYING RANGES "部分所定义的范围。

note: type: Labeled list
en: 'git diff' [<options>] <blob> <blob>
zh_HANS-CN: 'git diff' [<选项>] <blob> <blob>

note: type: Plain text
en: This form is to view the differences between the raw contents of two blob objects.
zh_HANS-CN: 这种形式是为了查看两个blob对象的原始内容之间的差异。

note: type: Plain text
en: Compare the working tree with the "base" version (stage #1), "our branch" (stage #2) or "their branch" (stage #3).  The index contains these stages only for unmerged entries i.e.  while resolving conflicts.  See linkgit:git-read-tree[1] section "3-Way Merge" for detailed information.
zh_HANS-CN: 将工作树与 "基础 "版本（阶段#1）、"我们的分支"（阶段#2）或 "他们的分支"（阶段#3）进行比较。  索引只对未合并的条目包含这些阶段，即在解决冲突时。  详细情况见 linkgit:git-read-tree[1] "3-Way Merge" 部分。

note: type: Plain text
en: Omit diff output for unmerged entries and just show "Unmerged".  Can be used only when comparing the working tree with the index.
zh_HANS-CN: 省略未合并的条目的差异输出，只显示 "Unmerged"。  只能在比较工作树和索引的时候使用。

note: type: Plain text
en: The <paths> parameters, when given, are used to limit the diff to the named paths (you can give directory names and get diff for all files under them).
zh_HANS-CN: <paths>参数，当给出时，用于将diff限制在指定的路径上（你可以给出目录名称，并获得其下所有文件的diff）。

note: type: Labeled list
en: Various ways to check your working tree
zh_HANS-CN: 检查你的工作树的各种方法

note: type: Plain text
en: Changes in the working tree not yet staged for the next commit.
zh_HANS-CN: 工作树上的修改还没有为下一次提交做铺垫。

note: type: Plain text
en: Changes between the index and your last commit; what you would be committing if you run `git commit` without `-a` option.
zh_HANS-CN: 索引和你最后一次提交之间的变化；如果你运行`git commit`而不使用`-a`选项，你将会提交的内容。

note: type: Plain text
en: Changes in the working tree since your last commit; what you would be committing if you run `git commit -a`
zh_HANS-CN: 自你上次提交后工作树上的变化；如果你运行`git commit -a'，你将提交的内容。

note: type: Labeled list
en: Comparing with arbitrary commits
zh_HANS-CN: 与任意提交的比较

note: type: delimited block -
en: $ git diff test            <1>
    $ git diff HEAD -- ./test  <2>
    $ git diff HEAD^ HEAD      <3>
zh_HANS-CN: $ git diff test <1>
    $ git diff HEAD -- ./test <2>
    $ git diff HEAD^ HEAD <3>

note: type: Plain text
en: Instead of using the tip of the current branch, compare with the tip of "test" branch.
zh_HANS-CN: 不使用当前分支的顶端，而是与 "测试 "分支的顶端比较。

note: type: Plain text
en: Instead of comparing with the tip of "test" branch, compare with the tip of the current branch, but limit the comparison to the file "test".
zh_HANS-CN: 与其说是与 "test "分支的顶端比较，不如说是与当前分支的顶端比较，但只限于与 "test "文件比较。

note: type: Plain text
en: Compare the version before the last commit and the last commit.
zh_HANS-CN: 比较上次提交前的版本和上次提交的版本。

note: type: Labeled list
en: Comparing branches
zh_HANS-CN: 比较分支机构

note: type: Plain text
en: Changes between the tips of the topic and the master branches.
zh_HANS-CN: 专题的提示和主分支之间的变化。

note: type: Plain text
en: Changes that occurred on the master branch since when the topic branch was started off it.
zh_HANS-CN: 自专题分支开始以来，在主分支上发生的变化。

note: type: Labeled list
en: Limiting the diff output
zh_HANS-CN: 限制差分输出

note: type: Plain text
en: Show only modification, rename, and copy, but not addition or deletion.
zh_HANS-CN: 只显示修改、重命名和复制，但不显示增加或删除。

note: type: Plain text
en: Show only names and the nature of change, but not actual diff output.
zh_HANS-CN: 只显示名称和变化的性质，但不显示实际的差异输出。

note: type: Plain text
en: Limit diff output to named subtrees.
zh_HANS-CN: 将diff输出限制在命名的子树上。

note: type: Labeled list
en: Munging the diff output
zh_HANS-CN: 轧制差速器输出

note: type: Plain text
en: Spend extra cycles to find renames, copies and complete rewrites (very expensive).
zh_HANS-CN: 花费额外的周期来寻找重命名、复制和完全重写（非常昂贵）。

note: type: Plain text
en: Output diff in reverse.
zh_HANS-CN: 反向输出差值。

note: type: Plain text
en: git-fast-export - Git data exporter
zh_HANS-CN: git-fast-export - Git 数据导出器

note: type: Plain text
en: This program dumps the given revisions in a form suitable to be piped into 'git fast-import'.
zh_HANS-CN: 该程序会将给定的修订转储为适合导入 'git fast-import' 的形式。

note: type: Plain text
en: You can use it as a human-readable bundle replacement (see linkgit:git-bundle[1]), or as a format that can be edited before being fed to 'git fast-import' in order to do history rewrites (an ability relied on by tools like 'git filter-repo').
zh_HANS-CN: 你可以把它用作人类可读的 bundle 替换（参见 linkgit:git-bundle[1]），也可以把它用作一种格式，在输入到 'git fast-import' 之前进行编辑，以便进行历史重写（'git filter-repo' 等工具依赖这种能力）。

note: type: Plain text
en: Insert 'progress' statements every <n> objects, to be shown by 'git fast-import' during import.
zh_HANS-CN: 每隔 <n> 个对象插入 'progress' （进度）语句，在导入时由 'git fast-import' 显示。

note: type: Plain text
en: Specify how to handle signed tags.  Since any transformation after the export can change the tag names (which can also happen when excluding revisions) the signatures will not match.
zh_HANS-CN: 指定如何处理已签名的标记。  由于导出后的任何转换都可能更改标记名（排除修订时也可能发生这种情况），因此签名将不匹配。

note: type: Plain text
en: When asking to 'abort' (which is the default), this program will die when encountering a signed tag.  With 'strip', the tags will silently be made unsigned, with 'warn-strip' they will be made unsigned but a warning will be displayed, with 'verbatim', they will be silently exported and with 'warn', they will be exported, but you will see a warning.
zh_HANS-CN: 当要求 'abort'（禁止，默认值）时，该程序将在遇到已签名标记时死亡。  如果使用 'strip'（剥夺），标签将被静默地取消签名；如果使用 'warn-strip'，标签将被取消签名，但会显示警告；如果使用 'verbatim'（逐字报告），标签将被静默地导出；如果使用 'warn'，标签将被导出，但会显示警告。

note: type: Plain text
en: Specify how to handle tags whose tagged object is filtered out.  Since revisions and files to export can be limited by path, tagged objects may be filtered completely.
zh_HANS-CN: 指定如何处理已过滤掉标记对象的标记。  由于要导出的版本和文件可能受路径限制，标记对象可能会被完全过滤掉。

note: type: Plain text
en: When asking to 'abort' (which is the default), this program will die when encountering such a tag.  With 'drop' it will omit such tags from the output.  With 'rewrite', if the tagged object is a commit, it will rewrite the tag to tag an ancestor commit (via parent rewriting; see linkgit:git-rev-list[1])
zh_HANS-CN: 如果要求 'abort'（终止，默认值），程序将在遇到此类标记时死亡。  如果使用 'drop'（丢弃），则会从输出中省略此类标记。  如果使用 'rewrite'（重写），如果标记对象是一个提交，程序将重写该标记以标记一个祖先提交（通过父级重写；参见 linkgit:git-rev-list[1])

note: type: Plain text
en: Perform move and/or copy detection, as described in the linkgit:git-diff[1] manual page, and use it to generate rename and copy commands in the output dump.
zh_HANS-CN: 如 linkgit:git-diff[1] 手册页所述，执行移动和/或复制检测，并在输出转储中生成重命名和复制命令。

note: type: Plain text
en: Note that earlier versions of this command did not complain and produced incorrect results if you gave these options.
zh_HANS-CN: 请注意，如果您提供了这些选项，该命令的早期版本不会发出错误提示，并会产生不正确的结果。

note: type: Plain text
en: Dumps the internal marks table to <file> when complete.  Marks are written one per line as `:markid SHA-1`. Only marks for revisions are dumped; marks for blobs are ignored.  Backends can use this file to validate imports after they have been completed, or to save the marks table across incremental runs.  As <file> is only opened and truncated at completion, the same path can also be safely given to --import-marks.  The file will not be written if no new object has been marked/exported.
zh_HANS-CN: 完成后将内部标记表转存到 <文件> 中。 标记以 `:markid SHA-1` 的形式每行写一个。只转储修订版的标记；忽略 blob 的标记。 后端可以在导入完成后使用此文件验证导入，或在增量运行时保存标记表。 由于 <文件> 仅在导入完成时打开并截断，因此也可以安全地为 --import-marks 提供相同的路径。 如果没有标记/导出新对象，文件将不会被写入。

note: type: Plain text
en: Before processing any input, load the marks specified in <file>.  The input file must exist, must be readable, and must use the same format as produced by --export-marks.
zh_HANS-CN: 在处理任何输入之前，加载 <文件> 中指定的标记。 输入文件必须存在，必须可读，必须使用与 --export-marks 生成的相同格式。

note: type: Plain text
en: In addition to labelling blobs and commits with mark ids, also label tags.  This is useful in conjunction with `--export-marks` and `--import-marks`, and is also useful (and necessary) for exporting of nested tags.  It does not hurt other cases and would be the default, but many fast-import frontends are not prepared to accept tags with mark identifiers.
zh_HANS-CN: 除了用标记 id 标记 blob 和提交，还可以标记标签。 这与 `--export-marks`（导出标记） 和 `--import-marks`（导入标记）`配合使用，对于导出嵌套标记也很有用（而且很必要）。 这对其他情况没有影响，也是默认做法，但许多快速导入前端并不准备接受带有标记标识符的标签。

note: type: Plain text
en: Any commits (or tags) that have already been marked will not be exported again.  If the backend uses a similar --import-marks file, this allows for incremental bidirectional exporting of the repository by keeping the marks the same across runs.
zh_HANS-CN: 任何已标记的提交（或标记）都不会再次导出。 如果后端使用类似的 --import-marks 文件，则可以通过在不同运行中保持相同的标记来实现仓库的增量双向导出。

note: type: Plain text
en: Some old repositories have tags without a tagger.  The fast-import protocol was pretty strict about that, and did not allow that.  So fake a tagger to be able to fast-import the output.
zh_HANS-CN: 有些旧仓库有标签，但没有标记。 快速导入协议对此非常严格，不允许这样做。 所以要伪造一个标签，以便能够快速导入输出。

note: type: Plain text
en: Start the stream with a 'feature done' stanza, and terminate it with a 'done' command.
zh_HANS-CN: 用 'feature done' 字符串启动数据流，用 'done' 命令终止数据流。

note: type: Plain text
en: Skip output of blob objects and instead refer to blobs via their original SHA-1 hash.  This is useful when rewriting the directory structure or history of a repository without touching the contents of individual files.  Note that the resulting stream can only be used by a repository which already contains the necessary objects.
zh_HANS-CN: 跳过 blob 对象的输出，而是通过其原始 SHA-1 哈希值引用 blob。 这在重写仓库的目录结构或历史记录时非常有用，而且不会触及单个文件的内容。 请注意，生成的数据流只能由已包含必要对象的仓库使用。

note: type: Plain text
en: This option will cause fast-export to issue a "deleteall" directive for each commit followed by a full list of all files in the commit (as opposed to just listing the files which are different from the commit's first parent).
zh_HANS-CN: 该选项将导致 fast-export 为每个提交发出一个 "deleteall" 指令，然后列出提交中所有文件的完整列表（而不是只列出与提交的第一个父文件不同的文件）。

note: type: Plain text
en: Anonymize the contents of the repository while still retaining the shape of the history and stored tree.  See the section on `ANONYMIZING` below.
zh_HANS-CN: 对资源库的内容进行匿名化处理，同时仍保留历史记录和存储树的形状。 请参阅下文 `匿名化` 部分。

note: type: Plain text
en: Convert token `<from>` to `<to>` in the anonymized output. If `<to>` is omitted, map `<from>` to itself (i.e., do not anonymize it). See the section on `ANONYMIZING` below.
zh_HANS-CN: 将匿名化输出中的令牌 `<from>` 转换为 `<to>`。如果省略了 `<to>`，则将 `<from>` 映射到其本身（即不对其进行匿名化）。请参阅下面的 `匿名化` 部分。

note: type: Plain text
en: By default, running a command such as `git fast-export master~5..master` will not include the commit master{tilde}5 and will make master{tilde}4 no longer have master{tilde}5 as a parent (though both the old master{tilde}4 and new master{tilde}4 will have all the same files).  Use --reference-excluded-parents to instead have the stream refer to commits in the excluded range of history by their sha1sum.  Note that the resulting stream can only be used by a repository which already contains the necessary parent commits.
zh_HANS-CN: 默认情况下，运行诸如 `git fast-export master~5..master` 这样的命令不会包含 master{tilde}5 提交，并会使 master{tilde}4 不再将 master{tilde}5 作为父提交（尽管旧的 master{tilde}4 和新的 master{tilde}4 拥有相同的文件）。 使用 --reference-excluded-parents 可以让数据流通过 sha1sum 来引用历史中排除范围内的提交。 需要注意的是，生成的数据流只能由已包含必要父提交的仓库使用。

note: type: Plain text
en: Add an extra directive to the output for commits and blobs, `original-oid <SHA1SUM>`.  While such directives will likely be ignored by importers such as git-fast-import, it may be useful for intermediary filters (e.g. for rewriting commit messages which refer to older commits, or for stripping blobs by id).
zh_HANS-CN: 为提交和 blob 的输出添加一个额外的指令：`original-oid <SHA1SUM>`。 虽然这类指令可能会被 git-fast-import 等导入程序忽略，但对于中间过滤器（例如重写引用较早提交的提交信息，或按 id 剔除 blobs）来说可能很有用。

note: type: Plain text
en: Specify how to handle `encoding` header in commit objects.  When asking to 'abort' (which is the default), this program will die when encountering such a commit object.  With 'yes', the commit message will be re-encoded into UTF-8.  With 'no', the original encoding will be preserved.
zh_HANS-CN: 指定如何处理提交对象中的 `encoding` （编码）头。 如果要求 'abort'（中止，默认值），程序将在遇到此类提交对象时结束。 如果使用 'yes'，提交信息将被重新编码为 UTF-8。 如果选择 'no'，则将保留原始编码。

note: type: Plain text
en: Apply the specified refspec to each ref exported. Multiple of them can be specified.
zh_HANS-CN: 对导出的每个引用应用指定的引用规范。可以指定多个。

note: type: Plain text
en: A list of arguments, acceptable to 'git rev-parse' and 'git rev-list', that specifies the specific objects and references to export.  For example, `master~10..master` causes the current master reference to be exported along with all objects added since its 10th ancestor commit and (unless the --reference-excluded-parents option is specified) all files common to master{tilde}9 and master{tilde}10.
zh_HANS-CN: 'git rev-parse' 和 'git rev-list' 可接受的参数列表，用于指定要导出的特定对象和引用。 例如，`master~10..master` 会导出当前的主引用，以及其第 10 次祖先提交后添加的所有对象，以及（除非指定了 --reference-excluded-parents 选项）master{tilde}9 和 master{tilde}10 的所有公共文件。

note: type: Plain text
en: This will export the whole repository and import it into the existing empty repository.  Except for reencoding commits that are not in UTF-8, it would be a one-to-one mirror.
zh_HANS-CN: 这将导出整个仓库，并导入现有的空仓库。 除了对非 UTF-8 版本的提交进行重新编码外，这将是一个一对一的镜像。

note: type: Plain text
en: This makes a new branch called 'other' from 'master~5..master' (i.e. if 'master' has linear history, it will take the last 5 commits).
zh_HANS-CN: 这样就从 'master~5..master' 中创建了一个名为 'other' 的新分支（也就是说，如果 'master' 的历史是线性的，那么它将采用最近的 5 次提交）。

note: type: Plain text
en: Note that this assumes that none of the blobs and commit messages referenced by that revision range contains the string 'refs/heads/master'.
zh_HANS-CN: 请注意，这是在假设该修订范围引用的 blob 和提交信息中没有包含 'refs/heads/master' 字符串。

note: type: Title -
en: ANONYMIZING
zh_HANS-CN: 匿名化

note: type: Plain text
en: If the `--anonymize` option is given, git will attempt to remove all identifying information from the repository while still retaining enough of the original tree and history patterns to reproduce some bugs. The goal is that a git bug which is found on a private repository will persist in the anonymized repository, and the latter can be shared with git developers to help solve the bug.
zh_HANS-CN: 如果给定了 `--anonymize` 选项，git 会尝试移除仓库中的所有身份信息，但仍会保留足够的原始树和历史模式来重现某些 bug。这样做的目的是，在私有仓库中发现的 git bug 会在匿名仓库中继续存在，而后者可以与 git 开发人员共享，以帮助解决 bug。

note: type: Plain text
en: With this option, git will replace all refnames, paths, blob contents, commit and tag messages, names, and email addresses in the output with anonymized data.  Two instances of the same string will be replaced equivalently (e.g., two commits with the same author will have the same anonymized author in the output, but bear no resemblance to the original author string). The relationship between commits, branches, and tags is retained, as well as the commit timestamps (but the commit messages and refnames bear no resemblance to the originals). The relative makeup of the tree is retained (e.g., if you have a root tree with 10 files and 3 trees, so will the output), but their names and the contents of the files will be replaced.
zh_HANS-CN: 使用该选项后，git 会用匿名数据替换输出中的所有引用名、路径、blob 内容、提交和标记信息、姓名和电子邮件地址。 同一字符串的两个实例将被等效替换（例如，两个提交的作者相同，输出中的匿名作者也相同，但与原始作者字符串并无相似之处）。提交、分支和标签之间的关系以及提交时间戳都会保留（但提交信息和引用名与原始信息没有任何相似之处）。保留树的相对构成（例如，如果根树有 10 个文件和 3 个树，输出也会保留），但文件名和文件内容会被替换。

note: type: Plain text
en: If you think you have found a git bug, you can start by exporting an anonymized stream of the whole repository:
zh_HANS-CN: 如果您认为自己发现了一个 git bug，可以从导出整个仓库的匿名流开始：

note: type: Plain text
en: Then confirm that the bug persists in a repository created from that stream (many bugs will not, as they really do depend on the exact repository contents):
zh_HANS-CN: 然后确认错误是否持续存在于根据该数据流创建的仓库中（许多错误不会持续存在，因为它们确实取决于仓库的确切内容）：

note: type: Plain text
en: If the anonymized repository shows the bug, it may be worth sharing `anon-stream` along with a regular bug report. Note that the anonymized stream compresses very well, so gzipping it is encouraged. If you want to examine the stream to see that it does not contain any private data, you can peruse it directly before sending. You may also want to try:
zh_HANS-CN: 如果匿名仓库显示了错误，则值得在提交常规错误报告的同时分享 `anon-stream`（匿名流）。请注意，匿名流的压缩效果非常好，因此建议将其压缩为 gzip 格式。如果您想检查流是否包含任何私人数据，可以在发送前直接阅读。您还可以尝试：

note: type: Plain text
en: which shows all of the unique lines (with numbers converted to "X", to collapse "User 0", "User 1", etc into "User X"). This produces a much smaller output, and it is usually easy to quickly confirm that there is no private data in the stream.
zh_HANS-CN: 显示所有的唯一行（数字转换为 "X"，将 "用户 0"、"用户 1" 等折叠为 "用户 X"）。这样产生的输出要小得多，而且通常很容易快速确认数据流中没有私人数据。

note: type: Plain text
en: Reproducing some bugs may require referencing particular commits or paths, which becomes challenging after refnames and paths have been anonymized. You can ask for a particular token to be left as-is or mapped to a new value. For example, if you have a bug which reproduces with `git rev-list sensitive -- secret.c`, you can run:
zh_HANS-CN: 重现某些错误可能需要引用特定的提交或路径，这在引用名和路径被匿名化后变得很有难度。您可以要求将特定标记保持原样或映射到一个新值。例如，如果有一个 bug 可以用 `git rev-list sensitive -- secret.c` 来重现，可以运行：

note: type: Plain text
en: After importing the stream, you can then run `git rev-list foo -- bar.c` in the anonymized repository.
zh_HANS-CN: 导入流之后，就可以在匿名仓库中运行 `git rev-list foo -- bar.c`。

note: type: Plain text
en: Note that paths and refnames are split into tokens at slash boundaries.  The command above would anonymize `subdir/secret.c` as something like `path123/bar.c`; you could then search for `bar.c` in the anonymized repository to determine the final pathname.
zh_HANS-CN: 请注意，路径和引用名会在斜线边界被分割成标记。 上面的命令会将 `subdir/secret.c` 匿名化为类似 `path123/bar.c` 的内容；然后你可以在匿名化的仓库中搜索 `bar.c` 以确定最终路径名。

note: type: Plain text
en: To make referencing the final pathname simpler, you can map each path component; so if you also anonymize `subdir` to `publicdir`, then the final pathname would be `publicdir/bar.c`.
zh_HANS-CN: 为了简化最终路径名的引用，可以对每个路径组件进行映射；因此，如果同时将 `subdir` 匿名化为 `publicdir`，那么最终路径名将是 `publicdir/bar.c`。

note: type: Plain text
en: Since 'git fast-import' cannot tag trees, you will not be able to export the linux.git repository completely, as it contains a tag referencing a tree instead of a commit.
zh_HANS-CN: 由于 'git fast-import' 无法对树进行标记，因此您将无法完全导出 linux.git 仓库，因为其中包含了一个引用树而非提交的标记。

note: type: Plain text
en: git-fast-import - Backend for fast Git data importers
zh_HANS-CN: git-fast-import - 快速 Git 数据导入的后端

note: type: Plain text
en: frontend | 'git fast-import' [<options>]
zh_HANS-CN: frontend | 'git fast-import' [<多个选项>]

note: type: Plain text
en: This program is usually not what the end user wants to run directly.  Most end users want to use one of the existing frontend programs, which parses a specific type of foreign source and feeds the contents stored there to 'git fast-import'.
zh_HANS-CN: 最终用户通常并不想直接运行这个程序。 大多数最终用户都希望使用现有的前端程序，这些程序会解析特定类型的外来源，并将其中存储的内容输入到 'git fast-import' 中。

note: type: Plain text
en: fast-import reads a mixed command/data stream from standard input and writes one or more packfiles directly into the current repository.  When EOF is received on standard input, fast import writes out updated branch and tag refs, fully updating the current repository with the newly imported data.
zh_HANS-CN: fast-import 从标准输入端读取混合命令/数据流，并将一个或多个文件包直接写入当前仓库。 当标准输入收到 EOF 时，fast import 会写出更新的分支和标记引用，用新导入的数据完全更新当前仓库。

note: type: Plain text
en: The fast-import backend itself can import into an empty repository (one that has already been initialized by 'git init') or incrementally update an existing populated repository.  Whether or not incremental imports are supported from a particular foreign source depends on the frontend program in use.
zh_HANS-CN: 快速导入后端本身可以导入一个空仓本库（一个已被 'git init' 初始化的仓库），也可以增量更新一个已填充的仓库。 是否支持从特定外来源增量导入，取决于所使用的前端程序。

note: type: Plain text
en: Force updating modified existing branches, even if doing so would cause commits to be lost (as the new commit does not contain the old commit).
zh_HANS-CN: 强制更新已修改的现有分支，即使这样做会导致提交丢失（因为新提交不包含旧提交）。

note: type: Plain text
en: Disable the output shown by --stats, making fast-import usually be silent when it is successful.  However, if the import stream has directives intended to show user output (e.g. `progress` directives), the corresponding messages will still be shown.
zh_HANS-CN: 禁用 --stats 显示的输出，使 fast-import 在成功导入时通常保持沉默。 不过，如果导入流中有用于显示用户输出的指令（如 `progress` 指令），则仍会显示相应的信息。

note: type: Plain text
en: Display some basic statistics about the objects fast-import has created, the packfiles they were stored into, and the memory used by fast-import during this run.  Showing this output is currently the default, but can be disabled with --quiet.
zh_HANS-CN: 显示 fast-import 创建的对象、这些对象存储在哪些文件包中，以及 fast-import 在运行过程中使用的内存等基本统计数据。 默认情况下显示此输出，但可使用 --quiet 关闭此功能。

note: type: Plain text
en: Many command-line options can be provided as part of the fast-import stream itself by using the `feature` or `option` commands. However, some of these options are unsafe (e.g., allowing fast-import to access the filesystem outside of the repository). These options are disabled by default, but can be allowed by providing this option on the command line.  This currently impacts only the `export-marks`, `import-marks`, and `import-marks-if-exists` feature commands.
zh_HANS-CN: 通过使用 `feature` 或 `option` 命令，许多命令行选项可以作为 fast-import 流本身的一部分提供。然而，其中一些选项是不安全的（例如，允许 fast-import 访问仓库之外的文件系统）。这些选项默认是禁用的，但可以通过在命令行中提供该选项来允许。 目前这只影响 `export-marks`、`import-marks` 和 `import-marks-if-exists`。

note: type: Plain text
en: Only enable this option if you trust the program generating the fast-import stream! This option is enabled automatically for remote-helpers that use the `import` capability, as they are already trusted to run their own code.
zh_HANS-CN: 只有在信任生成快速导入流的程序时，才能启用此选项！对于使用 `import` 功能的远程帮助程序，该选项会自动启用，因为它们已经被信任可以运行自己的代码。

note: type: Title ~
en: Options for Frontends
zh_HANS-CN: 前端的选项

note: type: Plain text
en: Write responses to `get-mark`, `cat-blob`, and `ls` queries to the file descriptor <fd> instead of `stdout`.  Allows `progress` output intended for the end-user to be separated from other output.
zh_HANS-CN: 将对 `get-mark`、`cat-blob` 和 `ls` 查询的响应写入文件描述符 <fd> 而不是 `stdout`。 允许将面向最终用户的 `progress` 输出与其他输出分开。

note: type: Plain text
en: Specify the type of dates the frontend will supply to fast-import within `author`, `committer` and `tagger` commands.  See ``Date Formats'' below for details about which formats are supported, and their syntax.
zh_HANS-CN: 指定前台在 `author`, `committer` 和 `tagger` 命令中提供给快速导入的日期类型。 有关支持的格式及其语法的详细信息，请参阅下面的 "日期格式"。

note: type: Plain text
en: Terminate with error if there is no `done` command at the end of the stream.  This option might be useful for detecting errors that cause the frontend to terminate before it has started to write a stream.
zh_HANS-CN: 如果数据流末尾没有 `done` 命令，则错误终止。 该选项可能有助于检测导致前端在开始写入数据流之前就终止的错误。

note: type: Title ~
en: Locations of Marks Files
zh_HANS-CN: 标记文件的位置

note: type: Plain text
en: Dumps the internal marks table to <file> when complete.  Marks are written one per line as `:markid SHA-1`.  Frontends can use this file to validate imports after they have been completed, or to save the marks table across incremental runs.  As <file> is only opened and truncated at checkpoint (or completion) the same path can also be safely given to --import-marks.
zh_HANS-CN: 完成后将内部标记表转存到 <文件> 中。 标记以 `:markid SHA-1` 的形式每行写一个。 前端可在导入完成后使用此文件验证导入，或在增量运行时保存标记表。 由于 <文件> 只在检查点（或完成时）打开和截断，因此同样的路径也可以安全地提供给 --import-marks 文件。

note: type: Plain text
en: Before processing any input, load the marks specified in <file>.  The input file must exist, must be readable, and must use the same format as produced by --export-marks.  Multiple options may be supplied to import more than one set of marks.  If a mark is defined to different values, the last file wins.
zh_HANS-CN: 在处理任何输入之前，加载 <文件> 中指定的标记。 输入文件必须存在，必须可读，必须使用与 --export-marks 生成的相同格式。 可以提供多个选项来导入多组标记。 如果一个标记被定义为不同的值，则以最后一个文件为准。

note: type: Plain text
en: Like --import-marks but instead of erroring out, silently skips the file if it does not exist.
zh_HANS-CN: 与 --import-marks 类似，但不会出错，而是在文件不存在时自动跳过。

note: type: Plain text
en: After specifying --relative-marks the paths specified with --import-marks= and --export-marks= are relative to an internal directory in the current repository.  In git-fast-import this means that the paths are relative to the .git/info/fast-import directory. However, other importers may use a different location.
zh_HANS-CN: 指定 --relative-marks（相对标记）后，用 --import-marks= 和 --export-marks= 指定的路径将相对于当前仓库的内部目录。 在 git-fast-import 中，这意味着路径是相对于 .git/info/fast-import 目录的。不过，其他导入程序可能会使用不同的位置。

note: type: Plain text
en: Relative and non-relative marks may be combined by interweaving --(no-)-relative-marks with the --(import|export)-marks= options.
zh_HANS-CN: 相对标记和非相对标记可以通过--(no-)-relative-marks 与--(import|export)-marks= 选项交织使用。

note: type: Title ~
en: Submodule Rewriting
zh_HANS-CN: 重写子模块

note: type: Plain text
en: Rewrite the object IDs for the submodule specified by <name> from the values used in the from <file> to those used in the to <file>. The from marks should have been created by `git fast-export`, and the to marks should have been created by `git fast-import` when importing that same submodule.
zh_HANS-CN: 将 <名称> 指定的子模块的对象 ID 从 from <文件> 中使用的值重写为 to <文件> 中使用的值。from 标记应由 `git fast-export` 创建，而 to 标记应在导入同一子模块时由 `git fast-import` 创建。

note: type: Plain text
en: <name> may be any arbitrary string not containing a colon character, but the same value must be used with both options when specifying corresponding marks.  Multiple submodules may be specified with different values for <name>. It is an error not to use these options in corresponding pairs.
zh_HANS-CN: <名称> 可以是不含冒号的任意字符串，但在指定相应标记时，两个选项必须使用相同的值。 可以使用不同的 <名称> 值指定多个子模块。不在相应的选项对中使用这些选项是错误的。

note: type: Plain text
en: These options are primarily useful when converting a repository from one hash algorithm to another; without them, fast-import will fail if it encounters a submodule because it has no way of writing the object ID into the new hash algorithm.
zh_HANS-CN: 这些选项主要用于将仓库从一种哈希算法转换为另一种哈希算法；如果没有这些选项，fast-import 在遇到子模块时就会失败，因为它无法将对象 ID 写入新的哈希算法。

note: type: Title ~
en: Performance and Compression Tuning
zh_HANS-CN: 性能和压缩调整

note: type: Plain text
en: Maximum number of branches to maintain active at once.  See ``Memory Utilization'' below for details.  Default is 5.
zh_HANS-CN: 同时激活的最大分支数。 详情请参阅下文的 "内存利用率"。 默认为 5。

note: type: Plain text
en: Maximum size of a blob that fast-import will attempt to create a delta for, expressed in bytes.  The default is 512m (512 MiB).  Some importers may wish to lower this on systems with constrained memory.
zh_HANS-CN: fast-import 将尝试创建 delta 的 blob 的最大大小，以字节为单位。 默认值为 512m（512MB）。 有些导入者可能希望在内存有限的系统上降低该值。

note: type: Plain text
en: Maximum delta depth, for blob and tree deltification.  Default is 50.
zh_HANS-CN: 用于 blob 和树形脱模的最大脱模深度。 默认值为 50。

note: type: Plain text
en: After creating a packfile, print a line of data to <file> listing the filename of the packfile and the last commit on each branch that was written to that packfile.  This information may be useful after importing projects whose total object set exceeds the 4 GiB packfile limit, as these commits can be used as edge points during calls to 'git pack-objects'.
zh_HANS-CN: 创建 packfile 后，向 <文件> 打印一行数据，列出 packfile 的文件名和写入该 packfile 的每个分支的最后一次提交。 在导入总对象集超过 4 GiB packfile 限制的项目后，这些信息可能会很有用，因为在调用 'git pack-objects' 时，这些提交可以用作边缘点。

note: type: Plain text
en: Maximum size of each output packfile.  The default is unlimited.
zh_HANS-CN: 每个输出包文件的最大大小。 默认为无限大。

note: type: Plain text
en: The design of fast-import allows it to import large projects in a minimum amount of memory usage and processing time.  Assuming the frontend is able to keep up with fast-import and feed it a constant stream of data, import times for projects holding 10+ years of history and containing 100,000+ individual commits are generally completed in just 1-2 hours on quite modest (~$2,000 USD) hardware.
zh_HANS-CN: fast-import 的设计使其能够以最少的内存占用和处理时间导入大型项目。 假设前端能够跟上 fast-import 的速度，并向其提供源源不断的数据流，那么对于拥有 10 年以上历史、包含 100,000 多次单独提交的项目，通常只需 1-2 个小时就能完成导入，而且硬件配置也不高（约 2,000 美元）。

note: type: Plain text
en: Most bottlenecks appear to be in foreign source data access (the source just cannot extract revisions fast enough) or disk IO (fast-import writes as fast as the disk will take the data).  Imports will run faster if the source data is stored on a different drive than the destination Git repository (due to less IO contention).
zh_HANS-CN: 大多数瓶颈似乎都出现在国外源数据访问（源无法以足够快的速度提取修订）或磁盘 IO（快速导入写入的速度与磁盘接受数据的速度一样快）上。 如果源数据存储在与目标 Git 仓库不同的驱动器上，导入速度会更快（因为 IO 竞争更少）。

note: type: Title -
en: DEVELOPMENT COST
zh_HANS-CN: 开发成本

note: type: Plain text
en: A typical frontend for fast-import tends to weigh in at approximately 200 lines of Perl/Python/Ruby code.  Most developers have been able to create working importers in just a couple of hours, even though it is their first exposure to fast-import, and sometimes even to Git.  This is an ideal situation, given that most conversion tools are throw-away (use once, and never look back).
zh_HANS-CN: 一个典型的快速导入前端往往需要大约 200 行 Perl/Python/Ruby 代码。 大多数开发人员都能在几个小时内创建出可用的导入程序，尽管这是他们第一次接触快速导入，有时甚至是第一次接触 Git。 鉴于大多数转换工具都是一次性工具（用过一次就不再回头），这种情况是最理想的。

note: type: Title -
en: PARALLEL OPERATION
zh_HANS-CN: 并行操作

note: type: Plain text
en: Like 'git push' or 'git fetch', imports handled by fast-import are safe to run alongside parallel `git repack -a -d` or `git gc` invocations, or any other Git operation (including 'git prune', as loose objects are never used by fast-import).
zh_HANS-CN: 与 'git push' 或 'git fetch' 一样，由 fast-import 处理的导入可以安全地与并行的 `git repack -a -d` 或 `git gc`调用，或任何其他 Git 操作（包括 'git prune'，因为 fast-import 从不使用松散对象）同时运行。

note: type: Plain text
en: fast-import does not lock the branch or tag refs it is actively importing.  After the import, during its ref update phase, fast-import tests each existing branch ref to verify the update will be a fast-forward update (the commit stored in the ref is contained in the new history of the commit to be written).  If the update is not a fast-forward update, fast-import will skip updating that ref and instead prints a warning message.  fast-import will always attempt to update all branch refs, and does not stop on the first failure.
zh_HANS-CN: fast-import 不会锁定正在导入的分支或标签引用。 导入后，在引用更新阶段，fast-import 会测试每个现有分支引用，以验证更新是否为快进更新（存储在引用中的提交包含在要写入的提交的新历史中）。 如果更新不是快进更新，fast-import 会跳过更新该引用，并打印警告信息。fast-import 会一直尝试更新所有分支引用，不会因为第一次失败而停止。

note: type: Plain text
en: Branch updates can be forced with --force, but it's recommended that this only be used on an otherwise quiet repository.  Using --force is not necessary for an initial import into an empty repository.
zh_HANS-CN: 分支更新可以使用 --force 强制进行，但建议只在没有更新的仓库中使用。 初次导入空仓库时，无需使用 --force。

note: type: Title -
en: TECHNICAL DISCUSSION
zh_HANS-CN: 技术探讨

note: type: Plain text
en: fast-import tracks a set of branches in memory.  Any branch can be created or modified at any point during the import process by sending a `commit` command on the input stream.  This design allows a frontend program to process an unlimited number of branches simultaneously, generating commits in the order they are available from the source data.  It also simplifies the frontend programs considerably.
zh_HANS-CN: fast-import 会在内存中跟踪一组分支。 在导入过程中，任何分支都可以通过向输入流发送 `commit` 命令来创建或修改。 这种设计允许前端程序同时处理数量不限的分支，并按照源数据的顺序生成提交。 这也大大简化了前端程序。

note: type: Plain text
en: fast-import does not use or alter the current working directory, or any file within it.  (It does however update the current Git repository, as referenced by `GIT_DIR`.)  Therefore an import frontend may use the working directory for its own purposes, such as extracting file revisions from the foreign source.  This ignorance of the working directory also allows fast-import to run very quickly, as it does not need to perform any costly file update operations when switching between branches.
zh_HANS-CN: fast-import 不会使用或更改当前工作目录或其中的任何文件。 (但它会更新当前的 Git 仓库，正如 `GIT_DIR` 所引用的那样）。 因此，导入前端可能会出于自己的目的使用工作目录，比如从外来源中提取文件修订版。 这种对工作目录的无视也使得 fast-import 可以非常快速地运行，因为在分支间切换时，它不需要执行任何代价高昂的文件更新操作。

note: type: Title -
en: INPUT FORMAT
zh_HANS-CN: 输入格式

note: type: Plain text
en: With the exception of raw file data (which Git does not interpret)  the fast-import input format is text (ASCII) based.  This text based format simplifies development and debugging of frontend programs, especially when a higher level language such as Perl, Python or Ruby is being used.
zh_HANS-CN: 除了原始文件数据（Git 不会对其进行解释），快速导入输入格式都是基于文本（ASCII）的。 这种基于文本的格式简化了前端程序的开发和调试，尤其是在使用 Perl、Python 或 Ruby 等高级语言的情况下。

note: type: Plain text
en: fast-import is very strict about its input.  Where we say SP below we mean *exactly* one space.  Likewise LF means one (and only one) linefeed and HT one (and only one) horizontal tab.  Supplying additional whitespace characters will cause unexpected results, such as branch names or file names with leading or trailing spaces in their name, or early termination of fast-import when it encounters unexpected input.
zh_HANS-CN: fast-import 对输入的要求非常严格。 我们在下文中所说的 SP 是指一个空格。 同样，LF 表示一个（且只有一个）换行符，HT 表示一个（且只有一个）水平制表符。 提供额外的空格字符会导致意想不到的结果，如分支名称或文件名称中包含前导空格或尾部空格，或当 fast-import 遇到意外输入时提前终止。

note: type: Title ~
en: Stream Comments
zh_HANS-CN: 流评论

note: type: Plain text
en: To aid in debugging frontends fast-import ignores any line that begins with `#` (ASCII pound/hash) up to and including the line ending `LF`.  A comment line may contain any sequence of bytes that does not contain an LF and therefore may be used to include any detailed debugging information that might be specific to the frontend and useful when inspecting a fast-import data stream.
zh_HANS-CN: 为了帮助调试前端，fast-import 会忽略任何以 `#`（ASCII 磅/散列）开头的行，包括以 `LF` 结尾的行。 注释行可以包含任何不包含 LF 的字节序列，因此可以用来包含任何详细的调试信息，这些信息可能是前端特有的，在检查 fast-import 数据流时也很有用。

note: type: Plain text
en: The following date formats are supported.  A frontend should select the format it will use for this import by passing the format name in the --date-format=<fmt> command-line option.
zh_HANS-CN: 支持以下日期格式。 前台应通过在 --date-format=<日期格式> 命令行选项中传递格式名称来选择导入时使用的格式。

note: type: Plain text
en: This is the Git native format and is `<time> SP <offutc>`.  It is also fast-import's default format, if --date-format was not specified.
zh_HANS-CN: 这是 Git 的本地格式，为 `<time> SP <offutc>`。 如果没有指定 --date-format 格式，它也是 fast-import 的默认格式。

note: type: Plain text
en: The time of the event is specified by `<time>` as the number of seconds since the UNIX epoch (midnight, Jan 1, 1970, UTC) and is written as an ASCII decimal integer.
zh_HANS-CN: 事件发生的时间由 `<时间>` 指定，是自 UNIX 纪元（世界协调时 1970 年 1 月 1 日午夜）以来的秒数，并写成 ASCII 十进制整数。

note: type: Plain text
en: If the local offset is not available in the source material, use ``+0000'', or the most common local offset.  For example many organizations have a CVS repository which has only ever been accessed by users who are located in the same location and time zone.  In this case a reasonable offset from UTC could be assumed.
zh_HANS-CN: 如果源材料中没有本地偏移量，则使用 ''+0000'' 或最常用的本地偏移量。 例如，许多组织都有一个 CVS 仓库，只有位于同一地点和时区的用户才能访问该仓库。 在这种情况下，可以假定与 UTC 有合理的偏移。

note: type: Plain text
en: Unlike the `rfc2822` format, this format is very strict.  Any variation in formatting will cause fast-import to reject the value, and some sanity checks on the numeric values may also be performed.
zh_HANS-CN: 与 `rfc2822` 格式不同，该格式非常严格。 格式上的任何变化都会导致 fast-import 拒绝该值，同时也会对数值进行一些正确性检查。

note: type: Plain text
en: This is the same as `raw` except that no sanity checks on the numeric epoch and local offset are performed.  This can be useful when trying to filter or import an existing history with e.g. bogus timezone values.
zh_HANS-CN: 这与 `raw` 相同，只是不对数字纪元和本地偏移进行正确性检查。 这在过滤或导入包含错误时区值等内容的现有历史记录时非常有用。

note: type: Plain text
en: This is the standard email format as described by RFC 2822.
zh_HANS-CN: 这是 RFC 2822 所描述的标准电子邮件格式。

note: type: Plain text
en: An example value is ``Tue Feb 6 11:22:18 2007 -0500''.  The Git parser is accurate, but a little on the lenient side.  It is the same parser used by 'git am' when applying patches received from email.
zh_HANS-CN: 示例值为 ''Tue Feb 6 11:22:18 2007 -0500''。 Git 解析器很准确，但有点偏宽松。 它与 'git am' 在应用从电子邮件收到的补丁时使用的解析器相同。

note: type: Plain text
en: Some malformed strings may be accepted as valid dates.  In some of these cases Git will still be able to obtain the correct date from the malformed string.  There are also some types of malformed strings which Git will parse wrong, and yet consider valid.  Seriously malformed strings will be rejected.
zh_HANS-CN: 有些畸形字符串可能会被当作有效日期。 在某些情况下，Git 仍能从畸形字符串中获取正确的日期。 还有一些类型的畸形字符串，Git 会将其解析为错误，但认为是有效的。 严重的畸形字符串将被拒绝。

note: type: Plain text
en: Unlike the `raw` format above, the time zone/UTC offset information contained in an RFC 2822 date string is used to adjust the date value to UTC prior to storage.  Therefore it is important that this information be as accurate as possible.
zh_HANS-CN: 与上述 `raw` 格式不同，RFC 2822 日期字符串中包含的时区/UTC 偏移信息用于在存储前将日期值调整为 UTC。 因此，该信息必须尽可能准确。

note: type: Plain text
en: If the source material uses RFC 2822 style dates, the frontend should let fast-import handle the parsing and conversion (rather than attempting to do it itself) as the Git parser has been well tested in the wild.
zh_HANS-CN: 如果源材料使用 RFC 2822 样式的日期，前台应让 fast-import 处理解析和转换（而不是自己尝试），因为 Git 解析器已在野外进行了良好的测试。

note: type: Plain text
en: Frontends should prefer the `raw` format if the source material already uses UNIX-epoch format, can be coaxed to give dates in that format, or its format is easily convertible to it, as there is no ambiguity in parsing.
zh_HANS-CN: 如果源材料已经使用了 UNIX-epoch 格式，或者可以哄骗源材料以该格式提供日期，或者源材料的格式很容易转换成该格式（因为在解析时不会产生歧义），那么前端程序应优先使用 `raw` 格式。

note: type: Plain text
en: Always use the current time and time zone.  The literal `now` must always be supplied for `<when>`.
zh_HANS-CN: 始终使用当前时间和时区。 必须始终为 `<when>` 提供字面意义上的 `now`。

note: type: Plain text
en: This is a toy format.  The current time and time zone of this system is always copied into the identity string at the time it is being created by fast-import.  There is no way to specify a different time or time zone.
zh_HANS-CN: 这是一种玩具格式。 在通过快速导入创建身份字符串时，系统的当前时间和时区总是被复制到身份字符串中。 无法指定不同的时间或时区。

note: type: Plain text
en: This particular format is supplied as it's short to implement and may be useful to a process that wants to create a new commit right now, without needing to use a working directory or 'git update-index'.
zh_HANS-CN: 提供这种格式的原因是，它的实现时间很短，而且可能对想要立即创建新提交的进程很有用，而不需要使用工作目录或 'git update-index'。

note: type: Plain text
en: If separate `author` and `committer` commands are used in a `commit` the timestamps may not match, as the system clock will be polled twice (once for each command).  The only way to ensure that both author and committer identity information has the same timestamp is to omit `author` (thus copying from `committer`) or to use a date format other than `now`.
zh_HANS-CN: 如果在 `commit` 中分别使用了 `authoe` 和 `committer` 命令，时间戳可能会不一致，因为系统时钟会轮询两次（每条命令一次）。 确保作者和提交者身份信息具有相同时间戳的唯一方法是省略 `author` 命令（因此从 `committer` 命令复制），或使用除 `now` 以外的其他日期格式。

note: type: Plain text
en: fast-import accepts several commands to update the current repository and control the current import process.  More detailed discussion (with examples) of each command follows later.
zh_HANS-CN: fast-import 接受多条命令来更新当前仓库和控制当前导入过程。 稍后将对每条命令进行更详细的讨论（附示例）。

note: type: Plain text
en: Creates a new branch or updates an existing branch by creating a new commit and updating the branch to point at the newly created commit.
zh_HANS-CN: 通过创建新提交并更新分支以指向新创建的提交，创建新分支或更新现有分支。

note: type: Plain text
en: Creates an annotated tag object from an existing commit or branch.  Lightweight tags are not supported by this command, as they are not recommended for recording meaningful points in time.
zh_HANS-CN: 从现有提交或分支创建注释标签对象。 此命令不支持轻量级标记，因为不建议用它们来记录有意义的时间点。

note: type: Plain text
en: Reset an existing branch (or a new branch) to a specific revision.  This command must be used to change a branch to a specific revision without making a commit on it.
zh_HANS-CN: 将现有分支（或新分支）重置为特定版本。 必须使用这条命令，才能在不提交的情况下，将分支更改为特定版本。

note: type: Plain text
en: Convert raw file data into a blob, for future use in a `commit` command.  This command is optional and is not needed to perform an import.
zh_HANS-CN: 将原始文件数据转换为 blob，以便将来在 `commit` 命令中使用。 该命令是可选的，执行导入时不需要。

note: type: Plain text
en: Record that a mark refers to a given object without first creating any new object.  Using --import-marks and referring to missing marks will cause fast-import to fail, so aliases can provide a way to set otherwise pruned commits to a valid value (e.g. the nearest non-pruned ancestor).
zh_HANS-CN: 在不创建任何新对象的情况下，记录一个标记指向一个给定对象。 使用 --import-marks 并引用缺失的标记会导致 fast-import 失败，因此别名可以提供一种方法，将原本已剪枝的提交设置为有效值（例如最近的未剪枝祖先）。

note: type: Plain text
en: Forces fast-import to close the current packfile, generate its unique SHA-1 checksum and index, and start a new packfile.  This command is optional and is not needed to perform an import.
zh_HANS-CN: 强制 fast-import 关闭当前包文件，生成其唯一的 SHA-1 校验和和索引，并启动一个新的包文件。 此命令为可选命令，执行导入时无需使用。

note: type: Plain text
en: Causes fast-import to echo the entire line to its own standard output.  This command is optional and is not needed to perform an import.
zh_HANS-CN: 使 fast-import 将整行内容回传至自己的标准输出。 该命令是可选的，执行导入时不需要它。

note: type: Plain text
en: Marks the end of the stream. This command is optional unless the `done` feature was requested using the `--done` command-line option or `feature done` command.
zh_HANS-CN: 标记数据流的结束。除非使用 `--done` 命令行选项或 `feature done` 命令要求使用 `done` 功能，否则该命令是可选的。

note: type: Plain text
en: Causes fast-import to print the SHA-1 corresponding to a mark to the file descriptor set with `--cat-blob-fd`, or `stdout` if unspecified.
zh_HANS-CN: 使 fast-import 向使用 `--cat-blob-fd` 设置的文件描述符打印标记对应的 SHA-1 值，如果未指定，则打印 `stdout`。

note: type: Plain text
en: Causes fast-import to print a blob in 'cat-file --batch' format to the file descriptor set with `--cat-blob-fd` or `stdout` if unspecified.
zh_HANS-CN: 使 fast-import 以 'cat-file --batch' 格式向使用 `--cat-blob-fd` 或 `stdout` 设置的文件描述符打印 blob。

note: type: Plain text
en: Causes fast-import to print a line describing a directory entry in 'ls-tree' format to the file descriptor set with `--cat-blob-fd` or `stdout` if unspecified.
zh_HANS-CN: 使 fast-import 以 'ls-tree' 格式向使用 `--cat-blob-fd` 或 `stdout` 设置的文件描述符打印描述目录条目的行。

note: type: Plain text
en: Enable the specified feature. This requires that fast-import supports the specified feature, and aborts if it does not.
zh_HANS-CN: 启用指定功能。这要求 fast-import 支持指定的功能，如果不支持则会终止。

note: type: Plain text
en: Specify any of the options listed under OPTIONS that do not change stream semantic to suit the frontend's needs. This command is optional and is not needed to perform an import.
zh_HANS-CN: 指定 "选项"（OPTIONS）中列出的任何选项，这些选项不会改变流语义以适应前台的需要。此命令为可选项，执行导入时不需要。

note: type: Plain text
en: Create or update a branch with a new commit, recording one logical change to the project.
zh_HANS-CN: 用新的提交创建或更新分支，记录项目的逻辑变更。

note: type: delimited block .
en: 	'commit' SP <ref> LF
    	mark?
    	original-oid?
    	('author' (SP <name>)? SP LT <email> GT SP <when> LF)?
    	'committer' (SP <name>)? SP LT <email> GT SP <when> LF
    	('encoding' SP <encoding>)?
    	data
    	('from' SP <commit-ish> LF)?
    	('merge' SP <commit-ish> LF)*
    	(filemodify | filedelete | filecopy | filerename | filedeleteall | notemodify)*
    	LF?
zh_HANS-CN: 	'commit' SP <引用> LF
    	mark?
    	original-oid?
    	('author' (SP <名称>)? SP LT <email> GT SP <when> LF)?
    	'committer' (SP <名称>)? SP LT <email> GT SP <when> LF
    	('encoding' SP <编码>)?
    	data
    	('from' SP <提交号> LF)?
    	('merge' SP <提交号> LF)*
    	(filemodify | filedelete | filecopy | filerename | filedeleteall | notemodify)*
    	LF?

note: type: Plain text
en: where `<ref>` is the name of the branch to make the commit on.  Typically branch names are prefixed with `refs/heads/` in Git, so importing the CVS branch symbol `RELENG-1_0` would use `refs/heads/RELENG-1_0` for the value of `<ref>`.  The value of `<ref>` must be a valid refname in Git.  As `LF` is not valid in a Git refname, no quoting or escaping syntax is supported here.
zh_HANS-CN: 其中 `<引用>` 是要提交的分支名称。 在 Git 中，分支名称通常以 `refs/heads/` 为前缀，因此导入 CVS 分支符号 `RELENG-1_0` 时，`<引用>` 的值应为 `refs/heads/RELENG-1_0`。 在 Git 中，`<引用>` 的值必须是有效的引用名称。 由于 `LF` 在 Git 引用名称中无效，因此此处不支持引号或转义语法。

note: type: Plain text
en: A `mark` command may optionally appear, requesting fast-import to save a reference to the newly created commit for future use by the frontend (see below for format).  It is very common for frontends to mark every commit they create, thereby allowing future branch creation from any imported commit.
zh_HANS-CN: `mark`（标记）命令可能会出现，要求 fast-import 保存新创建提交的引用，供前端将来使用（格式见下文）。 前端通常会标记他们创建的每个提交，从而允许将来从任何导入的提交中创建分支。

note: type: Plain text
en: The `data` command following `committer` must supply the commit message (see below for `data` command syntax).  To import an empty commit message use a 0 length data.  Commit messages are free-form and are not interpreted by Git.  Currently they must be encoded in UTF-8, as fast-import does not permit other encodings to be specified.
zh_HANS-CN: 在 `committer` 之后的 `data` 命令必须提供提交信息（请参阅下面的 `data` 命令语法）。 要导入空的提交信息，请使用长度为 0 的数据。 提交信息是自由格式的，Git 无法解释。 目前它们必须以 UTF-8 编码，因为 fast-import 不允许指定其他编码。

note: type: Plain text
en: Zero or more `filemodify`, `filedelete`, `filecopy`, `filerename`, `filedeleteall` and `notemodify` commands may be included to update the contents of the branch prior to creating the commit.  These commands may be supplied in any order.  However it is recommended that a `filedeleteall` command precede all `filemodify`, `filecopy`, `filerename` and `notemodify` commands in the same commit, as `filedeleteall` wipes the branch clean (see below).
zh_HANS-CN: 在创建提交之前，可以包含零个或多个 `filemodify`, `filedelete`, `filecopy`, `filerename`, `filedeleteall` 和 `notemodify` 命令来更新分支的内容。 这些命令可以任意顺序提供。 不过，我们建议在同一提交中的所有 `filemodify`, `filecopy`, `filerename` 和 `notemodify` 命令之前都加上 `filedeleteall` 命令，因为 `filedeleteall` 会将分支清除干净（见下文）。

note: type: Plain text
en: The `LF` after the command is optional (it used to be required).  Note that for reasons of backward compatibility, if the commit ends with a `data` command (i.e. it has no `from`, `merge`, `filemodify`, `filedelete`, `filecopy`, `filerename`, `filedeleteall` or `notemodify` commands) then two `LF` commands may appear at the end of the command instead of just one.
zh_HANS-CN: 命令后的 `LF` 是可选的（以前是必须的）。 请注意，出于向后兼容性的考虑，如果提交以一条 `data` 命令结束（即没有 `from`、`mmerge`、`filemodify`、`filedelete`、`filecopy`、`filerename`、`filedeleteall` 或 `notemodify` 命令），那么命令末尾可能会出现两条 `LF` 命令，而不是只有一条。

note: type: Plain text
en: An `author` command may optionally appear, if the author information might differ from the committer information.  If `author` is omitted then fast-import will automatically use the committer's information for the author portion of the commit.  See below for a description of the fields in `author`, as they are identical to `committer`.
zh_HANS-CN: 如果作者信息可能与提交者信息不同，可选择使用 `author` 命令。 如果省略了 `author` 命令，那么 fast-import 将自动使用提交者的信息来处理提交的作者部分。 有关 `author` 字段的描述，请参阅下文，因为它们与 `committer` 相同。

note: type: Plain text
en: The `committer` command indicates who made this commit, and when they made it.
zh_HANS-CN: `committer` 命令会显示谁提交了该提交，以及提交的时间。

note: type: Plain text
en: Here `<name>` is the person's display name (for example ``Com M Itter'') and `<email>` is the person's email address (``\cm@example.com'').  `LT` and `GT` are the literal less-than (\x3c)  and greater-than (\x3e) symbols.  These are required to delimit the email address from the other fields in the line.  Note that `<name>` and `<email>` are free-form and may contain any sequence of bytes, except `LT`, `GT` and `LF`.  `<name>` is typically UTF-8 encoded.
zh_HANS-CN: 这里的`<名称>`是个人的显示名（例如 ''Com M Itter''），`<email>`是个人的电子邮件地址（''\cm@example.com''）。 `LT` 和 `GT` 是字面上的小于（\x3c）和大于（\x3e）符号。 需要使用这些符号将电子邮件地址与行中的其他字段分隔开来。 请注意，`<名称>` 和 `<email>`是自由格式，可以包含任何字节序列，但 `LT`、`GT` 和`LF` 除外。 `<名称>` 通常采用 UTF-8 编码。

note: type: Plain text
en: The time of the change is specified by `<when>` using the date format that was selected by the --date-format=<fmt> command-line option.  See ``Date Formats'' above for the set of supported formats, and their syntax.
zh_HANS-CN: 更改的时间由 `<when>`指定，并使用 --date-format=<日期格式> 命令行选项选择的日期格式。 有关支持的格式及其语法，请参阅上文的 ''日期格式''。

note: type: Plain text
en: The optional `encoding` command indicates the encoding of the commit message.  Most commits are UTF-8 and the encoding is omitted, but this allows importing commit messages into git without first reencoding them.
zh_HANS-CN: 可选的 `encoding` 命令表示提交信息的编码。 大多数提交信息都是 UTF-8 编码，编码可以省略，但这样就可以将提交信息导入 git 而无需先重新编码。

note: type: Plain text
en: The `from` command is used to specify the commit to initialize this branch from.  This revision will be the first ancestor of the new commit.  The state of the tree built at this commit will begin with the state at the `from` commit, and be altered by the content modifications in this commit.
zh_HANS-CN: `from` 命令用于指定从哪个提交开始初始化分支。 此修订将成为新提交的第一个祖先。 在此提交中构建的树的状态将从 `from` 提交中的状态开始，并由此提交中的内容修改所改变。

note: type: Plain text
en: Omitting the `from` command in the first commit of a new branch will cause fast-import to create that commit with no ancestor. This tends to be desired only for the initial commit of a project.  If the frontend creates all files from scratch when making a new branch, a `merge` command may be used instead of `from` to start the commit with an empty tree.  Omitting the `from` command on existing branches is usually desired, as the current commit on that branch is automatically assumed to be the first ancestor of the new commit.
zh_HANS-CN: 在新分支的第一次提交中省略 `from` 命令会导致 fast-import 创建的提交没有祖先。这往往只适用于项目的首次提交。 如果前端在创建新分支时从头开始创建所有文件，则可以使用 `merge` 命令代替 `from` 命令，以空树开始提交。 在现有分支上，通常希望省略 `from` 命令，因为该分支上的当前提交会被自动假定为新提交的第一个祖先。

note: type: Plain text
en: As `LF` is not valid in a Git refname or SHA-1 expression, no quoting or escaping syntax is supported within `<commit-ish>`.
zh_HANS-CN: 由于 `LF` 在 Git 引用名称或 SHA-1 表达式中无效，因此 `<提交号>` 中不支持引号或转义语法。

note: type: Plain text
en: Here `<commit-ish>` is any of the following:
zh_HANS-CN: 这里的 `<提交号>` 是指以下任何一种：

note: type: Plain text
en: The name of an existing branch already in fast-import's internal branch table.  If fast-import doesn't know the name, it's treated as a SHA-1 expression.
zh_HANS-CN: fast-import 内部分支表中现有分支的名称。 如果 fast-import 不知道该名称，则将其视为 SHA-1 表达式。

note: type: Plain text
en: A mark reference, `:<idnum>`, where `<idnum>` is the mark number.
zh_HANS-CN: 标记引用，`<idnum>`，其中 `<idnum>`是标记编号。

note: type: Plain text
en: The reason fast-import uses `:` to denote a mark reference is this character is not legal in a Git branch name.  The leading `:` makes it easy to distinguish between the mark 42 (`:42`) and the branch 42 (`42` or `refs/heads/42`), or an abbreviated SHA-1 which happened to consist only of base-10 digits.
zh_HANS-CN: fast-import 使用 `:` 表示标记引用的原因是，这个字符在 Git 分支名称中是不合法的。 前导的 `:` 便于区分标记 42 (`:42`)和分支 42 (`42` 或 `refs/heads/42`)，或缩写的 SHA-1，而后者恰好只由基数为 10 的数字组成。

note: type: Plain text
en: Marks must be declared (via `mark`) before they can be used.
zh_HANS-CN: 标记必须先声明（通过 `mark` ）才能使用。

note: type: Plain text
en: A complete 40 byte or abbreviated commit SHA-1 in hex.
zh_HANS-CN: 以十六进制表示的完整的 40 字节或缩写的 SHA-1 提交。

note: type: Plain text
en: Any valid Git SHA-1 expression that resolves to a commit.  See ``SPECIFYING REVISIONS'' in linkgit:gitrevisions[7] for details.
zh_HANS-CN: 任何解析为提交的有效 Git SHA-1 表达式。 详见 linkgit:gitrevisions[7] 中的 ''指定修订格式''。

note: type: Plain text
en: The special null SHA-1 (40 zeros) specifies that the branch is to be removed.
zh_HANS-CN: 特殊的空 SHA-1（40 个零）表示要删除分支。

note: type: Plain text
en: The special case of restarting an incremental import from the current branch value should be written as:
zh_HANS-CN: 从当前分支值重新开始增量导入的特殊情况应写为：

note: type: Plain text
en: The `^0` suffix is necessary as fast-import does not permit a branch to start from itself, and the branch is created in memory before the `from` command is even read from the input.  Adding `^0` will force fast-import to resolve the commit through Git's revision parsing library, rather than its internal branch table, thereby loading in the existing value of the branch.
zh_HANS-CN: 后缀 `^0` 是必要的，因为 fast-import 不允许分支从自身开始，分支会在从输入的 `from` 命令读取之前在内存中创建。 添加 `^0` 会强制 fast-import 通过 Git 的修订解析库而非内部分支表来解析提交，从而加载分支的现有值。

note: type: Plain text
en: Includes one additional ancestor commit.  The additional ancestry link does not change the way the tree state is built at this commit.  If the `from` command is omitted when creating a new branch, the first `merge` commit will be the first ancestor of the current commit, and the branch will start out with no files.  An unlimited number of `merge` commands per commit are permitted by fast-import, thereby establishing an n-way merge.
zh_HANS-CN: 包括一个额外的祖先提交。 额外的祖先链接不会改变本次提交的树状态构建方式。 如果在创建新分支时省略了 `from` 命令，则第一个 `merge` 提交将是当前提交的第一个祖先，分支开始时将没有文件。 fast-import 允许在每次提交中使用不限次数的 `merge` 命令，从而建立 n 路合并。

note: type: Plain text
en: Here `<commit-ish>` is any of the commit specification expressions also accepted by `from` (see above).
zh_HANS-CN: 这里的 `<提交号>` 是`from` 也接受的任何提交规范表达式（见上文）。

note: type: Plain text
en: Included in a `commit` command to add a new file or change the content of an existing file.  This command has two different means of specifying the content of the file.
zh_HANS-CN: 包含在 `commit` 命令中，用于添加新文件或更改现有文件的内容。 该命令有两种指定文件内容的不同方式。

note: type: Labeled list
en: External data format
zh_HANS-CN: 外部数据格式

note: type: Plain text
en: The data content for the file was already supplied by a prior `blob` command.  The frontend just needs to connect it.
zh_HANS-CN: 文件的数据内容已由之前的 `blob` 命令提供。 前台只需将其连接起来即可。

note: type: Plain text
en: Here usually `<dataref>` must be either a mark reference (`:<idnum>`)  set by a prior `blob` command, or a full 40-byte SHA-1 of an existing Git blob object.  If `<mode>` is `040000`` then `<dataref>` must be the full 40-byte SHA-1 of an existing Git tree object or a mark reference set with `--import-marks`.
zh_HANS-CN: 通常情况下，`<数据引用>` 必须是由之前的 `blob` 命令设置的标记引用 (`:<idnum>`)，或者是现有 Git blob 对象的完整 40 字节 SHA-1 值。 如果 `<模式>` 是 `040000``，则 `<数据引用>` 必须是现有 Git 树对象的完整 40 字节 SHA-1 或用 `--import-marks` 设置的标记引用。

note: type: Labeled list
en: Inline data format
zh_HANS-CN: 内联数据格式

note: type: Plain text
en: The data content for the file has not been supplied yet.  The frontend wants to supply it as part of this modify command.
zh_HANS-CN: 文件的数据内容尚未提供。 前台希望将其作为该修改命令的一部分提供。

note: type: delimited block .
en: 	'M' SP <mode> SP 'inline' SP <path> LF
    	data
zh_HANS-CN: 	'M' SP <模式> SP 'inline' SP <路径> LF
    	data

note: type: Plain text
en: See below for a detailed description of the `data` command.
zh_HANS-CN: 有关 `data` 命令的详细说明，请参阅下文。

note: type: Plain text
en: In both formats `<mode>` is the type of file entry, specified in octal.  Git only supports the following modes:
zh_HANS-CN: 在这两种格式中，`<模式>` 都是以八进制指定的文件类型。 Git 仅支持以下模式：

note: type: Plain text
en: `100644` or `644`: A normal (not-executable) file.  The majority of files in most projects use this mode.  If in doubt, this is what you want.
zh_HANS-CN: `100644` 或 `644`： 普通（不可执行）文件。 大多数项目中的大部分文件都使用这种模式。 如果不知道用什么格式，请使用这种模式。

note: type: Plain text
en: `100755` or `755`: A normal, but executable, file.
zh_HANS-CN: `100755` 或 `755`： 一个普通但可执行的文件。

note: type: Plain text
en: `120000`: A symlink, the content of the file will be the link target.
zh_HANS-CN: `120000` ：符号链接，文件内容将成为链接目标。

note: type: Plain text
en: `160000`: A gitlink, SHA-1 of the object refers to a commit in another repository. Git links can only be specified by SHA or through a commit mark. They are used to implement submodules.
zh_HANS-CN: `160000` ： 一个 Git 链接，对象的 SHA-1 指向另一个仓库中的提交。Git 链接只能通过 SHA 或提交标记指定。它们用于实现子模块。

note: type: Plain text
en: `040000`: A subdirectory.  Subdirectories can only be specified by SHA or through a tree mark set with `--import-marks`.
zh_HANS-CN: `040000` ：子目录。 子目录只能通过 SHA 或使用 `--import-marks` 设置的树形标记来指定。

note: type: Plain text
en: In both formats `<path>` is the complete path of the file to be added (if not already existing) or modified (if already existing).
zh_HANS-CN: 在这两种格式中，`<路径>` 都是要添加（如果尚未存在）或修改（如果已经存在）的文件的完整路径。

note: type: Plain text
en: A `<path>` string must use UNIX-style directory separators (forward slash `/`), may contain any byte other than `LF`, and must not start with double quote (`"`).
zh_HANS-CN: `<路径>` 字符串必须使用 UNIX 风格的目录分隔符（正斜杠 `/`），可以包含除 `LF` 以外的任何字节，且不得以双引号 (`"`) 开头。

note: type: Plain text
en: A path can use C-style string quoting; this is accepted in all cases and mandatory if the filename starts with double quote or contains `LF`. In C-style quoting, the complete name should be surrounded with double quotes, and any `LF`, backslash, or double quote characters must be escaped by preceding them with a backslash (e.g., `"path/with\n, \\ and \" in it"`).
zh_HANS-CN: 路径可以使用 C 风格字符串引号；在任何情况下都可以使用，如果文件名以双引号开头或包含 `LF`，则必须使用。在 C 风格引号中，完整的名称应该用双引号括起来，任何 `LF`、反斜杠或双引号字符都必须用反斜杠括起来（例如，`"path/with\n, \\ and \" in it"`）。

note: type: Plain text
en: The value of `<path>` must be in canonical form. That is it must not:
zh_HANS-CN: `<路径>` 的值必须是规范格式。也就是说，绝不能是：

note: type: Plain text
en: contain an empty directory component (e.g. `foo//bar` is invalid),
zh_HANS-CN: 包含一个空目录组件（如 `foo//bar` 就是无效的），

note: type: Plain text
en: end with a directory separator (e.g. `foo/` is invalid),
zh_HANS-CN: 以目录分隔符结尾（如 `foo/` 是无效的），

note: type: Plain text
en: start with a directory separator (e.g. `/foo` is invalid),
zh_HANS-CN: 以目录分隔符开头（如 `/foo` 是无效的），

note: type: Plain text
en: contain the special component `.` or `..` (e.g. `foo/./bar` and `foo/../bar` are invalid).
zh_HANS-CN: 包含特殊成分 `.` 或 `..`（例如，`foo/./bar` 和 `foo/../bar` 是无效的）。

note: type: Plain text
en: The root of the tree can be represented by an empty string as `<path>`.
zh_HANS-CN: 树根可以用空字符 `<路径>` 表示。

note: type: Plain text
en: It is recommended that `<path>` always be encoded using UTF-8.
zh_HANS-CN: 建议始终使用 UTF-8 对 `<路径>` 进行编码。

note: type: Plain text
en: Included in a `commit` command to remove a file or recursively delete an entire directory from the branch.  If the file or directory removal makes its parent directory empty, the parent directory will be automatically removed too.  This cascades up the tree until the first non-empty directory or the root is reached.
zh_HANS-CN: 包含在 `commit` 命令中，用于从分支中删除文件或递归删除整个目录。 如果文件或目录删除后其父级目录为空，父级目录也会自动删除。 这将沿着树向上逐级进行，直到到达第一个非空目录或根目录为止。

note: type: delimited block .
en: 	'D' SP <path> LF
zh_HANS-CN: 	'D' SP <路径> LF

note: type: Plain text
en: here `<path>` is the complete path of the file or subdirectory to be removed from the branch.  See `filemodify` above for a detailed description of `<path>`.
zh_HANS-CN: 这里的 `<路劲>` 是要从分支中删除的文件或子目录的完整路径。 有关 `<路径>` 的详细说明，请参阅上文的 `filemodify` 。

note: type: Plain text
en: Recursively copies an existing file or subdirectory to a different location within the branch.  The existing file or directory must exist.  If the destination exists it will be completely replaced by the content copied from the source.
zh_HANS-CN: 递归复制现有文件或子目录到分支内的不同位置。 现有文件或目录必须存在。 如果目标位置存在，它将被从源位置复制的内容完全取代。

note: type: Plain text
en: here the first `<path>` is the source location and the second `<path>` is the destination.  See `filemodify` above for a detailed description of what `<path>` may look like.  To use a source path that contains SP the path must be quoted.
zh_HANS-CN: 这里第一个 `<路径>` 是源位置，第二个 `<路径>` 是目标位置。 关于 `<路径>` 的详细说明，请参阅上文的 `filemodify` 。 要使用包含 SP 的源路径，路径必须加引号。

note: type: Plain text
en: A `filecopy` command takes effect immediately.  Once the source location has been copied to the destination any future commands applied to the source location will not impact the destination of the copy.
zh_HANS-CN: `filecopy`（文件复制）命令会立即生效。 一旦源位置被复制到目标位置，今后应用于源位置的任何命令都不会影响复制的目标位置。

note: type: Plain text
en: Renames an existing file or subdirectory to a different location within the branch.  The existing file or directory must exist. If the destination exists it will be replaced by the source directory.
zh_HANS-CN: 将现有文件或子目录重命名到分支内的不同位置。 现有文件或目录必须存在。如果目标目录存在，它将被源目录取代。

note: type: Plain text
en: A `filerename` command takes effect immediately.  Once the source location has been renamed to the destination any future commands applied to the source location will create new files there and not impact the destination of the rename.
zh_HANS-CN: `filename`（文件重命名）命令会立即生效。 一旦源位置被重命名为目标位置，今后应用于源位置的任何命令都将在该位置创建新文件，而不会影响重命名的目标位置。

note: type: Plain text
en: Note that a `filerename` is the same as a `filecopy` followed by a `filedelete` of the source location.  There is a slight performance advantage to using `filerename`, but the advantage is so small that it is never worth trying to convert a delete/add pair in source material into a rename for fast-import.  This `filerename` command is provided just to simplify frontends that already have rename information and don't want bother with decomposing it into a `filecopy` followed by a `filedelete`.
zh_HANS-CN: 请注意，`filerename` 等同于源位置的 `filecopy` 和 `filedelete`。 使用 `filerename` 在性能上略有优势，但优势非常小，不值得为了快速导入而尝试将源材料中的删除/添加对转换为重命名。 提供这个 `fileerename` 命令只是为了简化已经有重命名信息的前端程序，而不需要将其分解为 `filecopy` 和 `filedelete` 命令。

note: type: Plain text
en: Included in a `commit` command to remove all files (and also all directories) from the branch.  This command resets the internal branch structure to have no files in it, allowing the frontend to subsequently add all interesting files from scratch.
zh_HANS-CN: 包含在 `commit` 命令中，用于删除分支中的所有文件（以及所有目录）。 该命令会重置内部分支结构，使其不包含任何文件，从而允许前台随后从头开始添加所有感兴趣的文件。

note: type: Plain text
en: This command is extremely useful if the frontend does not know (or does not care to know) what files are currently on the branch, and therefore cannot generate the proper `filedelete` commands to update the content.
zh_HANS-CN: 如果前台不知道（或不关心知道）当前分支上有哪些文件，因而无法生成适当的 `filedelete` 命令来更新内容，那么这条命令就非常有用。

note: type: Plain text
en: Issuing a `filedeleteall` followed by the needed `filemodify` commands to set the correct content will produce the same results as sending only the needed `filemodify` and `filedelete` commands.  The `filedeleteall` approach may however require fast-import to use slightly more memory per active branch (less than 1 MiB for even most large projects); so frontends that can easily obtain only the affected paths for a commit are encouraged to do so.
zh_HANS-CN: 在发出 `filedeleteall` 命令后，再发出所需的 `filemodify` 命令来设置正确的内容，与只发出所需的 `filemodify` 和 `filedelete` 命令产生的结果是一样的。 不过，`filedeleteall` 方法可能会要求 fast-import 在每个活动分支上使用稍多的内存（对于大多数大型项目而言，内存都小于 1MB）；因此，我们鼓励能够轻松获取提交中仅受影响路径的前端这样做。

note: type: Plain text
en: Included in a `commit` `<notes_ref>` command to add a new note annotating a `<commit-ish>` or change this annotation contents.  Internally it is similar to filemodify 100644 on `<commit-ish>` path (maybe split into subdirectories). It's not advised to use any other commands to write to the `<notes_ref>` tree except `filedeleteall` to delete all existing notes in this tree.  This command has two different means of specifying the content of the note.
zh_HANS-CN: 包含在`commit` `<引用笔记>`命令中，用于为 `<提交号>` 添加新注释或更改注释内容。 在内部，它类似于在 `<提交号>` 路径（可能分成子目录）上的文件修改 100644。除了使用 `filedeleteall` 命令删除`<notes_ref>` 树中的所有现有注释外，不建议使用任何其他命令向 `<引用笔记>` 树中写入注释。 该命令有两种指定笔记内容的不同方法。

note: type: Plain text
en: The data content for the note was already supplied by a prior `blob` command.  The frontend just needs to connect it to the commit that is to be annotated.
zh_HANS-CN: 注释的数据内容已由先前的 `blob` 命令提供。 前台只需将其连接到要注释的提交。

note: type: Plain text
en: Here `<dataref>` can be either a mark reference (`:<idnum>`)  set by a prior `blob` command, or a full 40-byte SHA-1 of an existing Git blob object.
zh_HANS-CN: 这里的 `<数据引用>` 既可以是之前的 `blob` 命令设置的标记引用（`:<idnum>`），也可以是现有 Git blob 对象的完整 40 字节 SHA-1 值。

note: type: Plain text
en: The data content for the note has not been supplied yet.  The frontend wants to supply it as part of this modify command.
zh_HANS-CN: 备注的数据内容尚未提供。 前台希望将其作为该修改命令的一部分提供。

note: type: delimited block .
en: 	'N' SP 'inline' SP <commit-ish> LF
    	data
zh_HANS-CN: 	'N' SP 'inline' SP <提交号> LF
    	data

note: type: Plain text
en: In both formats `<commit-ish>` is any of the commit specification expressions also accepted by `from` (see above).
zh_HANS-CN: 在这两种格式中，`<提交号>` 是 `from` 也接受的任何提交规范表达式（见上文）。

note: type: Plain text
en: Arranges for fast-import to save a reference to the current object, allowing the frontend to recall this object at a future point in time, without knowing its SHA-1.  Here the current object is the object creation command the `mark` command appears within.  This can be `commit`, `tag`, and `blob`, but `commit` is the most common usage.
zh_HANS-CN: 安排快速导入保存当前对象的引用，以便前端在未来某个时间点调用该对象，而无需知道其 SHA-1。 在这里，当前对象指的是 `mark` 命令中出现的对象创建命令。 这可以是 `commit`、`tag` 和 `blob`，但 `commit` 是最常见的用法。

note: type: Plain text
en: where `<idnum>` is the number assigned by the frontend to this mark.  The value of `<idnum>` is expressed as an ASCII decimal integer.  The value 0 is reserved and cannot be used as a mark.  Only values greater than or equal to 1 may be used as marks.
zh_HANS-CN: 其中，`<idnum>` 是前台分配给此标记的编号。 `<idnum>` 的值用 ASCII 十进制整数表示。 0 是保留值，不能用作标记。 只有大于或等于 1 的值才能用作标记。

note: type: Plain text
en: New marks are created automatically.  Existing marks can be moved to another object simply by reusing the same `<idnum>` in another `mark` command.
zh_HANS-CN: 新标记会自动创建。 只需在另一个 `mark` 命令中重复使用相同的 `<idnum>`，即可将现有标记移动到另一个对象上。

note: type: Plain text
en: Provides the name of the object in the original source control system.  fast-import will simply ignore this directive, but filter processes which operate on and modify the stream before feeding to fast-import may have uses for this information
zh_HANS-CN: 提供原始源码控制系统中对象的名称。fast-import 将直接忽略此指令，但在向 fast-import 输入数据流之前对其进行操作和修改的过滤进程可能会使用此信息

note: type: delimited block .
en: 	'original-oid' SP <object-identifier> LF
zh_HANS-CN: 	'original-oid' SP <对象标识符> LF

note: type: Plain text
en: where `<object-identifier>` is any string not containing LF.
zh_HANS-CN: 其中，`<对象标识符>` 是任何不包含 LF 的字符串。

note: type: Plain text
en: Creates an annotated tag referring to a specific commit.  To create lightweight (non-annotated) tags see the `reset` command below.
zh_HANS-CN: 创建指向特定提交的注释标记。 要创建轻量级（无注释）标签，请参阅下面的 `reset` 命令。

note: type: delimited block .
en: 	'tag' SP <name> LF
    	mark?
    	'from' SP <commit-ish> LF
    	original-oid?
    	'tagger' (SP <name>)? SP LT <email> GT SP <when> LF
    	data
zh_HANS-CN: 	'tag' SP <名称> LF
    	mark?
    	'from' SP <提交号> LF
    	original-oid?
    	'tagger' (SP <名称>)? SP LT <email> GT SP <when> LF
    	data

note: type: Plain text
en: where `<name>` is the name of the tag to create.
zh_HANS-CN: 其中 `<名称>` 是要创建的标记的名称。

note: type: Plain text
en: Tag names are automatically prefixed with `refs/tags/` when stored in Git, so importing the CVS branch symbol `RELENG-1_0-FINAL` would use just `RELENG-1_0-FINAL` for `<name>`, and fast-import will write the corresponding ref as `refs/tags/RELENG-1_0-FINAL`.
zh_HANS-CN: 因此，导入 CVS 分支符号 `RELENG-1_0-FINAL` 时，只需在 `<名称>` 中使用 `RELENG-1_0-FINAL`，而 fast-import 会将相应的引用写成 `refs/tags/RELENG-1_0-FINAL`。

note: type: Plain text
en: The value of `<name>` must be a valid refname in Git and therefore may contain forward slashes.  As `LF` is not valid in a Git refname, no quoting or escaping syntax is supported here.
zh_HANS-CN: 在 Git 中，`<名称>` 的值必须是有效的引用名称，因此可能包含正斜杠。 由于 `LF` 在 Git 引用名称中无效，因此此处不支持引号或转义语法。

note: type: Plain text
en: The `from` command is the same as in the `commit` command; see above for details.
zh_HANS-CN: `from` 命令与 `commit` 命令相同，详见上文。

note: type: Plain text
en: The `tagger` command uses the same format as `committer` within `commit`; again see above for details.
zh_HANS-CN: `tagger` 命令使用的格式与 `commit` 中的 `committer` 相同；详情参见上文。

note: type: Plain text
en: The `data` command following `tagger` must supply the annotated tag message (see below for `data` command syntax).  To import an empty tag message use a 0 length data.  Tag messages are free-form and are not interpreted by Git.  Currently they must be encoded in UTF-8, as fast-import does not permit other encodings to be specified.
zh_HANS-CN: 在 `tagger` 之后的 `data` 命令必须提供已注释的标记信息（请参阅下面的 `data` 命令语法）。 要导入空标签信息，请使用长度为 0 的数据。 标签信息是自由格式的，不会被 Git 解释。 目前，它们必须以 UTF-8 编码，因为 fast-import 不允许指定其他编码。

note: type: Plain text
en: Signing annotated tags during import from within fast-import is not supported.  Trying to include your own PGP/GPG signature is not recommended, as the frontend does not (easily) have access to the complete set of bytes which normally goes into such a signature.  If signing is required, create lightweight tags from within fast-import with `reset`, then create the annotated versions of those tags offline with the standard 'git tag' process.
zh_HANS-CN: 不支持在 fast-import 中导入时对已注释的标记进行签名。 不建议尝试加入自己的 PGP/GPG 签名，因为前端无法（轻易）获取通常用于签名的完整字节集。 如果需要签名，请使用 `reset` 在 fast-import 中创建轻量级标签，然后使用标准的 'git tag' 流程离线创建这些标签的注释版本。

note: type: Plain text
en: Creates (or recreates) the named branch, optionally starting from a specific revision.  The reset command allows a frontend to issue a new `from` command for an existing branch, or to create a new branch from an existing commit without creating a new commit.
zh_HANS-CN: 创建（或重新创建）指定的分支，可选择从特定版本开始。  重置命令允许前台为现有分支发布新的 `from` 命令，或从现有提交创建新分支，而无需创建新提交。

note: type: delimited block .
en: 	'reset' SP <ref> LF
    	('from' SP <commit-ish> LF)?
    	LF?
zh_HANS-CN: 	'reset' SP <引用> LF
    	('from' SP <提交号> LF)?
    	LF?

note: type: Plain text
en: For a detailed description of `<ref>` and `<commit-ish>` see above under `commit` and `from`.
zh_HANS-CN: 有关 `<引用>` 和 `<提交号>` 的详细说明，请参阅上文 `commit` 和 `from` 部分。

note: type: Plain text
en: The `LF` after the command is optional (it used to be required).
zh_HANS-CN: 命令后的 `LF` 是可选项（以前是必选项）。

note: type: Plain text
en: The `reset` command can also be used to create lightweight (non-annotated) tags.  For example:
zh_HANS-CN: `reset` （重置）命令还可用于创建轻量级（无注释）标记。  例如：

note: type: Plain text
en: would create the lightweight tag `refs/tags/938` referring to whatever commit mark `:938` references.
zh_HANS-CN: 将创建轻量级标记 `refs/tags/938`，并引用提交标记 `:938`。

note: type: Plain text
en: Requests writing one file revision to the packfile.  The revision is not connected to any commit; this connection must be formed in a subsequent `commit` command by referencing the blob through an assigned mark.
zh_HANS-CN: 请求向包文件写入一个文件修订。  修订版与任何提交都没有关联；这种关联必须在随后的 `commit` 命令中通过指定标记引用 blob 来形成。

note: type: Plain text
en: The mark command is optional here as some frontends have chosen to generate the Git SHA-1 for the blob on their own, and feed that directly to `commit`.  This is typically more work than it's worth however, as marks are inexpensive to store and easy to use.
zh_HANS-CN: 这里的标记命令是可选的，因为有些前端选择自己为 blob 生成 Git SHA-1，并直接将其输入到 `commit` 中。  这通常是得不偿失的，因为标记的存储成本很低，而且易于使用。

note: type: Plain text
en: Supplies raw data (for use as blob/file content, commit messages, or annotated tag messages) to fast-import.  Data can be supplied using an exact byte count or delimited with a terminating line.  Real frontends intended for production-quality conversions should always use the exact byte count format, as it is more robust and performs better.  The delimited format is intended primarily for testing fast-import.
zh_HANS-CN: 向 fast-import 提供原始数据（用作 blob/文件内容、提交信息或注释标签信息）。  提供的数据可以使用精确的字节数，也可以用终止行分隔。  用于生产质量转换的真正前端应始终使用精确字节数格式，因为这种格式更稳健、性能更好。  分隔格式主要用于测试快速导入。

note: type: Plain text
en: Comment lines appearing within the `<raw>` part of `data` commands are always taken to be part of the body of the data and are therefore never ignored by fast-import.  This makes it safe to import any file/message content whose lines might start with `#`.
zh_HANS-CN: 在 `data` 命令的 `<raw>` 部分中出现的注释行总是被视为数据正文的一部分，因此 fast-import 不会忽略这些注释行。  这样就可以安全导入任何可能以 `#` 开头的文件/信息内容。

note: type: Labeled list
en: Exact byte count format
zh_HANS-CN: 精确字节计数格式

note: type: Plain text
en: The frontend must specify the number of bytes of data.
zh_HANS-CN: 前台必须指定数据的字节数。

note: type: Plain text
en: where `<count>` is the exact number of bytes appearing within `<raw>`.  The value of `<count>` is expressed as an ASCII decimal integer.  The `LF` on either side of `<raw>` is not included in `<count>` and will not be included in the imported data.
zh_HANS-CN: 其中，`<count>` 是出现在 `<raw>` 中的确切字节数。 `<count>` 的值用 ASCII 十进制整数表示。  `<raw>` 两侧的 `LF` 不包含在 `<count>` 中，也不会包含在导入的数据中。

note: type: Plain text
en: The `LF` after `<raw>` is optional (it used to be required) but recommended.  Always including it makes debugging a fast-import stream easier as the next command always starts in column 0 of the next line, even if `<raw>` did not end with an `LF`.
zh_HANS-CN: 在 `<raw>` 后面的 `LF` 是可选的（以前是必须的），但建议使用。  始终包含它可以使调试快速导入流变得更容易，因为下一条命令总是从下一行的第 0 列开始，即使 `<raw>` 没有以 `LF` 结束。

note: type: Labeled list
en: Delimited format
zh_HANS-CN: 分隔格式

note: type: Plain text
en: A delimiter string is used to mark the end of the data.  fast-import will compute the length by searching for the delimiter.  This format is primarily useful for testing and is not recommended for real data.
zh_HANS-CN: fast-import 将通过搜索分隔符来计算长度。  这种格式主要用于测试，不建议用于真实数据。

note: type: Plain text
en: where `<delim>` is the chosen delimiter string.  The string `<delim>` must not appear on a line by itself within `<raw>`, as otherwise fast-import will think the data ends earlier than it really does.  The `LF` immediately trailing `<raw>` is part of `<raw>`.  This is one of the limitations of the delimited format, it is impossible to supply a data chunk which does not have an LF as its last byte.
zh_HANS-CN: 其中 `<delim>` 是选定的分隔符字符串。  字符串 `<delim>` 不能单独出现在 `<raw>` 中的一行，否则 fast-import 会认为数据结束的时间比实际时间早。  紧跟在 `<raw>` 后面的 `LF` 是 `<raw>` 的一部分。  这是分隔格式的限制之一，不可能提供最后一个字节没有 LF 的数据块。

note: type: Plain text
en: The `LF` after `<delim> LF` is optional (it used to be required).
zh_HANS-CN: 在 `<delim> LF` 后面的 `LF` 是可选的（以前是必须的）。

note: type: Plain text
en: Record that a mark refers to a given object without first creating any new object.
zh_HANS-CN: 记录标记指向某个对象，而无需先创建任何新对象。

note: type: delimited block .
en: 	'alias' LF
    	mark
    	'to' SP <commit-ish> LF
    	LF?
zh_HANS-CN: 	'alias' LF
    	mark
    	'to' SP <提交号> LF
    	LF?

note: type: Plain text
en: For a detailed description of `<commit-ish>` see above under `from`.
zh_HANS-CN: 有关 `<提交号>` 的详细说明，请参阅上文 `from` 部分。

note: type: Plain text
en: Forces fast-import to close the current packfile, start a new one, and to save out all current branch refs, tags and marks.
zh_HANS-CN: 强制 fast-import 关闭当前的打包文件，启动一个新文件，并保存所有当前的分支参考、标记和标记。

note: type: Plain text
en: Note that fast-import automatically switches packfiles when the current packfile reaches --max-pack-size, or 4 GiB, whichever limit is smaller.  During an automatic packfile switch fast-import does not update the branch refs, tags or marks.
zh_HANS-CN: 请注意，当当前包文件达到 --max-pack-size 或 4 GiB（以较小者为准）时，fast-import 会自动切换包文件。  在自动切换打包文件期间，fast-import 不会更新分支引用、标记或标记。

note: type: Plain text
en: As a `checkpoint` can require a significant amount of CPU time and disk IO (to compute the overall pack SHA-1 checksum, generate the corresponding index file, and update the refs) it can easily take several minutes for a single `checkpoint` command to complete.
zh_HANS-CN: 由于一个 `checkpoint` （检查点）可能需要大量的 CPU 时间和磁盘 IO（计算整个包的 SHA-1 校验和、生成相应的索引文件并更新引用），因此一条 `checkpoint` 命令可能需要几分钟才能完成。

note: type: Plain text
en: Frontends may choose to issue checkpoints during extremely large and long running imports, or when they need to allow another Git process access to a branch.  However given that a 30 GiB Subversion repository can be loaded into Git through fast-import in about 3 hours, explicit checkpointing may not be necessary.
zh_HANS-CN: 前端可能会选择在超大、超长的导入过程中，或需要允许另一个 Git 进程访问某个分支时，发出检查点。  不过，通过 fast-import 将一个 30GB 的 Subversion 仓库加载到 Git 大约只需要 3 个小时，因此可能不需要明确的检查点。

note: type: Plain text
en: Causes fast-import to print the entire `progress` line unmodified to its standard output channel (file descriptor 1) when the command is processed from the input stream.  The command otherwise has no impact on the current import, or on any of fast-import's internal state.
zh_HANS-CN: 在处理输入流中的命令时，使 fast-import 将整个 `progress` 行未经修改地打印到标准输出通道（文件描述符 1）。  除此之外，该命令不会对当前导入或 fast-import 的任何内部状态产生影响。

note: type: delimited block .
en: 	'progress' SP <any> LF
    	LF?
zh_HANS-CN: 	'progress' SP <任意> LF
    	LF?

note: type: Plain text
en: The `<any>` part of the command may contain any sequence of bytes that does not contain `LF`.  The `LF` after the command is optional.  Callers may wish to process the output through a tool such as sed to remove the leading part of the line, for example:
zh_HANS-CN: 命令的 `<任意>` 部分可包含不含 `LF` 的任何字节序列。  命令后的 `LF` 是可选的。  调用者可能希望通过 sed 等工具处理输出，例如删除行的前导部分：

note: type: Plain text
en: Placing a `progress` command immediately after a `checkpoint` will inform the reader when the `checkpoint` has been completed and it can safely access the refs that fast-import updated.
zh_HANS-CN: 在 `checkpoint` 之后紧接一个 `progress` 命令，可以通知阅读器 `checkpoint` 何时完成，阅读器可以安全地访问快速导入更新的引用。

note: type: Plain text
en: Causes fast-import to print the SHA-1 corresponding to a mark to stdout or to the file descriptor previously arranged with the `--cat-blob-fd` argument. The command otherwise has no impact on the current import; its purpose is to retrieve SHA-1s that later commits might want to refer to in their commit messages.
zh_HANS-CN: 命令 fast-import 将标记对应的 SHA-1 打印到标准输出流或之前用 `--cat-blob-fd` 参数安排的文件描述符。该命令不会对当前导入产生任何影响；其目的是检索 SHA-1，供以后的提交在提交信息中参考。

note: type: Plain text
en: See ``Responses To Commands'' below for details about how to read this output safely.
zh_HANS-CN: 有关如何安全读取输出结果的详细信息，请参阅下文 ''对命令的回复''。

note: type: Plain text
en: Causes fast-import to print a blob to a file descriptor previously arranged with the `--cat-blob-fd` argument.  The command otherwise has no impact on the current import; its main purpose is to retrieve blobs that may be in fast-import's memory but not accessible from the target repository.
zh_HANS-CN: 使 fast-import 将 blob 打印到先前用 `--cat-blob-fd` 参数安排的文件描述符。  该命令不会对当前导入产生任何影响；其主要目的是检索 fast-import 内存中的 blob，但目标存储库无法访问这些 blob。

note: type: Plain text
en: The `<dataref>` can be either a mark reference (`:<idnum>`)  set previously or a full 40-byte SHA-1 of a Git blob, preexisting or ready to be written.
zh_HANS-CN: `<数据引用>` 可以是之前设置的标记引用 (`:<idnum>`)，也可以是 Git blob 的完整 40 字节 SHA-1，可以是预先存在的，也可以是准备写入的。

note: type: Plain text
en: Output uses the same format as `git cat-file --batch`:
zh_HANS-CN: 输出格式与 `git cat-file --batch` 相同：

note: type: delimited block =
en: 	<sha1> SP 'blob' SP <size> LF
    	<contents> LF
zh_HANS-CN: 	<sha1> SP 'blob' SP <尺寸> LF
    	<内容> LF

note: type: Plain text
en: This command can be used where a `filemodify` directive can appear, allowing it to be used in the middle of a commit.  For a `filemodify` using an inline directive, it can also appear right before the `data` directive.
zh_HANS-CN: 该命令可用于出现 `filemodify` 指令的地方，允许在提交中间使用。  对于使用内联指令的 `filemodify`，它也可以出现在 `data` 指令之前。

note: type: Plain text
en: Prints information about the object at a path to a file descriptor previously arranged with the `--cat-blob-fd` argument.  This allows printing a blob from the active commit (with `cat-blob`) or copying a blob or tree from a previous commit for use in the current one (with `filemodify`).
zh_HANS-CN: 打印文件描述符路径上的对象信息，该文件描述符是之前用 `--cat-blob-fd` 参数安排的。  这样就可以打印当前提交中的 blob（使用 `cat-blob` 时），或复制先前提交中的 blob 或树以用于当前提交（使用 `filemodify` 时）。

note: type: Plain text
en: The `ls` command can also be used where a `filemodify` directive can appear, allowing it to be used in the middle of a commit.
zh_HANS-CN: `ls` 命令也可用于出现 `filemodify` 指令的地方，允许在提交过程中使用。

note: type: Labeled list
en: Reading from the active commit
zh_HANS-CN: 从活动提交中读取

note: type: Plain text
en: This form can only be used in the middle of a `commit`.  The path names a directory entry within fast-import's active commit.  The path must be quoted in this case.
zh_HANS-CN: 这种形式只能在 `commit` 过程中使用。  路径命名 fast-import 活动提交中的目录条目。  在这种情况下，路径必须加引号。

note: type: Labeled list
en: Reading from a named tree
zh_HANS-CN: 从命名树读取数据

note: type: Plain text
en: The `<dataref>` can be a mark reference (`:<idnum>`) or the full 40-byte SHA-1 of a Git tag, commit, or tree object, preexisting or waiting to be written.  The path is relative to the top level of the tree named by `<dataref>`.
zh_HANS-CN: `<数据引用>` 可以是一个标记引用 ( `:<idnum>` )，也可以是 Git 标签、提交或树对象的完整 40 字节 SHA-1，可以是已存在的，也可以是等待写入的。  路径是相对于由 `<数据引用>` 命名的树的顶层的。

note: type: Plain text
en: See `filemodify` above for a detailed description of `<path>`.
zh_HANS-CN: 有关 `<路径>` 的详细说明，请参阅上文的 `filemodify` 。

note: type: Plain text
en: Output uses the same format as `git ls-tree <tree> -- <path>`:
zh_HANS-CN: 输出格式与 `git ls-tree <目录树> -- <路径>`相同：

note: type: Plain text
en: The <dataref> represents the blob, tree, or commit object at <path> and can be used in later 'get-mark', 'cat-blob', 'filemodify', or 'ls' commands.
zh_HANS-CN: <数据引用> 表示 <路劲> 中的 blob、树或提交对象，可用于后面的 'get-mark'、'cat-blob'、'filemodify' 或 'ls' 命令。

note: type: Plain text
en: If there is no file or subtree at that path, 'git fast-import' will instead report
zh_HANS-CN: 如果该路径下没有文件或子树，'git fast-import' 将报告

note: type: delimited block =
en: 	missing SP <path> LF
zh_HANS-CN: 	missing SP <路径> LF

note: type: Plain text
en: Require that fast-import supports the specified feature, or abort if it does not.
zh_HANS-CN: 要求 fast-import 支持指定的功能，如果不支持则终止。

note: type: delimited block .
en: 	'feature' SP <feature> ('=' <argument>)? LF
zh_HANS-CN: 	'feature' SP <功能> ('=' <参数>)? LF

note: type: Plain text
en: The <feature> part of the command may be any one of the following:
zh_HANS-CN: 命令的 <功能> 部分可以是以下任何一种：

note: type: Plain text
en: date-format
zh_HANS-CN: date-format（日期格式）

note: type: Plain text
en: export-marks
zh_HANS-CN: export-marks（出口标记）

note: type: Plain text
en: Act as though the corresponding command-line option with a leading `--` was passed on the command line (see OPTIONS, above).
zh_HANS-CN: 就像在命令行中传递了带前导 `--` 的相应命令行选项一样（见上文选项）。

note: type: Plain text
en: import-marks
zh_HANS-CN: import-marks（入口标记）

note: type: Labeled list
en: import-marks-if-exists
zh_HANS-CN: import-marks-if-exists（导入标记是否存在）

note: type: Plain text
en: Like --import-marks except in two respects: first, only one "feature import-marks" or "feature import-marks-if-exists" command is allowed per stream; second, an --import-marks= or --import-marks-if-exists command-line option overrides any of these "feature" commands in the stream; third, "feature import-marks-if-exists" like a corresponding command-line option silently skips a nonexistent file.
zh_HANS-CN: 与 --import-marks 类似，但有两点不同：第一，每个数据流只允许一条 "feature import-marks" 或 "feature import-marks-if-exists" 命令；第二，命令行选项 --import-marks= 或 --import-marks-if-exists 会覆盖数据流中的任何这些 "feature" 命令；第三，"feature import-marks-if-exists" 与相应的命令行选项一样，会静默地跳过一个不存在的文件。

note: type: Plain text
en: Require that the backend support the 'get-mark', 'cat-blob', or 'ls' command respectively.  Versions of fast-import not supporting the specified command will exit with a message indicating so.  This lets the import error out early with a clear message, rather than wasting time on the early part of an import before the unsupported command is detected.
zh_HANS-CN: 要求后端分别支持 'get-mark'、'cat-blob' 或 'ls' 命令。  不支持指定命令的 fast-import 版本在退出时会给出提示信息。  这样，导入过程中就不会在检测到不支持的命令之前浪费时间，而会在早期就出现明确的错误信息。

note: type: Plain text
en: Require that the backend support the 'notemodify' (N)  subcommand to the 'commit' command.  Versions of fast-import not supporting notes will exit with a message indicating so.
zh_HANS-CN: 要求后端支持 'commit' 命令的 'notemodify'（N）子命令。  不支持备注的 fast-import 版本在退出时会显示相关信息。

note: type: Plain text
en: Error out if the stream ends without a 'done' command.  Without this feature, errors causing the frontend to end abruptly at a convenient point in the stream can go undetected.  This may occur, for example, if an import front end dies in mid-operation without emitting SIGTERM or SIGKILL at its subordinate git fast-import instance.
zh_HANS-CN: 如果数据流在没有 'done' （完成）命令的情况下结束，就会出错。  如果没有这项功能，导致前端在流中某个适当位置突然结束的错误就可能不会被发现。  例如，如果一个导入前端在操作中途死亡，而没有在其下属的 git fast-import 实例中发出 SIGTERM 或 SIGKILL，就可能发生这种情况。

note: type: Plain text
en: Processes the specified option so that git fast-import behaves in a way that suits the frontend's needs.  Note that options specified by the frontend are overridden by any options the user may specify to git fast-import itself.
zh_HANS-CN: 处理指定的选项，使 Git fast-import 的行为符合前端的需要。  注意，前端指定的选项会被用户为 Git fast-import 本身指定的任何选项所覆盖。

note: type: delimited block .
en:     'option' SP <option> LF
zh_HANS-CN:     'option' SP <选项> LF

note: type: Plain text
en: Option commands must be the first commands on the input (not counting feature commands), to give an option command after any non-option command is an error.
zh_HANS-CN: 选项命令必须是输入的第一条命令（不包括功能命令），在任何非选项命令之后给出选项命令都是错误的。

note: type: Plain text
en: The following command-line options change import semantics and may therefore not be passed as option:
zh_HANS-CN: 以下命令行选项会改变导入语义，因此不能作为选项传递：

note: type: Plain text
en: If the `done` feature is not in use, treated as if EOF was read.  This can be used to tell fast-import to finish early.
zh_HANS-CN: 如果未使用 `done` 功能，则视作已读取 EOF。  这可以用来告诉 fast-import 提前结束。

note: type: Plain text
en: If the `--done` command-line option or `feature done` command is in use, the `done` command is mandatory and marks the end of the stream.
zh_HANS-CN: 如果使用了 `--done` 命令行选项或 `feature done` 命令，则 `done` 命令是强制性的，标志着数据流的结束。

note: type: Title -
en: RESPONSES TO COMMANDS
zh_HANS-CN: 对命令的响应

note: type: Plain text
en: New objects written by fast-import are not available immediately.  Most fast-import commands have no visible effect until the next checkpoint (or completion).  The frontend can send commands to fill fast-import's input pipe without worrying about how quickly they will take effect, which improves performance by simplifying scheduling.
zh_HANS-CN: 快速导入写入的新对象不能立即使用。  大多数 fast-import 命令在下一个检查点（或完成）之前都不会有明显的效果。  前端可以发送命令来填充 fast-import 的输入管道，而不必担心这些命令的生效速度，这样可以简化调度，从而提高性能。

note: type: Plain text
en: For some frontends, though, it is useful to be able to read back data from the current repository as it is being updated (for example when the source material describes objects in terms of patches to be applied to previously imported objects).  This can be accomplished by connecting the frontend and fast-import via bidirectional pipes:
zh_HANS-CN: 不过，对于某些前端来说，在更新时从当前资源库读回数据是非常有用的（例如，当源材料以补丁的形式描述要应用到先前导入对象的对象时）。  这可以通过双向管道连接前端和快速导入来实现：

note: type: Plain text
en: A frontend set up this way can use `progress`, `get-mark`, `ls`, and `cat-blob` commands to read information from the import in progress.
zh_HANS-CN: 以这种方式设置的前端可以使用 `progress`、`get-mark`、`ls` 和 `cat-blob` 命令从正在进行的导入中读取信息。

note: type: Plain text
en: To avoid deadlock, such frontends must completely consume any pending output from `progress`, `ls`, `get-mark`, and `cat-blob` before performing writes to fast-import that might block.
zh_HANS-CN: 为避免死锁，此类前端在向 fast-import 写入可能阻塞的内容之前，必须完全耗尽来自 `progress`、`ls`、`get-mark` 和 `cat-blob` 的任何待处理输出。

note: type: Title -
en: CRASH REPORTS
zh_HANS-CN: 事故报告

note: type: Plain text
en: If fast-import is supplied invalid input it will terminate with a non-zero exit status and create a crash report in the top level of the Git repository it was importing into.  Crash reports contain a snapshot of the internal fast-import state as well as the most recent commands that lead up to the crash.
zh_HANS-CN: 如果 fast-import 收到无效输入，它将以非零的退出状态终止，并在导入的 Git 仓库顶层创建一份崩溃报告。  崩溃报告包含 fast-import 内部状态的快照，以及导致崩溃的最新命令。

note: type: Plain text
en: All recent commands (including stream comments, file changes and progress commands) are shown in the command history within the crash report, but raw file data and commit messages are excluded from the crash report.  This exclusion saves space within the report file and reduces the amount of buffering that fast-import must perform during execution.
zh_HANS-CN: 所有最近的命令（包括流注释、文件更改和进度命令）都会显示在崩溃报告中的命令历史记录中，但原始文件数据和提交信息不会显示在崩溃报告中。  这种排除可以节省报告文件的空间，并减少 fast-import 在执行过程中必须执行的缓冲量。

note: type: Plain text
en: After writing a crash report fast-import will close the current packfile and export the marks table.  This allows the frontend developer to inspect the repository state and resume the import from the point where it crashed.  The modified branches and tags are not updated during a crash, as the import did not complete successfully.  Branch and tag information can be found in the crash report and must be applied manually if the update is needed.
zh_HANS-CN: 写完崩溃报告后，fast-import 会关闭当前的包文件并导出标记表。  这样，前端开发人员就可以检查仓库状态，并从崩溃的位置继续导入。  由于导入未成功完成，因此崩溃期间不会更新已修改的分支和标记。  分支和标记信息可在崩溃报告中找到，如果需要更新，必须手动应用。

note: type: Plain text
en: An example crash:
zh_HANS-CN: 崩溃实例：

note: type: delimited block =
en: 	fatal: Corrupt mode: M 777 inline bob
zh_HANS-CN: 	fatal: Corrupt mode: M 777 inline bob（失败：错误的模式：M 777 ）

note: type: delimited block =
en: 	Most Recent Commands Before Crash
    	---------------------------------
    	  # my very first test commit
    	  commit refs/heads/master
    	  committer Shawn O. Pearce <spearce> 19283 -0400
    	  # who is that guy anyway?
    	  data <<EOF
    	  M 644 inline .gitignore
    	  data <<EOF
zh_HANS-CN: 	Most Recent Commands Before Crash
    	---------------------------------
    	  # my very first test commit（我最开始的测试提交）
    	  commit refs/heads/master
    	  committer Shawn O. Pearce <spearce> 19283 -0400
    	  # who is that guy anyway?（这是什么？）
    	  data <<EOF
    	  M 644 inline .gitignore
    	  data <<EOF

note: type: Title -
en: TIPS AND TRICKS
zh_HANS-CN: 提示和技巧

note: type: Plain text
en: The following tips and tricks have been collected from various users of fast-import, and are offered here as suggestions.
zh_HANS-CN: 以下提示和技巧是从 fast-import 的不同用户那里收集的，在此作为建议提供。

note: type: Title ~
en: Use One Mark Per Commit
zh_HANS-CN: 每次承诺使用一个标记

note: type: Plain text
en: When doing a repository conversion, use a unique mark per commit (`mark :<n>`) and supply the --export-marks option on the command line.  fast-import will dump a file which lists every mark and the Git object SHA-1 that corresponds to it.  If the frontend can tie the marks back to the source repository, it is easy to verify the accuracy and completeness of the import by comparing each Git commit to the corresponding source revision.
zh_HANS-CN: 在进行仓转换时，每个提交使用一个唯一的标记（`标记 :<n>`），并在命令行中提供 --export-marks 选项。  如果前端能将标记与源代码仓库绑定，就能通过比较每个 Git 提交和相应的源代码版本，轻松验证导入的准确性和完整性。

note: type: Plain text
en: Coming from a system such as Perforce or Subversion this should be quite simple, as the fast-import mark can also be the Perforce changeset number or the Subversion revision number.
zh_HANS-CN: 从 Perforce 或 Subversion 等系统导入时，这应该非常简单，因为快速导入标记也可以是 Perforce 更改集编号或 Subversion 修订编号。

note: type: Title ~
en: Freely Skip Around Branches
zh_HANS-CN: 自由跳转分支

note: type: Plain text
en: Don't bother trying to optimize the frontend to stick to one branch at a time during an import.  Although doing so might be slightly faster for fast-import, it tends to increase the complexity of the frontend code considerably.
zh_HANS-CN: 在导入过程中，不要费心去优化前端，使其一次只针对一个分支。  虽然这样做可能会稍微加快快速导入的速度，但往往会大大增加前端代码的复杂性。

note: type: Plain text
en: The branch LRU builtin to fast-import tends to behave very well, and the cost of activating an inactive branch is so low that bouncing around between branches has virtually no impact on import performance.
zh_HANS-CN: fast-import 内置的分支 LRU 通常表现非常出色，而且激活非活动分支的成本很低，在分支间跳来跳去对导入性能几乎没有影响。

note: type: Title ~
en: Handling Renames
zh_HANS-CN: 处理重命名

note: type: Plain text
en: When importing a renamed file or directory, simply delete the old name(s) and modify the new name(s) during the corresponding commit.  Git performs rename detection after-the-fact, rather than explicitly during a commit.
zh_HANS-CN: 在导入重命名的文件或目录时，只需在相应的提交过程中删除旧名称并修改新名称即可。  Git 会在事后执行重命名检测，而不是在提交时明确执行。

note: type: Title ~
en: Use Tag Fixup Branches
zh_HANS-CN: 使用标签修复分支

note: type: Plain text
en: Some other SCM systems let the user create a tag from multiple files which are not from the same commit/changeset.  Or to create tags which are a subset of the files available in the repository.
zh_HANS-CN: 其他一些 SCM 系统允许用户从多个文件创建标签，而这些文件并非来自同一提交/变更集。  或者创建的标签是仓库中可用文件的子集。

note: type: Plain text
en: Importing these tags as-is in Git is impossible without making at least one commit which ``fixes up'' the files to match the content of the tag.  Use fast-import's `reset` command to reset a dummy branch outside of your normal branch space to the base commit for the tag, then commit one or more file fixup commits, and finally tag the dummy branch.
zh_HANS-CN: 如果不至少提交一次 ''修'' 文件以匹配标签内容，就无法在 Git 中原样导入这些标签。  使用 fast-import 的 `reset` 命令，在正常分支空间外重置一个假分支，使其与标签的基本提交一致，然后提交一次或多次文件修复提交，最后给假分支打上标签。

note: type: Plain text
en: For example since all normal branches are stored under `refs/heads/` name the tag fixup branch `TAG_FIXUP`.  This way it is impossible for the fixup branch used by the importer to have namespace conflicts with real branches imported from the source (the name `TAG_FIXUP` is not `refs/heads/TAG_FIXUP`).
zh_HANS-CN: 例如，由于所有正常分支都存储在 `refs/heads/` 下，因此将标记修复分支命名为 `TAG_FIXUP`。  这样，导入程序使用的修复分支就不可能与从源代码导入的真正分支发生命名空间冲突（名称 `TAG_FIXUP` 不是 `refs/heads/TAG_FIXUP`）。

note: type: Plain text
en: When committing fixups, consider using `merge` to connect the commit(s) which are supplying file revisions to the fixup branch.  Doing so will allow tools such as 'git blame' to track through the real commit history and properly annotate the source files.
zh_HANS-CN: 提交修复时，请考虑使用 `merge` 将提供文件修订的提交连接到修复分支。  这样做可以让 'git blame' 等工具追踪真实的提交历史，并正确地注释源文件。

note: type: Plain text
en: After fast-import terminates the frontend will need to do `rm .git/TAG_FIXUP` to remove the dummy branch.
zh_HANS-CN: 快速导入结束后，前台需要执行 `rm .git/TAG_FIXUP` 来移除虚拟分支。

note: type: Title ~
en: Import Now, Repack Later
zh_HANS-CN: 立即导入，稍后重新打包

note: type: Plain text
en: As soon as fast-import completes the Git repository is completely valid and ready for use.  Typically this takes only a very short time, even for considerably large projects (100,000+ commits).
zh_HANS-CN: 快速导入完成后，Git 仓库就完全有效，可以随时使用。  通常这只需要很短的时间，即使对于相当大的项目（100,000+ 次提交）也是如此。

note: type: Plain text
en: However repacking the repository is necessary to improve data locality and access performance.  It can also take hours on extremely large projects (especially if -f and a large --window parameter is used).  Since repacking is safe to run alongside readers and writers, run the repack in the background and let it finish when it finishes.  There is no reason to wait to explore your new Git project!
zh_HANS-CN: 不过，为了提高数据的位置性和访问性能，有必要重新打包仓库。  在超大型项目中，这也可能需要数小时（尤其是在使用 -f 和较大的 --window 参数时）。  由于重新打包可以安全地与读写器同时运行，因此请在后台运行重新打包，并让它在完成时完成。  没有理由等待探索新的 Git 项目！

note: type: Plain text
en: If you choose to wait for the repack, don't try to run benchmarks or performance tests until repacking is completed.  fast-import outputs suboptimal packfiles that are simply never seen in real use situations.
zh_HANS-CN: 如果您选择等待重新打包，在重新打包完成之前不要尝试运行基准或性能测试。

note: type: Title ~
en: Repacking Historical Data
zh_HANS-CN: 重新打包历史数据

note: type: Plain text
en: If you are repacking very old imported data (e.g. older than the last year), consider expending some extra CPU time and supplying --window=50 (or higher) when you run 'git repack'.  This will take longer, but will also produce a smaller packfile.  You only need to expend the effort once, and everyone using your project will benefit from the smaller repository.
zh_HANS-CN: 如果您要重新打包非常旧的导入数据（例如，比去年更旧的数据），可以考虑在运行 'git repack' 时花费一些额外的 CPU 时间并提供 --window=50（或更高）的参数。  这样会花费更多时间，但生成的打包文件也会更小。  您只需花费一次精力，而使用您项目的每个人都将受益于更小的仓库。

note: type: Title ~
en: Include Some Progress Messages
zh_HANS-CN: 包括一些进展信息

note: type: Plain text
en: Every once in a while have your frontend emit a `progress` message to fast-import.  The contents of the messages are entirely free-form, so one suggestion would be to output the current month and year each time the current commit date moves into the next month.  Your users will feel better knowing how much of the data stream has been processed.
zh_HANS-CN: 每隔一段时间，让你的前端向快速导入发出一条 `progress`（进度）信息。  消息的内容可以完全自由发挥，因此建议在当前提交日期进入下一个月时，输出当前月份和年份。  这样，用户就能更好地了解数据流的处理情况。

note: type: Title -
en: PACKFILE OPTIMIZATION
zh_HANS-CN: 包文件优化

note: type: Plain text
en: Run verbosely.
zh_HANS-CN: 详细运行。

note: type: Plain text
en: 'git fetch' [<options>] [<repository> [<refspec>...]]
    'git fetch' [<options>] <group>
    'git fetch' --multiple [<options>] [(<repository> | <group>)...]
    'git fetch' --all [<options>]
zh_HANS-CN: 'git fetch' [<选项>] [<仓库> [<引用规范>...]]
    'git fetch' [<选项>] <组>
    'git fetch' --multiple [<选项>] [(<仓库> | <组>)...]
    'git fetch' --all [<选项>]

note: type: Plain text
en: Fetch branches and/or tags (collectively, "refs") from one or more other repositories, along with the objects necessary to complete their histories.  Remote-tracking branches are updated (see the description of <refspec> below for ways to control this behavior).
zh_HANS-CN: 从一个或多个其它仓库获取分支和/或标记（统称为 "refs"），以及完成其历史所需的对象。  远程跟踪的分支会被更新（关于控制这种行为的方法，请参见下面 <引用规范> 的描述）。

note: type: Plain text
en: By default, any tag that points into the histories being fetched is also fetched; the effect is to fetch tags that point at branches that you are interested in.  This default behavior can be changed by using the --tags or --no-tags options or by configuring remote.<name>.tagOpt.  By using a refspec that fetches tags explicitly, you can fetch tags that do not point into branches you are interested in as well.
zh_HANS-CN: 默认情况下，任何指向被获取的历史的标签也会被获取；其效果是获取指向你感兴趣的分支的标签。  这个默认行为可以通过使用 --tags 或 --no-tags 选项或者配置 remote.<远程仓库名称>.tagOpt 来改变。  通过使用明确获取标签的引用规范，你也可以获取那些没有指向你感兴趣的分支的标签。

note: type: Plain text
en: 'git fetch' can fetch from either a single named repository or URL, or from several repositories at once if <group> is given and there is a remotes.<group> entry in the configuration file.  (See linkgit:git-config[1]).
zh_HANS-CN: 'git fetch' 可以从一个命名的仓库或 URL 中获取，或者如果给定了 <组> 并且在配置文件中有 remotes.<组> 项，则可以同时从几个仓库获取。  (参见 linkgit:git-config[1]）。

note: type: Plain text
en: When no remote is specified, by default the `origin` remote will be used, unless there's an upstream branch configured for the current branch.
zh_HANS-CN: 当没有指定远程仓库时，默认情况下将使用 `origin` 远程仓库，除非有一个上游分支配置在当前分支上。

note: type: Plain text
en: The names of refs that are fetched, together with the object names they point at, are written to `.git/FETCH_HEAD`.  This information may be used by scripts or other git commands, such as linkgit:git-pull[1].
zh_HANS-CN: 被获取的引用名称，以及它们所指向的对象名称，被写到 `.git/FETCH_HEAD`。  这些信息可以被脚本或其他 git 命令使用，比如linkgit:git-pull[1]。

note: type: Plain text
en: Read refspecs, one per line, from stdin in addition to those provided as arguments. The "tag <name>" format is not supported.
zh_HANS-CN: 从stdin中读取引用规范，每行一个，除了作为参数提供的那些之外。不支持 "标签 <名称>" 格式。

note: type: Title -
en: CONFIGURED REMOTE-TRACKING BRANCHES[[CRTB]]
zh_HANS-CN: 配置的远程跟踪分支 [[CRTB]]

note: type: Plain text
en: You often interact with the same remote repository by regularly and repeatedly fetching from it.  In order to keep track of the progress of such a remote repository, `git fetch` allows you to configure `remote.<repository>.fetch` configuration variables.
zh_HANS-CN: 你通过经常定期和重复地从同一个远程仓库取东西来与之互动。  为了跟踪这种远程仓库的进度，`git fetch` 允许你配置 `remote.<仓库>.fetch` 配置变量。

note: type: Plain text
en: Typically such a variable may look like this:
zh_HANS-CN: 一般来说，这种变量可能看起来像这样：

note: type: Plain text
en: This configuration is used in two ways:
zh_HANS-CN: 这种配置有两种使用方式：

note: type: Plain text
en: When `git fetch` is run without specifying what branches and/or tags to fetch on the command line, e.g. `git fetch origin` or `git fetch`, `remote.<repository>.fetch` values are used as the refspecs--they specify which refs to fetch and which local refs to update.  The example above will fetch all branches that exist in the `origin` (i.e. any ref that matches the left-hand side of the value, `refs/heads/*`) and update the corresponding remote-tracking branches in the `refs/remotes/origin/*` hierarchy.
zh_HANS-CN: 当 `git fetch` 运行时，没有在命令行中指定要取哪些分支和/或标记，例如 `git fetch origin` 或 `git fetch`，`remote.<仓库>.fetch` 值被用作引用规范——它们指定要取哪些引用和要更新哪些本地引用。  上面的例子将获取所有存在于 `origin` 中的分支（即任何与数值左边的`refs/heads/*`相匹配的引用），并更新 `refs/remotes/origin/*` 层次结构中相应的远程跟踪的分支。

note: type: Plain text
en: When `git fetch` is run with explicit branches and/or tags to fetch on the command line, e.g. `git fetch origin master`, the <refspec>s given on the command line determine what are to be fetched (e.g. `master` in the example, which is a short-hand for `master:`, which in turn means "fetch the 'master' branch but I do not explicitly say what remote-tracking branch to update with it from the command line"), and the example command will fetch _only_ the 'master' branch.  The `remote.<repository>.fetch` values determine which remote-tracking branch, if any, is updated.  When used in this way, the `remote.<repository>.fetch` values do not have any effect in deciding _what_ gets fetched (i.e. the values are not used as refspecs when the command-line lists refspecs); they are only used to decide _where_ the refs that are fetched are stored by acting as a mapping.
zh_HANS-CN: 当 `git fetch` 运行时，命令行上有明确的要取的分支和/或标记，例如 `git fetch origin master`，命令行上给出的所有 <引用规范> 决定了要取的是什么（例如例子中的 `master` 是  `master:` 的简称，意思是 "获取 'master' 分支，但我没有明确说要在命令行中更新哪个远程跟踪分支"），而这个例子的命令将「只」获取 'master' 分支。  `remote.<仓库>.fetch`值决定了哪个远程跟踪分支（如果有的话）被更新。  当以这种方式使用时，`remote.<仓库>.fetch` 值对决定获取什么没有任何影响（即当命令行列出引用规范时，这些值不会被用作引用规范）；它们只是通过作为一个映射来决定获取的引用被存储在哪里。

note: type: Plain text
en: The latter use of the `remote.<repository>.fetch` values can be overridden by giving the `--refmap=<refspec>` parameter(s) on the command line.
zh_HANS-CN: 后者对 `remote.<仓库>.fetch` 值的使用可以通过在命令行中给出 `--refmap=<引用规范>` 参数去覆盖。

note: type: Title -
en: PRUNING
zh_HANS-CN: 剪枝

note: type: Plain text
en: Git has a default disposition of keeping data unless it's explicitly thrown away; this extends to holding onto local references to branches on remotes that have themselves deleted those branches.
zh_HANS-CN: Git默认保留数据，除非它被明确地扔掉；这延伸到保留对远程分支的本地引用，而这些分支本身已经被删除。

note: type: Plain text
en: If left to accumulate, these stale references might make performance worse on big and busy repos that have a lot of branch churn, and e.g. make the output of commands like `git branch -a --contains <commit>` needlessly verbose, as well as impacting anything else that'll work with the complete set of known references.
zh_HANS-CN: 如果任其积累，这些陈旧的引用可能会使大型繁忙仓库的性能变差，例如，使 `git branch -a --contains <提交>` 等命令的输出不必要地冗长，以及影响其他任何与完整的已知引用有关的工作。

note: type: Plain text
en: These remote-tracking references can be deleted as a one-off with either of:
zh_HANS-CN: 这些远程跟踪引用可以通过以下两种方式一次性删除：

note: type: delimited block -
en: # While fetching
    $ git fetch --prune <name>
zh_HANS-CN: # 在获取的时候
    $ git fetch --prune <名称>

note: type: Plain text
en: To prune references as part of your normal workflow without needing to remember to run that, set `fetch.prune` globally, or `remote.<name>.prune` per-remote in the config. See linkgit:git-config[1].
zh_HANS-CN: 要把修剪引用作为正常工作流程的一部分，而不需要记住运行该程序，可以在全局设置 `fetch.prune`，或者在配置中设置 `remote.<名称>.prune`，为每个远程仓库进行设置。见linkgit:git-config[1]。

note: type: Plain text
en: Here's where things get tricky and more specific. The pruning feature doesn't actually care about branches, instead it'll prune local <--> remote-references as a function of the refspec of the remote (see `<refspec>` and <<CRTB,CONFIGURED REMOTE-TRACKING BRANCHES>> above).
zh_HANS-CN: 这里是事情变得棘手和更具体的地方。修剪功能实际上并不关心分支，相反，它将修剪本地<-->远程引用，作为远程的引用规范的函数（见上面的`<引用规范>`和上面的<<CRTB，配置远程跟踪分支>>）。

note: type: Plain text
en: Therefore if the refspec for the remote includes e.g. `refs/tags/*:refs/tags/*`, or you manually run e.g. `git fetch --prune <name> "refs/tags/*:refs/tags/*"` it won't be stale remote tracking branches that are deleted, but any local tag that doesn't exist on the remote.
zh_HANS-CN: 因此，如果远程的引用规范包括例如 `refs/tags/*:refs/tags/*`这样的规范，或者你手动运行例如 `git fetch --prune <名称> "refs/tags/*:refs/tags/*"`，那么被删除的就不是过时的远程跟踪分支，而是远程上不存在的任何本地标签。

note: type: Plain text
en: This might not be what you expect, i.e. you want to prune remote `<name>`, but also explicitly fetch tags from it, so when you fetch from it you delete all your local tags, most of which may not have come from the `<name>` remote in the first place.
zh_HANS-CN: 这可能不是你所期望的，即你想修剪远程的 `<名称>`，但也明确地从它那里获取标签，所以当你从它那里获取时，你会删除所有的本地标签，其中大部分可能首先不是来自远程的 `<名称>`。

note: type: Plain text
en: So be careful when using this with a refspec like `refs/tags/*:refs/tags/*`, or any other refspec which might map references from multiple remotes to the same local namespace.
zh_HANS-CN: 因此，当与 `refs/tags/*:refs/tags/*` 这样的引用规范一起使用时要小心，或者任何其他可能将多个远程的引用映射到同一本地命名空间的引用规范。

note: type: Plain text
en: Since keeping up-to-date with both branches and tags on the remote is a common use-case the `--prune-tags` option can be supplied along with `--prune` to prune local tags that don't exist on the remote, and force-update those tags that differ. Tag pruning can also be enabled with `fetch.pruneTags` or `remote.<name>.pruneTags` in the config. See linkgit:git-config[1].
zh_HANS-CN: 由于在远程保持最新的分支和标签是一个常见的使用情况，`--prune-tags` 选项可以和 `--prune` 一起使用，以修剪在远程不存在的本地标签，并强制更新那些不同的标签。标签修剪也可以通过配置中的 `fetch.pruneTags` 或 `remote.<名称>.pruneTags` 启用。见linkgit:git-config[1]。

note: type: Plain text
en: The `--prune-tags` option is equivalent to having `refs/tags/*:refs/tags/*` declared in the refspecs of the remote. This can lead to some seemingly strange interactions:
zh_HANS-CN: `--prune-tags` 选项相当于在远程的引用规范中声明 `refs/tags/*:refs/tags/*` 。这可能会导致一些看起来很奇怪的结果：

note: type: delimited block -
en: # These both fetch tags
    $ git fetch --no-tags origin 'refs/tags/*:refs/tags/*'
    $ git fetch --no-tags --prune-tags origin
zh_HANS-CN: # 这两个命令都可以用来获取标签
    $ git fetch --no-tags origin 'refs/tags/*:refs/tags/*'
    $ git fetch --no-tags --prune-tags origin

note: type: Plain text
en: The reason it doesn't error out when provided without `--prune` or its config versions is for flexibility of the configured versions, and to maintain a 1=1 mapping between what the command line flags do, and what the configuration versions do.
zh_HANS-CN: 在没有 `--prune` 或其配置的情况下，它不会出错的原因是为了配置的灵活性，以及在命令行标志和配置之间保持 1=1 的映射。

note: type: Plain text
en: It's reasonable to e.g. configure `fetch.pruneTags=true` in `~/.gitconfig` to have tags pruned whenever `git fetch --prune` is run, without making every invocation of `git fetch` without `--prune` an error.
zh_HANS-CN: 例如，在 `~/.gitconfig` 中配置 `fetch.pruneTags=true`，以便在运行 `git fetch --prune` 时修剪标签，这是很合理的，不会使每次调用 `git fetch` 而没有 `--prune` 时都出现错误。

note: type: Plain text
en: Pruning tags with `--prune-tags` also works when fetching a URL instead of a named remote. These will all prune tags not found on origin:
zh_HANS-CN: 使用 `--prune-tags` 修剪标签，在获取一个URL而不是一个命名的远程时也能发挥作用。这些都会修剪在原点没有发现的标签：

note: type: Plain text
en: The output of "git fetch" depends on the transport method used; this section describes the output when fetching over the Git protocol (either locally or via ssh) and Smart HTTP protocol.
zh_HANS-CN: "git fetch" 的输出取决于所使用的传输方式；本节描述了通过 Git 协议（本地或通过 ssh）和智能 HTTP 协议获取时的输出。

note: type: Plain text
en: The status of the fetch is output in tabular form, with each line representing the status of a single ref. Each line is of the form:
zh_HANS-CN: 获取的状态以表格的形式输出，每一行代表一个引用的状态。每一行的形式是：

note: type: Plain text
en: When using `--porcelain`, the output format is intended to be machine-parseable. In contrast to the human-readable output formats it thus prints to standard output instead of standard error. Each line is of the form:
zh_HANS-CN: 当使用 `--porcelain` 时，输出格式的目的是让机器可以解析。与人类可读的输出格式不同，它将打印到标准输出而不是标准错误。每一行都是这样的形式：

note: type: delimited block -
en: <flag> <old-object-id> <new-object-id> <local-reference>
zh_HANS-CN: <标志> <旧对象ID> <新对象ID> <本地引用>

note: type: Plain text
en: The status of up-to-date refs is shown only if the --verbose option is used.
zh_HANS-CN: 只有在使用 --verbose 选项时，才会显示最新的引用状态。

note: type: Plain text
en: In compact output mode, specified with configuration variable fetch.output, if either entire `<from>` or `<to>` is found in the other string, it will be substituted with `*` in the other string. For example, `master -> origin/master` becomes `master -> origin/*`.
zh_HANS-CN: 在紧凑输出模式下，通过配置变量 fetch.output 指定，如果在另一个字符串中发现整个 `<起点>` 或 `<终点>`，它将被替换成另一个字符串中的 `*`。例如，`master -> origin/master` 变成 `master -> origin/*`。

note: type: Plain text
en: A single character indicating the status of the ref:
zh_HANS-CN: 表示引用状态的单个字符：

note: type: Labeled list
en: (space)
zh_HANS-CN: （空格）

note: type: Plain text
en: for a successfully fetched fast-forward;
zh_HANS-CN: 表示成功的快速合并；

note: type: Plain text
en: for a successful forced update;
zh_HANS-CN: 表示一个成功的强制更新；

note: type: Plain text
en: for a successfully pruned ref;
zh_HANS-CN: 表示成功修剪引用；

note: type: Plain text
en: for a successful tag update;
zh_HANS-CN: 表示成功更新标签；

note: type: Plain text
en: for a successfully fetched new ref;
zh_HANS-CN: 表示成功获取新引用；

note: type: Plain text
en: for a ref that was rejected or failed to update; and
zh_HANS-CN: 表示被拒绝或更新失败的引用；以及

note: type: Plain text
en: for a ref that was up to date and did not need fetching.
zh_HANS-CN: 表示一个最新的、不需要获取的引用。

note: type: Plain text
en: For a successfully fetched ref, the summary shows the old and new values of the ref in a form suitable for using as an argument to `git log` (this is `<old>..<new>` in most cases, and `<old>...<new>` for forced non-fast-forward updates).
zh_HANS-CN: 对于一个成功获取的引用，摘要以适合作为 `git log` 参数的形式显示该引用的新旧值（在大多数情况下是 `<旧>..<新>`，对于强制非快速合并是 `<旧>...<新>`）。

note: type: Plain text
en: The name of the remote ref being fetched from, minus its `refs/<type>/` prefix. In the case of deletion, the name of the remote ref is "(none)".
zh_HANS-CN: 被获取的远程引用的名称，减去其`refs/<类型>/`前缀。在删除的情况下，远程引用的名称是 "(none)"。

note: type: Plain text
en: The name of the local ref being updated, minus its `refs/<type>/` prefix.
zh_HANS-CN: 被更新的本地引用的名称，去掉其 `refs/<类型>/` 前缀。

note: type: Plain text
en: A human-readable explanation. In the case of successfully fetched refs, no explanation is needed. For a failed ref, the reason for failure is described.
zh_HANS-CN: 一个人类可读的解释。如果是成功获取的引用，不需要解释。对于失败的引用，将描述失败的原因。

note: type: Plain text
en: Update the remote-tracking branches:
zh_HANS-CN: 更新远程追踪的分支：

note: type: Plain text
en: The above command copies all branches from the remote `refs/heads/` namespace and stores them to the local `refs/remotes/origin/` namespace, unless the `remote.<repository>.fetch` option is used to specify a non-default refspec.
zh_HANS-CN: 上述命令从远程的 `refs/heads/` 命名空间复制所有分支，并存储到本地的 `refs/remotes/origin/` 命名空间，除非使用 `remote.<仓库>.fetch` 选项来指定一个非默认的引用规范。

note: type: Plain text
en: Using refspecs explicitly:
zh_HANS-CN: 明确使用引用规范：

note: type: Plain text
en: This updates (or creates, as necessary) branches `seen` and `tmp` in the local repository by fetching from the branches (respectively)  `seen` and `maint` from the remote repository.
zh_HANS-CN: 这通过从远程存储库的分支（分别）获取 `seen` 和 `maint` 来更新（或根据需要创建）本地存储库中的分支 `seen` 和 `tmp`。

note: type: Plain text
en: The `seen` branch will be updated even if it does not fast-forward, because it is prefixed with a plus sign; `tmp` will not be.
zh_HANS-CN: 即使不快进，`seen` 分支也会被更新，因为它的前缀是加号；`tmp` 则不会。

note: type: Plain text
en: Peek at a remote's branch, without configuring the remote in your local repository:
zh_HANS-CN: 窥视一个远程的分支，而不需要在你的本地版本库中配置远程：

note: type: Plain text
en: The first command fetches the `maint` branch from the repository at `git://git.kernel.org/pub/scm/git/git.git` and the second command uses `FETCH_HEAD` to examine the branch with linkgit:git-log[1].  The fetched objects will eventually be removed by git's built-in housekeeping (see linkgit:git-gc[1]).
zh_HANS-CN: 第一条命令从 `git://git.kernel.org/pub/scm/git.git` 的存储库中获取 `maint` 分支，第二条命令使用 `FETCH_HEAD` 用 linkgit:git-log[1] 来检查该分支。  取出的对象最终会被 git 内置的内务管理删除（见 linkgit:git-gc[1]）。

note: type: Plain text
en: Using --recurse-submodules can only fetch new commits in submodules that are present locally e.g. in `$GIT_DIR/modules/`. If the upstream adds a new submodule, that submodule cannot be fetched until it is cloned e.g. by `git submodule update`. This is expected to be fixed in a future Git version.
zh_HANS-CN: 使用 --recurse-submodules 只能获取本地存在的子模块中的新提交，例如在 `$GIT_DIR/modules/`。如果上游添加了一个新的子模块，该子模块不能被获取，直到它被克隆，例如，通过`git submodule update`。这个问题有望在未来的 Git 版本中被修复。

note: type: Plain text
en: Takes the list of merged objects on stdin and produces a suitable commit message to be used for the merge commit, usually to be passed as the '<merge-message>' argument of 'git merge'.
zh_HANS-CN: 接收标准输入流中的合并对象列表，并产生一个合适的提交信息，用于合并提交，通常作为 'git merge' 的 '<merge-message>' 参数传递。

note: type: Plain text
en: This command is intended mostly for internal use by scripts automatically invoking 'git merge'.
zh_HANS-CN: 这条命令主要是供自动调用 'git merge' 的脚本内部使用。

note: type: Plain text
en: In addition to branch names, populate the log message with one-line descriptions from the actual commits that are being merged.  At most <n> commits from each merge parent will be used (20 if <n> is omitted).  This overrides the `merge.log` configuration variable.
zh_HANS-CN: 除了分支名称外，在日志信息中加入被合并的实际提交内容的单行描述。 最多使用每个合并父分支的 <n> 个提交（如果 <n> 被省略，则为 20 个）。 这覆盖了 `merge.log` 配置变量。

note: type: Plain text
en: Do not list one-line descriptions from the actual commits being merged.
zh_HANS-CN: 不要列出被合并的实际提交中的单行描述。

note: type: Plain text
en: Synonyms to --log and --no-log; these are deprecated and will be removed in the future.
zh_HANS-CN: 与 --log 和 --no-log 的同义词；这些都是废弃的，将来会被删除。

note: type: Plain text
en: Use <message> instead of the branch names for the first line of the log message.  For use with `--log`.
zh_HANS-CN: 在日志信息的第一行使用 <message> 而不是分支名称。 与 `--log` 一起使用。

note: type: Plain text
en: Prepare the merge message as if merging to the branch `<branch>`, instead of the name of the real branch to which the merge is made.
zh_HANS-CN: 准备合并信息，就像合并到分支 `<branch>` 一样，而不是合并到真正的分支名称。

note: type: Labeled list
en: --file <file>
zh_HANS-CN: --file <文件>

note: type: Plain text
en: Take the list of merged objects from <file> instead of stdin.
zh_HANS-CN: 从 <文件> 而不是标准输入流获取合并后的对象列表。

note: type: Plain text
en: Synonym to `merge.log`; this is deprecated and will be removed in the future.
zh_HANS-CN: `merge.log` 的同义词；这已被废弃，将来会被删除。

note: type: Plain text
en: Print a log message describing a merge of the "master" branch from the "origin" remote.
zh_HANS-CN: 打印一条日志信息，描述从 "origin" 远程分支合并到 "master" 分支的情况。

note: type: Plain text
en: Respect any colors specified in the `--format` option. The `<when>` field must be one of `always`, `never`, or `auto` (if `<when>` is absent, behave as if `always` was given).
zh_HANS-CN: 尊重`--format`选项中指定的任何颜色。`<什么时候>`字段必须是`always`、`never`或`auto`之一（如果没有`<什么时候>`，则表现为`always`）。

note: type: Plain text
en: The optional GPG signature of the tag.
zh_HANS-CN: tag的可选GPG签名。

note: type: Plain text
en: git-format-patch - Prepare patches for e-mail submission
zh_HANS-CN: git-format-patch - 为提交电子邮件准备补丁

note: type: Plain text
en: Prepare each non-merge commit with its "patch" in one "message" per commit, formatted to resemble a UNIX mailbox.  The output of this command is convenient for e-mail submission or for use with 'git am'.
zh_HANS-CN: 将每个非合并提交及其 “补丁” 准备在每个提交的一个 “消息” 中，格式类似于 UNIX 邮箱。 这条命令的输出便于提交电子邮件或与 "git am" 一起使用。

note: type: Plain text
en: A "message" generated by the command consists of three parts:
zh_HANS-CN: 命令产生的 "信息" 由三部分组成：

note: type: Plain text
en: A brief metadata header that begins with `From <commit>` with a fixed `Mon Sep 17 00:00:00 2001` datestamp to help programs like "file(1)" to recognize that the file is an output from this command, fields that record the author identity, the author date, and the title of the change (taken from the first paragraph of the commit log message).
zh_HANS-CN: 一个简短的元数据头，以 "From <提交>" 开始，带有固定的 "Mon Sep 17 00:00:00 2001" 的日期，以帮助 "file(1)" 等程序识别该文件是该命令的输出，记录作者身份、作者日期和修改标题的字段（取自提交日志信息的第一段）。

note: type: Plain text
en: The second and subsequent paragraphs of the commit log message.
zh_HANS-CN: 提交日志信息的第二段和后续段落。

note: type: Plain text
en: The "patch", which is the "diff -p --stat" output (see linkgit:git-diff[1]) between the commit and its parent.
zh_HANS-CN: “补丁”，也就是该提交和其父辈之间的 "diff -p -stat" 输出（见 linkgit:git-diff[1]）。

note: type: Plain text
en: The log message and the patch is separated by a line with a three-dash line.
zh_HANS-CN: 日志信息和补丁之间用一行三折线分开。

note: type: Plain text
en: There are two ways to specify which commits to operate on.
zh_HANS-CN: 有两种方法可以指定要对哪些提交进行操作。

note: type: Plain text
en: Generic <revision range> expression (see "SPECIFYING REVISIONS" section in linkgit:gitrevisions[7]) means the commits in the specified range.
zh_HANS-CN: 通用的 <修订范围> 表达式（见 linkgit:gitrevisions[7]中的 "指定修订" 一节）表示指定范围内的提交。

note: type: Plain text
en: The first rule takes precedence in the case of a single <commit>.  To apply the second rule, i.e., format everything since the beginning of history up until <commit>, use the `--root` option: `git format-patch --root <commit>`.  If you want to format only <commit> itself, you can do this with `git format-patch -1 <commit>`.
zh_HANS-CN: 在只有一个 <提交> 的情况下，第一条规则具有优先权。 要应用第二条规则，即格式化从历史开始到 <提交> 为止的所有内容，使用 `--root` 选项：`git format-patch --root <提交>`。 如果你只想格式化 <提交> 本身，你可以用`git format-patch -1 <提交>`来做。

note: type: Plain text
en: By default, each output file is numbered sequentially from 1, and uses the first line of the commit message (massaged for pathname safety) as the filename. With the `--numbered-files` option, the output file names will only be numbers, without the first line of the commit appended.  The names of the output files are printed to standard output, unless the `--stdout` option is specified.
zh_HANS-CN: 默认情况下，每个输出文件从 1 开始依次编号，并使用提交信息的第一行（为保证路径名的安全而进行了调整）作为文件名。使用 `--numbered-files` 选项，输出文件名将只有数字，而没有附加提交信息的第一行。 除非指定 `--stdout` 选项，否则输出文件的名称将被打印到标准输出。

note: type: Plain text
en: If `-o` is specified, output files are created in <dir>.  Otherwise they are created in the current working directory. The default path can be set with the `format.outputDirectory` configuration option.  The `-o` option takes precedence over `format.outputDirectory`.  To store patches in the current working directory even when `format.outputDirectory` points elsewhere, use `-o .`. All directory components will be created.
zh_HANS-CN: 如果指定了 `-o`，输出文件将在<目录>创建。 否则，它们将在当前工作目录下创建。默认路径可以通过 `format.outputDirectory` 配置选项来设置。 `-o` 选项优先于 `format.outputDirectory`。 要在当前工作目录下存储补丁，即使 `format.outputDirectory` 指向其他地方，使用 `-o .`。所有的目录组件都将被创建。

note: type: Plain text
en: By default, the subject of a single patch is "[PATCH] " followed by the concatenation of lines from the commit message up to the first blank line (see the DISCUSSION section of linkgit:git-commit[1]).
zh_HANS-CN: 默认情况下，单个补丁的主题是 "[PATCH]"，后面是提交信息到第一个空行的串联（见 linkgit:git-commit[1] 的讨论部分）。

note: type: Plain text
en: When multiple patches are output, the subject prefix will instead be "[PATCH n/m] ".  To force 1/1 to be added for a single patch, use `-n`.  To omit patch numbers from the subject, use `-N`.
zh_HANS-CN: 当输出多个补丁时，主题前缀将改为 "[PATCH n/m] "。 要强制为单个补丁添加 1/1，使用 `-n`。 要从主题中省略补丁编号，使用 `-N`。

note: type: Plain text
en: If given `--thread`, `git-format-patch` will generate `In-Reply-To` and `References` headers to make the second and subsequent patch mails appear as replies to the first mail; this also generates a `Message-ID` header to reference.
zh_HANS-CN: 如果给出 `--thread`，`git-format-patch` 将生成 `In-Reply-To` 和 `References` 头，使第二封和随后的补丁邮件显示为对第一封邮件的回复；这也会生成一个 `Message-ID` 头供参考。

note: type: Plain text
en: Prepare patches from the topmost <n> commits.
zh_HANS-CN: 从最上面的 <n> 个提交中准备补丁。

note: type: Labeled list
en: -o <dir>
zh_HANS-CN: -o <目录>

note: type: Plain text
en: Use <dir> to store the resulting files, instead of the current working directory.
zh_HANS-CN: 使用 <目录> 来存储结果文件，而不是当前工作目录。

note: type: Plain text
en: Name output in '[PATCH n/m]' format, even with a single patch.
zh_HANS-CN: 以 '[PATCH n/m]' 的格式输出名称，即使只有一个补丁。

note: type: Plain text
en: Name output in '[PATCH]' format.
zh_HANS-CN: 以 '[PATCH]' 格式输出名称。

note: type: Plain text
en: Start numbering the patches at <n> instead of 1.
zh_HANS-CN: 从<n>开始个给补丁编号，替代默认从1开始。

note: type: Plain text
en: Output file names will be a simple number sequence without the default first line of the commit appended.
zh_HANS-CN: 输出文件名将是一个简单的数字序列，没有附加默认的第一行提交。

note: type: Plain text
en: Do not strip/add '[PATCH]' from the first line of the commit log message.
zh_HANS-CN: 不要从提交日志信息的第一行剥离/添加 '[PATCH]'。

note: type: Plain text
en: Print all commits to the standard output in mbox format, instead of creating a file for each one.
zh_HANS-CN: 以 mbox 格式将所有的提交打印到标准输出，而不是为每个提交创建一个文件。

note: type: Plain text
en: Create multipart/mixed attachment, the first part of which is the commit message and the patch itself in the second part, with `Content-Disposition: attachment`.
zh_HANS-CN: 创建多部分/混合附件，第一部分是提交信息，第二部分是补丁本身，`Content-Disposition: attachment`。

note: type: Plain text
en: Disable the creation of an attachment, overriding the configuration setting.
zh_HANS-CN: 禁用附件的创建，覆盖配置设置。

note: type: Plain text
en: Create multipart/mixed attachment, the first part of which is the commit message and the patch itself in the second part, with `Content-Disposition: inline`.
zh_HANS-CN: 创建 multipart/mixed 附件，第一部分是提交信息，第二部分是补丁本身，使用 `Content-Disposition: inline`。

note: type: Plain text
en: Controls addition of `In-Reply-To` and `References` headers to make the second and subsequent mails appear as replies to the first.  Also controls generation of the `Message-ID` header to reference.
zh_HANS-CN: 控制添加 `In-Reply-To` 和 `References` 标头，使第二封及以后的邮件显示为对第一封邮件的回复。 还控制生成 `Message-ID` 头，以便参考。

note: type: Plain text
en: The optional <style> argument can be either `shallow` or `deep`.  'shallow' threading makes every mail a reply to the head of the series, where the head is chosen from the cover letter, the `--in-reply-to`, and the first patch mail, in this order.  'deep' threading makes every mail a reply to the previous one.
zh_HANS-CN: 可选的 <风格> 参数可以是 `shallow` 或 `deep`。 ‘浅’ 线程使每封邮件都是对该系列的头的回复，其中头是从封面信、`--in-reply-to` 和第一个补丁邮件中选择的，按这个顺序。 ‘深’ 线程使每封邮件都是对前一封的回复。

note: type: Plain text
en: The default is `--no-thread`, unless the `format.thread` configuration is set.  `--thread` without an argument is equivalent to `--thread=shallow`.
zh_HANS-CN: 默认是 `--no-thread`，除非设置了 `format.thread` 配置。 没有参数的 `--thread` 等同于 `--thread=shallow`。

note: type: Plain text
en: Beware that the default for 'git send-email' is to thread emails itself.  If you want `git format-patch` to take care of threading, you will want to ensure that threading is disabled for `git send-email`.
zh_HANS-CN: 请注意，'git send-email' 的默认设置是对邮件本身进行线程处理。 如果你想让 `git format-patch` 负责线程，你要确保 `git send-email` 的线程被禁用。

note: type: Plain text
en: Make the first mail (or all the mails with `--no-thread`) appear as a reply to the given <message id>, which avoids breaking threads to provide a new patch series.
zh_HANS-CN: 使第一封邮件（或所有带有 `--no-thread` 的邮件）作为给定的 <消息 id> 的回复出现，这可以避免破坏线程以提供一个新的补丁系列。

note: type: Plain text
en: Do not include a patch that matches a commit in <until>..<since>.  This will examine all patches reachable from <since> but not from <until> and compare them with the patches being generated, and any patch that matches is ignored.
zh_HANS-CN: 不包括与 <until>...<since> 中的提交相匹配的补丁。 这将检查所有可从 <since> 到达但不在 <until> 的补丁，并将它们与正在生成的补丁进行比较，任何匹配的补丁都将被忽略。

note: type: Plain text
en: Include patches for commits that do not introduce any change, which are omitted by default.
zh_HANS-CN: 包括那些没有引入任何变化的提交的补丁，这些补丁默认是省略的。

note: type: Plain text
en: Controls which parts of the cover letter will be automatically populated using the branch's description.
zh_HANS-CN: 控制求职信的哪些部分将使用分支机构的描述自动填充。

note: type: Plain text
en: If `<mode>` is `message` or `default`, the cover letter subject will be populated with placeholder text. The body of the cover letter will be populated with the branch's description. This is the default mode when no configuration nor command line option is specified.
zh_HANS-CN: 如果 `<模式>` 是 `message` 或 `default`，求职信的主题将被填充为占位符文本。信函的正文将被填入分支的描述。这是没有指定配置或命令行选项时的默认模式。

note: type: Plain text
en: If `<mode>` is `subject`, the first paragraph of the branch description will populate the cover letter subject. The remainder of the description will populate the body of the cover letter.
zh_HANS-CN: 如果 `<模式>` 是 `subject`，分支描述的第一段将填入求职信的主题。描述的其余部分将填充到求职信的正文中。

note: type: Plain text
en: If `<mode>` is `auto`, if the first paragraph of the branch description is greater than 100 bytes, then the mode will be `message`, otherwise `subject` will be used.
zh_HANS-CN: 如果 `<模式>` 是 `auto`，如果分支描述的第一段大于100字节，那么模式将是 `message`，否则将使用 `subject`。

note: type: Plain text
en: If `<mode>` is `none`, both the cover letter subject and body will be populated with placeholder text.
zh_HANS-CN: 如果 `<模式>` 为 `none`，求职信的主题和正文都将被填充为占位符文本。

note: type: Plain text
en: Instead of the standard '[PATCH]' prefix in the subject line, instead use '[<subject prefix>]'. This allows for useful naming of a patch series, and can be combined with the `--numbered` option.
zh_HANS-CN: 在主题行中不要使用标准的 '[PATCH]' 前缀，而要使用 '[<subject prefix>]'。这允许对一个补丁系列进行有用的命名，并可以与 `--numbered` 选项结合使用。

note: type: Plain text
en: Instead of the standard 64 bytes, chomp the generated output filenames at around '<n>' bytes (too short a value will be silently raised to a reasonable length).  Defaults to the value of the `format.filenameMaxLength` configuration variable, or 64 if unconfigured.
zh_HANS-CN: 代替标准的 64 字节，将生成的输出文件名压缩到 '<n>' 字节左右（太短的值会被默默提升到合理的长度）。 默认为 `format.filenameMaxLength` 配置变量的值，如果没有配置，则为 64。

note: type: Plain text
en: Alias for `--subject-prefix="RFC PATCH"`. RFC means "Request For Comments"; use this when sending an experimental patch for discussion rather than application.
zh_HANS-CN: `--subject-prefix="RFC PATCH"` 的别名。RFC 的意思是 "Request For Comments"；在发送实验性补丁供讨论而非应用时使用。

note: type: Labeled list
en: --to=<email>
zh_HANS-CN: --to=<e-mail>

note: type: Plain text
en: Add a `To:` header to the email headers. This is in addition to any configured headers, and may be used multiple times.  The negated form `--no-to` discards all `To:` headers added so far (from config or command line).
zh_HANS-CN: 在邮件标题中增加一个 `To: ` 头。这是在任何配置的头信息之外的，可以多次使用。 否定的形式 `--no-to` 会丢弃到目前为止添加的所有 `To:` 头信息（来自配置或命令行）。

note: type: Plain text
en: Add a `Cc:` header to the email headers. This is in addition to any configured headers, and may be used multiple times.  The negated form `--no-cc` discards all `Cc:` headers added so far (from config or command line).
zh_HANS-CN: 在邮件标题中添加 `Cc: ` 标头。这是在任何配置的头信息之外的，可以多次使用。 否定的形式 `--no-cc` 会丢弃到目前为止添加的所有 `Cc:` 头信息（来自配置或命令行）。

note: type: Plain text
en: Use `ident` in the `From:` header of each commit email. If the author ident of the commit is not textually identical to the provided `ident`, place a `From:` header in the body of the message with the original author. If no `ident` is given, use the committer ident.
zh_HANS-CN: 在每封提交邮件的`From:` 标头中使用 `ident`。如果提交的作者身份与所提供的 `ident` 在文字上不一致，则在邮件正文中放置一个 `From: ` 头，注明原作者。如果没有给出 `ident`，则使用提交者的身份。

note: type: Plain text
en: Note that this option is only useful if you are actually sending the emails and want to identify yourself as the sender, but retain the original author (and `git am` will correctly pick up the in-body header). Note also that `git send-email` already handles this transformation for you, and this option should not be used if you are feeding the result to `git send-email`.
zh_HANS-CN: 注意，这个选项只有在你实际发送邮件时才有用，并且想把你自己确定为发件人，但保留原作者（`git am` 会正确接收正文头）。还要注意的是，`git send-email` 已经为你处理了这种转换，如果你将结果反馈给 `git send-email`，就不应该使用这个选项。

note: type: Plain text
en: With the e-mail sender specified via the `--from` option, by default, an in-body "From:" to identify the real author of the commit is added at the top of the commit log message if the sender is different from the author.  With this option, the in-body "From:" is added even when the sender and the author have the same name and address, which may help if the mailing list software mangles the sender's identity.  Defaults to the value of the `format.forceInBodyFrom` configuration variable.
zh_HANS-CN: 对于通过 `--from` 选项指定的电子邮件发件人，默认情况下，如果发件人与作者不同，会在提交日志信息的顶部添加一个内文 "From:"，以确定提交的真正作者。 有了这个选项，即使发件人和作者的名字和地址相同，也会在正文中加入 "From："，这在邮件列表软件混淆发件人身份时可能会有帮助。 默认为 `format.forceInBodyFrom` 配置变量的值。

note: type: Plain text
en: Add an arbitrary header to the email headers.  This is in addition to any configured headers, and may be used multiple times.  For example, `--add-header="Organization: git-foo"`.  The negated form `--no-add-header` discards *all* (`To:`, `Cc:`, and custom) headers added so far from config or command line.
zh_HANS-CN: 在邮件头中添加一个任意的头。 这是在任何配置的头文件之外的，并且可以多次使用。 例如，`--add-header="Organization: git-foo"`。 否定的形式 `--no-add-header` 会丢弃 *所有*（`To:`, `Cc:`, 和自定义）从配置或命令行添加的头信息。

note: type: Plain text
en: In addition to the patches, generate a cover letter file containing the branch description, shortlog and the overall diffstat.  You can fill in a description in the file before sending it out.
zh_HANS-CN: 除了补丁之外，还要生成一个包含分支描述、短日志和整体差异状态的封面文件。 你可以在发送之前在文件中填写描述。

note: type: Plain text
en: Encode email headers that have non-ASCII characters with "Q-encoding" (described in RFC 2047), instead of outputting the headers verbatim. Defaults to the value of the `format.encodeEmailHeaders` configuration variable.
zh_HANS-CN: 用 "Q-encoding"（在RFC 2047中描述）对有非 ASCII 字符的邮件头进行编码，而不是逐字输出邮件头。默认为 `format.encodeEmailHeaders` 配置变量的值。

note: type: Plain text
en: As a reviewer aid, insert an interdiff into the cover letter, or as commentary of the lone patch of a 1-patch series, showing the differences between the previous version of the patch series and the series currently being formatted. `previous` is a single revision naming the tip of the previous series which shares a common base with the series being formatted (for example `git format-patch --cover-letter --interdiff=feature/v1 -3 feature/v2`).
zh_HANS-CN: 作为审查员的帮助，在封面信中插入一个 interdiff，或者作为1个补丁系列中唯一一个补丁的注释，显示补丁系列的前一个版本与当前被格式化的系列之间的差异。`previous` 是一个单一的修订，命名了与被格式化的系列有共同基础的前一个系列的提示（例如 `git format-patch --cover-letter --interdiff=feature/v1 -3 feature/v2`）。

note: type: Plain text
en: As a reviewer aid, insert a range-diff (see linkgit:git-range-diff[1])  into the cover letter, or as commentary of the lone patch of a 1-patch series, showing the differences between the previous version of the patch series and the series currently being formatted.  `previous` can be a single revision naming the tip of the previous series if it shares a common base with the series being formatted (for example `git format-patch --cover-letter --range-diff=feature/v1 -3 feature/v2`), or a revision range if the two versions of the series are disjoint (for example `git format-patch --cover-letter --range-diff=feature/v1~3..feature/v1 -3 feature/v2`).
zh_HANS-CN: 作为审查员的辅助工具，在封面信中插入一个 range-diff（见 linkgit:git-range-diff[1]），或者作为1个补丁系列中唯一一个补丁的注释，显示该补丁系列的前一个版本与当前被格式化的系列之间的差异。 `previous` 可以是一个单一的修订版，如果它与被格式化的系列有共同的基础，则命名为前一个系列的提示（例如 `git format-patch --cover-letter --range-diff=feature/v1 -3 feature/v2`），如果两个系列的版本不相干，则是一个修订范围（例如 `git format-patch --cover-letter --range-diff=feature/v1~3.feature/v1 -3 feature/v2`）。

note: type: Plain text
en: Note that diff options passed to the command affect how the primary product of `format-patch` is generated, and they are not passed to the underlying `range-diff` machinery used to generate the cover-letter material (this may change in the future).
zh_HANS-CN: 请注意，传递给命令的差异选项会影响 `format-patch` 的主要产品如何生成，它们不会传递给用于生成封面材料的基础 `range-diff ` 机器（这在将来可能会改变）。

note: type: Labeled list
en: --creation-factor=<percent>
zh_HANS-CN: --creation-factor=<百分比>

note: type: Plain text
en: Used with `--range-diff`, tweak the heuristic which matches up commits between the previous and current series of patches by adjusting the creation/deletion cost fudge factor. See linkgit:git-range-diff[1])  for details.
zh_HANS-CN: 与 `--range-diff` 一起使用，通过调整创建/删除成本的模糊系数，来调整匹配上一个和当前系列补丁之间提交的启发式方法。详情见 linkgit:git-range-diff[1]）。

note: type: Plain text
en: Append the notes (see linkgit:git-notes[1]) for the commit after the three-dash line.
zh_HANS-CN: 在三折线之后添加该提交的注释（见 linkgit:git-notes[1]）。

note: type: Plain text
en: The expected use case of this is to write supporting explanation for the commit that does not belong to the commit log message proper, and include it with the patch submission. While one can simply write these explanations after `format-patch` has run but before sending, keeping them as Git notes allows them to be maintained between versions of the patch series (but see the discussion of the `notes.rewrite` configuration options in linkgit:git-notes[1] to use this workflow).
zh_HANS-CN: 预期的用例是为提交编写不属于提交日志信息本身的支持性解释，并将其包含在补丁提交中。虽然我们可以在 `format-patch` 运行后但在发送前简单地写下这些解释，但将其保留为 Git 笔记，可以在补丁系列的不同版本之间进行维护（但要使用这种工作流程，请参考 linkgit:git-notes[1] 中关于`notes.rewrite` 配置选项的讨论）。

note: type: Plain text
en: The default is `--no-notes`, unless the `format.notes` configuration is set.
zh_HANS-CN: 默认为`--no-notes`，除非设置了 `format.notes` 配置。

note: type: Plain text
en: Add a signature to each message produced. Per RFC 3676 the signature is separated from the body by a line with '-- ' on it. If the signature option is omitted the signature defaults to the Git version number.
zh_HANS-CN: 给每个产生的信息添加一个签名。根据 RFC 3676，签名与正文之间用一行 '--' 分隔。如果签名选项被省略，则签名默认为 Git 版本号。

note: type: Plain text
en: Works just like --signature except the signature is read from a file.
zh_HANS-CN: 工作原理与--签名相同，只是签名是从文件中读取的。

note: type: Plain text
en: Instead of using `.patch` as the suffix for generated filenames, use specified suffix.  A common alternative is `--suffix=.txt`.  Leaving this empty will remove the `.patch` suffix.
zh_HANS-CN: 不使用 `.patch` 作为生成文件名的后缀，而使用指定的后缀。 一个常见的选择是 `--suffix=.txt`。 将此留空将删除 `.patch` 后缀。

note: type: Plain text
en: Note that the leading character does not have to be a dot; for example, you can use `--suffix=-patch` to get `0001-description-of-my-change-patch`.
zh_HANS-CN: 请注意，前导字符不一定是点；例如，你可以使用 `--suffix=-patch` 来获得 `0001-description-of-my-change-patch`。

note: type: Plain text
en: Do not print the names of the generated files to standard output.
zh_HANS-CN: 不要将生成的文件名打印到标准输出。

note: type: Plain text
en: Do not output contents of changes in binary files, instead display a notice that those files changed.  Patches generated using this option cannot be applied properly, but they are still useful for code review.
zh_HANS-CN: 不输出二进制文件中的变化内容，而是显示这些文件变化的通知。 使用该选项生成的补丁不能被正确应用，但它们对代码审查仍然有用。

note: type: Plain text
en: Output an all-zero hash in each patch's From header instead of the hash of the commit.
zh_HANS-CN: 在每个补丁的 From 头中输出一个全零的哈希值，而不是提交的哈希值。

note: type: Plain text
en: Record the base tree information to identify the state the patch series applies to.  See the BASE TREE INFORMATION section below for details. If <commit> is "auto", a base commit is automatically chosen. The `--no-base` option overrides a `format.useAutoBase` configuration.
zh_HANS-CN: 记录基树信息，以确定该补丁系列所适用的状态。 详见下面的基树信息部分。如果 <提交> 是 "auto"，就会自动选择一个基数提交。`--no-base` 选项会覆盖 `format.useAutoBase` 配置。

note: type: Plain text
en: Treat the revision argument as a <revision range>, even if it is just a single commit (that would normally be treated as a <since>).  Note that root commits included in the specified range are always formatted as creation patches, independently of this flag.
zh_HANS-CN: 将修订版参数视为 <revision range>，即使它只是一个单一的提交（通常会被视为 <since>）。 注意，包含在指定范围内的根提交总是被格式化为创建补丁，与此标志无关。

note: type: Plain text
en: Show progress reports on stderr as patches are generated.
zh_HANS-CN: 在生成补丁时在标准错误流上显示进度报告。

note: type: Plain text
en: You can specify extra mail header lines to be added to each message, defaults for the subject prefix and file suffix, number patches when outputting more than one patch, add "To:" or "Cc:" headers, configure attachments, change the patch output directory, and sign off patches with configuration variables.
zh_HANS-CN: 你可以指定额外的邮件标题行添加到每封邮件中，主题前缀和文件后缀的默认值，在输出多个补丁时对补丁进行编号，添加 "To: " 或 "Cc: " 标题，配置附件，更改补丁输出目录，以及用配置变量签署补丁。

note: type: Plain text
en: The patch produced by 'git format-patch' is in UNIX mailbox format, with a fixed "magic" time stamp to indicate that the file is output from format-patch rather than a real mailbox, like so:
zh_HANS-CN: 由 'git format-patch' 产生的补丁是 UNIX 邮箱格式，有一个固定的 "magic" 时间戳，以表明该文件是由 format-patch 输出的，而不是一个真正的邮箱，像这样：

note: type: delimited block -
en: arch/arm config files were slimmed down using a python script
    (See commit c2330e286f68f1c408b4aa6515ba49d57f05beae comment)
zh_HANS-CN: arch/arm config files were slimmed down using a python script
    (见提交 c2330e286f68f1c408b4aa6515ba49d57f05beae 评论)

note: type: delimited block -
en: Do the same for ia64 so we can have sleek & trim looking
    ...
zh_HANS-CN: 为 ia64 做同样的事情，这样我们就可以有光滑和修长的外观了。
    ...

note: type: Plain text
en: Typically it will be placed in a MUA's drafts folder, edited to add timely commentary that should not go in the changelog after the three dashes, and then sent as a message whose body, in our example, starts with "arch/arm config files were...".  On the receiving end, readers can save interesting patches in a UNIX mailbox and apply them with linkgit:git-am[1].
zh_HANS-CN: 通常情况下，它会被放在 MUA 的 drafts 文件夹中，被编辑以添加及时的评论，这些评论不应该被放在 changelog 中的三个破折号之后，然后以消息的形式发送，在我们的例子中，其正文以 "arch/arm config files were..." 开始。 在接收端，读者可以将有趣的补丁保存在 UNIX 邮箱中，并通过 linkgit:git-am[1] 应用它们。

note: type: Plain text
en: When a patch is part of an ongoing discussion, the patch generated by 'git format-patch' can be tweaked to take advantage of the 'git am --scissors' feature.  After your response to the discussion comes a line that consists solely of "`-- >8 --`" (scissors and perforation), followed by the patch with unnecessary header fields removed:
zh_HANS-CN: 当一个补丁是正在进行的讨论的一部分时，由 'git format-patch' 生成的补丁可以进行调整，以利用 'git am --scissors' 功能。 在你对讨论的回应之后，有一行只由 "`-- >8 --`"（剪刀和打孔）组成，后面是去除不必要的头域的补丁：

note: type: delimited block -
en: Makes sense to me.  How about this patch?
zh_HANS-CN: 对我来说是有意义的。 这个补丁怎么样？

note: type: delimited block -
en: arch/arm config files were slimmed down using a python script
    ...
zh_HANS-CN: 使用 python 脚本对 arch/arm 配置文件进行了精简
    ...

note: type: Plain text
en: When sending a patch this way, most often you are sending your own patch, so in addition to the "`From $SHA1 $magic_timestamp`" marker you should omit `From:` and `Date:` lines from the patch file.  The patch title is likely to be different from the subject of the discussion the patch is in response to, so it is likely that you would want to keep the Subject: line, like the example above.
zh_HANS-CN: 当用这种方式发送补丁时，大多数情况下是发送你自己的补丁，所以除了 "`From $SHA1 $magic_timestamp`" 标记外，你应该从补丁文件中省略 `From: ` 和 `Date: ` 行。 补丁的标题很可能与补丁所回应的讨论主题不同，所以很可能要保留 Subject: 这一行，就像上面的例子一样。

note: type: Title ~
en: Checking for patch corruption
zh_HANS-CN: 检查补丁是否损坏

note: type: Plain text
en: Many mailers if not set up properly will corrupt whitespace.  Here are two common types of corruption:
zh_HANS-CN: 许多邮件如果设置不当就会破坏空白。 以下是两种常见的损坏类型：

note: type: Plain text
en: Empty context lines that do not have _any_ whitespace.
zh_HANS-CN: 没有「任何」空格的空的上下文行。

note: type: Plain text
en: Non-empty context lines that have one extra whitespace at the beginning.
zh_HANS-CN: 非空的上下文行，在开头有一个额外的空白。

note: type: Plain text
en: One way to test if your MUA is set up correctly is:
zh_HANS-CN: 测试你的 MUA 是否设置正确的一个方法是：

note: type: Plain text
en: Send the patch to yourself, exactly the way you would, except with To: and Cc: lines that do not contain the list and maintainer address.
zh_HANS-CN: 将补丁发送给自己，完全按照你的方式，只是在 To: 和 Cc: 行中不包含列表和维护者地址。

note: type: Plain text
en: Save that patch to a file in UNIX mailbox format.  Call it a.patch, say.
zh_HANS-CN: 将该补丁保存为 UNIX 邮箱格式的文件。 称之为 a.patch，例如。

note: type: Plain text
en: Apply it:
zh_HANS-CN: 应用它：

note: type: Plain text
en: If it does not apply correctly, there can be various reasons.
zh_HANS-CN: 如果它不能正确应用，可能有各种原因。

note: type: Plain text
en: The patch itself does not apply cleanly.  That is _bad_ but does not have much to do with your MUA.  You might want to rebase the patch with linkgit:git-rebase[1] before regenerating it in this case.
zh_HANS-CN: 补丁本身不能干净地应用。 这很糟糕，但与你的 MUA 没有多大关系。 在这种情况下，你可能要先用 linkgit:git-rebase[1] 把补丁重新归位，再重新生成。

note: type: Plain text
en: The MUA corrupted your patch; "am" would complain that the patch does not apply.  Look in the .git/rebase-apply/ subdirectory and see what 'patch' file contains and check for the common corruption patterns mentioned above.
zh_HANS-CN: MUA 损坏了你的补丁；"am" 会抱怨补丁不适用。 查看 .git/rebase-apply/ 子目录，看看 "补丁" 文件包含哪些内容，并检查上面提到的常见损坏模式。

note: type: Plain text
en: While at it, check the 'info' and 'final-commit' files as well.  If what is in 'final-commit' is not exactly what you would want to see in the commit log message, it is very likely that the receiver would end up hand editing the log message when applying your patch.  Things like "Hi, this is my first patch.\n" in the patch e-mail should come after the three-dash line that signals the end of the commit message.
zh_HANS-CN: 同时，还要检查 'info' 和 'final-commit' 文件。 如果 'final-commit' 中的内容与你希望在提交日志信息中看到的不完全一样，那么很可能接收者在应用你的补丁时最终会手工编辑日志信息。 补丁邮件中的 "Hi, this is my first patch.\n" 等内容应该出现在提交信息末尾的三折线之后。

note: type: Title -
en: MUA-SPECIFIC HINTS
zh_HANS-CN: 针对 Mua 的提示

note: type: Plain text
en: Here are some hints on how to successfully submit patches inline using various mailers.
zh_HANS-CN: 这里有一些关于如何使用各种邮件工具成功地在线提交补丁的提示。

note: type: Plain text
en: GMail does not have any way to turn off line wrapping in the web interface, so it will mangle any emails that you send.  You can however use "git send-email" and send your patches through the GMail SMTP server, or use any IMAP email client to connect to the google IMAP server and forward the emails through that.
zh_HANS-CN: GMail 没有办法在网页界面上关闭换行，所以它会把你发送的任何邮件弄得一团糟。 然而，你可以使用 "git send-email"，通过 GMail 的 SMTP 服务器发送你的补丁，或者使用任何 IMAP 电子邮件客户端连接到谷歌的 IMAP 服务器，并通过它转发电子邮件。

note: type: Plain text
en: For hints on using 'git send-email' to send your patches through the GMail SMTP server, see the EXAMPLE section of linkgit:git-send-email[1].
zh_HANS-CN: 关于使用 'git send-email' 通过 GMail SMTP 服务器发送补丁的提示，请参见 linkgit:git-send-email[1] 的案例部分。

note: type: Plain text
en: For hints on submission using the IMAP interface, see the EXAMPLE section of linkgit:git-imap-send[1].
zh_HANS-CN: 关于使用 IMAP 接口提交的提示，请参见 linkgit:git-imap-send[1] 的案例部分。

note: type: Plain text
en: By default, Thunderbird will both wrap emails as well as flag them as being 'format=flowed', both of which will make the resulting email unusable by Git.
zh_HANS-CN: 默认情况下，Thunderbird 会将邮件包裹起来，并将其标记为 'format=flowed'，这两种情况都会使 Git 无法使用这些邮件。

note: type: Plain text
en: There are three different approaches: use an add-on to turn off line wraps, configure Thunderbird to not mangle patches, or use an external editor to keep Thunderbird from mangling the patches.
zh_HANS-CN: 有三种不同的方法：使用插件来关闭换行，配置 Thunderbird 使其不纠缠补丁，或者使用外部编辑器来防止 Thunderbird 纠缠补丁。

note: type: Title ^
en: Approach #1 (add-on)
zh_HANS-CN: 办法1（附加的）

note: type: Plain text
en: Install the Toggle Word Wrap add-on that is available from https://addons.mozilla.org/thunderbird/addon/toggle-word-wrap/ It adds a menu entry "Enable Word Wrap" in the composer's "Options" menu that you can tick off. Now you can compose the message as you otherwise do (cut + paste, 'git format-patch' | 'git imap-send', etc), but you have to insert line breaks manually in any text that you type.
zh_HANS-CN: 安装 Toggle Word Wrap 插件，该插件可从 https://addons.mozilla.org/thunderbird/addon/toggle-word-wrap/。它在作曲家的 "选项" 菜单中增加了一个 "启用换行符" 的菜单项，你可以将其勾掉。现在你可以像其他方式一样编写信息（剪切+粘贴，'git format-patch'|'git imap-send'，等等），但你必须在你输入的任何文本中手动插入换行符。

note: type: Title ^
en: Approach #2 (configuration)
zh_HANS-CN: 方法#2（配置）

note: type: Plain text
en: Three steps:
zh_HANS-CN: 三个步骤：

note: type: Plain text
en: Configure your mail server composition as plain text: Edit...Account Settings...Composition & Addressing, uncheck "Compose Messages in HTML".
zh_HANS-CN: 将你的邮件服务器组成配置为纯文本： 编辑......账户设置......组成和地址，取消勾选 "以HTML编写邮件"。

note: type: Plain text
en: Configure your general composition window to not wrap.
zh_HANS-CN: 配置你的一般组成窗口，使其不被包裹。

note: type: Plain text
en: In Thunderbird 2: Edit..Preferences..Composition, wrap plain text messages at 0
zh_HANS-CN: 在 Thunderbird 2 中：编辑...偏好...组成，将纯文本信息包在 0 处

note: type: Plain text
en: In Thunderbird 3: Edit..Preferences..Advanced..Config Editor.  Search for "mail.wrap_long_lines".  Toggle it to make sure it is set to `false`. Also, search for "mailnews.wraplength" and set the value to 0.
zh_HANS-CN: 在 Thunderbird 3 中：编辑...偏好...高级...配置编辑器。 搜索 "mail.wrap_long_lines"。 切换它，确保它被设置为 "false"。另外，搜索 "mailnews.wraplength" 并将其设置为 0。

note: type: Plain text
en: Disable the use of format=flowed: Edit..Preferences..Advanced..Config Editor.  Search for "mailnews.send_plaintext_flowed".  Toggle it to make sure it is set to `false`.
zh_HANS-CN: 禁止使用 format=flowed： 编辑...偏好...高级...配置编辑器。 搜索 "mailnews.send_plaintext_flowed"。 拨动它，确保它被设置为 `false`。

note: type: Plain text
en: After that is done, you should be able to compose email as you otherwise would (cut + paste, 'git format-patch' | 'git imap-send', etc), and the patches will not be mangled.
zh_HANS-CN: 完成后，你应该能够像其他方式一样编写电子邮件（剪切+粘贴，'git format-patch' | 'git imap-send'，等等），而且补丁不会被弄乱。

note: type: Title ^
en: Approach #3 (external editor)
zh_HANS-CN: 方法三（外部编辑）

note: type: Plain text
en: The following Thunderbird extensions are needed: AboutConfig from http://aboutconfig.mozdev.org/ and External Editor from http://globs.org/articles.php?lng=en&pg=8
zh_HANS-CN: 需要以下 Thunderbird 扩展： http://aboutconfig.mozdev.org/ 中的 AboutConfig和http://globs.org/articles.php?lng=en&pg=8 中的 External Editor

note: type: Plain text
en: Prepare the patch as a text file using your method of choice.
zh_HANS-CN: 用你选择的方法把补丁准备成一个文本文件。

note: type: Plain text
en: Before opening a compose window, use Edit->Account Settings to uncheck the "Compose messages in HTML format" setting in the "Composition & Addressing" panel of the account to be used to send the patch.
zh_HANS-CN: 在打开撰写窗口之前，使用 Edit->Account Settingd 取消勾选要用来发送补丁的账户的 "Composition & Addressing" 面板中的 "Compose messages in HTML format" 设置。

note: type: Plain text
en: In the main Thunderbird window, 'before' you open the compose window for the patch, use Tools->about:config to set the following to the indicated values:
zh_HANS-CN: 在 Thunderbird 主窗口中，在你打开补丁的撰写窗口之前，使用 Tools->about:config 将以下内容设置为指定值：

note: type: Plain text
en: Open a compose window and click the external editor icon.
zh_HANS-CN: 打开一个作曲窗口，点击外部编辑器图标。

note: type: Plain text
en: In the external editor window, read in the patch file and exit the editor normally.
zh_HANS-CN: 在外部编辑器窗口，读入补丁文件并正常退出编辑器。

note: type: Plain text
en: Side note: it may be possible to do step 2 with about:config and the following settings but no one's tried yet.
zh_HANS-CN: 题外话：也许可以用 about:config 和以下设置来完成第二步，但还没有人试过。

note: type: Plain text
en: There is a script in contrib/thunderbird-patch-inline which can help you include patches with Thunderbird in an easy way. To use it, do the steps above and then use the script as the external editor.
zh_HANS-CN: contrib/thunderbird-patch-inline 中有一个脚本，可以帮助你以一种简单的方式将补丁加入 Thunderbird。要使用它，请执行上面的步骤，然后使用该脚本作为外部编辑器。

note: type: Plain text
en: This should help you to submit patches inline using KMail.
zh_HANS-CN: 这应该有助于你使用 KMail 在线提交补丁。

note: type: Plain text
en: Prepare the patch as a text file.
zh_HANS-CN: 把补丁准备成一个文本文件。

note: type: Plain text
en: Click on New Mail.
zh_HANS-CN: 点击 "New Mail"。

note: type: Plain text
en: Go under "Options" in the Composer window and be sure that "Word wrap" is not set.
zh_HANS-CN: 在合成器窗口的 "Otions" 下，确保没有设置 "Word warp"。

note: type: Plain text
en: Use Message -> Insert file... and insert the patch.
zh_HANS-CN: Use Message -> Insert file... 并插入补丁。

note: type: Plain text
en: Back in the compose window: add whatever other text you wish to the message, complete the addressing and subject fields, and press send.
zh_HANS-CN: 回到撰写窗口：在信息中添加你想要的任何其他文本，完成地址和主题字段，然后按发送。

note: type: Title -
en: BASE TREE INFORMATION
zh_HANS-CN: 基准树信息

note: type: Plain text
en: The base tree information block is used for maintainers or third party testers to know the exact state the patch series applies to. It consists of the 'base commit', which is a well-known commit that is part of the stable part of the project history everybody else works off of, and zero or more 'prerequisite patches', which are well-known patches in flight that is not yet part of the 'base commit' that need to be applied on top of 'base commit' in topological order before the patches can be applied.
zh_HANS-CN: 基准树信息块用于维护者或第三方测试人员了解补丁系列所适用的确切状态。它由 ‘基本提交’ 和零个或多个 ‘前提补丁’ 组成，前者是众所周知的提交，是项目历史中稳定部分的一部分，而后者是正在运行的知名补丁，还不是 ‘基本提交’ 的一部分，在应用这些补丁之前需要在 ‘基本提交’ 之上按拓扑顺序应用。

note: type: Plain text
en: The 'base commit' is shown as "base-commit: " followed by the 40-hex of the commit object name.  A 'prerequisite patch' is shown as "prerequisite-patch-id: " followed by the 40-hex 'patch id', which can be obtained by passing the patch through the `git patch-id --stable` command.
zh_HANS-CN: ‘基本提交’ 显示为 "base-commit: "，后面是提交对象名称的 40-hex。 ‘先决补丁’ 显示为 "prerequisite-patch-id: "，后面是 40-hex 的 “补丁ID”，这个 ID 可以通过 `git patch-id --stable` 命令来获得。

note: type: Plain text
en: Imagine that on top of the public commit P, you applied well-known patches X, Y and Z from somebody else, and then built your three-patch series A, B, C, the history would be like:
zh_HANS-CN: 想象一下，在公开提交的 P 之上，你应用了别人的知名补丁 X、Y 和 Z，然后建立了你的三套补丁系列 A、B、C，历史会是这样：

note: type: Plain text
en: With `git format-patch --base=P -3 C` (or variants thereof, e.g. with `--cover-letter` or using `Z..C` instead of `-3 C` to specify the range), the base tree information block is shown at the end of the first message the command outputs (either the first patch, or the cover letter), like this:
zh_HANS-CN: 使用 `git format-patch --base=P -3 C`（或其变体，例如使用 `-cover-letter` 或使用 `Z...C` 代替 `-3 C` 来指定范围），基础树信息块会显示在命令输出的第一个信息（第一个补丁，或封面信）的末尾，像这样：

note: type: Plain text
en: For non-linear topology, such as
zh_HANS-CN: 对于非线性拓扑结构，如

note: type: Plain text
en: You can also use `git format-patch --base=P -3 C` to generate patches for A, B and C, and the identifiers for P, X, Y, Z are appended at the end of the first message.
zh_HANS-CN: 你也可以使用 `git format-patch --base=P -3 C` 来生成 A、B 和 C 的补丁，P、X、Y、Z 的标识符被附加在第一条信息的末尾。

note: type: Plain text
en: If set `--base=auto` in cmdline, it will automatically compute the base commit as the merge base of tip commit of the remote-tracking branch and revision-range specified in cmdline.  For a local branch, you need to make it to track a remote branch by `git branch --set-upstream-to` before using this option.
zh_HANS-CN: 如果在 cmdline 中设置 `--base=auto`，它将自动计算基础提交，作为远程跟踪分支和 cmdline 中指定的修订范围的提示提交的合并基础。 对于本地分支，在使用此选项之前，需要通过 `git branch --set-upstream-to` 使其跟踪远程分支。

note: type: Plain text
en: Extract commits between revisions R1 and R2, and apply them on top of the current branch using 'git am' to cherry-pick them:
zh_HANS-CN: 提取 R1 和 R2 修订版之间的提交，并用 "git am" 将其应用于当前分支之上，以拣选它们：

note: type: Plain text
en: Extract all commits which are in the current branch but not in the origin branch:
zh_HANS-CN: 提取所有在当前分支但不在原生分支中的提交：

note: type: Plain text
en: For each commit a separate file is created in the current directory.
zh_HANS-CN: 每次提交都会在当前目录下创建一个单独的文件。

note: type: Plain text
en: Extract all commits that lead to 'origin' since the inception of the project:
zh_HANS-CN: 提取自项目开始以来所有导致 'origin' 的提交：

note: type: Plain text
en: The same as the previous one:
zh_HANS-CN: 与前者相同：

note: type: Plain text
en: Additionally, it detects and handles renames and complete rewrites intelligently to produce a renaming patch.  A renaming patch reduces the amount of text output, and generally makes it easier to review.  Note that non-Git "patch" programs won't understand renaming patches, so use it only when you know the recipient uses Git to apply your patch.
zh_HANS-CN: 此外，它还能智能地检测和处理重命名和完全重写，以产生重命名补丁。 重命名补丁减少了文本输出的数量，一般来说，它更容易审查。 注意，非 Git 的 “补丁” 程序不会理解重命名补丁，所以只有当你知道收件人使用 Git 来应用你的补丁时才会使用它。

note: type: Plain text
en: Extract three topmost commits from the current branch and format them as e-mailable patches:
zh_HANS-CN: 从当前分支中提取三个最重要的提交，并将其格式化为可发送电子邮件的补丁：

note: type: Plain text
en: Note that `format-patch` will omit merge commits from the output, even if they are part of the requested range. A simple "patch" does not include enough information for the receiving end to reproduce the same merge commit.
zh_HANS-CN: 请注意，`format-patch` 将从输出中省略合并提交，即使它们是请求范围的一部分。一个简单的 “补丁” 并不包括足够的信息让接收端重现同一个合并提交。

note: type: Plain text
en: git-fsck-objects - Verifies the connectivity and validity of the objects in the database
zh_HANS-CN: git-fsck-objects - 验证数据库中对象的连接性和有效性

note: type: Plain text
en: This is a synonym for linkgit:git-fsck[1].  Please refer to the documentation of that command.
zh_HANS-CN: 这是 linkgit:git-fsck[1] 的同义词。 请参考该命令的文档。

note: type: Plain text
en: An object to treat as the head of an unreachability trace.
zh_HANS-CN: 一个要作为不可及性追踪的头的对象。

note: type: Plain text
en: If no objects are given, 'git fsck' defaults to using the index file, all SHA-1 references in `refs` namespace, and all reflogs (unless --no-reflogs is given) as heads.
zh_HANS-CN: 如果没有给出对象，'git fsck' 默认使用索引文件、`refs` 命名空间中的所有 SHA-1 引用，以及所有引用日志（除非--no-reflogs被给出）作为头。

note: type: Plain text
en: Print out objects that exist but that aren't reachable from any of the reference nodes.
zh_HANS-CN: 打印出存在但不能从任何参考节点到达的对象。

note: type: Plain text
en: Print objects that exist but that are never 'directly' used (default).  `--no-dangling` can be used to omit this information from the output.
zh_HANS-CN: 打印存在但从未 'directly ' 使用的对象（默认）。 `--no-dangling` 可以用来从输出中省略这一信息。

note: type: Plain text
en: Report root nodes.
zh_HANS-CN: 报告根节点。

note: type: Plain text
en: Report tags.
zh_HANS-CN: 报告标签。

note: type: Plain text
en: Consider any object recorded in the index also as a head node for an unreachability trace.
zh_HANS-CN: 考虑将索引中记录的任何对象也作为不可达性追踪的头节点。

note: type: Plain text
en: Do not consider commits that are referenced only by an entry in a reflog to be reachable.  This option is meant only to search for commits that used to be in a ref, but now aren't, but are still in that corresponding reflog.
zh_HANS-CN: 不认为那些只被引用日志中的条目引用的提交是可以达到的。 这个选项只是为了搜索那些曾经在引用中，但现在不在了，但仍在那个相应引用日志中的提交。

note: type: Plain text
en: Check not just objects in GIT_OBJECT_DIRECTORY ($GIT_DIR/objects), but also the ones found in alternate object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES or $GIT_DIR/objects/info/alternates, and in packed Git archives found in $GIT_DIR/objects/pack and corresponding pack subdirectories in alternate object pools.  This is now default; you can turn it off with --no-full.
zh_HANS-CN: 不仅检查 GIT_OBJECT_DIRECTORY ($GIT_DIR/objects) 中的对象，还检查 GIT_ALTERNATE_OBJECT_DIRECTORIES 或 $GIT_DIR/objects/info/alternates 中列出的备用对象库中的对象，以及 $GIT_DIR/objects/pack 和备用对象库中相应 pack 子目录中的打包 Git 档案。 这现在是默认的；你可以用 --no-full 关闭它。

note: type: Plain text
en: Check only the connectivity of reachable objects, making sure that any objects referenced by a reachable tag, commit, or tree is present. This speeds up the operation by avoiding reading blobs entirely (though it does still check that referenced blobs exist). This will detect corruption in commits and trees, but not do any semantic checks (e.g., for format errors). Corruption in blob objects will not be detected at all.
zh_HANS-CN: 只检查可达对象的连接性，确保可达标签、提交或树所引用的任何对象都存在。这样可以完全避免读取 blobs，从而加快操作速度（尽管它仍然会检查被引用的 blobs 是否存在）。这将检测提交和树的损坏，但不做任何语义检查（例如，格式错误）。blob 对象中的损坏将完全不会被检测到。

note: type: Plain text
en: Unreachable tags, commits, and trees will also be accessed to find the tips of dangling segments of history. Use `--no-dangling` if you don't care about this output and want to speed it up further.
zh_HANS-CN: 无法到达的标签、提交和树也会被访问，以找到历史的悬空部分的提示。如果你不关心这个输出并想进一步加快它的速度，请使用 `--no-dangling`。

note: type: Plain text
en: Enable more strict checking, namely to catch a file mode recorded with g+w bit set, which was created by older versions of Git.  Existing repositories, including the Linux kernel, Git itself, and sparse repository have old objects that triggers this check, but it is recommended to check new projects with this flag.
zh_HANS-CN: 启用更严格的检查，即抓取记录有 g+w 位的文件模式，这是由旧版本的 Git 创建的。 现有的仓库，包括 Linux 内核、Git 本身和稀疏仓库都有旧的对象，会触发这个检查，但建议用这个标志检查新项目。

note: type: Plain text
en: Be chatty.
zh_HANS-CN: 要健谈。

note: type: Plain text
en: Write dangling objects into .git/lost-found/commit/ or .git/lost-found/other/, depending on type.  If the object is a blob, the contents are written into the file, rather than its object name.
zh_HANS-CN: 将悬空的对象写入 .git/lost-found/commit/ 或 .git/lost-found/other/，具体取决于类型。 如果对象是一个 blob，其内容将被写入文件，而不是其对象名称。

note: type: Plain text
en: When displaying names of reachable objects, in addition to the SHA-1 also display a name that describes *how* they are reachable, compatible with linkgit:git-rev-parse[1], e.g.  `HEAD@{1234567890}~25^2:src/`.
zh_HANS-CN: 当显示可达对象的名称时，除了 SHA-1外，还显示描述 *如何* 可达的名称，与 linkgit:git-rev-parse[1] 兼容，例如，`HEAD@{1234567890}~25^2:src/`。

note: type: Plain text
en: Progress status is reported on the standard error stream by default when it is attached to a terminal, unless --no-progress or --verbose is specified. --progress forces progress status even if the standard error stream is not directed to a terminal.
zh_HANS-CN: 除非指定 --no-progress 或 --verbose，否则当标准错误流连接到终端时，默认情况下会报告进度状态。--progress 即使标准错误流没有指向终端，也会强制显示进度状态。

note: type: Plain text
en: git-fsck tests SHA-1 and general object sanity, and it does full tracking of the resulting reachability and everything else. It prints out any corruption it finds (missing or bad objects), and if you use the `--unreachable` flag it will also print out objects that exist but that aren't reachable from any of the specified head nodes (or the default set, as mentioned above).
zh_HANS-CN: git-fsck 测试 SHA-1和一般对象的正确性，并对结果的可及性和其他一切进行全面跟踪。它打印出它发现的任何损坏（缺失或坏的对象），如果你使用 `--unreachable` 标志，它也会打印出存在但从任何指定的头部节点（或默认集，如上所述）无法到达的对象。

note: type: Plain text
en: Any corrupt objects you will have to find in backups or other archives (i.e., you can just remove them and do an 'rsync' with some other site in the hopes that somebody else has the object you have corrupted).
zh_HANS-CN: 任何损坏的对象，你将不得不在备份或其他档案中找到（也就是说，你可以直接删除它们，并与其他网站做一个 'rsync'，希望别人拥有你损坏的对象）。

note: type: Plain text
en: If core.commitGraph is true, the commit-graph file will also be inspected using 'git commit-graph verify'. See linkgit:git-commit-graph[1].
zh_HANS-CN: 如果 core.commitGraph 为真，提交的图形文件也将用 'git commit-graph verify' 来检查。见 linkgit:git-commit-graph[1]。

note: type: Title -
en: Extracted Diagnostics
zh_HANS-CN: 提取的诊断方法

note: type: Labeled list
en: unreachable <type> <object>
zh_HANS-CN: 无法到达 <类型> <对象> 的问题

note: type: Labeled list
en: missing <type> <object>
zh_HANS-CN: 缺少 <类型> <对象>

note: type: Plain text
en: The <type> object <object>, is referred to but isn't present in the database.
zh_HANS-CN: <类型> 对象 <object>，被提及但不存在于数据库中。

note: type: Labeled list
en: dangling <type> <object>
zh_HANS-CN: 悬空的 <类型> <对象>

note: type: Plain text
en: The <type> object <object>, is present in the database but never 'directly' used. A dangling commit could be a root node.
zh_HANS-CN: <类型> 对象 <object>，存在于数据库中，但从未 'directly' 使用。一个悬空的提交可能是一个根节点。

note: type: Labeled list
en: hash mismatch <object>
zh_HANS-CN: 哈希值不匹配 <对象>

note: type: Plain text
en: The database has an object whose hash doesn't match the object database value.  This indicates a serious data integrity problem.
zh_HANS-CN: 数据库中有一个对象的哈希值与对象数据库的值不一致。 这表明一个严重的数据完整性问题。

note: type: Title -
en: FSCK MESSAGES
zh_HANS-CN: FSCK 信息

note: type: Plain text
en: The following lists the types of errors `git fsck` detects and what each error means, with their default severity.  The severity of the error, other than those that are marked as "(FATAL)", can be tweaked by setting the corresponding `fsck.<msg-id>` configuration variable.
zh_HANS-CN: 下面列出了 `git fsck` 检测的错误类型和每个错误的含义，以及它们的默认严重程度。 除了那些被标记为 "(FATAL)" 的错误，其他错误的严重程度可以通过设置相应的 `fsck.<msg-id>` 配置变量来调整。

note: type: Plain text
en: used to specify the object database root (usually $GIT_DIR/objects)
zh_HANS-CN: 用来指定对象数据库的根（通常是 $GIT_DIR/objects）

note: type: Plain text
en: used to specify the index file of the index
zh_HANS-CN: 用来指定索引的索引文件

note: type: Plain text
en: used to specify additional object database roots (usually unset)
zh_HANS-CN: 用来指定额外的对象数据库根（通常不设置）

note: type: Plain text
en: Runs a number of housekeeping tasks within the current repository, such as compressing file revisions (to reduce disk space and increase performance), removing unreachable objects which may have been created from prior invocations of 'git add', packing refs, pruning reflog, rerere metadata or stale working trees. May also update ancillary indexes such as the commit-graph.
zh_HANS-CN: 在当前版本库中执行一些内务管理任务，比如压缩文件修订（以减少磁盘空间并提高性能），移除之前调用 'git add' 所创建的不可达对象，打包引用，修剪引用日志、rerere metadata 或过时的工作区。也可以更新辅助索引，如提交图。

note: type: Plain text
en: When common porcelain operations that create objects are run, they will check whether the repository has grown substantially since the last maintenance, and if so run `git gc` automatically. See `gc.auto` below for how to disable this behavior.
zh_HANS-CN: 当运行创建对象的普通上层命令操作时，它们会检查仓库在上次维护后是否有大幅增长，如果有，就自动运行 `git gc`。参见下面的 `gc.auto` 以了解如何禁用这一行为。

note: type: Plain text
en: Running `git gc` manually should only be needed when adding objects to a repository without regularly running such porcelain commands, to do a one-off repository optimization, or e.g. to clean up a suboptimal mass-import. See the "PACKFILE OPTIMIZATION" section in linkgit:git-fast-import[1] for more details on the import case.
zh_HANS-CN: 手动运行 `git gc` 应该只在向仓库添加对象而不定期运行这种上层命令时才需要，以进行一次性的仓库优化，或者例如清理次优的大规模导入。关于导入情况的更多细节，请参见 linkgit:git-fast-import[1] 中的 “包装文件优化” 部分。

note: type: Plain text
en: Usually 'git gc' runs very quickly while providing good disk space utilization and performance.  This option will cause 'git gc' to more aggressively optimize the repository at the expense of taking much more time.  The effects of this optimization are mostly persistent. See the "AGGRESSIVE" section below for details.
zh_HANS-CN: 通常，'git gc' 运行得非常快，同时提供良好的磁盘空间利用率和性能。 这个选项会使 'git gc' 更积极地优化仓库，代价是花费更多的时间。 这种优化的效果大多是持续性的。详情见下面的 "AGGRESSIVE" 部分。

note: type: Plain text
en: With this option, 'git gc' checks whether any housekeeping is required; if not, it exits without performing any work.
zh_HANS-CN: 有了这个选项，'git gc' 就会检查是否需要任何内务处理；如果不需要，它就会退出，不执行任何工作。

note: type: Plain text
en: See the `gc.auto` option in the "CONFIGURATION" section below for how this heuristic works.
zh_HANS-CN: 关于这个启发式的工作原理，请看下面 “配置” 部分的 `gc.auto` 选项。

note: type: Plain text
en: Once housekeeping is triggered by exceeding the limits of configuration options such as `gc.auto` and `gc.autoPackLimit`, all other housekeeping tasks (e.g. rerere, working trees, reflog...) will be performed as well.
zh_HANS-CN: 一旦超过配置选项如 `gc.auto` 和 `gc.autoPackLimit` 的限制而触发内务管理，所有其他内务管理任务（如 reere、working trees、reflog...）也将被执行。

note: type: Plain text
en: When expiring unreachable objects, pack them separately into a cruft pack instead of storing them as loose objects. `--cruft` is on by default.
zh_HANS-CN: 当无法到达的对象过期时，将它们单独打包到一个 cruft 包中，而不是将它们作为散装对象存储。`--cruft` 是默认开启的。

note: type: Labeled list
en: --prune=<date>
zh_HANS-CN: --prune=<日期>

note: type: Plain text
en: Prune loose objects older than date (default is 2 weeks ago, overridable by the config variable `gc.pruneExpire`).  --prune=now prunes loose objects regardless of their age and increases the risk of corruption if another process is writing to the repository concurrently; see "NOTES" below. --prune is on by default.
zh_HANS-CN: 修剪超过日期的松散对象（默认是 2 周前，可由配置变量 `gc.pruneExpire` 覆盖）。 --prune=now 删减松散对象，无论其年龄大小，如果有其他进程同时向仓库写入，则会增加损坏的风险；见下面的 “注意事项”。--prune 默认是打开的。

note: type: Plain text
en: Do not prune any loose objects.
zh_HANS-CN: 不要修剪任何松散的对象。

note: type: Plain text
en: Suppress all progress reports.
zh_HANS-CN: 抑制所有进度报告。

note: type: Plain text
en: Force `git gc` to run even if there may be another `git gc` instance running on this repository.
zh_HANS-CN: 强制 `git gc` 运行，即使这个仓库可能有另一个 `git gc` 实例在运行。

note: type: Plain text
en: All packs except the largest non-cruft pack, any packs marked with a `.keep` file, and any cruft pack(s) are consolidated into a single pack. When this option is used, `gc.bigPackThreshold` is ignored.
zh_HANS-CN: 除了最大的非破坏性包，任何标有 `.keep` 文件的包，以及任何破坏性的包，都会被合并为一个包。当使用这个选项时，`gc.bigPackThreshold` 被忽略。

note: type: Plain text
en: When the `--aggressive` option is supplied, linkgit:git-repack[1] will be invoked with the `-f` flag, which in turn will pass `--no-reuse-delta` to linkgit:git-pack-objects[1]. This will throw away any existing deltas and re-compute them, at the expense of spending much more time on the repacking.
zh_HANS-CN: 当提供 `--aggressive` 选项时，linkgit:git-repack[1] 将被调用，并带有 `-f` 标志，这又将把 `--no-reuse-delta` 传递给 linkgit:git-pack-objects[1]。这将丢弃任何现有的 delta 并重新计算，代价是在重新打包上花费更多的时间。

note: type: Plain text
en: The effects of this are mostly persistent, e.g. when packs and loose objects are coalesced into one another pack the existing deltas in that pack might get re-used, but there are also various cases where we might pick a sub-optimal delta from a newer pack instead.
zh_HANS-CN: 这方面的影响主要是持久性的，例如，当包和松散对象被凝聚成另一个包时，该包中现有的 delta 可能会被重新使用，但也有各种情况，我们可能会从一个较新的包中挑选一个次优 delta。

note: type: Plain text
en: Furthermore, supplying `--aggressive` will tweak the `--depth` and `--window` options passed to linkgit:git-repack[1]. See the `gc.aggressiveDepth` and `gc.aggressiveWindow` settings below. By using a larger window size we're more likely to find more optimal deltas.
zh_HANS-CN: 此外，提供 `--aggressive` 将调整传递给 linkgit:git-repack[1] 的 `--depth` 和 `--window` 选项。见下面的 `gc.aggressiveDepth` 和 `gc.aggressiveWindow` 设置。通过使用较大的窗口尺寸，我们更有可能找到更多的最佳 deltas。

note: type: Plain text
en: It's probably not worth it to use this option on a given repository without running tailored performance benchmarks on it. It takes a lot more time, and the resulting space/delta optimization may or may not be worth it. Not using this at all is the right trade-off for most users and their repositories.
zh_HANS-CN: 在没有运行定制的性能基准的情况下，在一个给定的仓库上使用这个选项可能是不值得的。它需要更多的时间，而由此产生的空间/延迟优化可能值得也可能不值得。对于大多数用户和他们的仓库来说，完全不使用这个选项是正确的权衡。

note: type: Plain text
en: 'git gc' tries very hard not to delete objects that are referenced anywhere in your repository. In particular, it will keep not only objects referenced by your current set of branches and tags, but also objects referenced by the index, remote-tracking branches, reflogs (which may reference commits in branches that were later amended or rewound), and anything else in the refs/* namespace. Note that a note (of the kind created by 'git notes') attached to an object does not contribute in keeping the object alive. If you are expecting some objects to be deleted and they aren't, check all of those locations and decide whether it makes sense in your case to remove those references.
zh_HANS-CN: 'git gc' 非常努力地不删除在你的仓库中任何地方被引用的对象。特别是，它不仅会保留当前分支和标记集所引用的对象，还会保留索引、远程跟踪分支、 引用日志（可能引用了后来被修改或回绕的分支中的提交）以及 refs/* 名称空间中的任何其他对象。请注意，附在一个对象上的注释（由 'git notes' 创建的那种）并不有助于保持该对象的活力。如果你期待一些对象被删除，而它们没有被删除，请检查所有这些位置，并决定在你的情况下，删除这些引用是否有意义。

note: type: Plain text
en: On the other hand, when 'git gc' runs concurrently with another process, there is a risk of it deleting an object that the other process is using but hasn't created a reference to. This may just cause the other process to fail or may corrupt the repository if the other process later adds a reference to the deleted object. Git has two features that significantly mitigate this problem:
zh_HANS-CN: 另一方面，当 'git gc' 与另一个进程同时运行时，它有可能删除另一个进程正在使用但还没有创建引用的对象。这可能会导致其他进程失败，或者如果其他进程后来添加了对被删除对象的引用，则可能会破坏仓库。Git 有两个功能可以大大缓解这个问题：

note: type: Plain text
en: Any object with modification time newer than the `--prune` date is kept, along with everything reachable from it.
zh_HANS-CN: 任何修改时间早于 `--prune` 日期的对象都会被保留，同时也会保留所有可以到达的对象。

note: type: Plain text
en: Most operations that add an object to the database update the modification time of the object if it is already present so that #1 applies.
zh_HANS-CN: 大多数向数据库添加对象的操作都会更新对象的修改时间，如果它已经存在，那么 #1 就适用。

note: type: Plain text
en: However, these features fall short of a complete solution, so users who run commands concurrently have to live with some risk of corruption (which seems to be low in practice).
zh_HANS-CN: 然而，这些功能并不是一个完整的解决方案，所以同时运行命令的用户不得不忍受一些损坏的风险（在实践中似乎很低）。

note: type: Plain text
en: Read a tar archive created by 'git archive' from the standard input and extract the commit ID stored in it.  It reads only the first 1024 bytes of input, thus its runtime is not influenced by the size of the tar archive very much.
zh_HANS-CN: 从标准输入中读取 'git archive' 创建的 tar 档案，并提取其中的提交 ID。 它只读取输入的前 1024 字节，因此它的运行时间不会受到 tar 压缩包大小的影响。

note: type: Plain text
en: If no commit ID is found, 'git get-tar-commit-id' quietly exists with a return code of 1.  This can happen if the archive had not been created using 'git archive' or if the first parameter of 'git archive' had been a tree ID instead of a commit ID or tag.
zh_HANS-CN: 如果没有找到提交 ID，'git get-tar-commit-id' 就会悄悄存在，返回代码为 1。如果档案没有用 'git archive' 创建，或者 'git archive' 的第一个参数是树的 ID 而不是提交 ID 或标签，就会发生这种情况。

note: type: Plain text
en: Look for specified patterns in the tracked files in the work tree, blobs registered in the index file, or blobs in given tree objects.  Patterns are lists of one or more search expressions separated by newline characters.  An empty string as search expression matches all lines.
zh_HANS-CN: 在工作区中的跟踪文件、在索引文件中注册的 blobs 或给定树对象中的 blobs 中寻找指定的模式。 模式是由一个或多个搜索表达式组成的列表，用换行符分隔。 一个空的字符串作为搜索表达式可以匹配所有的行。

note: type: Plain text
en: Instead of searching tracked files in the working tree, search blobs registered in the index file.
zh_HANS-CN: 与其搜索工作区中的跟踪文件，不如搜索索引文件中注册的 blobs。

note: type: Plain text
en: Search files in the current directory that is not managed by Git.
zh_HANS-CN: 搜索当前目录中不被 Git 管理的文件。

note: type: Plain text
en: In addition to searching in the tracked files in the working tree, search also in untracked files.
zh_HANS-CN: 除了在工作区中的跟踪文件中搜索外，还可以在未跟踪的文件中搜索。

note: type: Plain text
en: Also search in ignored files by not honoring the `.gitignore` mechanism. Only useful with `--untracked`.
zh_HANS-CN: 也可以通过不遵守 `.gitignore` 机制在被忽略的文件中搜索。只对 `--untracked` 有用。

note: type: Plain text
en: Do not pay attention to ignored files specified via the `.gitignore` mechanism.  Only useful when searching files in the current directory with `--no-index`.
zh_HANS-CN: 不注意通过 `.gitignore` 机制指定的被忽略的文件。 只有在用 `--no-index` 搜索当前目录下的文件时才有用。

note: type: Plain text
en: Recursively search in each submodule that is active and checked out in the repository.  When used in combination with the <tree> option the prefix of all submodule output will be the name of the parent project's <tree> object. This option has no effect if `--no-index` is given.
zh_HANS-CN: 递归搜索在仓库中激活和检出的每个子模块。 当与 <tree> 选项结合使用时，所有子模块输出的前缀将是父项目的 <tree> 对象的名称。如果给了 `--no-index`，这个选项就没有效果。

note: type: Plain text
en: Process binary files as if they were text.
zh_HANS-CN: 像处理文本一样处理二进制文件。

note: type: Plain text
en: Honor textconv filter settings.
zh_HANS-CN: 认可 textconv 过滤器设置。

note: type: Plain text
en: Do not honor textconv filter settings.  This is the default.
zh_HANS-CN: 不用认可 textconv 过滤器的设置。 这是默认的。

note: type: Plain text
en: Ignore case differences between the patterns and the files.
zh_HANS-CN: 忽略图案和文件之间的大小写差异。

note: type: Plain text
en: Don't match the pattern in binary files.
zh_HANS-CN: 不匹配二进制文件中的模式。

note: type: Plain text
en: For each <pathspec> given on command line, descend at most <depth> levels of directories. A value of -1 means no limit.  This option is ignored if <pathspec> contains active wildcards.  In other words if "a*" matches a directory named "a*", "*" is matched literally so --max-depth is still effective.
zh_HANS-CN: 对于命令行上给出的每个 <路径规范>，最多下降 <深度> 级目录。值为-1意味着没有限制。 如果 <路径规范> 包含有效的通配符，这个选项会被忽略。 换句话说，如果 "a*" 匹配名为 "a* "的目录，"*" 就会被匹配，所以 --max-depth 仍然有效。

note: type: Plain text
en: Same as `--max-depth=-1`; this is the default.
zh_HANS-CN: 与 `--max-depth=-1` 相同；这是默认值。

note: type: Plain text
en: Same as `--max-depth=0`.
zh_HANS-CN: 与 `--max-depth=0` 相同。

note: type: Plain text
en: Match the pattern only at word boundary (either begin at the beginning of a line, or preceded by a non-word character; end at the end of a line or followed by a non-word character).
zh_HANS-CN: 只在词的边界处匹配模式（要么从一行的开头开始，要么前面是一个非词的字符；要么在一行的结尾结束，要么后面是一个非词的字符）。

note: type: Plain text
en: Select non-matching lines.
zh_HANS-CN: 选择非匹配的行。

note: type: Plain text
en: By default, the command shows the filename for each match.  `-h` option is used to suppress this output.  `-H` is there for completeness and does not do anything except it overrides `-h` given earlier on the command line.
zh_HANS-CN: 默认情况下，该命令显示每个匹配的文件名。 `-h` 选项用于抑制这种输出。 `-H` 是为了完整性而存在的，除了覆盖先前在命令行中给出的 `-h` 外，它不做任何事情。

note: type: Plain text
en: When run from a subdirectory, the command usually outputs paths relative to the current directory.  This option forces paths to be output relative to the project top directory.
zh_HANS-CN: 当从一个子目录运行时，该命令通常会输出相对于当前目录的路径。 这个选项强制输出相对于项目顶层目录的路径。

note: type: Plain text
en: Use POSIX extended/basic regexp for patterns.  Default is to use basic regexp.
zh_HANS-CN: 对模式使用 POSIX 扩展/基本的正则表达式。 默认是使用基本的正则表达式。

note: type: Plain text
en: Use Perl-compatible regular expressions for patterns.
zh_HANS-CN: 使用与 Perl 兼容的正则表达式的模式。

note: type: Plain text
en: Support for these types of regular expressions is an optional compile-time dependency. If Git wasn't compiled with support for them providing this option will cause it to die.
zh_HANS-CN: 对这些类型的正则表达式的支持是一个可选的编译时依赖。如果Git在编译时没有对它们的支持，提供这个选项将导致它死亡。

note: type: Plain text
en: Use fixed strings for patterns (don't interpret pattern as a regex).
zh_HANS-CN: 使用固定的字符串来表示模式（不要把模式解释为一个重合词）。

note: type: Plain text
en: Prefix the line number to matching lines.
zh_HANS-CN: 在匹配的行前加上行号。

note: type: Plain text
en: Prefix the 1-indexed byte-offset of the first match from the start of the matching line.
zh_HANS-CN: 前缀为从匹配行开始的第一个匹配的索引的字节偏移量。

note: type: Plain text
en: Instead of showing every matched line, show only the names of files that contain (or do not contain) matches.  For better compatibility with 'git diff', `--name-only` is a synonym for `--files-with-matches`.
zh_HANS-CN: 不显示每个匹配行，只显示包含（或不包含）匹配的文件名。 为了与 'git diff' 更好地兼容，`--name-only` 是 `--files-with-matches` 的同义词。

note: type: Labeled list
en: --open-files-in-pager[=<pager>]
zh_HANS-CN: --在分页中打开文件[=<分页器>]

note: type: Plain text
en: Open the matching files in the pager (not the output of 'grep').  If the pager happens to be "less" or "vi", and the user specified only one pattern, the first file is positioned at the first match automatically. The `pager` argument is optional; if specified, it must be stuck to the option without a space. If `pager` is unspecified, the default pager will be used (see `core.pager` in linkgit:git-config[1]).
zh_HANS-CN: 在分页器中打开匹配的文件（不是 'grep' 的输出）。 如果分页器恰好是 "less" 或 "vi"，而用户只指定了一个模式，那么第一个文件就会自动定位在第一个匹配处。`pager` 参数是可选的；如果指定，它必须与选项卡在一起，没有空格。如果没有指定 `pager`，将使用默认的分页器（见 linkgit:git-config[1] 中的 `core.pager`）。

note: type: Plain text
en: Use \0 as the delimiter for pathnames in the output, and print them verbatim. Without this option, pathnames with "unusual" characters are quoted as explained for the configuration variable core.quotePath (see linkgit:git-config[1]).
zh_HANS-CN: 使用\0作为输出中路径名的分隔符，并逐字打印它们。按照配置变量core.quotePath的说明，引用带有“ unusual”字符的路径名 (查阅linkgit:git-config[1])。

note: type: Plain text
en: Print only the matched (non-empty) parts of a matching line, with each such part on a separate output line.
zh_HANS-CN: 只打印匹配行中的匹配（非空）部分，每一个这样的部分都在单独的输出行中。

note: type: Plain text
en: Instead of showing every matched line, show the number of lines that match.
zh_HANS-CN: 与其显示每一个匹配的行，不如显示匹配的行数。

note: type: Plain text
en: Show colored matches.  The value must be always (the default), never, or auto.
zh_HANS-CN: 显示有颜色的匹配。 该值必须是总是（默认值）、从不、或自动。

note: type: Plain text
en: Turn off match highlighting, even when the configuration file gives the default to color output.  Same as `--color=never`.
zh_HANS-CN: 关闭匹配高亮，即使在配置文件中默认为彩色输出。 与 `--color=never` 相同。

note: type: Plain text
en: Print an empty line between matches from different files.
zh_HANS-CN: 在不同文件的匹配之间打印一个空行。

note: type: Plain text
en: Show the filename above the matches in that file instead of at the start of each shown line.
zh_HANS-CN: 在该文件中的匹配项上方显示文件名，而不是在每个显示行的开头。

note: type: Plain text
en: Show the preceding line that contains the function name of the match, unless the matching line is a function name itself.  The name is determined in the same way as `git diff` works out patch hunk headers (see 'Defining a custom hunk-header' in linkgit:gitattributes[5]).
zh_HANS-CN: 显示包含匹配的函数名的前一行，除非匹配的一行本身就是一个函数名。 该名称的确定方式与 `git diff` 编制补丁组头的方式相同（见 linkgit:gitattributes[5] 中的 ‘定义自定义组头’）。

note: type: Plain text
en: Show <num> leading and trailing lines, and place a line containing `--` between contiguous groups of matches.
zh_HANS-CN: 显示 <num> 前导行和后导行，并在连续的匹配组之间放置一个包含`--`的行。

note: type: Plain text
en: Show <num> trailing lines, and place a line containing `--` between contiguous groups of matches.
zh_HANS-CN: 显示 <num> 尾行，并在连续的匹配组之间放置一个包含 `--` 的行。

note: type: Plain text
en: Show <num> leading lines, and place a line containing `--` between contiguous groups of matches.
zh_HANS-CN: 显示 <num> 引导行，并在连续的匹配组之间放置一个包含 `--` 的行。

note: type: Plain text
en: Show the surrounding text from the previous line containing a function name up to the one before the next function name, effectively showing the whole function in which the match was found. The function names are determined in the same way as `git diff` works out patch hunk headers (see 'Defining a custom hunk-header' in linkgit:gitattributes[5]).
zh_HANS-CN: 显示从包含函数名的前一行到下一个函数名之前的周围文本，有效地显示找到匹配的整个函数。函数名的确定方式与 `git diff` 确定补丁组头的方式相同（见 linkgit:gitattributes[5] 中的 ‘定义自定义组头’）。

note: type: Plain text
en: Limit the amount of matches per file. When using the `-v` or `--invert-match` option, the search stops after the specified number of non-matches. A value of -1 will return unlimited results (the default). A value of 0 will exit immediately with a non-zero status.
zh_HANS-CN: 限制每个文件的匹配数量。当使用 `-v` 或 `--invert-match` 选项时，搜索会在指定的非匹配数量后停止。值为 -1 将返回无限的结果（默认）。值为 0 将立即退出，状态为非零。

note: type: Plain text
en: Number of grep worker threads to use.  See `grep.threads` in 'CONFIGURATION' for more information.
zh_HANS-CN: 要使用的 grep 工作线程的数量。 更多信息见 “配置” 中的 `grep.threads`。

note: type: Plain text
en: Read patterns from <file>, one per line.
zh_HANS-CN: 从 <文件> 中读取模式，每行一个。

note: type: Plain text
en: Passing the pattern via <file> allows for providing a search pattern containing a \0.
zh_HANS-CN: 通过<文件> 传递模式，可以提供一个包含一个 \0 的搜索模式。

note: type: Plain text
en: Not all pattern types support patterns containing \0. Git will error out if a given pattern type can't support such a pattern. The `--perl-regexp` pattern type when compiled against the PCRE v2 backend has the widest support for these types of patterns.
zh_HANS-CN: 不是所有的模式类型都支持包含 \0 的模式。如果一个给定的模式类型不支持这样的模式，Git 会出错。`--perl-regexp` 模式类型在针对 PCRE v2 后端进行编译时，对这些类型的模式有最广泛的支持。

note: type: Plain text
en: In versions of Git before 2.23.0 patterns containing \0 would be silently considered fixed. This was never documented, there were also odd and undocumented interactions between e.g. non-ASCII patterns containing \0 and `--ignore-case`.
zh_HANS-CN: 在 2.23.0 之前的 Git 版本中，含有 \0 的模式会被默默地认为是固定的。这一点从未被记录下来，还有一些奇怪的、未被记录的互动，例如包含 \0 的非 ASCII 模式和 `--ignore-case` 之间。

note: type: Plain text
en: In future versions we may learn to support patterns containing \0 for more search backends, until then we'll die when the pattern type in question doesn't support them.
zh_HANS-CN: 在未来的版本中，我们可能会学会为更多的搜索后端支持含有 \0 的模式，在此之前，当有关的模式类型不支持它们时，我们就会死心。

note: type: Plain text
en: The next parameter is the pattern. This option has to be used for patterns starting with `-` and should be used in scripts passing user input to grep.  Multiple patterns are combined by 'or'.
zh_HANS-CN: 下一个参数是模式。这个选项必须用于以 `-` 开头的模式，并应在将用户输入传递给 grep 的脚本中使用。 多个模式用 'or' 组合。

note: type: Plain text
en: Specify how multiple patterns are combined using Boolean expressions.  `--or` is the default operator.  `--and` has higher precedence than `--or`.  `-e` has to be used for all patterns.
zh_HANS-CN: 使用布尔表达式指定多个模式的组合方式。 `--or` 是默认的运算符。 `--and` 比 `--or` 有更高的优先权。 `-e` 必须用于所有模式。

note: type: Plain text
en: When giving multiple pattern expressions combined with `--or`, this flag is specified to limit the match to files that have lines to match all of them.
zh_HANS-CN: 当给出多个模式表达式与 `--or` 组合时，指定这个标志是为了将匹配限制在有行的文件中，以匹配所有的文件。

note: type: Plain text
en: Do not output matched lines; instead, exit with status 0 when there is a match and with non-zero status when there isn't.
zh_HANS-CN: 不输出匹配的行；相反，当有匹配时以状态 0 退出，没有匹配时以非零状态退出。

note: type: Plain text
en: Instead of searching tracked files in the working tree, search blobs in the given trees.
zh_HANS-CN: 与其在工作区中搜索被追踪的文件，不如在给定的目录树中搜索 blobs。

note: type: Plain text
en: Signals the end of options; the rest of the parameters are <pathspec> limiters.
zh_HANS-CN: 标志着选项的结束；其余的参数是 <路径规范> 限制器。

note: type: Plain text
en: If given, limit the search to paths matching at least one pattern.  Both leading paths match and glob(7) patterns are supported.
zh_HANS-CN: 如果给定，将搜索限制在与至少一个模式匹配的路径上。 前导路径匹配和 glob(7) 模式都被支持。

note: type: Plain text
en: Looks for `time_t` in all tracked .c and .h files in the working directory and its subdirectories.
zh_HANS-CN: 在工作目录及其子目录中所有跟踪的 .c 和 .h 文件中寻找 `time_t`。

note: type: Plain text
en: Looks for a line that has `#define` and either `MAX_PATH` or `PATH_MAX`.
zh_HANS-CN: 寻找有 `#define` 和 `MAX_PATH` 或 `PATH_MAX` 的行。

note: type: Plain text
en: Looks for a line that has `NODE` or `Unexpected` in files that have lines that match both.
zh_HANS-CN: 在文件中寻找有 `NODE` 或 `Unexpected` 字样的行，这些行与这两个字相匹配。

note: type: Plain text
en: Looks for `solution`, excluding files in `Documentation`.
zh_HANS-CN: 寻找 `solution`，排除 `Documentation`中的文件。

note: type: Title -
en: NOTES ON THREADS
zh_HANS-CN: 线条的注释

note: type: Plain text
en: The `--threads` option (and the grep.threads configuration) will be ignored when `--open-files-in-pager` is used, forcing a single-threaded execution.
zh_HANS-CN: 当使用 `--open-files-in-pager` 时，`--threads` 选项（和 grep.threads 配置）将被忽略，强制单线程执行。

note: type: Plain text
en: When grepping the object store (with `--cached` or giving tree objects), running with multiple threads might perform slower than single threaded if `--textconv` is given and there're too many text conversions. So if you experience low performance in this case, it might be desirable to use `--threads=1`.
zh_HANS-CN: 当检索对象存储时（使用 `--cached` 或给出树状对象），如果给出 `--textconv` 并且有太多的文本转换，多线程运行可能比单线程运行要慢。因此，如果你在这种情况下遇到低性能，使用 `--threads=1` 可能是可取的。

note: type: Plain text
en: git-gui - A portable graphical interface to Git
zh_HANS-CN: git-gui - 一个可移植的git图形界面

note: type: Plain text
en: A Tcl/Tk based graphical user interface to Git.  'git gui' focuses on allowing users to make changes to their repository by making new commits, amending existing ones, creating branches, performing local merges, and fetching/pushing to remote repositories.
zh_HANS-CN: 一个基于 Tcl/Tk 的 Git 图形化用户界面。 'git gui' 的重点是允许用户对他们的仓库进行修改，包括做出新的提交，修改现有的提交，创建分支，执行本地合并，以及获取/推送到远程仓库。

note: type: Plain text
en: Unlike 'gitk', 'git gui' focuses on commit generation and single file annotation and does not show project history.  It does however supply menu actions to start a 'gitk' session from within 'git gui'.
zh_HANS-CN: 与 'gitk' 不同，'git gui' 专注于提交生成和单一文件注释，不显示项目历史。 不过它提供了菜单操作，可以从 'git gui' 中启动 'gitk' 会话。

note: type: Plain text
en: 'git gui' is known to work on all popular UNIX systems, Mac OS X, and Windows (under both Cygwin and MSYS).  To the extent possible OS specific user interface guidelines are followed, making 'git gui' a fairly native interface for users.
zh_HANS-CN: 众所周知，'git gui' 可以在所有流行的UNIX系统、Mac OS X 和 Windows（在 Cygwin 和 MSYS 下）运行。 在可能的范围内，遵循操作系统特定的用户界面准则，使 'git gui' 成为用户的一个相当原始的界面。

note: type: Title -
en: COMMANDS
zh_HANS-CN: 命令

note: type: Plain text
en: Start a blame viewer on the specified file on the given version (or working directory if not specified).
zh_HANS-CN: 在指定的版本（如果没有指定，则为工作目录）上对指定的文件启动一个历史追溯查看器。

note: type: Plain text
en: Start a tree browser showing all files in the specified commit.  Files selected through the browser are opened in the blame viewer.
zh_HANS-CN: 启动一个树状浏览器，显示指定提交中的所有文件。 通过浏览器选择的文件会在历史追溯查看器中打开。

note: type: Plain text
en: Start 'git gui' and arrange to make exactly one commit before exiting and returning to the shell.  The interface is limited to only commit actions, slightly reducing the application's startup time and simplifying the menubar.
zh_HANS-CN: 启动 'git gui' 并安排在退出并返回 shell 之前正好做一次提交。 该界面只限于提交操作，稍微减少了应用程序的启动时间，并简化了菜单栏。

note: type: Plain text
en: Display the currently running version of 'git gui'.
zh_HANS-CN: 显示当前运行的 'git gui' 的版本。

note: type: Plain text
en: Show the contents of the file 'Makefile' in the current working directory, and provide annotations for both the original author of each line, and who moved the line to its current location.  The uncommitted file is annotated, and uncommitted changes (if any) are explicitly attributed to 'Not Yet Committed'.
zh_HANS-CN: 显示当前工作目录中 'Makefile' 文件的内容，并为每一行的原作者和谁把这一行移到当前位置提供注释。 未提交的文件有注释，未提交的修改（如果有的话）被明确地归结为 ‘尚未提交’。

note: type: Plain text
en: Show the contents of 'Makefile' in revision 'v0.99.8' and provide annotations for each line.  Unlike the above example the file is read from the object database and not the working directory.
zh_HANS-CN: 显示修订版 'v0.99.8' 中 'Makefile' 的内容，并为每一行提供注释。 与上面的例子不同，该文件是从对象数据库而不是工作目录中读取的。

note: type: Plain text
en: Loads annotations as described above and automatically scrolls the view to center on line '100'.
zh_HANS-CN: 如上所述加载注释，并自动滚动视图至第 '100' 行中心。

note: type: Plain text
en: Make one commit and return to the shell when it is complete.  This command returns a non-zero exit code if the window was closed in any way other than by making a commit.
zh_HANS-CN: 进行一次提交，完成后返回到 shell。 如果窗口被关闭，而不是通过提交的方式，该命令会返回一个非零的退出代码。

note: type: Plain text
en: Automatically enter the 'Amend Last Commit' mode of the interface.
zh_HANS-CN: 自动进入界面的 ‘修正最后提交’ 模式。

note: type: Plain text
en: Behave as normal citool, but instead of making a commit simply terminate with a zero exit code. It still checks that the index does not contain any unmerged entries, so you can use it as a GUI version of linkgit:git-mergetool[1]
zh_HANS-CN: 和普通的 citool 一样，但不做提交，而是以零退出代码结束。它仍然会检查索引是否包含任何未合并的条目，所以你可以把它当作 linkgit:git-mergetool[1] 的 GUI 版本

note: type: Plain text
en: Same as `git gui citool` (above).
zh_HANS-CN: 与 `git gui citool`（上文）相同。

note: type: Plain text
en: Show a browser for the tree of the 'maint' branch.  Files selected in the browser can be viewed with the internal blame viewer.
zh_HANS-CN: 显示 'maint' 分支的树的浏览器。 在浏览器中选择的文件可以用内部责备查看器查看。

note: type: Plain text
en: The Git repository browser.  Shows branches, commit history and file differences.  gitk is the utility started by 'git gui''s Repository Visualize actions.
zh_HANS-CN: Git 仓库浏览器。 gitk 是由 'git gui' 的 Repository Visualize 操作启动的实用程序，显示分支、提交历史和文件差异。

note: type: Plain text
en: The official repository of the 'git gui' project can be found at:
zh_HANS-CN: 'git gui' 项目的官方仓库可以在以下网址找到：

note: type: Plain text
en: git-help - Display help information about Git
zh_HANS-CN: git-help - 显示有关git的帮助信息

note: type: Plain text
en: 'git help' [-a|--all] [--[no-]verbose] [--[no-]external-commands] [--[no-]aliases]
    'git help' [[-i|--info] [-m|--man] [-w|--web]] [<command>|<doc>]
    'git help' [-g|--guides]
    'git help' [-c|--config]
    'git help' [--user-interfaces]
    'git help' [--developer-interfaces]
zh_HANS-CN: 'git help' [-a|--all] [--[no-]verbose] [--[no-]external-commands] [--[no-]aliases]
    'git help' [[-i|--info] [-m|--man] [-w|--web]] [<命令>|<文档>]
    'git help' [-g|--guides]
    'git help' [-c|--config]
    'git help' [--user-interfaces]
    'git help' [--developer-interfaces]

note: type: Plain text
en: With no options and no '<command>' or '<doc>' given, the synopsis of the 'git' command and a list of the most commonly used Git commands are printed on the standard output.
zh_HANS-CN: 如果没有选项，也没有给出 '<命令>' 或 '<文档>'，'git' 命令的概要和最常用的 Git 命令的列表会被打印在标准输出上。

note: type: Plain text
en: If the option `--all` or `-a` is given, all available commands are printed on the standard output.
zh_HANS-CN: 如果给出选项 `--all` 或 `--a`，所有可用的命令都会打印在标准输出上。

note: type: Plain text
en: If the option `--guides` or `-g` is given, a list of the Git concept guides is also printed on the standard output.
zh_HANS-CN: 如果给了 `--guide` 或 `--g` 选项，Git 概念指南的列表也会打印在标准输出上。

note: type: Plain text
en: If a command or other documentation is given, the relevant manual page will be brought up. The 'man' program is used by default for this purpose, but this can be overridden by other options or configuration variables.
zh_HANS-CN: 如果给出了一个命令或其他文件，相关的手册页就会被调出来。默认情况下使用 'man' 程序来实现这一目的，但这可以被其他选项或配置变量所覆盖。

note: type: Plain text
en: If an alias is given, git shows the definition of the alias on standard output. To get the manual page for the aliased command, use `git <command> --help`.
zh_HANS-CN: 如果给了一个别名，git 会在标准输出上显示该别名的定义。要获得别名命令的手册页，请使用 `git <command> --help`。

note: type: Plain text
en: Note that `git --help ...` is identical to `git help ...` because the former is internally converted into the latter.
zh_HANS-CN: 请注意，`git --help ...` 与 `git help ...` 相同，因为前者在内部被转换为后者。

note: type: Plain text
en: To display the linkgit:git[1] man page, use `git help git`.
zh_HANS-CN: 要显示 linkgit:git[1] 的帮助页，请使用 `git help git`。

note: type: Plain text
en: This page can be displayed with 'git help help' or `git help --help`
zh_HANS-CN: 这个页面可以用 'git help help' 或 'git help --help' 显示

note: type: Plain text
en: Prints all the available commands on the standard output.
zh_HANS-CN: 在标准输出上打印所有可用的命令。

note: type: Plain text
en: When used with `--all`, exclude the listing of external "git-*" commands found in the `$PATH`.
zh_HANS-CN: 当与 `--all` 一起使用时，排除在`$PATH` 中发现的外部 "git-*" 命令的列表。

note: type: Plain text
en: When used with `--all`, exclude the listing of configured aliases.
zh_HANS-CN: 当与 `--all` 一起使用时，不包括配置的别名列表。

note: type: Plain text
en: When used with `--all` print description for all recognized commands. This is the default.
zh_HANS-CN: 当与 `--all` 一起使用时，打印所有识别的命令的描述。这是默认的。

note: type: Plain text
en: List all available configuration variables. This is a short summary of the list in linkgit:git-config[1].
zh_HANS-CN: 列出所有可用的配置变量。这是对 linkgit:git-config[1] 中的列表的简短总结。

note: type: Plain text
en: Prints a list of the Git concept guides on the standard output.
zh_HANS-CN: 在标准输出上打印 Git 概念指南的列表。

note: type: Plain text
en: Prints a list of the repository, command and file interfaces documentation on the standard output.
zh_HANS-CN: 在标准输出上打印一个仓库、命令和文件接口文档的列表。

note: type: Plain text
en: In-repository file interfaces such as `.git/info/exclude` are documented here (see linkgit:gitrepository-layout[5]), as well as in-tree configuration such as `.mailmap` (see linkgit:gitmailmap[5]).
zh_HANS-CN: 仓库内的文件接口，如 `.git/info/exclude`，在这里有记录（见 linkgit:gitrepository-layout[5]），以及树内配置，如 `.mailmap`（见linkgit:gitmailmap[5]）。

note: type: Plain text
en: This section of the documentation also covers general or widespread user-interface conventions (e.g. linkgit:gitcli[7]), and pseudo-configuration such as the file-based `.git/hooks/*` interface described in linkgit:githooks[5].
zh_HANS-CN: 这一部分的文档还包括一般的或普遍的用户界面惯例（例如 linkgit:gitcli[7]），以及伪配置，例如 linkgit:githooks[5] 中描述的基于文件的 `.git/hooks/*` 界面。

note: type: Plain text
en: Print list of file formats, protocols and other developer interfaces documentation on the standard output.
zh_HANS-CN: 在标准输出上打印文件格式、协议和其他开发者接口文件的清单。

note: type: Plain text
en: Display manual page for the command in the 'info' format. The 'info' program will be used for that purpose.
zh_HANS-CN: 以 'info' 格式显示该命令的手册页。'info' 程序将被用于该目的。

note: type: Plain text
en: Display manual page for the command in the 'man' format. This option may be used to override a value set in the `help.format` configuration variable.
zh_HANS-CN: 以 'man' 格式显示该命令的手册页。这个选项可以用来覆盖 `help.format` 配置变量中设置的值。

note: type: Plain text
en: By default the 'man' program will be used to display the manual page, but the `man.viewer` configuration variable may be used to choose other display programs (see below).
zh_HANS-CN: 默认情况下，将使用 'man' 程序来显示手册页面，但 `man.viewer` 配置变量可以用来选择其他显示程序（见下文）。

note: type: Plain text
en: Display manual page for the command in the 'web' (HTML)  format. A web browser will be used for that purpose.
zh_HANS-CN: 以 ‘网页’（HTML）格式显示该命令的手册页面。为此将使用一个网络浏览器。

note: type: Plain text
en: The web browser can be specified using the configuration variable `help.browser`, or `web.browser` if the former is not set. If none of these config variables is set, the 'git web{litdd}browse' helper script (called by 'git help') will pick a suitable default. See linkgit:git-web{litdd}browse[1] for more information about this.
zh_HANS-CN: 网络浏览器可以用配置变量 `help.browser` 来指定，如果前者没有设置，则用 `web.browser`。如果这些配置变量都没有设置，'git web{litdd}browse' 辅助脚本（由 "git help "调用）会选择一个合适的默认值。参见 linkgit:git-web{litdd}browse[1] 获取更多相关信息。

note: type: Title -
en: CONFIGURATION VARIABLES
zh_HANS-CN: 配置变量

note: type: Plain text
en: If no command-line option is passed, the `help.format` configuration variable will be checked. The following values are supported for this variable; they make 'git help' behave as their corresponding command- line option:
zh_HANS-CN: 如果没有传递命令行选项，将检查 `help.format` 配置变量。该变量支持以下值；它们使 'git help' 的行为与它们相应的命令行选项相同：

note: type: Plain text
en: "man" corresponds to '-m|--man',
zh_HANS-CN: "man" 对应的是 '-m|--man'，

note: type: Plain text
en: "info" corresponds to '-i|--info',
zh_HANS-CN: "info" 对应的是 '-i|--info'，

note: type: Plain text
en: "web" or "html" correspond to '-w|--web'.
zh_HANS-CN: "web" 或 "html" 对应于 '-w|-web'。

note: type: Title ~
en: help.browser, web.browser and browser.<tool>.path
zh_HANS-CN: help.browser, web.browser 和 browser.<工具>.path

note: type: Plain text
en: The `help.browser`, `web.browser` and `browser.<tool>.path` will also be checked if the 'web' format is chosen (either by command-line option or configuration variable). See '-w|--web' in the OPTIONS section above and linkgit:git-web{litdd}browse[1].
zh_HANS-CN: 如果选择了 'web' 格式（通过命令行选项或配置变量），`help.browser`、`web.browser` 和 `browser.<工具>.path` 也将被检查。见上面选项部分的 '-w|-web' 和 linkgit:git-web{litdd}browse[1]。

note: type: Plain text
en: The `man.viewer` configuration variable will be checked if the 'man' format is chosen. The following values are currently supported:
zh_HANS-CN: 如果选择 'man' 格式，`man.viewer` 配置变量将被检查。目前支持以下数值：

note: type: Plain text
en: "man": use the 'man' program as usual,
zh_HANS-CN: "man" : 像往常一样使用 'man' 程序、

note: type: Plain text
en: "woman": use 'emacsclient' to launch the "woman" mode in emacs (this only works starting with emacsclient versions 22),
zh_HANS-CN: "woman": 使用 'emacsclient' 在 emacs 中启动 "woman" 模式（这只在 emacsclient 第 22 版开始工作），

note: type: Plain text
en: "konqueror": use 'kfmclient' to open the man page in a new konqueror tab (see 'Note about konqueror' below).
zh_HANS-CN: "konqueror": 使用 'kfmclient' 在一个新的 konqueror 标签中打开手册页（见下文 ‘关于 konqueror 的说明’）。

note: type: Plain text
en: Values for other tools can be used if there is a corresponding `man.<tool>.cmd` configuration entry (see below).
zh_HANS-CN: 如果有相应的 `man.<工具>.cmd` 配置项，可以使用其他工具的值（见下文）。

note: type: Plain text
en: Multiple values may be given to the `man.viewer` configuration variable. Their corresponding programs will be tried in the order listed in the configuration file.
zh_HANS-CN: 可以给 `man.viewer` 配置变量设置多个值。他们相应的程序将按照配置文件中列出的顺序进行尝试。

note: type: Plain text
en: For example, this configuration:
zh_HANS-CN: 例如，这种配置：

note: type: Plain text
en: will try to use konqueror first. But this may fail (for example, if DISPLAY is not set) and in that case emacs' woman mode will be tried.
zh_HANS-CN: 将首先尝试使用 konqueror。但这可能会失败（例如，如果没有设置DISPLAY），在这种情况下，将尝试 Emacs 的 woman 模式。

note: type: Plain text
en: If everything fails, or if no viewer is configured, the viewer specified in the `GIT_MAN_VIEWER` environment variable will be tried.  If that fails too, the 'man' program will be tried anyway.
zh_HANS-CN: 如果一切都失败了，或者没有配置查看器，将尝试 `GIT_MAN_VIEWER` 环境变量中指定的查看器。 如果这也失败了，将尝试使用 'man' 程序。

note: type: Title ~
en: man.<tool>.path
zh_HANS-CN: man.<工具>.path

note: type: Plain text
en: You can explicitly provide a full path to your preferred man viewer by setting the configuration variable `man.<tool>.path`. For example, you can configure the absolute path to konqueror by setting 'man.konqueror.path'. Otherwise, 'git help' assumes the tool is available in PATH.
zh_HANS-CN: 你可以通过设置配置变量 `man.<工具>.path` 来明确提供你喜欢的 man viewer 的完整路径。例如，你可以通过设置 'man.konqueror.path' 来配置 konqueror 的绝对路径。否则，'git help' 会假定该工具在 PATH中 是可用的。

note: type: Title ~
en: man.<tool>.cmd
zh_HANS-CN: man.<工具>.cmd

note: type: Plain text
en: When the man viewer, specified by the `man.viewer` configuration variables, is not among the supported ones, then the corresponding `man.<tool>.cmd` configuration variable will be looked up. If this variable exists then the specified tool will be treated as a custom command and a shell eval will be used to run the command with the man page passed as arguments.
zh_HANS-CN: 当由 `man.viewer` 配置变量指定的 man viewer 不在支持的范围内时，将查找相应的 `man.<工具>.cmd` 配置变量。如果这个变量存在，那么指定的工具将被视为一个自定义的命令，shell eval 将被用来运行命令，并将 man page 作为参数传递。

note: type: Title ~
en: Note about konqueror
zh_HANS-CN: 关于 konqueror 的说明

note: type: Plain text
en: When 'konqueror' is specified in the `man.viewer` configuration variable, we launch 'kfmclient' to try to open the man page on an already opened konqueror in a new tab if possible.
zh_HANS-CN: 当 `man.viewer` 配置变量中指定为 'konqueror' 时，我们启动 'kfmclient'，以尝试在新标签页中打开已经打开的 konqueror 的 man 页面。

note: type: Plain text
en: If you really want to use 'konqueror', then you can use something like the following:
zh_HANS-CN: 如果你真的想使用 'konqueror'，那么你可以使用类似以下的东西：

note: type: Title ~
en: Note about git config --global
zh_HANS-CN: 关于 git config --global 的说明

note: type: Plain text
en: Note that all these configuration variables should probably be set using the `--global` flag, for example like this:
zh_HANS-CN: 请注意，所有这些配置变量可能都应该使用 `--global` 标志来设置，比如说像这样：

note: type: Plain text
en: as they are probably more user specific than repository specific.  See linkgit:git-config[1] for more information about this.
zh_HANS-CN: 因为它们可能更多是针对用户而不是针对仓库。 更多相关信息见 linkgit:git-config[1]。

note: type: Plain text
en: git-http-backend - Server side implementation of Git over HTTP
zh_HANS-CN: git-http-backend - Git 在 HTTP 上的服务器端实现

note: type: Plain text
en: A simple CGI program to serve the contents of a Git repository to Git clients accessing the repository over http:// and https:// protocols.  The program supports clients fetching using both the smart HTTP protocol and the backwards-compatible dumb HTTP protocol, as well as clients pushing using the smart HTTP protocol. It also supports Git's more-efficient "v2" protocol if properly configured; see the discussion of `GIT_PROTOCOL` in the ENVIRONMENT section below.
zh_HANS-CN: 一个简单的 CGI 程序，为通过 http:// 和 https:// 协议访问仓库的 Git 客户提供内容。 该程序支持客户端使用智能 HTTP 协议和向后兼容的哑 HTTP 协议获取内容，以及客户端使用智能 HTTP 协议推送内容。如果配置得当，它还支持 Git 更高效的 "v2" 协议；见下文环境部分关于`GIT_PROTOCOL` 的讨论。

note: type: Plain text
en: By default, only the `upload-pack` service is enabled, which serves 'git fetch-pack' and 'git ls-remote' clients, which are invoked from 'git fetch', 'git pull', and 'git clone'.  If the client is authenticated, the `receive-pack` service is enabled, which serves 'git send-pack' clients, which is invoked from 'git push'.
zh_HANS-CN: 默认情况下，只有 `upload-pack` 服务被启用，它为 'git fetch-pack' 和 'git ls-remote' 客户端服务，这些客户端被 'git fetch'、'git pull' 和 'git clone' 调用。 如果客户端经过认证，`receive-pack` 服务将被启用，它为 'git send-pack' 客户端服务，该服务由 'git push' 调用。

note: type: Plain text
en: These services can be enabled/disabled using the per-repository configuration file:
zh_HANS-CN: 这些服务可以使用每个库的配置文件来启用/禁用：

note: type: Plain text
en: This serves Git clients older than version 1.6.6 that are unable to use the upload pack service.  When enabled, clients are able to read any file within the repository, including objects that are no longer reachable from a branch but are still present.  It is enabled by default, but a repository can disable it by setting this configuration item to `false`.
zh_HANS-CN: 这是为 1.6.6 版本以上的 Git 客户端提供服务，它们无法使用上传包服务。 启用后，客户端能够读取仓库内的任何文件，包括不再能从分支到达但仍然存在的对象。 默认情况下是启用的，但仓库可以通过将此配置项设置为 `false` 来禁用它。

note: type: Plain text
en: This serves 'git fetch-pack' and 'git ls-remote' clients.  It is enabled by default, but a repository can disable it by setting this configuration item to `false`.
zh_HANS-CN: 这为 'git fetch-pack' 和 'git ls-remote' 客户端服务。 它在默认情况下是启用的，但仓库可以通过将此配置项设置为`false`来禁用它。

note: type: Plain text
en: This serves 'git send-pack' clients, allowing push.  It is disabled by default for anonymous users, and enabled by default for users authenticated by the web server.  It can be disabled by setting this item to `false`, or enabled for all users, including anonymous users, by setting it to `true`.
zh_HANS-CN: 这为 'git send-pack' 客户提供服务，允许推送。 默认情况下，它对匿名用户是禁用的，而对通过网络服务器认证的用户是启用的。 可以通过设置该项为 `false` 来禁用它，或者通过设置为 `true` 来为所有用户（包括匿名用户）启用。

note: type: Plain text
en: To determine the location of the repository on disk, 'git http-backend' concatenates the environment variables PATH_INFO, which is set automatically by the web server, and GIT_PROJECT_ROOT, which must be set manually in the web server configuration.  If GIT_PROJECT_ROOT is not set, 'git http-backend' reads PATH_TRANSLATED, which is also set automatically by the web server.
zh_HANS-CN: 为了确定磁盘上仓库的位置，'git http-backend' 将环境变量 PATH_INFO 和 GIT_PROJECT_ROOT 连接起来，前者由 Web 服务器自动设置，后者则必须在 Web 服务器配置中手动设置。 如果 GIT_PROJECT_ROOT 没有设置，'git http-backend '会读取 PATH_TRANSLATED，这也是由网络服务器自动设置的。

note: type: Plain text
en: All of the following examples map `http://$hostname/git/foo/bar.git` to `/var/www/git/foo/bar.git`.
zh_HANS-CN: 下面所有的例子都把 `http://$hostname/git/foo/bar.git` 映射到 `/var/www/git/foo/bar.git`。

note: type: Plain text
en: Ensure mod_cgi, mod_alias, and mod_env are enabled, set GIT_PROJECT_ROOT (or DocumentRoot) appropriately, and create a ScriptAlias to the CGI:
zh_HANS-CN: 确保 mod_cgi、mod_alias 和 mod_env被 启用，适当地设置 GIT_PROJECT_ROOT（或 DocumentRoot），并为 CGI 创建一个 ScriptAlias：

note: type: delimited block -
en: # This is not strictly necessary using Apache and a modern version of
    # git-http-backend, as the webserver will pass along the header in the
    # environment as HTTP_GIT_PROTOCOL, and http-backend will copy that into
    # GIT_PROTOCOL. But you may need this line (or something similar if you
    # are using a different webserver), or if you want to support older Git
    # versions that did not do that copying.
    #
    # Having the webserver set up GIT_PROTOCOL is perfectly fine even with
    # modern versions (and will take precedence over HTTP_GIT_PROTOCOL,
    # which means it can be used to override the client's request).
    SetEnvIf Git-Protocol ".*" GIT_PROTOCOL=$0
zh_HANS-CN: # 这在使用 Apache 和现代版本的
    # git-http-backend，因为网络服务器会把头信息在
    # 环境中作为 HTTP_GIT_PROTOCOL 传递，而 http-backend 会将其复制到
    # git_protocol。但你可能需要这一行（或类似的东西，如果你
    # 使用不同的 webserver），或者如果你想支持旧的 Git
    # 版本没有做这样的复制。
    #
    # 让 webserver 设置 GIT_PROTOCOL 是完全可以的，即使在
    # 现代版本也是如此（并且优先于 HTTP_GIT_PROTOCOL，
    # 这意味着它可以被用来覆盖客户端的请求）。
    SetEnvIf Git-Protocol ".*"GIT_PROTOCOL=$0

note: type: Plain text
en: To enable anonymous read access but authenticated write access, require authorization for both the initial ref advertisement (which we detect as a push via the service parameter in the query string), and the receive-pack invocation itself:
zh_HANS-CN: 为了实现匿名的读取访问，但要有认证的写入访问，需要对最初的引用广播（我们通过查询字符串中的服务参数检测为推送）和接收包调用本身进行授权：

note: type: Plain text
en: If you do not have `mod_rewrite` available to match against the query string, it is sufficient to just protect `git-receive-pack` itself, like:
zh_HANS-CN: 如果你没有 `mod_rewrite` 可用来匹配查询字符串，只需保护 `git-receive-pack` 本身即可，比如：

note: type: Plain text
en: In this mode, the server will not request authentication until the client actually starts the object negotiation phase of the push, rather than during the initial contact.  For this reason, you must also enable the `http.receivepack` config option in any repositories that should accept a push. The default behavior, if `http.receivepack` is not set, is to reject any pushes by unauthenticated users; the initial request will therefore report `403 Forbidden` to the client, without even giving an opportunity for authentication.
zh_HANS-CN: 在这种模式下，服务器将不会请求认证，直到客户端实际开始推送的对象协商阶段，而不是在最初的接触中。 由于这个原因，你必须在任何应该接受推送的存储库中启用 `http.receivepack` 配置选项。如果没有设置 `http.receivepack`，默认行为是拒绝任何未经认证的用户的推送；因此初始请求将向客户端报告 `403 Forbidden`，甚至不给认证机会。

note: type: Plain text
en: To require authentication for both reads and writes, use a Location directive around the repository, or one of its parent directories:
zh_HANS-CN: 要对读和写都要求认证，可以在仓库或它的一个父目录周围使用 Location 指令：

note: type: Plain text
en: To serve gitweb at the same url, use a ScriptAliasMatch to only those URLs that 'git http-backend' can handle, and forward the rest to gitweb:
zh_HANS-CN: 要在同一个网址上为 gitweb 提供服务，使用 ScriptAliasMatch，只对那些 'git http-backend' 可以处理的网址进行匹配，其余的转发给 gitweb：

note: type: Plain text
en: To serve multiple repositories from different linkgit:gitnamespaces[7] in a single repository:
zh_HANS-CN: 在一个仓库中为来自不同 linkgit:gitnamespaces[7] 的多个仓库提供服务：

note: type: Plain text
en: Similar to the above, but Apache can be used to return static files that are stored on disk.  On many systems this may be more efficient as Apache can ask the kernel to copy the file contents from the file system directly to the network:
zh_HANS-CN: 与上述情况类似，但 Apache 可以用来返回存储在磁盘上的静态文件。 在许多系统上，这可能更有效率，因为 Apache 可以要求内核将文件内容从文件系统直接复制到网络上：

note: type: Plain text
en: This can be combined with the gitweb configuration:
zh_HANS-CN: 这可以与 gitweb 的配置相结合：

note: type: Plain text
en: Ensure that `mod_cgi`, `mod_alias`, `mod_auth`, `mod_setenv` are loaded, then set `GIT_PROJECT_ROOT` appropriately and redirect all requests to the CGI:
zh_HANS-CN: 确保 `mod_cgi`、`mod_alias`、`mod_auth`、`mod_setenv` 已经加载，然后适当设置 `GIT_PROJECT_ROOT`，并将所有请求重定向到 CGI：

note: type: Plain text
en: To enable anonymous read access but authenticated write access:
zh_HANS-CN: 要启用匿名的读取访问，但要有认证的写入访问：

note: type: Plain text
en: where `git-auth.conf` looks something like:
zh_HANS-CN: 其中 `git-auth.conf` 看起来像：

note: type: delimited block -
en: auth.require = (
    	"/" => (
    		"method" => "basic",
    		"realm" => "Git Access",
    		"require" => "valid-user"
    	       )
    )
    # ...and set up auth.backend here
zh_HANS-CN: auth.require = (
    	"/" => (
    		"method" => "basic",
    		"realm" => "Git Access",
    		"require" => "valid-user"
    	       )
    )
    # ...并在此设置auth.backend

note: type: Plain text
en: To require authentication for both reads and writes:
zh_HANS-CN: 要求对读和写都进行认证：

note: type: Plain text
en: PATH_INFO (if GIT_PROJECT_ROOT is set, otherwise PATH_TRANSLATED)
zh_HANS-CN: PATH_INFO（如果设置了 GIT_PROJECT_ROOT，否则为 PATH_TRANSLATED）

note: type: Plain text
en: The `GIT_HTTP_EXPORT_ALL` environmental variable may be passed to 'git-http-backend' to bypass the check for the "git-daemon-export-ok" file in each repository before allowing export of that repository.
zh_HANS-CN: `GIT_HTTP_EXPORT_ALL` 环境变量可以传递给 'git-http-backend'，以绕过在允许导出每个仓库前对 "git-daemon-export-ok" 文件的检查。

note: type: Plain text
en: The `GIT_HTTP_MAX_REQUEST_BUFFER` environment variable (or the `http.maxRequestBuffer` config variable) may be set to change the largest ref negotiation request that git will handle during a fetch; any fetch requiring a larger buffer will not succeed.  This value should not normally need to be changed, but may be helpful if you are fetching from a repository with an extremely large number of refs.  The value can be specified with a unit (e.g., `100M` for 100 megabytes). The default is 10 megabytes.
zh_HANS-CN: `GIT_HTTP_MAX_REQUEST_BUFFER` 环境变量（或 `http.maxRequestBuffer` 配置变量）可以被设置为改变 git 在获取过程中所处理的最大引用协商请求；任何需要更大缓冲区的获取将不会成功。 这个值通常不需要改变，但如果你从一个有大量引用的仓库中获取，可能会有帮助。 这个值可以指定一个单位（例如，`100M` 表示 100 兆字节）。默认是 10 兆字节。

note: type: Plain text
en: Clients may probe for optional protocol capabilities (like the v2 protocol) using the `Git-Protocol` HTTP header. In order to support these, the contents of that header must appear in the `GIT_PROTOCOL` environment variable. Most webservers will pass this header to the CGI via the `HTTP_GIT_PROTOCOL` variable, and `git-http-backend` will automatically copy that to `GIT_PROTOCOL`. However, some webservers may be more selective about which headers they'll pass, in which case they need to be configured explicitly (see the mention of `Git-Protocol` in the Apache config from the earlier EXAMPLES section).
zh_HANS-CN: 客户端可以使用 `Git-Protocol` HTTP 头来探测可选的协议能力（如 v2 协议）。为了支持这些，该标头的内容必须出现在 `GIT_PROTOCOL` 环境变量中。大多数网络服务器将通过 `HTTP_GIT_PROTOCOL` 变量把这个头传递给 CGI，`git-http-backend` 将自动把它复制到 `GIT_PROTOCOL`。然而，一些网络服务器可能对他们要传递的头信息更有选择性，在这种情况下，他们需要明确配置（见前面例子部分的 Apache 配置中对 `Git-Protocol` 的提及）。

note: type: Plain text
en: The backend process sets GIT_COMMITTER_NAME to '$REMOTE_USER' and GIT_COMMITTER_EMAIL to '$\{REMOTE_USER}@http.$\{REMOTE_ADDR\}', ensuring that any reflogs created by 'git-receive-pack' contain some identifying information of the remote user who performed the push.
zh_HANS-CN: 后台进程将 GIT_COMMITTER_NAME 设置为 '$REMOTE_USER'，将 GIT_COMMITTER_EMAIL 设置为 '$\{REMOTE_USER}\@http.${REMOTE_ADDR\}'，确保任何由 'git-receive-pack' 创建的引用日志包含执行推送的远程用户的一些识别信息。

note: type: Plain text
en: All `CGI` environment variables are available to each of the hooks invoked by the 'git-receive-pack'.
zh_HANS-CN: 所有 `CGI` 环境变量对 'git-receive-pack' 调用的每个钩子都是可用的。

note: type: Plain text
en: Downloads a remote Git repository via HTTP.
zh_HANS-CN: 通过HTTP下载远程Git存储库。

note: type: Plain text
en: This command always gets all objects. Historically, there were three options `-a`, `-c` and `-t` for choosing which objects to download. They are now silently ignored.
zh_HANS-CN: 这个命令总是获取所有的对象。在过去，有三个选项 `-a`、`-c` 和 `-t`用于选择下载哪些对象。现在它们被默默地忽略了。

note: type: Plain text
en: Either the hash or the filename under [URL]/refs/ to pull.
zh_HANS-CN: 在 [URL]/refs/ 下的哈希值或文件名来拉取。

note: type: Plain text
en: These options are ignored for historical reasons.
zh_HANS-CN: 由于历史原因，这些选项被忽略了。

note: type: Plain text
en: Report what is downloaded.
zh_HANS-CN: 报告所下载的内容。

note: type: Plain text
en: Writes the commit-id into the filename under $GIT_DIR/refs/<filename> on the local end after the transfer is complete.
zh_HANS-CN: 转移完成后，在本地端将 commit-id 写入 $GIT_DIR/refs/<文件名>下的文件名。

note: type: Plain text
en: Instead of a commit id on the command line (which is not expected in this case), 'git http-fetch' expects lines on stdin in the format
zh_HANS-CN: 'git http-fetch' 希望在标准输入流上看到格式为以下的行，而不是命令行上的提交 ID（在这种情况下不需要提交 ID）

note: type: Plain text
en: For internal use only. The command to run on the contents of the downloaded pack. Arguments are URL-encoded separated by spaces.
zh_HANS-CN: 仅供内部使用。对下载的包的内容运行的命令。参数为 URL 编码，以空格分隔。

note: type: Plain text
en: Verify that everything reachable from target is fetched.  Used after an earlier fetch is interrupted.
zh_HANS-CN: 验证所有可以从目标地可达的东西都被取走了。 在一个较早的获取被中断后使用。

note: type: Plain text
en: git-http-push - Push objects over HTTP/DAV to another repository
zh_HANS-CN: git-http-push - 通过http/DAV将对象推送到另一个存储库

note: type: Plain text
en: Sends missing objects to remote repository, and updates the remote branch.
zh_HANS-CN: 将丢失的对象发送到远程仓库，并更新远程分支。

note: type: Plain text
en: *NOTE*: This command is temporarily disabled if your libcurl
    is older than 7.16, as the combination has been reported
    not to work and sometimes corrupts repository.
zh_HANS-CN: *注意*： 如果你的 libcurl 的版本超过 7.16，这个命令会暂时失效。
    早于 7.16，这个命令会被暂时禁用，因为有报告说这个组合
    不起作用，并且有时会破坏仓库。

note: type: Plain text
en: Do not assume that the remote repository is complete in its current state, and verify all objects in the entire local ref's history exist in the remote repository.
zh_HANS-CN: 不要假设远程仓库的当前状态是完整的，要验证整个本地引用的历史中的所有对象是否存在于远程仓库。

note: type: Plain text
en: Usually, the command refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it.  This flag disables the check.  What this means is that the remote repository can lose commits; use it with care.
zh_HANS-CN: 通常情况下，命令拒绝更新一个不是用来覆盖它的本地引用的祖先远程引用。 这个标志可以禁止这种检查。 这意味着远程仓库可能会丢失提交，使用时要小心。

note: type: Plain text
en: Do everything except actually send the updates.
zh_HANS-CN: 做除了实际发送更新外的所有事。

note: type: Plain text
en: Report the list of objects being walked locally and the list of objects successfully sent to the remote repository.
zh_HANS-CN: 报告正在本地行走的对象的列表和成功发送到远程仓库的对象的列表。

note: type: Plain text
en: Remove <ref> from remote repository.  The specified branch cannot be the remote HEAD.  If -d is specified the following other conditions must also be met:
zh_HANS-CN: 从远程仓库中删除 <引用>。 指定的分支不能是远程的 HEAD。 如果指定了 -d，还必须满足以下其他条件：

note: type: Plain text
en: Remote HEAD must resolve to an object that exists locally
zh_HANS-CN: 远程 HEAD 必须解析到一个本地存在的对象

note: type: Plain text
en: Specified branch resolves to an object that exists locally
zh_HANS-CN: 指定的分支解析到一个本地存在的对象

note: type: Plain text
en: Specified branch is an ancestor of the remote HEAD
zh_HANS-CN: 指定的分支是远程 HEAD 的一个祖先

note: type: Plain text
en: The remote refs to update.
zh_HANS-CN: 要更新的远程引用。

note: type: Title -
en: SPECIFYING THE REFS
zh_HANS-CN: 指定引用

note: type: Plain text
en: A '<ref>' specification can be either a single pattern, or a pair of such patterns separated by a colon ":" (this means that a ref name cannot have a colon in it).  A single pattern '<name>' is just a shorthand for '<name>:<name>'.
zh_HANS-CN: 一个 '<引用>' 规范既可以是一个单一的模式，也可以是一对由冒号 ":" 隔开的模式（这意味着一个引用名称中不能有冒号）。 一个单一的模式 '<名称>' 只是 '<名称>:<名称>' 的一个缩写。

note: type: Plain text
en: Each pattern pair '<src>:<dst>' consists of the source side (before the colon) and the destination side (after the colon).  The ref to be pushed is determined by finding a match that matches the source side, and where it is pushed is determined by using the destination side.
zh_HANS-CN: 每个模式对 '<src>:<dst>' 由源端（冒号之前）和目标端（冒号之后）组成。 要推送的引用是通过找到与源端相匹配的匹配物来确定的，而推送的位置是通过目的地端来确定的。

note: type: Plain text
en: It is an error if '<src>' does not match exactly one of the local refs.
zh_HANS-CN: 如果 '<src>' 与本地引用中的一个不完全匹配，则是一个错误。

note: type: Plain text
en: If '<dst>' does not match any remote ref, either
zh_HANS-CN: 如果 '<dst>' 不匹配任何远程引用，或者

note: type: Plain text
en: it has to start with "refs/"; <dst> is used as the destination literally in this case.
zh_HANS-CN: 它必须以 "refs/" 开头；在这种情况下，<dst> 被用作目标字面。

note: type: Plain text
en: <src> == <dst> and the ref that matched the <src> must not exist in the set of remote refs; the ref matched <src> locally is used as the name of the destination.
zh_HANS-CN: <src> == <dst>，并且与 <src> 相匹配的引用必须不存在于远程引用集合中；本地匹配的 <src>引用被用作目的地的名称。

note: type: Plain text
en: Without `--force`, the <src> ref is stored at the remote only if <dst> does not exist, or <dst> is a proper subset (i.e. an ancestor) of <src>.  This check, known as "fast-forward check", is performed in order to avoid accidentally overwriting the remote ref and lose other peoples' commits from there.
zh_HANS-CN: 如果没有 `--force`，只有当 <dst> 不存在，或者 <dst> 是 <src> 的适当子集（即祖先）时，<src> 的引用才会被保存在远程。 这个检查被称为 “快速检查”，是为了避免不小心覆盖了远程引用而丢失其他人在那里的提交。

note: type: Plain text
en: With `--force`, the fast-forward check is disabled for all refs.
zh_HANS-CN: 使用 `--force`，所有裁判的快进检查都被禁用。

note: type: Plain text
en: Optionally, a <ref> parameter can be prefixed with a plus '+' sign to disable the fast-forward check only on that ref.
zh_HANS-CN: 可以选择在 <ref> 参数前加上一个加号 '+' 号，以便仅在该引用上禁用快进检查。

note: type: Plain text
en: This command uploads a mailbox generated with 'git format-patch' into an IMAP drafts folder.  This allows patches to be sent as other email is when using mail clients that cannot read mailbox files directly. The command also works with any general mailbox in which emails have the fields "From", "Date", and "Subject" in that order.
zh_HANS-CN: 这条命令将用 'git format-patch' 生成的邮箱上传到 IMAP 的 drafts 文件夹。 这允许在使用不能直接读取邮箱文件的邮件客户端时，将补丁作为其他邮件发送。该命令也适用于任何一般的邮箱，其中的邮件按顺序有 "Form"、"Date" 和 "Subject" 字段。

note: type: Plain text
en: Typical usage is something like:
zh_HANS-CN: 典型的用法是这样的：

note: type: Plain text
en: Use libcurl to communicate with the IMAP server, unless tunneling into it.  Ignored if Git was built without the USE_CURL_FOR_IMAP_SEND option set.
zh_HANS-CN: 使用 libcurl 与 IMAP 服务器通信，除非通过隧道进入。 如果 Git 在构建时没有设置 USE_CURL_FOR_IMAP_SEND 选项，则会被忽略。

note: type: Plain text
en: Talk to the IMAP server using git's own IMAP routines instead of using libcurl.  Ignored if Git was built with the NO_OPENSSL option set.
zh_HANS-CN: 使用 git 自己的 IMAP 例程与 IMAP 服务器对话，而不是使用 libcurl。 如果 Git 在构建时设置了 NO_OPENSSL 选项，则忽略。

note: type: Plain text
en: To use the tool, `imap.folder` and either `imap.tunnel` or `imap.host` must be set to appropriate values.
zh_HANS-CN: 要使用该工具，`imap.folder` 和 `imap.tunnel` 或 `imap.host` 必须被设置为适当的值。

note: type: Plain text
en: Using tunnel mode:
zh_HANS-CN: 使用隧道模式：

note: type: Plain text
en: Using direct mode:
zh_HANS-CN: 使用直接模式：

note: type: Plain text
en: Using direct mode with SSL:
zh_HANS-CN: 使用 SSL 的直接模式：

note: type: Plain text
en: You may want to use `sslVerify=false` while troubleshooting, if you suspect that the reason you are having trouble connecting is because the certificate you use at the private server `example.com` you are trying to set up (or have set up) may not be verified correctly.
zh_HANS-CN: 在排除故障时，如果你怀疑连接有问题的原因是你在试图建立（或已经建立）的私人服务器 `example.com`上使用的证书可能没有被正确验证，你可能想使用 `sslVerify=false`。

note: type: Plain text
en: Using Gmail's IMAP interface:
zh_HANS-CN: 使用 Gmail 的 IMAP 界面：

note: type: Plain text
en: You might need to instead use: `folder = "[Google Mail]/Drafts"` if you get an error that the "Folder doesn't exist".
zh_HANS-CN: 如果你得到一个错误，即 “文件夹不存在”，你可能需要改用： `folder = "[Google Mail]/Drafts"` 。

note: type: Plain text
en: If your Gmail account is set to another language than English, the name of the "Drafts" folder will be localized.
zh_HANS-CN: 如果你的 Gmail 账户被设置为英语以外的其他语言，"Drafts" 文件夹的名称将被本地化。

note: type: Plain text
en: Once the commits are ready to be sent, run the following command:
zh_HANS-CN: 一旦准备好发送提交，请运行以下命令：

note: type: Plain text
en: Just make sure to disable line wrapping in the email client (Gmail's web interface will wrap lines no matter what, so you need to use a real IMAP client).
zh_HANS-CN: 只要确保禁用电子邮件客户端的换行功能（Gmail 的网络界面无论如何都会换行，所以你需要使用真正的 IMAP 客户端）。

note: type: Plain text
en: It is still your responsibility to make sure that the email message sent by your email program meets the standards of your project.  Many projects do not like patches to be attached.  Some mail agents will transform patches (e.g. wrap lines, send them as format=flowed) in ways that make them fail.  You will get angry flames ridiculing you if you don't check this.
zh_HANS-CN: 你仍然有责任确保你的电子邮件程序所发送的电子邮件符合你的项目的标准。 许多项目不喜欢附加补丁。 一些邮件代理会对补丁进行转换（例如，包行，以 format=flowed 的方式发送），使其失败。 如果你不检查这个，你会得到愤怒的火苗。

note: type: Plain text
en: Thunderbird in particular is known to be problematic.  Thunderbird
    users may wish to visit this web page for more information:
      http://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird#Completely_plain_email
zh_HANS-CN: 尤其是Thunderbird，众所周知，它存在问题。 Thunderbird
    用户可能希望访问这个网页以了解更多信息：
      http://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird#Completely_plain_email

note: type: Plain text
en: Reads a packed archive (.pack) from the specified file, and builds a pack index file (.idx) for it. Optionally writes a reverse-index (.rev) for the specified pack. The packed archive together with the pack index can then be placed in the objects/pack/ directory of a Git repository.
zh_HANS-CN: 从指定的文件中读取一个打包的档案（.pack），并为其建立一个打包索引文件（.idx）。可以选择为指定的包写一个反向索引（.rev）。打包后的归档文件连同打包索引可以放在 Git 仓库的 objects/pack/ 目录中。

note: type: Plain text
en: Be verbose about what is going on, including progress status.
zh_HANS-CN: 对正在发生的事情要言之有物，包括进度状态。

note: type: Plain text
en: Write the generated pack index into the specified file.  Without this option the name of pack index file is constructed from the name of packed archive file by replacing .pack with .idx (and the program fails if the name of packed archive does not end with .pack).
zh_HANS-CN: 将生成的数据包索引写入指定的文件中。 如果没有这个选项，打包索引文件的名称是根据打包档案文件的名称构建的，将 .pack 替换为 .idx（如果打包档案的名称不是以 .pack 结尾，程序将失败）。

note: type: Plain text
en: When this flag is provided, generate a reverse index (a `.rev` file) corresponding to the given pack. If `--verify` is given, ensure that the existing reverse index is correct. Takes precedence over `pack.writeReverseIndex`.
zh_HANS-CN: 当提供这个标志时，生成一个与给定包对应的反向索引（一个 `.rev` 文件）。如果给了 `--verify`，确保现有的反向索引是正确的。优先于 `pack.writeReverseIndex`。

note: type: Plain text
en: When this flag is provided, the pack is read from stdin instead and a copy is then written to <pack-file>. If <pack-file> is not specified, the pack is written to objects/pack/ directory of the current Git repository with a default name determined from the pack content.  If <pack-file> is not specified consider using --keep to prevent a race condition between this process and 'git repack'.
zh_HANS-CN: 当提供这个标志时，数据包将从标注输入流读取，然后将副本写入 <pack-file>。如果没有指定 <pack-file>，数据包会被写入当前 Git 仓库的 objects/pack/ 目录中，其默认名称由数据包内容决定。 如果没有指定 <pack-file>，可以考虑使用 --keep 来防止这个过程和 'git repack' 之间出现竞争状态。

note: type: Plain text
en: Fix a "thin" pack produced by `git pack-objects --thin` (see linkgit:git-pack-objects[1] for details) by adding the excluded objects the deltified objects are based on to the pack. This option only makes sense in conjunction with --stdin.
zh_HANS-CN: 修正由 `git pack-objects --thin` 产生的 “轻量” 包（详见 linkgit:git-pack-objects[1]），将被删除的对象所基于的排除对象加入包中。这个选项只有在与 --stdin 结合时才有意义。

note: type: Plain text
en: Before moving the index into its final destination create an empty .keep file for the associated pack file.  This option is usually necessary with --stdin to prevent a simultaneous 'git repack' process from deleting the newly constructed pack and index before refs can be updated to use objects contained in the pack.
zh_HANS-CN: 在将索引移到其最终目的地之前，为相关的包文件创建一个空的 .keep 文件。 这个选项通常需要和 --stdin一起使用，以防止同时进行的 "git repack" 进程在更新引用以使用 pack 中包含的对象之前删除新建的 pack 和 index。

note: type: Plain text
en: Like --keep create a .keep file before moving the index into its final destination, but rather than creating an empty file place '<msg>' followed by an LF into the .keep file.  The '<msg>' message can later be searched for within all .keep files to locate any which have outlived their usefulness.
zh_HANS-CN: 像 --keep 一样，在将索引移到最终目的地之前创建一个 .keep 文件，但不是创建一个空文件，而是在 .keep 文件中放入 '<msg>' 和一个 LF。 以后可以在所有的 .keep 文件中搜索 '<msg>' 信息，以找到任何已经失去作用的文件。

note: type: Plain text
en: This is intended to be used by the test suite only. It allows to force the version for the generated pack index, and to force 64-bit index entries on objects located above the given offset.
zh_HANS-CN: 这是为测试套件准备的。它允许为生成的数据包索引强制选择版本，并对位于给定偏移量以上的对象强制选择 64 位索引条目。

note: type: Plain text
en: Die, if the pack contains broken objects or links.
zh_HANS-CN: 死亡，如果该包包含破碎的对象或链接。

note: type: Plain text
en: For internal use only.
zh_HANS-CN: 仅供内部使用。

note: type: Plain text
en: Set the title of the progress bar. The title is "Receiving objects" by default and "Indexing objects" when `--stdin` is specified.
zh_HANS-CN: 设置进度条的标题。标题默认为 "Receiving objects"，当指定 `--stdin` 时为 "Indexing objects"。

note: type: Plain text
en: Die if the pack contains broken links. For internal use only.
zh_HANS-CN: 如果数据包中包含无法链接的链接则死亡。仅供内部使用。

note: type: Plain text
en: Die if the pack contains broken objects. If the pack contains a tree pointing to a .gitmodules blob that does not exist, prints the hash of that blob (for the caller to check) after the hash that goes into the name of the pack/idx file (see "Notes").
zh_HANS-CN: 如果数据包中包含破损的对象，则死亡。如果数据包包含一个指向不存在的 .gitmodules blob 的树，则在进入数据包 /idx 文件名的哈希值之后打印该 blob 的哈希值（供调用者检查）（见 “注意事项”）。

note: type: Plain text
en: Specifies the number of threads to spawn when resolving deltas. This requires that index-pack be compiled with pthreads otherwise this option is ignored with a warning.  This is meant to reduce packing time on multiprocessor machines. The required amount of memory for the delta search window is however multiplied by the number of threads.  Specifying 0 will cause Git to auto-detect the number of CPU's and use maximum 3 threads.
zh_HANS-CN: 指定解析 deltas 时产生的线程数量。这要求 index-pack 在编译时使用 pthreads，否则这个选项会被忽略并发出警告。 这是为了减少多处理器机器上的打包时间。然而，delta 搜索窗口所需的内存量要乘以线程的数量。 指定为 0 将导致 Git 自动检测 CPU 的数量并使用最多 3 个线程。

note: type: Plain text
en: Die, if the pack is larger than <size>.
zh_HANS-CN: 如果数据包大于 <size>，则死亡。

note: type: Plain text
en: Before committing the pack-index, create a .promisor file for this pack. Particularly helpful when writing a promisor pack with --fix-thin since the name of the pack is not final until the pack has been fully written. If a `<message>` is provided, then that content will be written to the .promisor file for future reference. See link:technical/partial-clone.html[partial clone] for more information.
zh_HANS-CN: 在提交 pack-index 之前，为这个 pack 创建一个 .promosor 文件。在用 --fix-thin 编写 pack 时特别有帮助，因为在完全编写完 pack 之前，pack 的名字还不是最终的。如果提供了 `<message>`，那么该内容将被写入 .promosor 文件，供将来参考。参见 link:technical/partial-clone.html[partial clone] 以了解更多信息。

note: type: Plain text
en: Once the index has been created, the hash that goes into the name of the pack/idx file is printed to stdout. If --stdin was also used then this is prefixed by either "pack\t", or "keep\t" if a new .keep file was successfully created. This is useful to remove a
zh_HANS-CN: 一旦索引被创建，进入 pack/idx 文件名的哈希值将被打印到标准输出流。如果还使用了 --stdin，那么它的前缀是 "pack\t"，或者 "keep\t"（如果成功创建了一个新的 .keep 文件）。这对于删除一个

note: type: Block title
en: keep file used as a lock to prevent the race with 'git repack'
zh_HANS-CN: 用一个锁来持有文件，以防止与 'git repack' 竞争

note: type: Plain text
en: mentioned above.
zh_HANS-CN: 上述提到的。

note: type: Plain text
en: git-init-db - Creates an empty Git repository
zh_HANS-CN: git-init-db - 创建一个空的 Git 仓库

note: type: Plain text
en: This is a synonym for linkgit:git-init[1].  Please refer to the documentation of that command.
zh_HANS-CN: 这是 linkgit:git-init[1] 的一个同义词。 请参考该命令的文档。

note: type: Plain text
en: the contents of the `$GIT_TEMPLATE_DIR` environment variable;
zh_HANS-CN: `$GIT_TEMPLATE_DIR` 环境变量的内容；

note: type: Plain text
en: git-instaweb - Instantly browse your working repository in gitweb
zh_HANS-CN: git-instaweb - 立即在 gitweb 中浏览您的工作仓库

note: type: Plain text
en: 'git instaweb' [--local] [--httpd=<httpd>] [--port=<port>]
                   [--browser=<browser>]
    'git instaweb' [--start] [--stop] [--restart]
zh_HANS-CN: 'git instaweb' [--local] [--httpd=<httpd>] [--port=<端口>]
                   [--browser=<浏览器>]
    'git instaweb' [--start] [--stop] [--restart]

note: type: Plain text
en: A simple script to set up `gitweb` and a web server for browsing the local repository.
zh_HANS-CN: 一个简单的脚本，用来设置 `gitweb` 和浏览本地仓库的网络服务器。

note: type: Plain text
en: Only bind the web server to the local IP (127.0.0.1).
zh_HANS-CN: 只将 Web 服务器绑定到本地 IP（127.0.0.1）。

note: type: Plain text
en: The HTTP daemon command-line that will be executed.  Command-line options may be specified here, and the configuration file will be added at the end of the command-line.  Currently apache2, lighttpd, mongoose, plackup, python and webrick are supported.  (Default: lighttpd)
zh_HANS-CN: 将被执行的 HTTP 守护程序的命令行。 命令行选项可以在这里指定，配置文件将被添加到命令行的最后。 目前支持 apache2、lighttpd、mongoose、plackup、python 和 webrick。 (默认：lighttpd)

note: type: Plain text
en: The module path (only needed if httpd is Apache).  (Default: /usr/lib/apache2/modules)
zh_HANS-CN: 模块路径（只有当 httpd 是 Apache 时才需要）。 (默认：/usr/lib/apache2/modules)

note: type: Plain text
en: The port number to bind the httpd to.  (Default: 1234)
zh_HANS-CN: 绑定 httpd 的端口号。 (默认：1234)

note: type: Plain text
en: The web browser that should be used to view the gitweb page. This will be passed to the 'git web{litdd}browse' helper script along with the URL of the gitweb instance. See linkgit:git-web{litdd}browse[1] for more information about this. If the script fails, the URL will be printed to stdout.
zh_HANS-CN: 查看 gitweb 页面时应使用的网络浏览器。这将与 gitweb 实例的 URL 一起传递给 'git web{litdd}browse' 辅助脚本。参见 linkgit:git-web{litdd}browse[1] 获取更多相关信息。如果脚本失败，URL 会被打印到标准输出流。

note: type: Plain text
en: Start the httpd instance and exit.  Regenerate configuration files as necessary for spawning a new instance.
zh_HANS-CN: 启动 httpd 实例并退出。 根据需要重新生成配置文件以生成新的实例。

note: type: Plain text
en: Stop the httpd instance and exit.  This does not generate any of the configuration files for spawning a new instance, nor does it close the browser.
zh_HANS-CN: 停止 httpd 实例并退出。 这不会生成任何用于生成新实例的配置文件，也不会关闭浏览器。

note: type: Plain text
en: Restart the httpd instance and exit.  Regenerate configuration files as necessary for spawning a new instance.
zh_HANS-CN: 重新启动 httpd 实例并退出。 根据需要重新生成配置文件以生成新的实例。

note: type: Plain text
en: You may specify configuration in your .git/config
zh_HANS-CN: 你可以在你的 .git/config 中指定配置

note: type: Plain text
en: If the configuration variable `instaweb.browser` is not set, `web.browser` will be used instead if it is defined. See linkgit:git-web{litdd}browse[1] for more information about this.
zh_HANS-CN: 如果配置变量 `instaweb.browser` 没有设置，如果定义了 `web.browser`，将使用它来代替。参见 linkgit:git-web{litdd}browse[1] 以了解更多相关信息。

note: type: Plain text
en: git-interpret-trailers - Add or parse structured information in commit messages
zh_HANS-CN: git-interpret-trailers - 添加或解析提交消息中的结构化信息

note: type: Plain text
en: 'git interpret-trailers' [--in-place] [--trim-empty]
    			[(--trailer <token>[(=|:)<value>])...]
    			[--parse] [<file>...]
zh_HANS-CN: 'git interpret-trailers' [--in-place] [--trim-empty]
    			[(--trailer <token>[(=|:)<值>])...]
    			[--parse] [<文件>...]

note: type: delimited block -
en: Lorem ipsum dolor sit amet, consectetur adipiscing elit.
zh_HANS-CN: Lorem ipsum dolor sit amet, consectetur adipiscing elit. 乱序拉丁文，作为占位符使用，无任何意义

note: type: Plain text
en: the last two lines starting with "Signed-off-by" are trailers.
zh_HANS-CN: 以 "Signed-off-by" 开头的最后两行是尾注。

note: type: Plain text
en: This command can also operate on the output of linkgit:git-format-patch[1], which is more elaborate than a plain commit message. Namely, such output includes a commit message (as above), a "---" divider line, and a patch part.  For these inputs, the divider and patch parts are not modified by this command and are emitted as is on the output, unless `--no-divider` is specified.
zh_HANS-CN: 这条命令也可以处理 linkgit:git-format-patch[1] 的输出，它比普通的提交信息更复杂。也就是说，这种输出包括提交信息（如上所述）、"---" 分隔线和补丁部分。 对于这些输入，除非指定了 `---no-divider`，否则分隔线和补丁部分不会被此命令修改，而是原样输出。

note: type: Plain text
en: This means that the trimmed <token> and <value> will be separated by `': '` (one colon followed by one space). For convenience, the <token> can be a shortened string key (e.g., "sign") instead of the full string which should appear before the separator on the output (e.g., "Signed-off-by"). This can be configured using the 'trailer.<token>.key' configuration variable.
zh_HANS-CN: 这意味着修剪后的 <token> 和 <value> 将用 `': '`（一个冒号后加一个空格）分隔。为方便起见，<token> 可以是缩短的字符串关键字（如 "sign"），而不是完整的字符串，完整的字符串应出现在输出分隔符之前（如 "Signed-off-by"）。这可以使用 'trailer.<token>.key ' 配置变量进行配置。

note: type: delimited block -
en: token: This is a very long value, with spaces and
      newlines in it.
zh_HANS-CN: token: This is a very long value, with spaces and
      newlines in it. （这是一个很长的值，包括空格和换行符）

note: type: Plain text
en: Edit the files in place.
zh_HANS-CN: 在原地编辑文件。

note: type: Plain text
en: Specify where all new trailers will be added.  A setting provided with '--where' overrides all configuration variables and applies to all '--trailer' options until the next occurrence of '--where' or '--no-where'. Possible values are `after`, `before`, `end` or `start`.
zh_HANS-CN: 指定所有新尾注的添加位置。 '--where' 提供的设置将覆盖所有配置变量并应用于所有 '--trailer' 选项，直到下一次出现 '--where' 或 '--no-where'。可能的值为 `after`、`before`、`end` 或 `start`。

note: type: Plain text
en: Output only the trailers, not any other parts of the input.
zh_HANS-CN: 只输出尾注，不输出输入的任何其他部分。

note: type: Plain text
en: Output only trailers that exist in the input; do not add any from the command-line or by following configured `trailer.*` rules.
zh_HANS-CN: 只输出输入中存在的尾注；不要从命令行或按照配置的 `trailer.*` 规则添加任何尾注。

note: type: Plain text
en: Remove any whitespace-continuation in trailers, so that each trailer appears on a line by itself with its full content.
zh_HANS-CN: 移除尾注中的任何空格，以便每个尾注都能以其完整的内容出现在一行中。

note: type: Plain text
en: A convenience alias for `--only-trailers --only-input --unfold`.
zh_HANS-CN: `--only-trailers --only-input --unfold` 的别名。

note: type: Plain text
en: Do not treat `---` as the end of the commit message. Use this when you know your input contains just the commit message itself (and not an email or the output of `git format-patch`).
zh_HANS-CN: 不要把 `---` 当作提交信息的结尾。当你知道你的输入只包含提交信息本身（而不是电子邮件或 `git format-patch` 的输出）时，请使用这个方法。

note: type: Plain text
en: This option tells which characters are recognized as trailer separators. By default only ':' is recognized as a trailer separator, except that '=' is always accepted on the command line for compatibility with other git commands.
zh_HANS-CN: 这个选项告诉我们哪些字符可以被识别为尾注分隔符。默认情况下，只有 ':' 被识别为尾注分隔符，但为了与其他 git 命令兼容，命令行上总是接受 '='。

note: type: Plain text
en: The first character given by this option will be the default character used when another separator is not specified in the config for this trailer.
zh_HANS-CN: 当这个尾注的配置中没有指定其他分隔符时，这个选项给出的第一个字符将是默认使用的字符。

note: type: Plain text
en: For example, if the value for this option is "%=$", then only lines using the format '<token><sep><value>' with <sep> containing '%', '=' or '$' and then spaces will be considered trailers. And '%' will be the default separator used, so by default trailers will appear like: '<token>% <value>' (one percent sign and one space will appear between the token and the value).
zh_HANS-CN: 例如，如果这个选项的值是 "%=$"，那么只有使用 '<token><sep><value>' 格式的行，<sep> 包含 '%'、'=' 或 '$'，然后是空格，才会被视为尾注。而 '%' 将是默认使用的分隔符，所以默认情况下，尾注会出现如下情况： '<token>% <value>' （一个百分号和一个空格将出现在标记和值之间）。

note: type: Plain text
en: This option tells where a new trailer will be added.
zh_HANS-CN: 这个选项告诉人们新的尾注将被添加到哪里。

note: type: Plain text
en: This can be `end`, which is the default, `start`, `after` or `before`.
zh_HANS-CN: 默认是 `end`，也可以是 `start`，`after` 或 `before`。

note: type: Plain text
en: If it is `end`, then each new trailer will appear at the end of the existing trailers.
zh_HANS-CN: 如果它是 `end`，那么每个新的拖车将出现在现有拖车的末尾。

note: type: Plain text
en: If it is `start`, then each new trailer will appear at the start, instead of the end, of the existing trailers.
zh_HANS-CN: 如果是 `start`，那么每个新尾注将出现在现有尾注的开端，而不是结尾。

note: type: Plain text
en: If it is `after`, then each new trailer will appear just after the last trailer with the same <token>.
zh_HANS-CN: 如果是 `after`，那么每个新的尾注将出现在具有相同 <token> 的最后一个尾注之后。

note: type: Plain text
en: If it is `before`, then each new trailer will appear just before the first trailer with the same <token>.
zh_HANS-CN: 如果是 `before`，那么每个新的尾注将出现在具有相同 <token> 的第一个尾注之前。

note: type: Plain text
en: The valid values for this option are: `addIfDifferentNeighbor` (this is the default), `addIfDifferent`, `add`, `replace` or `doNothing`.
zh_HANS-CN: 这个选项的有效值是： `addIfDifferentNeighbor`（这是默认值），`addIfDifferent`，`add`，`replace` 或 `doNothing`。

note: type: Plain text
en: With `addIfDifferentNeighbor`, a new trailer will be added only if no trailer with the same (<token>, <value>) pair is above or below the line where the new trailer will be added.
zh_HANS-CN: 使用 `addIfDifferentNeighbor`，只有在没有相同（<token>, <value>）的尾注对在新尾注的上方或下方，才会添加新的尾注。

note: type: Plain text
en: With `replace`, an existing trailer with the same <token> will be deleted and the new trailer will be added. The deleted trailer will be the closest one (with the same <token>) to the place where the new one will be added.
zh_HANS-CN: 使用 `replace`，一个具有相同 <token> 的现有尾注将被删除，新的尾注将被添加。被删除的尾注将是离新尾注位置最近的一个（具有相同的<token>）。

note: type: Plain text
en: The valid values for this option are: `add` (this is the default) and `doNothing`.
zh_HANS-CN: 这个选项的有效值是： `add`（这是默认值）和 `doNothing`。

note: type: Plain text
en: With `add`, a new trailer will be added.
zh_HANS-CN: 使用 `add`，一个新的尾注将被添加。

note: type: Plain text
en: With `doNothing`, nothing will be done.
zh_HANS-CN: 有了 `doNothing`，就不会有任何事情发生。

note: type: Plain text
en: This `key` will be used instead of <token> in the trailer. At the end of this key, a separator can appear and then some space characters. By default the only valid separator is ':', but this can be changed using the `trailer.separators` config variable.
zh_HANS-CN: 这个 `key` 将被用来代替尾注中的 <token>。在这个键的末端，可以出现一个分隔符，然后是一些空格字符。默认情况下，唯一有效的分隔符是 ':'，但这可以通过 `trailer.separators` 配置变量来改变。

note: type: Plain text
en: If there is a separator, then the key will be used instead of both the <token> and the default separator when adding the trailer.
zh_HANS-CN: 如果有一个分隔符，那么在添加尾注时，将使用该键而不是 <token> 和默认的分隔符。

note: type: Plain text
en: This option takes the same values as the 'trailer.where' configuration variable and it overrides what is specified by that option for trailers with the specified <token>.
zh_HANS-CN: 这个选项与 'trailer.where' 配置变量的取值相同，对于指定 <token> 的尾注，它覆盖了该选项所指定的内容。

note: type: Plain text
en: This option takes the same values as the 'trailer.ifexists' configuration variable and it overrides what is specified by that option for trailers with the specified <token>.
zh_HANS-CN: 这个选项与 'trailer.ifexists' 配置变量的取值相同，对于具有指定 <token> 的尾注，它覆盖了该选项所指定的内容。

note: type: Plain text
en: This option takes the same values as the 'trailer.ifmissing' configuration variable and it overrides what is specified by that option for trailers with the specified <token>.
zh_HANS-CN: 这个选项与'trailer.ifmissing' 配置变量的取值相同，对于指定 <token> 的尾注，它覆盖该选项所指定的内容。

note: type: Plain text
en: When both 'trailer.<token>.cmd' and 'trailer.<token>.command' are given for the same <token>, 'trailer.<token>.cmd' is used and 'trailer.<token>.command' is ignored.
zh_HANS-CN: 当'trailer.<token>.cmd' 和 'trailer.<token>.command' 都是针对同一个 <token> 给出的时候，使用 'trailer.<token>.cmd'，'trailer.<token>.command' 被忽略。

note: type: Plain text
en: When the specified command is first called to add a trailer with the specified <token>, the behavior is as if a special '--trailer <token>=<value>' argument was added at the beginning of the "git interpret-trailers" command, where <value> is taken to be the standard output of the command with any leading and trailing whitespace trimmed off.
zh_HANS-CN: 当第一次调用指定的命令来添加带有指定 <token> 的尾注时，其行为就像在 "git interpret-trailers" 命令的开头添加了一个特殊的 '-trailer <token>=<value>' 参 数，其中 <value> 被认为是该命令的标准输出，其前面和后面的空白被修剪掉。

note: type: Plain text
en: If some '--trailer <token>=<value>' arguments are also passed on the command line, the command is called again once for each of these arguments with the same <token>. And the <value> part of these arguments, if any, will be passed to the command as its first argument. This way the command can produce a <value> computed from the <value> passed in the '--trailer <token>=<value>' argument.
zh_HANS-CN: 如果在命令行中还传递了一些 '--trailer <token>=<value>' 参数，那么对于这些参数中的每一个，都会以相同的 <token> 再次调用该命令。而这些参数的 <value>部分，如果有的话，将作为第一个参数传递给命令。这样，命令可以产生一个从 '--trailer <token>=<value>' 参数中传递的 <value> 计算出来的 <value>。

note: type: delimited block -
en: body text
zh_HANS-CN: 正文

note: type: Plain text
en: Extract the last commit as a patch, and add a 'Cc' and a 'Reviewed-by' trailer to it:
zh_HANS-CN: 将最后一次提交的内容提取为补丁，并在其中加入 'Cc' 和 'Reviewed-by' 尾注：

note: type: Plain text
en: Configure a 'sign' trailer with a command to automatically add a 'Signed-off-by: ' with the author information only if there is no 'Signed-off-by: ' already, and show how it works:
zh_HANS-CN: 配置一个带有命令的 'sign' 拖车，只有在没有 'Signed-off-by: ' 的情况下，才会自动添加带有作者信息的 'Signed-off-by: ' ，以下展示它是如何工作的：

note: type: Plain text
en: Configure a 'fix' trailer with a key that contains a '#' and no space after this character, and show how it works:
zh_HANS-CN: 配置一个 'fix' 尾注，其关键是包含一个 '#'，并且这个字符后面没有空格，以下展示它是如何工作的：

note: type: Plain text
en: Configure a 'help' trailer with a cmd use a script `glog-find-author` which search specified author identity from git log in git repository and show how it works:
zh_HANS-CN: 在 cmd 中使用脚本 `glog-find-author` 配置一个 'help' 尾注，从 git 仓库的 git日志中搜索指定的作者身份，以下展示它是如何工作的：

note: type: Plain text
en: Configure a 'ref' trailer with a cmd use a script `glog-grep` to grep last relevant commit from git log in the git repository and show how it works:
zh_HANS-CN: 在 cmd 中用脚本 `glog-grep` 从git仓库的git日志中搜索最后一次相关的提交并配置一个 'ref' 尾注，以下展示它是如何工作的：

note: type: Plain text
en: Configure a 'see' trailer with a command to show the subject of a commit that is related, and show how it works:
zh_HANS-CN: 配置一个带有命令的 'see' 尾注，以显示相关提交的主题，以下展示它是如何工作的：

note: type: Plain text
en: Configure a commit template with some trailers with empty values (using sed to show and keep the trailing spaces at the end of the trailers), then configure a commit-msg hook that uses 'git interpret-trailers' to remove trailers with empty values and to add a 'git-version' trailer:
zh_HANS-CN: 配置一个带有一些空尾注的提交模板（使用 sed 来显示并保留尾注末尾的空格），然后配置一个 commit-msg 钩子，使用 'git interpret-trailers' 来移除空值尾注，并添加一个 'git-version' 尾注：

note: type: Plain text
en: git-log - Show commit logs
zh_HANS-CN: git-log - 显示提交日志

note: type: Plain text
en: Shows the commit logs.
zh_HANS-CN: 显示提交日志。

note: type: Plain text
en: The command takes options applicable to the linkgit:git-rev-list[1] command to control what is shown and how, and options applicable to the linkgit:git-diff[1] command to control how the changes each commit introduces are shown.
zh_HANS-CN: 该命令采用适用于 linkgit:git-rev-list[1] 命令的选项来控制显示的内容和方式，以及适用于 linkgit:git-diff[1] 命令的选项来控制每次提交引入的更改的显示方式。

note: type: Plain text
en: Continue listing the history of a file beyond renames (works only for a single file).
zh_HANS-CN: 继续列出文件的历史记录，包括重命名之后的情况（仅适用于单个文件）。

note: type: Plain text
en: Print out the ref names of any commits that are shown. If 'short' is specified, the ref name prefixes 'refs/heads/', 'refs/tags/' and 'refs/remotes/' will not be printed. If 'full' is specified, the full ref name (including prefix) will be printed. If 'auto' is specified, then if the output is going to a terminal, the ref names are shown as if 'short' were given, otherwise no ref names are shown. The option `--decorate` is short-hand for `--decorate=short`.  Default to configuration value of `log.decorate` if configured, otherwise, `auto`.
zh_HANS-CN: 打印显示的任何提交的引用名称。如果指定了 "short"，则不会打印引用名称的前缀 "refs/heads/"、"refs/tags/" 和 "refs/remotes/"。如果指定了 "full"，将打印完整的引用名称（包括前缀）。如果指定了 "auto"，则如果输出是发送到终端，则显示引用名称，就如同指定了"short"一样，否则不显示引用名称。选项 `--decorate` 是 `--decorate=short` 的简写。如果配置了 `log.decorate` 的配置值，默认为配置值，否则为 "auto"。

note: type: Plain text
en: For each candidate reference, do not use it for decoration if it matches any patterns given to `--decorate-refs-exclude` or if it doesn't match any of the patterns given to `--decorate-refs`. The `log.excludeDecoration` config option allows excluding refs from the decorations, but an explicit `--decorate-refs` pattern will override a match in `log.excludeDecoration`.
zh_HANS-CN: 对于每个候选引用，在以下情况下不要将其用于装饰（decorate）：若它与`--decorate-refs-exclude`指定的任何模式匹配，或者若它不与`--decorate-refs`指定的任何模式匹配。配置选项`log.excludeDecoration`允许从装饰中排除引用，但是在`log.excludeDecoration`中的匹配项将被`--decorate-refs`模式中的显式指定所覆盖。

note: type: Plain text
en: If none of these options or config settings are given, then references are used as decoration if they match `HEAD`, `refs/heads/`, `refs/remotes/`, `refs/stash/`, or `refs/tags/`.
zh_HANS-CN: 如果没有给出这些选项或配置设置中的任何一个，那么如果引用与 `HEAD` 、`refs/heads/`、`refs/remotes/` 、`refs/stash/` 或 `refs/tags/` 匹配，则使用引用作为装饰。

note: type: Plain text
en: When specified, this option clears all previous `--decorate-refs` or `--decorate-refs-exclude` options and relaxes the default decoration filter to include all references. This option is assumed if the config value `log.initialDecorationSet` is set to `all`.
zh_HANS-CN: 当指定了该选项时，它会清除所有先前的 `--decorate-refs` 或 `--decorate-refs-exclude` 选项，并放宽默认的装饰过滤器以包括所有引用。如果配置值 `log.initialDecorationSet` 设置为 `all`，则假定使用此选项。

note: type: Plain text
en: Print out the ref name given on the command line by which each commit was reached.
zh_HANS-CN: 打印出通过命令行给定的引用名称，以便触及每个提交。

note: type: Plain text
en: Use mailmap file to map author and committer names and email addresses to canonical real names and email addresses. See linkgit:git-shortlog[1].
zh_HANS-CN: 使用 mailmap 文件将作者和提交者的名称和电子邮件地址映射到规范的真实名称和电子邮件地址。请参阅 linkgit:git-shortlog[1]。

note: type: Plain text
en: Without this flag, `git log -p <path>...` shows commits that touch the specified paths, and diffs about the same specified paths.  With this, the full diff is shown for commits that touch the specified paths; this means that "<path>..." limits only commits, and doesn't limit diff for those commits.
zh_HANS-CN: 如果不使用此标志， `git log -p <path>...` 将显示与指定路径相关的提交，并显示关于相同指定路径的差异。使用此标志，将显示与指定路径相关的提交的完整差异；这意味着 "<path>..." 将仅限定提交，并不限定这些提交的差异。

note: type: Plain text
en: Note that this affects all diff-based output types, e.g. those produced by `--stat`, etc.
zh_HANS-CN: 请注意，这会影响所有基于差异的输出类型。例如：由 `--stat` 等产生的输出。

note: type: Plain text
en: Include a line ``log size <number>'' in the output for each commit, where <number> is the length of that commit's message in bytes.  Intended to speed up tools that read log messages from `git log` output by allowing them to allocate space in advance.
zh_HANS-CN: 在每个提交的输出中包含一行 ``log size <number>"" ，其中 <number> 是该提交消息的字节长度。旨在通过允许工具预先分配空间，加快从 `git log` 输出中读取日志消息的工具的速度。

note: type: Plain text
en: Show only commits in the specified revision range.  When no <revision-range> is specified, it defaults to `HEAD` (i.e. the whole history leading to the current commit).  `origin..HEAD` specifies all the commits reachable from the current commit (i.e. `HEAD`), but not from `origin`. For a complete list of ways to spell <revision-range>, see the 'Specifying Ranges' section of linkgit:gitrevisions[7].
zh_HANS-CN: 仅显示指定修订范围内的提交。当没有指定 <revision-range> 时，默认为 `HEAD`（即导致当前提交的整个历史记录）。`origin..HEAD` 指定从当前提交（即 `HEAD` ）可达的所有提交，但不包括从 `origin` 可达的提交。有关拼写 <revision-range> 的完整列表，请参阅 linkgit:gitrevisions[7] 的 "Specifying Ranges" 部分。

note: type: Plain text
en: Show only commits that are enough to explain how the files that match the specified paths came to be.  See 'History Simplification' below for details and other simplification modes.
zh_HANS-CN: 只显示那些足以解释符合指定路径的文件是如何形成的提交。  有关细节和其他简化模式，请参见下面的'历史简化'。

note: type: Plain text
en: Paths may need to be prefixed with `--` to separate them from options or the revision range, when confusion arises.
zh_HANS-CN: 当出现混淆时，路径可能需要以`--`为前缀，以便将其与选项或修订范围分开。

note: type: Title -
en: DIFF FORMATTING
zh_HANS-CN: 差异格式化

note: type: Plain text
en: By default, `git log` does not generate any diff output. The options below can be used to show the changes made by each commit.
zh_HANS-CN: 默认情况下，`git log`不会产生任何差异输出。下面的选项可以用来显示每次提交所做的修改。

note: type: Plain text
en: Note that unless one of `--diff-merges` variants (including short `-m`, `-c`, and `--cc` options) is explicitly given, merge commits will not show a diff, even if a diff format like `--patch` is selected, nor will they match search options like `-S`. The exception is when `--first-parent` is in use, in which case `first-parent` is the default format.
zh_HANS-CN: 注意，除非明确给出`--diff-merges`的变体（包括短的`-m`，`-c`和`-cc`选项），否则合并提交不会显示差异，即使选择了`--patch`这样的差异格式，也不会匹配`-S`这样的搜索选项。例外情况是当`--first-parent`被使用时，在这种情况下，`first-parent`是默认格式。

note: type: Labeled list
en: `git log --no-merges`
zh_HANS-CN: `git log --no-merges`。

note: type: Plain text
en: Show the whole commit history, but skip any merges
zh_HANS-CN: 显示整个提交历史，但跳过任何合并内容

note: type: Plain text
en: Show all commits since version 'v2.6.12' that changed any file in the `include/scsi` or `drivers/scsi` subdirectories
zh_HANS-CN: 显示自版本'v2.6.12'以来改变`include/scsi`或`drivers/scsi`子目录中任何文件的所有提交。

note: type: Labeled list
en: `git log --since="2 weeks ago" -- gitk`
zh_HANS-CN: `git log --since="2 weeks ago" -- gitk`。

note: type: Plain text
en: Show the changes during the last two weeks to the file 'gitk'.  The `--` is necessary to avoid confusion with the *branch* named 'gitk'
zh_HANS-CN: 显示过去两周内对文件'gitk'的修改。  `--`是必要的，以避免与名为'gitk'的*分支相混淆。

note: type: Plain text
en: Show the commits that are in the "test" branch but not yet in the "release" branch, along with the list of paths each commit modifies.
zh_HANS-CN: 显示在 "test "分支中但尚未在 "release "分支中的提交，以及每个提交修改的路径列表。

note: type: Labeled list
en: `git log --follow builtin/rev-list.c`
zh_HANS-CN: `git log --follow builtin/rev-list.c`。

note: type: Plain text
en: Shows the commits that changed `builtin/rev-list.c`, including those commits that occurred before the file was given its present name.
zh_HANS-CN: 显示改变`builtin/rev-list.c`的提交，包括那些在文件被赋予现在名字之前发生的提交。

note: type: Labeled list
en: `git log --branches --not --remotes=origin`
zh_HANS-CN: `git log --branches --not --remotes=origin`。

note: type: Plain text
en: Shows all commits that are in any of local branches but not in any of remote-tracking branches for 'origin' (what you have that origin doesn't).
zh_HANS-CN: 显示所有在本地分支中但不在 "origin "的远程跟踪分支中的提交（你有而origin没有的东西）。

note: type: Labeled list
en: `git log master --not --remotes=*/master`
zh_HANS-CN: `git log master --not --remotes=*/master`。

note: type: Plain text
en: Shows all commits that are in local master but not in any remote repository master branches.
zh_HANS-CN: 显示所有在本地主库但不在任何远程仓库主库分支中的提交。

note: type: Labeled list
en: `git log -p -m --first-parent`
zh_HANS-CN: `git log -p -m -first-parent`。

note: type: Plain text
en: Shows the history including change diffs, but only from the ``main branch'' perspective, skipping commits that come from merged branches, and showing full diffs of changes introduced by the merges.  This makes sense only when following a strict policy of merging all topic branches when staying on a single integration branch.
zh_HANS-CN: 显示包括变化差异的历史，但只从 "主分支 "的角度，跳过来自合并分支的提交，并显示合并带来的全部变化差异。  这只有在遵循严格的政策，在停留在一个集成分支时合并所有主题分支时才有意义。

note: type: Labeled list
en: `git log -L '/int main/',/^}/:main.c`
zh_HANS-CN: `git log -L '/int main/',/^}/:main.c`。

note: type: Plain text
en: Shows how the function `main()` in the file `main.c` evolved over time.
zh_HANS-CN: 显示了文件`main.c`中的函数`main()`是如何随时间演变的。

note: type: Plain text
en: Limits the number of commits to show to 3.
zh_HANS-CN: 将显示的提交数量限制在3个。

note: type: Plain text
en: See linkgit:git-config[1] for core variables and linkgit:git-diff[1] for settings related to diff generation.
zh_HANS-CN: 核心变量见 linkgit:git-config[1] ，与 diff 生成相关的设置见 linkgit:git-diff[1] 。

note: type: Plain text
en: Default for the `--format` option.  (See 'Pretty Formats' above.)  Defaults to `medium`.
zh_HANS-CN: `--format`选项的默认值。  (见上面的 "漂亮的格式"。)默认为 "中等"。

note: type: Plain text
en: Encoding to use when displaying logs.  (See 'Discussion' above.)  Defaults to the value of `i18n.commitEncoding` if set, and UTF-8 otherwise.
zh_HANS-CN: 显示日志时要使用的编码。  (见上面的 "讨论"。)如果设置了，默认为`i18n.commitEncoding`的值，否则为UTF-8。

note: type: Plain text
en: Displays references available in a remote repository along with the associated commit IDs.
zh_HANS-CN: 显示远程版本库中可用的引用以及相关的提交 ID。

note: type: Plain text
en: Limit to only refs/heads and refs/tags, respectively.  These options are _not_ mutually exclusive; when given both, references stored in refs/heads and refs/tags are displayed.  Note that `git ls-remote -h` used without anything else on the command line gives help, consistent with other git subcommands.
zh_HANS-CN: 分别限制在 refs/heads 和 refs/tags。 这些选项不是相互排斥的；当两个选项都给出时，存储在 refs/heads 和 refs/tags 中的引用会被显示。 注意，`git ls-remote -h` 在命令行中不使用任何其他东西，就会提供帮助，与其他 git 子命令一致。

note: type: Plain text
en: Do not show peeled tags or pseudorefs like `HEAD` in the output.
zh_HANS-CN: 在输出中不显示剥离的标签或像 `HEAD` 这样的伪引用。

note: type: Plain text
en: Do not print remote URL to stderr.
zh_HANS-CN: 不将远程 URL 打印到标准错误流。

note: type: Plain text
en: Specify the full path of 'git-upload-pack' on the remote host. This allows listing references from repositories accessed via SSH and where the SSH daemon does not use the PATH configured by the user.
zh_HANS-CN: 指定远程主机上 'git-upload-pack' 的完整路径。这允许列出通过 SSH 访问的存储库的引用，而且 SSH 守护程序不使用用户配置的 PATH。

note: type: Plain text
en: Exit with status "2" when no matching refs are found in the remote repository. Usually the command exits with status "0" to indicate it successfully talked with the remote repository, whether it found any matching refs.
zh_HANS-CN: 当在远程版本库中没有找到匹配的引用时，以状态 "2" 退出。通常该命令以状态 "0" 退出，表示它成功地与远程版本库进行了对话，无论是否找到了匹配的引用。

note: type: Plain text
en: Expand the URL of the given remote repository taking into account any "url.<base>.insteadOf" config setting (See linkgit:git-config[1]) and exit without talking to the remote.
zh_HANS-CN: 考虑任何 "url.<base>.insteadOf" 的配置设置（见linkgit:git-config[1]），展开给定的远程仓库的URL，然后退出，不与远程对话。

note: type: Plain text
en: In addition to the object pointed by it, show the underlying ref pointed by it when showing a symbolic ref.  Currently, upload-pack only shows the symref HEAD, so it will be the only one shown by ls-remote.
zh_HANS-CN: 除了它所指向的对象之外，在显示一个符号引用时，还要显示它所指向的底层引用。 目前，upload-pack 只显示符号引用HEAD，所以它将是 ls-remote 显示的唯一对象。

note: type: Plain text
en: Sort based on the key given. Prefix `-` to sort in descending order of the value. Supports "version:refname" or "v:refname" (tag names are treated as versions). The "version:refname" sort order can also be affected by the "versionsort.suffix" configuration variable.  See linkgit:git-for-each-ref[1] for more sort options, but be aware keys like `committerdate` that require access to the objects themselves will not work for refs whose objects have not yet been fetched from the remote, and will give a `missing object` error.
zh_HANS-CN: 根据给定的键进行排序。前缀 `-` 以数值的降序来排序。支持 "version:refname" 或 "v:refname"（标签名被视为版本）。"version:refname" 的排序顺序也可以由 "versionort.suffix" 配置的变量影响。 见 linkgit:git-for-each-ref[1] 以获得更多的排序选项，但要注意像 `committerdate` 这样需要访问对象本身的键，对对象尚未从远程获取的引用不起作用，并会出现 `missing object` 的错误。

note: type: Plain text
en: Transmit the given string to the server when communicating using protocol version 2.  The given string must not contain a NUL or LF character.  When multiple `--server-option=<option>` are given, they are all sent to the other side in the order listed on the command line.
zh_HANS-CN: 当使用协议版本2进行通信时，将给定的字符串传输给服务器。 给定的字符串不能包含 NUL 或 LF 字符。 当给出多个 `--server-option=<option>` 时，它们将按照命令行中列出的顺序全部发送给对方。

note: type: Plain text
en: The "remote" repository to query.  This parameter can be either a URL or the name of a remote (see the GIT URLS and REMOTES sections of linkgit:git-fetch[1]).
zh_HANS-CN: 要查询的 "远程" 版本库。 这个参数可以是一个 URL，也可以是一个远程的名称（见 linkgit:git-fetch[1] 的 GIT URLS 和远端部分）。

note: type: Plain text
en: When unspecified, all references, after filtering done with --heads and --tags, are shown.  When <patterns>... are specified, only references matching one or more of the given patterns are displayed. Each pattern is interpreted as a glob (see `glob` in linkgit:gitglossary[7]) which is matched against the "tail" of a ref, starting either from the start of the ref (so a full name like `refs/heads/foo` matches) or from a slash separator (so `bar` matches `refs/heads/bar` but not `refs/heads/foobar`).
zh_HANS-CN: 当未指定时，在用 --heads 和 --tags 过滤后，所有引用都会被显示。 当 <patterns>... 被指定时，只显示匹配一个或多个给定模式的引用。每个模式都被解释为一个 glob（见 linkgit:gitglossary[7] 中的 `glob`），它与引用的 "尾巴" 相匹配，从引用的开头开始（所以像 `refs/heads/foo` 这样的全名匹配）或者从斜线分隔符开始（所以 `bar` 匹配 `refs/heads/bar`，而不是 `refs/heads/foobar`）。

note: type: Plain text
en: When showing an annotated tag, unless `--refs` is given, two such lines are shown: one with the refname for the tag itself as `<ref>`, and another with `<ref>` followed by `^{}`. The `<oid>` on the latter line shows the name of the object the tag points at.
zh_HANS-CN: 在显示注释标记时，除非给出 `--refs`，否则会显示两行：一行是标记本身的参考名 `<ref>`，另一行是 `<ref>` 后跟 `^{}`。后一行的 `<oid>` 显示的是标签指向的对象名称。

note: type: Plain text
en: List all references (including symbolics and pseudorefs), peeling tags:
zh_HANS-CN: 列出所有引用（包括符号和伪引用），剥离标签：

note: type: Plain text
en: git-mailinfo - Extracts patch and authorship from a single e-mail message
zh_HANS-CN: git-mailinfo - 从单个电子邮件信息中提取补丁和作者

note: type: Plain text
en: Reads a single e-mail message from the standard input, and writes the commit log message in <msg> file, and the patches in <patch> file.  The author name, e-mail and e-mail subject are written out to the standard output to be used by 'git am' to create a commit.  It is usually not necessary to use this command directly.  See linkgit:git-am[1] instead.
zh_HANS-CN: 从标准输入中读取一条电子邮件，并将提交日志信息写入<msg> 文件，将补丁写入<patch>文件。 作者姓名、电子邮件和电子邮件主题会被写到标准输出，以便被 'git am' 用来创建一个提交。 通常没有必要直接使用这个命令。 请参见 linkgit:git-am[1]。

note: type: Plain text
en: Usually the program removes email cruft from the Subject: header line to extract the title line for the commit log message.  This option prevents this munging, and is most useful when used to read back 'git format-patch -k' output.
zh_HANS-CN: 通常情况下，程序会从Subject: header  行中删除电子邮件的残余部分，以提取提交日志信息的标题行。 这个选项可以防止这种删除，在用于回读 'git format-patch -k' 输出时最有用。

note: type: Plain text
en: Specifically, the following are removed until none of them remain:
zh_HANS-CN: 具体来说，以下内容会被删除，直到一个都不剩：

note: type: Plain text
en: Leading and trailing whitespace.
zh_HANS-CN: 前导和尾部的多余空白字符。

note: type: Plain text
en: Leading `Re:`, `re:`, and `:`.
zh_HANS-CN: 前导的的 `Re:`，`re:`，和 `:`。

note: type: Plain text
en: Leading bracketed strings (between `[` and `]`, usually
zh_HANS-CN: 前导括号内的字符串（在 `[` 和 `]` 之间，通常是

note: type: Plain text
en: `[PATCH]`).
zh_HANS-CN: `[PATCH]`）。

note: type: Plain text
en: Finally, runs of whitespace are normalized to a single ASCII space character.
zh_HANS-CN: 最后，空格被规范化为一个ASCII空格字符。

note: type: Plain text
en: When -k is not in effect, all leading strings bracketed with '[' and ']' pairs are stripped.  This option limits the stripping to only the pairs whose bracketed string contains the word "PATCH".
zh_HANS-CN: 当-k 不生效时，所有用 '[' 和 ']' 对括起来的前导字符串都被剥离。 这个选项限制了剥离的范围，只限于括号内的字符串包含 "PATCH " 一词的对括号。

note: type: Plain text
en: The commit log message, author name and author email are taken from the e-mail, and after minimally decoding MIME transfer encoding, re-coded in the charset specified by `i18n.commitEncoding` (defaulting to UTF-8) by transliterating them.  This used to be optional but now it is the default.
zh_HANS-CN: 提交日志信息、作者姓名和作者的电子邮件来自电子邮件，在对 MIME 传输编码进行最小化解码后，通过音译将其重新编码为 `i18n.commitEncoding` 指定的字符集（默认为 UTF-8）。 这曾经是可选的，但现在是默认的。

note: type: Plain text
en: Note that the patch is always used as-is without charset conversion, even with this flag.
zh_HANS-CN: 注意，即使有这个标志，补丁也总是按原样使用，不进行字符集转换。

note: type: Plain text
en: Similar to -u.  But when re-coding, the charset specified here is used instead of the one specified by `i18n.commitEncoding` or UTF-8.
zh_HANS-CN: 与 -u 类似。 但在重新编码时，使用这里指定的字符集，而不是 `i18n.commitEncoding` 或 UTF-8 所指定的。

note: type: Plain text
en: Disable all charset re-coding of the metadata.
zh_HANS-CN: 禁用元数据的所有字符集重新编码。

note: type: Plain text
en: Copy the Message-ID header at the end of the commit message.  This is useful in order to associate commits with mailing list discussions.
zh_HANS-CN: 复制提交信息末尾的 Message-ID 头。 这对于将提交与邮件列表讨论联系起来是很有用的。

note: type: Plain text
en: Remove everything in body before a scissors line (e.g. "-- >8 --").  The line represents scissors and perforation marks, and is used to request the reader to cut the message at that line.  If that line appears in the body of the message before the patch, everything before it (including the scissors line itself) is ignored when this option is used.
zh_HANS-CN: 删除正文中剪刀线之前的所有内容（如"-->8--"）。 这条线代表剪刀和打孔的标记，用来要求读者在该线处剪切信息。 如果该行出现在邮件正文中的补丁之前，当使用该选项时，它之前的所有内容（包括剪刀线本身）都会被忽略。

note: type: Plain text
en: This is useful if you want to begin your message in a discussion thread with comments and suggestions on the message you are responding to, and to conclude it with a patch submission, separating the discussion and the beginning of the proposed commit log message with a scissors line.
zh_HANS-CN: 如果你想在讨论线中开始你的信息，对你所回应的信息提出评论和建议，并以提交补丁作为结束，用剪刀线把讨论和建议的提交日志信息的开头分开，这很有用。

note: type: Plain text
en: This can be enabled by default with the configuration option mailinfo.scissors.
zh_HANS-CN: 这可以通过配置选项 mailinfo.scissors 来默认启用。

note: type: Plain text
en: Ignore scissors lines. Useful for overriding mailinfo.scissors settings.
zh_HANS-CN: 忽略剪切线。对于覆盖 mailinfo.scissors 设置很有用。

note: type: Plain text
en: Action when processes email messages sent with base64 or quoted-printable encoding, and the decoded lines end with a CRLF instead of a simple LF.
zh_HANS-CN: 当处理以 base64 或 quoted-printable 编码发送的电子邮件，并且解码后的行以 CRLF 而不是简单的 LF 结尾时，就会启用。

note: type: Plain text
en: The valid actions are:
zh_HANS-CN: 有效的行为是：

note: type: Plain text
en: `nowarn`: Git will do nothing when such a CRLF is found.
zh_HANS-CN: `nowarn`： 当发现这样的 CRLF 时，Git将不做任何事情。

note: type: Plain text
en: `warn`: Git will issue a warning for each message if such a CRLF is
zh_HANS-CN: `warn`： 如果有这样的 CRLF，Git 会对每条信息发出警告。

note: type: Plain text
en: found.
zh_HANS-CN: 找到了。

note: type: Plain text
en: `strip`: Git will convert those CRLF to LF.
zh_HANS-CN: `strip`： Git 将把这些 CRLF 转换为 LF。

note: type: Plain text
en: The default action could be set by configuration option `mailinfo.quotedCR`.  If no such configuration option has been set, `warn` will be used.
zh_HANS-CN: 默认动作可以通过配置选项 `mailinfo.quotedCR` 设置。 如果没有设置这样的配置选项，将使用 `warn`。

note: type: Plain text
en: The commit log message extracted from e-mail, usually except the title line which comes from e-mail Subject.
zh_HANS-CN: 从电子邮件中提取的提交日志信息，通常除了来自电子邮件主题的标题行。

note: type: Plain text
en: The patch extracted from e-mail.
zh_HANS-CN: 从电子邮件中提取的补丁。

note: type: Plain text
en: git-mailsplit - Simple UNIX mbox splitter program
zh_HANS-CN: git-mailsplit - 简单的UNIX mbox分割程序

note: type: Plain text
en: Splits a mbox file or a Maildir into a list of files: "0001" "0002" ..  in the specified directory so you can process them further from there.
zh_HANS-CN: 将一个 mbox 文件或一个 Maildir 分割成一个文件列表： "0001" "0002"...... 存放在指定的目录中，这样你就可以从那里进一步处理它们。

note: type: Plain text
en: Maildir splitting relies upon filenames being sorted to output patches in the correct order.
zh_HANS-CN: Maildir 分割依赖于文件名的排序，以便按照正确的顺序输出补丁。

note: type: Plain text
en: Mbox file to split.  If not given, the mbox is read from the standard input.
zh_HANS-CN: 要分割的 Mbox 文件。 如果没有给出，则从标准输入中读取 Mbox。

note: type: Plain text
en: Root of the Maildir to split. This directory should contain the cur, tmp and new subdirectories.
zh_HANS-CN: 要分割的 Maildir 的根目录。这个目录应该包含 cur、tmp 和新的子目录。

note: type: Plain text
en: Directory in which to place the individual messages.
zh_HANS-CN: 放置各个信息的目录。

note: type: Plain text
en: If any file doesn't begin with a From line, assume it is a single mail message instead of signaling error.
zh_HANS-CN: 如果任何文件没有以发件人行开始，就假定它是一个单一的邮件信息，而不是说这是错误。

note: type: Plain text
en: Instead of the default 4 digits with leading zeros, different precision can be specified for the generated filenames.
zh_HANS-CN: 可以为生成的文件名指定不同的精度，而不是默认的带前导零的4位数。

note: type: Plain text
en: Skip the first <nn> numbers, for example if -f3 is specified, start the numbering with 0004.
zh_HANS-CN: 跳过第一个 <nn>数字，例如如果指定了-f3，就从 0004 开始编号。

note: type: Plain text
en: Do not remove `\r` from lines ending with `\r\n`.
zh_HANS-CN: 不要从以 `\r\n` 结尾的行中删除`\r`。

note: type: Plain text
en: Input is of the "mboxrd" format and "^>+From " line escaping is reversed.
zh_HANS-CN: 输入是 "mboxrd" 格式，"^>+From" 行转义被颠倒。

note: type: Plain text
en: git-merge-one-file - The standard helper program to use with git-merge-index
zh_HANS-CN: git-merge-one-file - 与 git-merge-index 一起使用的标准辅助程序。

note: type: Plain text
en: This is the standard helper program to use with 'git merge-index' to resolve a merge after the trivial merge done with 'git read-tree -m'.
zh_HANS-CN: 这是标准的辅助程序，与 'git merge-index' 一起使用，以解决用 'git read-tree -m' 进行的琐碎合并后的合并问题。

note: type: Plain text
en: git-mergetool--lib - Common Git merge tool shell scriptlets
zh_HANS-CN: git-mergetool--lib - 常见的 Git 合并工具壳 shell 脚本程序

note: type: Plain text
en: This is not a command the end user would want to run.  Ever.  This documentation is meant for people who are studying the Porcelain-ish scripts and/or are writing new ones.
zh_HANS-CN: 这不是一个终端用户想要运行的命令。 永远不会。 这个文档是为研究 Porcelain-ish 脚本和/或正在编写新脚本的人准备的。

note: type: Plain text
en: The 'git-mergetool{litdd}lib' scriptlet is designed to be sourced (using `.`) by other shell scripts to set up functions for working with Git merge tools.
zh_HANS-CN: 'git-mergetool{litdd}lib' 脚本被设计成可以被其他 shell 脚本引用（使用 `.`），以设置与 Git 合并工具一起工作的功能。

note: type: Plain text
en: Before sourcing 'git-mergetool{litdd}lib', your script must set `TOOL_MODE` to define the operation mode for the functions listed below.  'diff' and 'merge' are valid values.
zh_HANS-CN: 在链接到 'git-mergetool{litdd}lib' 之前，你的脚本必须设置 `TOOL_MODE` 来定义下列函数的操作模式。 'diff' 和 'merge'是有效值。

note: type: Plain text
en: returns a merge tool. the return code is 1 if we returned a guessed merge tool, else 0. '$GIT_MERGETOOL_GUI' may be set to 'true' to search for the appropriate guitool.
zh_HANS-CN: 返回一个合并工具。如果我们返回一个被猜中的合并工具，返回代码为 1，否则为0。'$GIT_MERGETOOL_GUI' 可以被设置为 'true' 以搜索合适的 guitool。

note: type: Plain text
en: returns the custom command for a merge tool.
zh_HANS-CN: 返回一个合并工具的自定义命令。

note: type: Plain text
en: returns the custom path for a merge tool.
zh_HANS-CN: 返回一个合并工具的自定义路径。

note: type: Plain text
en: bring merge tool specific functions into scope so they can be used or overridden.
zh_HANS-CN: 将合并工具的特定函数带入范围，以便它们可以被使用或重写。

note: type: Plain text
en: launches a merge tool given the tool name and a true/false flag to indicate whether a merge base is present.  '$MERGED', '$LOCAL', '$REMOTE', and '$BASE' must be defined for use by the merge tool.
zh_HANS-CN: 启动一个合并工具，给定工具名称和一个 true/false 标志，表示是否存在一个合并基础。 $MERGED'， '$LOCAL'，'$REMOTE' 和 '$BASE' 必须被定义，以便由合并工具使用。

note: type: Plain text
en: 'git mergetool' [--tool=<tool>] [-y | --[no-]prompt] [<file>...]
zh_HANS-CN: 'git mergetool' [--tool=<工具>] [-y |-[no-]prompt] [<文件>...] 。

note: type: Plain text
en: Use `git mergetool` to run one of several merge utilities to resolve merge conflicts.  It is typically run after 'git merge'.
zh_HANS-CN: 使用`git mergetool`来运行几个合并工具中的一个来解决合并冲突。  它通常在 "git merge "之后运行。

note: type: Plain text
en: If one or more <file> parameters are given, the merge tool program will be run to resolve differences on each file (skipping those without conflicts).  Specifying a directory will include all unresolved files in that path.  If no <file> names are specified, 'git mergetool' will run the merge tool program on every file with merge conflicts.
zh_HANS-CN: 如果给出一个或多个<文件>参数，合并工具程序会运行以解决每个文件的差异（跳过那些没有冲突的文件）。  指定一个目录将包括该路径中所有未解决的文件。  如果没有指定<文件>名称，'git mergetool'将对每个有合并冲突的文件运行合并工具程序。

note: type: Plain text
en: Use the merge resolution program specified by <tool>.  Valid values include emerge, gvimdiff, kdiff3, meld, vimdiff, and tortoisemerge. Run `git mergetool --tool-help` for the list of valid <tool> settings.
zh_HANS-CN: 使用由<工具>指定的合并解决程序。  有效值包括 emerge、gvimdiff、kdiff3、meld、vimdiff 和 tortoisemerge。运行`git mergetool --tool-help`以获得有效的<工具>设置列表。

note: type: Plain text
en: If a merge resolution program is not specified, 'git mergetool' will use the configuration variable `merge.tool`.  If the configuration variable `merge.tool` is not set, 'git mergetool' will pick a suitable default.
zh_HANS-CN: 如果没有指定合并解决程序，'git mergetool'将使用配置变量`merge.tool`。  如果配置变量`merge.tool`没有设置，'git mergetool'将自行挑选一个合适的程序。

note: type: Plain text
en: You can explicitly provide a full path to the tool by setting the configuration variable `mergetool.<tool>.path`. For example, you can configure the absolute path to kdiff3 by setting `mergetool.kdiff3.path`. Otherwise, 'git mergetool' assumes the tool is available in PATH.
zh_HANS-CN: 你可以通过设置配置变量`mergetool.<工具>.path`来明确提供工具的完整路径。例如，你可以通过设置`mergetool.kdiff3.path`来配置kdiff3的绝对路径。否则，"git mergetool"会假定该工具在PATH中配置过。

note: type: Plain text
en: Instead of running one of the known merge tool programs, 'git mergetool' can be customized to run an alternative program by specifying the command line to invoke in a configuration variable `mergetool.<tool>.cmd`.
zh_HANS-CN: 通过在配置变量`mergetool.<工具>.cmd`中指定调用的命令行，'git mergetool'可以代替运行一个已知的合并工具程序，从而指定运行另一个程序。

note: type: Plain text
en: When 'git mergetool' is invoked with this tool (either through the `-t` or `--tool` option or the `merge.tool` configuration variable) the configured command line will be invoked with `$BASE` set to the name of a temporary file containing the common base for the merge, if available; `$LOCAL` set to the name of a temporary file containing the contents of the file on the current branch; `$REMOTE` set to the name of a temporary file containing the contents of the file to be merged, and `$MERGED` set to the name of the file to which the merge tool should write the result of the merge resolution.
zh_HANS-CN: 当'git mergetool'与该工具一起被调用时（通过`-t`或`--tool`选项或`merge.tool`配置变量），配置的命令行将被调用，`$BASE`被设置为临时文件的名称，包含合并的共同基础（如果有的话）；`$LOCAL`被设置为包含当前分支上的文件内容的临时文件名称；`$REMOTE`被设置为包含要合并文件内容的临时文件名称，以及合并工具应该将合并的结果写入`$MERGED`设置的文件中。

note: type: Plain text
en: If the custom merge tool correctly indicates the success of a merge resolution with its exit code, then the configuration variable `mergetool.<tool>.trustExitCode` can be set to `true`.  Otherwise, 'git mergetool' will prompt the user to indicate the success of the resolution after the custom tool has exited.
zh_HANS-CN: 如果自定义合并工具能够正确地用其退出代码指示合并成功，那么配置变量`mergetool.<工具>.trustExitCode`可以被设置为`true`。  否则，'git mergetool'将在用户在自定义工具退出后表明解决成功。

note: type: Plain text
en: Print a list of merge tools that may be used with `--tool`.
zh_HANS-CN: 打印出可以和"--tool"命令一起使用的merge工具列表。

note: type: Plain text
en: Don't prompt before each invocation of the merge resolution program.  This is the default if the merge resolution program is explicitly specified with the `--tool` option or with the `merge.tool` configuration variable.
zh_HANS-CN: 在每次调用合并解决程序之前不会提示。  如果用`--tool`选项或`merge.tool`配置变量明确指定了合并解决程序，默认就是这种做法。

note: type: Plain text
en: Prompt before each invocation of the merge resolution program to give the user a chance to skip the path.
zh_HANS-CN: 在每次调用合并解决程序前提示，让用户有机会跳过该路径。

note: type: Plain text
en: Process files in the order specified in the <orderfile>, which has one shell glob pattern per line.  This overrides the `diff.orderFile` configuration variable (see linkgit:git-config[1]).  To cancel `diff.orderFile`, use `-O/dev/null`.
zh_HANS-CN: 按照 <顺序文件> 中指定的顺序处理文件，每行有一个 shell匹配模式。  这会覆盖 `diff.orderFile` 配置的变量（见 linkgit:git-config[1]）。  可以使用使用 `-O/dev/null`取消 `diff.orderFile`。

note: type: Title -
en: TEMPORARY FILES
zh_HANS-CN: 临时文件

note: type: Plain text
en: `git mergetool` creates `*.orig` backup files while resolving merges.  These are safe to remove once a file has been merged and its `git mergetool` session has completed.
zh_HANS-CN: `git mergetool`在解决合并问题时创建`*.orig`备份文件。  一旦文件被合并，并且其`git mergetool`会话完成，这些文件就可以安全地删除。

note: type: Plain text
en: Setting the `mergetool.keepBackup` configuration variable to `false` causes `git mergetool` to automatically remove the backup as files are successfully merged.
zh_HANS-CN: 将`mergetool.keepBackup`配置变量设置为`false`会使`git mergetool`在文件成功合并后自动删除备份。

note: type: Plain text
en: Performs a merge, but does not make any new commits and does not read from or write to either the working tree or index.
zh_HANS-CN: 执行合并，但不做任何新的提交，也不从工作区或索引中读取或写入。

note: type: Plain text
en: The performed merge will use the same feature as the "real" linkgit:git-merge[1], including:
zh_HANS-CN: 执行的合并将使用与 “真正的” linkgit:git-merge[1] 相同的功能，包括：

note: type: Plain text
en: three way content merges of individual files
zh_HANS-CN: 单个文件的多路合并

note: type: Plain text
en: proper directory/file conflict handling
zh_HANS-CN: 正确处理目录/文件冲突

note: type: Plain text
en: recursive ancestor consolidation (i.e. when there is more than one merge base, creating a virtual merge base by merging the merge bases)
zh_HANS-CN: 递归祖先合并（即当有一个以上的合并基数时，通过合并基数创建一个虚拟合并基数）。

note: type: Plain text
en: etc.
zh_HANS-CN: 等等。

note: type: Plain text
en: After the merge completes, a new toplevel tree object is created.  See `OUTPUT` below for details.
zh_HANS-CN: 合并完成后，会创建一个新的顶层树对象。 详见下面的 “输出”。

note: type: Plain text
en: Do not quote filenames in the <Conflicted file info> section, and end each filename with a NUL character rather than newline.  Also begin the messages section with a NUL character instead of a newline.  See <<OUTPUT>> below for more information.
zh_HANS-CN: 在 <冲突文件信息> 部分不要引用文件名，每个文件名用 NUL 字符而不是换行来结束。 在信息部分也要用 NUL 字符而不是换行来开始。 更多信息见下面的 <<OUTPUT>>。

note: type: Plain text
en: In the Conflicted file info section, instead of writing a list of (mode, oid, stage, path) tuples to output for conflicted files, just provide a list of filenames with conflicts (and do not list filenames multiple times if they have multiple conflicting stages).
zh_HANS-CN: 在冲突的文件信息部分，不要为冲突的文件写一个（mode, oid, stage, path）图元列表来输出，只需提供一个有冲突的文件名列表（如果文件有多个冲突的阶段，不多次列出文件名）。

note: type: Plain text
en: Write any informational messages such as "Auto-merging <path>" or CONFLICT notices to the end of stdout.  If unspecified, the default is to include these messages if there are merge conflicts, and to omit them otherwise.
zh_HANS-CN: 将任何信息性的消息，如"Auto-merging <path>" 或冲突通知写到标准输出流的末尾。 如果没有指定，默认情况下，如果有合并冲突，就包括这些信息，否则就省略它们。

note: type: Plain text
en: merge-tree will by default error out if the two branches specified share no common history.  This flag can be given to override that check and make the merge proceed anyway.
zh_HANS-CN: 如果指定的两个分支没有共同的历史，merge-tree 默认会出错。 这个标志可以用来覆盖这个检查，并使合并继续进行。

note: type: Plain text
en: Instead of finding the merge-bases for <branch1> and <branch2>, specify a merge-base for the merge, and specifying multiple bases is currently not supported. This option is incompatible with `--stdin`.
zh_HANS-CN: 不需要为 <branch1> 和 <branch2> 寻找合并基础，而是为合并指定一个合并基础，目前不支持指定多个合并基础。该选项与 `--stdin` 不兼容。

note: type: Plain text
en: For a successful merge, the output from git-merge-tree is simply one line:
zh_HANS-CN: 对于一个成功的合并，git-merge-tree 的输出仅仅是一行：

note: type: Plain text
en: Whereas for a conflicted merge, the output is by default of the form:
zh_HANS-CN: 而对于有冲突的合并，默认的输出形式是：

note: type: Plain text
en: These are discussed individually below.
zh_HANS-CN: 下面将分别讨论这些问题。

note: type: Plain text
en: However, there is an exception.  If `--stdin` is passed, then there is an extra section at the beginning, a NUL character at the end, and then all the sections repeat for each line of input.  Thus, if the first merge is conflicted and the second is clean, the output would be of the form:
zh_HANS-CN: 然而，有一个例外。 如果通过了 `--stdin`，那么在开头有一个额外的部分，在结尾有一个 NUL 字符，然后所有的部分在每行输入中都会重复。 因此，如果第一次合并是冲突的，而第二次是干净的，输出将是这样的形式：

note: type: Plain text
en: This is an integer status followed by a NUL character.  The integer status is:
zh_HANS-CN: 这是一个整数状态，后面有一个 NUL 字符。 整数状态是：

note: type: Plain text
en:      0: merge had conflicts
         1: merge was clean
         <0: something prevented the merge from running (e.g. access to repository
    	 objects denied by filesystem)
zh_HANS-CN:      0：合并后有冲突
         1： 合并是干净的
         <0：有什么东西阻止了合并的运行（例如，文件系统拒绝对仓库对象的访问
    	 对象的访问被文件系统拒绝)

note: type: Title ~
en: OID of toplevel tree
zh_HANS-CN: 顶层目录树的 OID

note: type: Plain text
en: This is a tree object that represents what would be checked out in the working tree at the end of `git merge`.  If there were conflicts, then files within this tree may have embedded conflict markers.  This section is always followed by a newline (or NUL if `-z` is passed).
zh_HANS-CN: 这是一个树状对象，代表在`git merge` 结束时工作区上检查出来的东西。 如果有冲突，那么这个目录树中的文件可能会有嵌入式冲突标记。 这一部分的后面总是有一个换行符（如果传递了 `-z` 则为 NUL）。

note: type: Title ~
en: Conflicted file info
zh_HANS-CN: 冲突的文件信息

note: type: Plain text
en: This is a sequence of lines with the format
zh_HANS-CN: 这是一连串的行，格式为

note: type: Plain text
en: This section provides informational messages, typically about conflicts.  The format of the section varies significantly depending on whether `-z` is passed.
zh_HANS-CN: 这一部分提供信息，通常是关于冲突的信息。 该部分的格式因是否传递了 `-z` 而有很大不同。

note: type: Plain text
en: If `-z` is passed:
zh_HANS-CN: 如果 `-z`被传递：

note: type: Plain text
en: The output format is zero or more conflict informational records, each of the form:
zh_HANS-CN: 输出格式是零条或更多的冲突信息记录，每条记录的形式都是：

note: type: Plain text
en: where <list-of-paths> is of the form
zh_HANS-CN: 其中 <list-of-paths> 的形式为

note: type: Plain text
en: and includes paths (or branch names) affected by the conflict or informational message in <conflict-message>.  Also, <conflict-type> is a stable string explaining the type of conflict, such as
zh_HANS-CN: 并包括受冲突影响的路径（或分支名称）或 <conflict-message> 中的信息消息。 另外，<conflict-type> 是一个稳定的字符串，解释了冲突的类型，比如说

note: type: Plain text
en: and <conflict-message> is a more detailed message about the conflict which often (but not always) embeds the <stable-short-type-description> within it.  These strings may change in future Git versions.  Some examples:
zh_HANS-CN: 和 <conflict-message> 是关于冲突的更详细的信息，通常（但不一定）会嵌入 <stable-short-type-description> 中。 这些字符串在未来的Git版本中可能会改变。 一些例子：

note: type: Plain text
en: "CONFLICT (rename/delete): <oldfile> renamed...but deleted in..."
zh_HANS-CN: "CONFLICT (rename/delete): <oldfile> 被重命名... 但在... 被删除。"

note: type: Plain text
en: "Failed to merge submodule <submodule> (no merge base)"
zh_HANS-CN: “合并子模块 <submodule> 失败（没有合并基础）”

note: type: Plain text
en: "Warning: cannot merge binary files: <filename>"
zh_HANS-CN: “警告：不能合并二进制文件： <filename>”

note: type: Plain text
en: If `-z` is NOT passed:
zh_HANS-CN: 如果没有传递 `-z`：

note: type: Plain text
en: This section starts with a blank line to separate it from the previous sections, and then only contains the <conflict-message> information from the previous section (separated by newlines).  These are non-stable strings that should not be parsed by scripts, and are just meant for human consumption.  Also, note that while <conflict-message> strings usually do not contain embedded newlines, they sometimes do.  (However, the free-form messages will never have an embedded NUL character).  So, the entire block of information is meant for human readers as an agglomeration of all conflict messages.
zh_HANS-CN: 这一节以空行开始，与前几节分开，然后只包含前一节的 <conflict-message> 信息（用换行符分开）。 这些是不稳定的字符串，不应该被脚本解析，只是为了供人使用。 另外，请注意，虽然 <conflict-message> 字符串通常不包含嵌入式换行符，但有时也会包含。 (然而，自由格式的信息永远不会有一个嵌入的 NUL 字符）。 所以，整个信息块是作为所有冲突信息的集合体提供给人类阅读的。

note: type: Plain text
en: For a successful, non-conflicted merge, the exit status is 0.  When the merge has conflicts, the exit status is 1.  If the merge is not able to complete (or start) due to some kind of error, the exit status is something other than 0 or 1 (and the output is unspecified).  When --stdin is passed, the return status is 0 for both successful and conflicted merges, and something other than 0 or 1 if it cannot complete all the requested merges.
zh_HANS-CN: 如果合并成功，没有冲突，退出状态为 0；如果合并有冲突，退出状态为 1；如果合并由于某种错误而无法完成（或开始），退出状态为 0 或 1 以外的内容（而且输出结果未指明）。 当传递 --stdin 时，对于成功的合并和有冲突的合并，返回状态都是 0，如果不能完成所有要求的合并，则返回 0 或 1 以外的其他状态。

note: type: Plain text
en: This command is intended as low-level plumbing, similar to linkgit:git-hash-object[1], linkgit:git-mktree[1], linkgit:git-commit-tree[1], linkgit:git-write-tree[1], linkgit:git-update-ref[1], and linkgit:git-mktag[1].  Thus, it can be used as a part of a series of steps such as:
zh_HANS-CN: 这个命令旨在作为低级的底层命令，类似于 linkgit:git-hash-object[1]，linkgit:git-mktree[1]， linkgit:git-commit-tree[1]， linkgit:git-write-tree[1]，linkgit:git-update-ref[1] 和 linkgit:git-mktag[1]。 因此，它可以作为一系列步骤的一部分来使用，比如：

note: type: Plain text
en: Note that when the exit status is non-zero, `NEWTREE` in this sequence will contain a lot more output than just a tree.
zh_HANS-CN: 注意，当退出状态为非零时，这个序列中的 `NEWTREE` 将包含很多输出，而不仅仅是一棵目录树。

note: type: Plain text
en: For conflicts, the output includes the same information that you'd get with linkgit:git-merge[1]:
zh_HANS-CN: 对于冲突，输出包括你用 linkgit:git-merge[1] 得到的相同信息：

note: type: Plain text
en: what would be written to the working tree (the <<OIDTLT,OID of toplevel tree>>)
zh_HANS-CN: 什么会被写入工作区（<<OIDTLT,顶层目录树树的 OID>>）

note: type: Plain text
en: the higher order stages that would be written to the index (the <<CFI,Conflicted file info>>)
zh_HANS-CN: 将被写入索引的高阶阶段（<<CFI,冲突的文件信息>>）

note: type: Plain text
en: any messages that would have been printed to stdout (the <<IM,Informational messages>>)
zh_HANS-CN: 任何会被打印到标准输出流的信息（<<IM,信息性信息>>）。

note: type: Plain text
en: 'git merge-tree --stdin' input format is fully text based. Each line has this format:
zh_HANS-CN: 'git merge-tree --stdin' 的输入格式是完全基于文本的。每一行都有这样的格式：

note: type: Plain text
en: 	[<base-commit> -- ]<branch1> <branch2>
zh_HANS-CN: 	[<基础提交> -- ]<分支1> <分支2>

note: type: Plain text
en: If one line is separated by `--`, the string before the separator is used for specifying a merge-base for the merge and the string after the separator describes the branches to be merged.
zh_HANS-CN: 如果一行被 `--` 分隔，分隔符前的字符串用于指定合并的基础，分隔符后的字符串描述要合并的分支。

note: type: Title -
en: MISTAKES TO AVOID
zh_HANS-CN: 应避免的错误

note: type: Plain text
en: Do NOT look through the resulting toplevel tree to try to find which files conflict; parse the <<CFI,Conflicted file info>> section instead.  Not only would parsing an entire tree be horrendously slow in large repositories, there are numerous types of conflicts not representable by conflict markers (modify/delete, mode conflict, binary file changed on both sides, file/directory conflicts, various rename conflict permutations, etc.)
zh_HANS-CN: 不要在产生的顶层目录树中寻找哪些文件有冲突，而要解析 <<CFI,冲突文件信息>> 部分。 在大型存储库中，不仅解析整个目录树会慢得吓人，而且有许多冲突类型无法用冲突标记来表示（修改/删除，模式冲突，二进制文件在两边都有改变，文件/目录冲突，各种重命名冲突的变种，等等。）

note: type: Plain text
en: Do NOT interpret an empty <<CFI,Conflicted file info>> list as a clean merge; check the exit status.  A merge can have conflicts without having individual files conflict (there are a few types of directory rename conflicts that fall into this category, and others might also be added in the future).
zh_HANS-CN: 不要把一个空的 <<CFI,冲突文件信息>> 列表理解为一个干净的合并；检查退出状态。 一个合并可以有冲突而没有单个文件的冲突（有几种类型的目录重命名冲突属于这个类别，其他的也可能在将来被添加）。

note: type: Plain text
en: Do NOT attempt to guess or make the user guess the conflict types from the <<CFI,Conflicted file info>> list.  The information there is insufficient to do so.  For example: Rename/rename(1to2) conflicts (both sides renamed the same file differently) will result in three different file having higher order stages (but each only has one higher order stage), with no way (short of the <<IM,Informational messages>> section)  to determine which three files are related.  File/directory conflicts also result in a file with exactly one higher order stage.  Possibly-involved-in-directory-rename conflicts (when "merge.directoryRenames" is unset or set to "conflicts") also result in a file with exactly one higher order stage.  In all cases, the <<IM,Informational messages>> section has the necessary info, though it is not designed to be machine parseable.
zh_HANS-CN: 不要试图猜测或让用户猜测 <<CFI,冲突文件信息>> 列表中的冲突类型。 那里的信息不足以做到这一点。 比如说： Rname/rename（ 1 对 2 ）冲突（双方以不同方式重命名同一文件）将导致三个不同的文件具有高阶阶段(但每个文件只有一个高阶阶段），没有办法（除了 <<IM,信息消息>> 部分）确定哪三个文件是相关的。 文件/目录冲突也会导致一个文件正好有一个高阶阶段。 可能涉及目录重命名的冲突（当 "merge.directoryRenames" 未设置或设置为 "conflict" 时）也会导致一个文件正好有一个高阶阶段。 在所有情况下，<<IM,消息性信息>> 部分都有必要的信息，尽管它不是被设计为可被机器解析的。

note: type: Plain text
en: Do NOT assume that each paths from <<CFI,Conflicted file info>>, and the logical conflicts in the <<IM,Informational messages>> have a one-to-one mapping, nor that there is a one-to-many mapping, nor a many-to-one mapping.  Many-to-many mappings exist, meaning that each path can have many logical conflict types in a single merge, and each logical conflict type can affect many paths.
zh_HANS-CN: 不要假设 <<CFI,冲突文件信息>> 中的每个路径和 <<IM,信息消息>> 中的逻辑冲突有一对一的映射，也不要假设存在一对多的映射，更不要假设存在多对一的映射。 存在多对多的映射，意味着每个路径在一次合并中可以有许多逻辑冲突类型，每个逻辑冲突类型可以影响许多路径。

note: type: Plain text
en: Do NOT assume all filenames listed in the <<IM,Informational messages>> section had conflicts.  Messages can be included for files that have no conflicts, such as "Auto-merging <file>".
zh_HANS-CN: 不要认为 <<IM,信息消息>> 部分列出的所有文件名都有冲突。 对于没有冲突的文件，可以包括信息，如 "Auto-merging <文件>"。

note: type: Plain text
en: AVOID taking the OIDS from the <<CFI,Conflicted file info>> and re-merging them to present the conflicts to the user.  This will lose information.  Instead, look up the version of the file found within the <<OIDTLT,OID of toplevel tree>> and show that instead.  In particular, the latter will have conflict markers annotated with the original branch/commit being merged and, if renames were involved, the original filename.  While you could include the original branch/commit in the conflict marker annotations when re-merging, the original filename is not available from the <<CFI,Conflicted file info>> and thus you would be losing information that might help the user resolve the conflict.
zh_HANS-CN: 避免从 <<CFI,冲突文件信息>> 中提取 OIDS，并将它们重新合并以向用户展示冲突。 这将丢失信息。 相反，在 <<OIDTLT,顶层目录树的OID>> 中查找文件的版本，并显示它。 特别是，后者将有冲突标记，并标明被合并的原始分支/提交，如果涉及重名，则标明原始文件名。 虽然你可以在重新合并时将原始分支/提交包括在冲突标记的注释中，但原始文件名不能从 <<CFI,冲突文件信息>> 中获得，因此你会失去可能帮助用户解决冲突的信息。

note: type: Plain text
en: Per the <<NEWMERGE,DESCRIPTION>> and unlike the rest of this documentation, this section describes the deprecated `--trivial-merge` mode.
zh_HANS-CN: 根据 <<NEWMERGE,DESCRIPTION>>，与本文档的其他部分不同，本节描述了被废弃的 `--trivial-merge` 模式。

note: type: Plain text
en: Other than the optional `--trivial-merge`, this mode accepts no options.
zh_HANS-CN: 除了可选的 `--trivial-merge` 外，该模式不接受任何选项。

note: type: Plain text
en: This mode reads three tree-ish, and outputs trivial merge results and conflicting stages to the standard output in a semi-diff format.  Since this was designed for higher level scripts to consume and merge the results back into the index, it omits entries that match <branch1>.  The result of this second form is similar to what three-way 'git read-tree -m' does, but instead of storing the results in the index, the command outputs the entries to the standard output.
zh_HANS-CN: 这种模式读取三个树状的，并将琐碎的合并结果和冲突的阶段以 semi-diff 格式输出到标准输出。 由于这是为更高级别的脚本设计的，以消耗并将结果合并回索引中，所以它省略了与 <branch1> 相匹配的条目。 第二种形式的结果类似于三方 "git read-tree -m" 的做法，但该命令不是将结果存储在索引中，而是将条目输出到标准输出。

note: type: Plain text
en: This form not only has limited applicability (a trivial merge cannot handle content merges of individual files, rename detection, proper directory/file conflict handling, etc.), the output format is also difficult to work with, and it will generally be less performant than the first form even on successful merges (especially if working in large repositories).
zh_HANS-CN: 这种形式不仅适用性有限（一个琐碎的合并不能处理单个文件的内容合并、重命名检测、适当的目录/文件冲突处理等），输出格式也很难处理，而且即使在成功的合并中，它的性能一般也不如第一种形式（特别是在大型仓库中工作）。

note: type: Plain text
en: Incorporates changes from the named commits (since the time their histories diverged from the current branch) into the current branch.  This command is used by 'git pull' to incorporate changes from another repository and can be used by hand to merge changes from one branch into another.
zh_HANS-CN: 将指定的提交内容（从它们的历史与当前分支相分离时起）并入当前分支。  这条命令被 "git pull "用来合并另一个仓库的改动，也可以用手将一个分支的改动合并到另一个分支。

note: type: Plain text
en: Assume the following history exists and the current branch is "`master`":
zh_HANS-CN: 假设存在以下历史，且当前分支为"`master`"：

note: type: Plain text
en: Then "`git merge topic`" will replay the changes made on the `topic` branch since it diverged from `master` (i.e., `E`) until its current commit (`C`) on top of `master`, and record the result in a new commit along with the names of the two parent commits and a log message from the user describing the changes. Before the operation, `ORIG_HEAD` is set to the tip of the current branch (`C`).
zh_HANS-CN: 然后"`git merge topic`"将重现`topic`分支从`master`（即`E`）分流到`master`之上的当前提交（`C`）所做的修改，并将结果与两个父提交的名称和用户描述修改的日志信息一起记录在一个新提交中。在操作之前，`ORIG_HEAD`被设置为当前分支（`C`）的顶端。

note: type: Plain text
en: The second syntax ("`git merge --abort`") can only be run after the merge has resulted in conflicts. 'git merge --abort' will abort the merge process and try to reconstruct the pre-merge state. However, if there were uncommitted changes when the merge started (and especially if those changes were further modified after the merge was started), 'git merge --abort' will in some cases be unable to reconstruct the original (pre-merge) changes. Therefore:
zh_HANS-CN: 第二种语法（"`git merge --abort`"）只能在合并导致冲突后运行。"git merge --abort"将中止合并过程，并尝试重建合并前的状态。然而，如果合并开始时有未提交的修改（特别是如果这些修改在合并开始后被进一步修改），'git merge --abort'在某些情况下将无法重建原始（合并前）修改。因此：

note: type: Plain text
en: *Warning*: Running 'git merge' with non-trivial uncommitted changes is
    discouraged: while possible, it may leave you in a state that is hard to
    back out of in the case of a conflict.
zh_HANS-CN: *警告*：在非重要的未提交的修改中运行 "git merge "是不可取的。
    不鼓励这样做：虽然有可能，但它可能会让你处于一个很难在冲突中恢复的状态。
    并且如果发生冲突的话会处于一个很难退出的状态。

note: type: Plain text
en: The third syntax ("`git merge --continue`") can only be run after the merge has resulted in conflicts.
zh_HANS-CN: 第三种语法（"`git merge --continue`"）只能在合并导致冲突后运行。

note: type: Plain text
en: Set the commit message to be used for the merge commit (in case one is created).
zh_HANS-CN: 设置用于合并提交的提交信息（如果创建了一个的话）。

note: type: Plain text
en: If `--log` is specified, a shortlog of the commits being merged will be appended to the specified message.
zh_HANS-CN: 如果指定了`--log`，正在合并的提交的简短日志将被附加到指定的消息中。

note: type: Plain text
en: Prepare the default merge message as if merging to the branch `<branch>`, instead of the name of the real branch to which the merge is made.
zh_HANS-CN: 准备默认的合并信息，就像合并到分支`<分支>`一样，而不是真正要合并的分支名称。

note: type: Plain text
en: Read the commit message to be used for the merge commit (in case one is created).
zh_HANS-CN: 读取用于合并提交的提交信息（如果创建了）。

note: type: Plain text
en: Silently overwrite ignored files from the merge result. This is the default behavior. Use `--no-overwrite-ignore` to abort.
zh_HANS-CN: 默认会静默地覆盖合并结果中被忽略的文件。使用`--no-overwrite-ignore`来终止。

note: type: Plain text
en: Abort the current conflict resolution process, and try to reconstruct the pre-merge state. If an autostash entry is present, apply it to the worktree.
zh_HANS-CN: 中止当前的冲突解决过程，并尝试重建合并前的状态。工作区会自动应用自动存储条目。

note: type: Plain text
en: If there were uncommitted worktree changes present when the merge started, 'git merge --abort' will in some cases be unable to reconstruct these changes. It is therefore recommended to always commit or stash your changes before running 'git merge'.
zh_HANS-CN: 如果合并开始时有未提交的工作区变化，'git merge --abort'在某些情况下将无法重现这些变化。因此，建议在运行'git merge'之前，一定要提交或储存你的修改。

note: type: Plain text
en: Forget about the current merge in progress. Leave the index and the working tree as-is. If `MERGE_AUTOSTASH` is present, the stash entry will be saved to the stash list.
zh_HANS-CN: 忘记当前正在进行的合并。让索引和工作区保持原样。如果`MERGE_AUTOSTASH`存在，储藏库条目将被保存到储藏库列表。

note: type: Plain text
en: After a 'git merge' stops due to conflicts you can conclude the merge by running 'git merge --continue' (see "HOW TO RESOLVE CONFLICTS" section below).
zh_HANS-CN: 在 "git merge "因冲突而停止后，你可以通过运行 "git merge --continue "来结束当前合并（见下文 "如何解决冲突"部分）。

note: type: Plain text
en: Commits, usually other branch heads, to merge into our branch.  Specifying more than one commit will create a merge with more than two parents (affectionately called an Octopus merge).
zh_HANS-CN: 提交，通常是其他分支负责人，合并到我们的分支中。 指定多个提交将创建具有两个以上父项的合并（亲切地称为八爪/多路合并）。

note: type: Plain text
en: If no commit is given from the command line, merge the remote-tracking branches that the current branch is configured to use as its upstream.  See also the configuration section of this manual page.
zh_HANS-CN: 如果命令行没有给出提交，则合并当前分支被配置为上游的远程跟踪分支。  参见本手册页的配置部分。

note: type: Plain text
en: When `FETCH_HEAD` (and no other commit) is specified, the branches recorded in the `.git/FETCH_HEAD` file by the previous invocation of `git fetch` for merging are merged to the current branch.
zh_HANS-CN: 当指定`FETCH_HEAD`（没有其他提交）时，之前调用 `git fetch`进行合并时记录在`.git/FETCH_HEAD`文件中的分支会被合并到当前分支。

note: type: Title -
en: PRE-MERGE CHECKS
zh_HANS-CN: 合并前检查

note: type: Plain text
en: Before applying outside changes, you should get your own work in good shape and committed locally, so it will not be clobbered if there are conflicts.  See also linkgit:git-stash[1].  'git pull' and 'git merge' will stop without doing anything when local uncommitted changes overlap with files that 'git pull'/'git merge' may need to update.
zh_HANS-CN: 在应用外部的修改之前，你应该把自己的工作做好，并在本地提交，这样在有冲突的时候就不会被打乱了。  参见 linkgit:git-stash[1]。  "git pul "和 "git merge "会在本地未提交的修改与 "git pull"/"git merge "可能需要更新的文件重叠时会不做任何操作，立即停止。

note: type: Plain text
en: To avoid recording unrelated changes in the merge commit, 'git pull' and 'git merge' will also abort if there are any changes registered in the index relative to the `HEAD` commit.  (Special narrow exceptions to this rule may exist depending on which merge strategy is in use, but generally, the index must match HEAD.)
zh_HANS-CN: 为了避免在合并提交中记录不相关的变化，'git pull'和'git merge'也会在相对于`HEAD`提交的索引中存在任何变化时中止。  (根据使用的合并策略，这一规则可能存在特殊的狭义例外，但一般来说，索引必须与HEAD相匹配。)

note: type: Plain text
en: If all named commits are already ancestors of `HEAD`, 'git merge' will exit early with the message "Already up to date."
zh_HANS-CN: 如果所有命名的提交都已经是`HEAD`的祖先，'git merge'将提前退出，提示 "已经是最新的。"

note: type: Title -
en: FAST-FORWARD MERGE
zh_HANS-CN: 快进式合并

note: type: Plain text
en: Often the current branch head is an ancestor of the named commit.  This is the most common case especially when invoked from 'git pull': you are tracking an upstream repository, you have committed no local changes, and now you want to update to a newer upstream revision.  In this case, a new commit is not needed to store the combined history; instead, the `HEAD` (along with the index) is updated to point at the named commit, without creating an extra merge commit.
zh_HANS-CN: 通常情况下，当前的分支头是指定提交的祖先。  这是最常见的情况，特别是当从'git pull'调用时：你正在跟踪一个上游仓库，你没有提交本地的修改，现在你想更新到一个更新的上游版本。  在这种情况下，不需要新的提交来存储合并历史；相反，`HEAD`（连同索引）被更新为指向指定的提交，而不需要创建额外的合并提交。

note: type: Plain text
en: This behavior can be suppressed with the `--no-ff` option.
zh_HANS-CN: 这种行为可以通过`--no-ff`选项来抑制。

note: type: Title -
en: TRUE MERGE
zh_HANS-CN: 正确的合并

note: type: Plain text
en: Except in a fast-forward merge (see above), the branches to be merged must be tied together by a merge commit that has both of them as its parents.
zh_HANS-CN: 除了快进合并（见上文），被合并的分支必须由一个以它们两个为父分支的合并提交捆绑在一起。

note: type: Plain text
en: A merged version reconciling the changes from all branches to be merged is committed, and your `HEAD`, index, and working tree are updated to it.  It is possible to have modifications in the working tree as long as they do not overlap; the update will preserve them.
zh_HANS-CN: 一个调和了所有要合并的分支的修改的合并版本被提交，你的`HEAD`、索引和工作区将更新到这个版本。  在工作区中可以有一些修改，只要它们不重叠；更新将保留这些修改。

note: type: Plain text
en: When it is not obvious how to reconcile the changes, the following happens:
zh_HANS-CN: 当不清楚如何调和这些变化时，就会发生以下情况：

note: type: Plain text
en: The `HEAD` pointer stays the same.
zh_HANS-CN: `HEAD`的指针保持不变。

note: type: Plain text
en: The `MERGE_HEAD` ref is set to point to the other branch head.
zh_HANS-CN: `MERGE_HEAD`参数被设置为指向另一个分支头部。

note: type: Plain text
en: Paths that merged cleanly are updated both in the index file and in your working tree.
zh_HANS-CN: 合并干净的路径在索引文件和你的工作区中都更新了。

note: type: Plain text
en: A special ref `AUTO_MERGE` is written, pointing to a tree corresponding to the current content of the working tree (including conflict markers for textual conflicts).  Note that this ref is only written when the 'ort' merge strategy is used (the default).
zh_HANS-CN: 会写入一个特殊的 `AUTO_MERGE` 引用，指向一个与当前工作区内容（包括文本冲突的冲突标记）相对应的目录树。 请注意，只有在使用 'ort' 合并策略（默认）时，才会写入这个引用。

note: type: Plain text
en: No other changes are made.  In particular, the local modifications you had before you started merge will stay the same and the index entries for them stay as they were, i.e. matching `HEAD`.
zh_HANS-CN: 没有其他变化。  特别是，你在开始合并之前的本地修改将保持不变，它们的索引条目保持原样，即匹配`HEAD`。

note: type: Plain text
en: If you tried a merge which resulted in complex conflicts and want to start over, you can recover with `git merge --abort`.
zh_HANS-CN: 如果你尝试的合并导致了复杂的冲突，并想重新开始，你可以用`git merge --abort`恢复。

note: type: Title -
en: MERGING TAG
zh_HANS-CN: 合并标签

note: type: Plain text
en: When merging an annotated (and possibly signed) tag, Git always creates a merge commit even if a fast-forward merge is possible, and the commit message template is prepared with the tag message.  Additionally, if the tag is signed, the signature check is reported as a comment in the message template. See also linkgit:git-tag[1].
zh_HANS-CN: 当合并一个有注释的（可能是有签名的）标签时，即使可以进行快速合并，Git也会创建一个合并提交，并且会一起准备提交消息模板和标签消息。  此外，如果标签有签名，签名检查会在消息模板中作为注释报告。参见 linkgit:git-tag[1]。

note: type: Plain text
en: When you want to just integrate with the work leading to the commit that happens to be tagged, e.g. synchronizing with an upstream release point, you may not want to make an unnecessary merge commit.
zh_HANS-CN: 当你只想与恰好被标记的提交的工作整合时，比如说与上游发布点同步，你可能不想做一个不必要的合并提交。

note: type: Plain text
en: In such a case, you can "unwrap" the tag yourself before feeding it to `git merge`, or pass `--ff-only` when you do not have any work on your own. e.g.
zh_HANS-CN: 在这种情况下，你可以在把标签送入`git merge`之前自己 "解包"，或者在自己没有任何工作的时候设置`--ff-only`，如下例。

note: type: Plain text
en: During a merge, the working tree files are updated to reflect the result of the merge.  Among the changes made to the common ancestor's version, non-overlapping ones (that is, you changed an area of the file while the other side left that area intact, or vice versa) are incorporated in the final result verbatim.  When both sides made changes to the same area, however, Git cannot randomly pick one side over the other, and asks you to resolve it by leaving what both sides did to that area.
zh_HANS-CN: 在合并过程中，工作区文件被更新以反映合并的结果。  在对共同祖先的版本所做的修改中，非重叠的修改（即你改变了文件的某个区域，而另一方则保留了该区域，反之亦然）会被逐字纳入最终结果中。  然而，当双方都对同一区域进行了修改时，Git不能随机地选择一方而不是另一方，而是要求你通过保留双方对该区域的修改来解决这个问题。

note: type: Plain text
en: By default, Git uses the same style as the one used by the "merge" program from the RCS suite to present such a conflicted hunk, like this:
zh_HANS-CN: 默认情况下，Git使用与RCS套件中的 "merge"程序相同的样式来呈现这样一个有冲突的大块，像这样：

note: type: delimited block -
en: Here are lines that are either unchanged from the common
    ancestor, or cleanly resolved because only one side changed,
    or cleanly resolved because both sides changed the same way.
    <<<<<<< yours:sample.txt
    Conflict resolution is hard;
    let's go shopping.
    =======
    Git makes conflict resolution easy.
    >>>>>>> theirs:sample.txt
    And here is another line that is cleanly resolved or unmodified.
zh_HANS-CN: 这里是与共同的祖先相比没有变化的行。
    祖先没有变化，或者因为只有一方发生了变化而得到干净的解决、
    或者因为两边都有相同的变化而被干净地解决了。
    <<<<<<< yours:sample.txt
    冲突的解决是困难的；
    让我们去购物吧。
    =======
    Git让冲突解决变得简单。
    >>>>>>> theirs:sample.txt
    而这里是另一行干净利落的解决或未修改的内容。

note: type: Plain text
en: The area where a pair of conflicting changes happened is marked with markers `<<<<<<<`, `=======`, and `>>>>>>>`.  The part before the `=======` is typically your side, and the part afterwards is typically their side.
zh_HANS-CN: 发生一对冲突变化的区域被标记为`<<<<<<<`、`=======`和`>>>>>>>`。  `=======`之前的部分通常是你做的修改，而之后的部分通常是别人的修改。

note: type: Plain text
en: The default format does not show what the original said in the conflicting area.  You cannot tell how many lines are deleted and replaced with Barbie's remark on your side.  The only thing you can tell is that your side wants to say it is hard and you'd prefer to go shopping, while the other side wants to claim it is easy.
zh_HANS-CN: 默认的格式并不显示原文在冲突区说了什么。  你无法知道有多少行被删除，并被替换成你方的芭比娃娃的言论。  你唯一能知道的是，你方想说这很难，你更愿意去购物，而另一方则想说这很容易。

note: type: Plain text
en: An alternative style can be used by setting the "merge.conflictStyle" configuration variable to either "diff3" or "zdiff3".  In "diff3" style, the above conflict may look like this:
zh_HANS-CN: 通过将 "merge.conflictStyle "配置变量设置为 "diff3 "或 "zdiff3"，可以使用另一种风格。  在 "diff3 "风格中，上述冲突可能看起来像这样：

note: type: delimited block -
en: Here are lines that are either unchanged from the common
    ancestor, or cleanly resolved because only one side changed,
    <<<<<<< yours:sample.txt
    or cleanly resolved because both sides changed the same way.
    Conflict resolution is hard;
    let's go shopping.
    ||||||| base:sample.txt
    or cleanly resolved because both sides changed identically.
    Conflict resolution is hard.
    =======
    or cleanly resolved because both sides changed the same way.
    Git makes conflict resolution easy.
    >>>>>>> theirs:sample.txt
    And here is another line that is cleanly resolved or unmodified.
zh_HANS-CN: 这里是与共同的祖先相比没有变化的行。
    祖先没有变化，或者因为只有一方发生了变化而得到了干净的解决、
    <<<<<<< yours:sample.txt
    或干净地解决了，因为双方都以同样的方式改变了。
    冲突的解决是很难的；
    让我们去购物吧。
    ||||||| base:sample.txt
    或干净利落地解决了，因为双方的变化都一样。
    冲突的解决是很难的。
    =======
    或干净利落地解决了，因为双方都有相同的变化。
    Git使冲突解决变得容易。
    >>>>>>> theirs:sample.txt
    而这里是另一行被干净地解决或未修改的。

note: type: Plain text
en: In addition to the `<<<<<<<`, `=======`, and `>>>>>>>` markers, it uses another `|||||||` marker that is followed by the original text.  You can tell that the original just stated a fact, and your side simply gave in to that statement and gave up, while the other side tried to have a more positive attitude.  You can sometimes come up with a better resolution by viewing the original.
zh_HANS-CN: 除了`<<<<<<<`、`=======`和`>>>>>>>`标记外，它还使用了另一个`|||||||`标记，后面是原文。  你可以看出，原文只是陈述了一个事实，而你的一方只是屈服于这个陈述而放弃了，而另一方则试图有一个更积极的态度。  你有时可以通过查看原文得出一个更好的解决方案。

note: type: Title -
en: HOW TO RESOLVE CONFLICTS
zh_HANS-CN: 如何解决冲突

note: type: Plain text
en: After seeing a conflict, you can do two things:
zh_HANS-CN: 看到冲突后，你可以做两件事：

note: type: Plain text
en: Decide not to merge.  The only clean-ups you need are to reset the index file to the `HEAD` commit to reverse 2. and to clean up working tree changes made by 2. and 3.; `git merge --abort` can be used for this.
zh_HANS-CN: 决定不进行合并。  唯一需要清理的是将索引文件重置为`HEAD`提交，以逆转2.，并清理2.和3.对工作树的修改；可以用`git merge --abort`来做这份工作。

note: type: Plain text
en: Resolve the conflicts.  Git will mark the conflicts in the working tree.  Edit the files into shape and 'git add' them to the index.  Use 'git commit' or 'git merge --continue' to seal the deal. The latter command checks whether there is a (interrupted) merge in progress before calling 'git commit'.
zh_HANS-CN: 解决冲突。  Git会在工作树上标记冲突。  将文件编辑成形，然后'git add'它们到索引中。  使用'git commit'或'git merge --continue'解决。后一个命令在调用'git commit'之前会检查是否有一个（中断的）合并正在进行。

note: type: Plain text
en: You can work through the conflict with a number of tools:
zh_HANS-CN: 你可以用一些工具来解决冲突：

note: type: Plain text
en: Use a mergetool.  `git mergetool` to launch a graphical mergetool which will work you through the merge.
zh_HANS-CN: 使用一个mergetool。  `git mergetool`启动一个图形化的mergetool，它将帮助你完成合并工作。

note: type: Plain text
en: Look at the diffs from each branch. `git log --merge -p <path>` will show diffs first for the `HEAD` version and then the `MERGE_HEAD` version.
zh_HANS-CN: 看看每个分支的差异。`git log --merge -p <路径>`将首先显示`HEAD`版本的差异，然后是`MERGE_HEAD`版本。

note: type: Plain text
en: Look at the originals.  `git show :1:filename` shows the common ancestor, `git show :2:filename` shows the `HEAD` version, and `git show :3:filename` shows the `MERGE_HEAD` version.
zh_HANS-CN: 看一下原件。  `git show :1:filename`显示共同的祖先，`git show :2:filename`显示`HEAD`版本，`git show :3:filename`显示`MERGE_HEAD`版本。

note: type: Plain text
en: Merge branches `fixes` and `enhancements` on top of the current branch, making an octopus merge:
zh_HANS-CN: 合并分支 `fixes` 和 `enhancements`到当前分支之上, 进行多路合并。

note: type: Plain text
en: Merge branch `obsolete` into the current branch, using `ours` merge strategy:
zh_HANS-CN: 将分支`obsolete`合并到当前分支，使用`ours`的合并策略：

note: type: Plain text
en: Merge branch `maint` into the current branch, but do not make a new commit automatically:
zh_HANS-CN: 合并分支`maint`到当前分支，但是我们不做自动创建新提交:

note: type: Plain text
en: This can be used when you want to include further changes to the merge, or want to write your own merge commit message.
zh_HANS-CN: 当您想在合并中加入进一步的更改，或者您想手动编写合并提交信息时，就可以使用此功能。

note: type: Plain text
en: You should refrain from abusing this option to sneak substantial changes into a merge commit.  Small fixups like bumping release/version name would be acceptable.
zh_HANS-CN: 你应该避免滥用这个选项，它可以在合并提交中偷偷地进行版本库中实质性的修改。 小的修正，例如修改发布日志内容/版本名称，是推荐的。

note: type: Labeled list
en: branch.<name>.mergeOptions
zh_HANS-CN: 分支 .<名字>.合并操作选项

note: type: Plain text
en: Sets default options for merging into branch <name>. The syntax and supported options are the same as those of 'git merge', but option values containing whitespace characters are currently not supported.
zh_HANS-CN: 设置合并到分支<分支名>的默认选项。语法和支持的选项与'git merge'相同，不过目前不支持包含空格的选项值。

note: type: Plain text
en: Reads a tag contents on standard input and creates a tag object. The output is the new tag's <object> identifier.
zh_HANS-CN: 读取标准输入中的标签内容并创建一个标签对象。输出是新标签的 <object> 标识符。

note: type: Plain text
en: This command is mostly equivalent to linkgit:git-hash-object[1] invoked with `-t tag -w --stdin`. I.e. both of these will create and write a tag found in `my-tag`:
zh_HANS-CN: 这个命令主要等同于 linkgit:git-hash-object[1] 与 `-t tag -w -stdin` 一起调用。也就是说，这两个命令都会创建并写入一个在 `my-tag` 中找到的标签：

note: type: Plain text
en: The difference is that mktag will die before writing the tag if the tag doesn't pass a linkgit:git-fsck[1] check.
zh_HANS-CN: 不同的是，如果标签没有通过 linkgit:git-fsck[1] 的检查，mktag 进程会在写入标签前结束。

note: type: Plain text
en: The "fsck" check done mktag is stricter than what linkgit:git-fsck[1] would run by default in that all `fsck.<msg-id>` messages are promoted from warnings to errors (so e.g. a missing "tagger" line is an error).
zh_HANS-CN: mktag 的 "fsck" 检查比 linkgit:git-fsck[1] 默认运行的更严格，因为所有的 `fsck.<msg-id>` 信息都从警告提升为错误（所以例如，缺少 "tagger" 行就是一个错误）。

note: type: Plain text
en: By default mktag turns on the equivalent of linkgit:git-fsck[1] `--strict` mode. Use `--no-strict` to disable it.
zh_HANS-CN: 默认情况下，mktag 打开了相当于 linkgit:git-fsck[1] 的 `--strict` 模式。使用 `--no-strict` 来禁用它。

note: type: Plain text
en: A tag signature file, to be fed to this command's standard input, has a very simple fixed format: four lines of
zh_HANS-CN: 将被送入该命令的标准输入的标签签名文件有一个非常简单的固定格式：四行的

note: type: Plain text
en: followed by some 'optional' free-form message (some tags created by older Git may not have `tagger` line).  The message, when it exists, is separated by a blank line from the header.  The message part may contain a signature that Git itself doesn't care about, but that can be verified with gpg.
zh_HANS-CN: 后面是一些 "可选的" 自由形式的信息（一些由旧版 Git 创建的标签可能没有 `tagger` 行）。 当信息存在时，会用一行空行与标头分开。 消息部分可能包含一个 Git 自己并不关心的签名，但可以用 gpg 验证。

note: type: Plain text
en: git-mktree - Build a tree-object from ls-tree formatted text
zh_HANS-CN: git-mktree - 从 ls-tree 格式化文本构建树对象

note: type: Plain text
en: Reads standard input in non-recursive `ls-tree` output format, and creates a tree object.  The order of the tree entries is normalized by mktree so pre-sorting the input is not required.  The object name of the tree object built is written to the standard output.
zh_HANS-CN: 以非递归的 `ls-tree` 输出格式读取标准输入，并创建一个树形对象。 树条目的顺序由 mktree 规范化，所以不需要对输入进行预先排序。 建立的树形对象的对象名称被写入标准输出。

note: type: Plain text
en: Read the NUL-terminated `ls-tree -z` output instead.
zh_HANS-CN: 读取以 NUL 结尾的 `ls-tree -z` 输出。

note: type: Plain text
en: Allow missing objects.  The default behaviour (without this option)  is to verify that each tree entry's sha1 identifies an existing object.  This option has no effect on the treatment of gitlink entries (aka "submodules") which are always allowed to be missing.
zh_HANS-CN: 允许缺失的对象。 默认行为（没有这个选项）是验证每个树条目的 sha1 标识了一个现有对象。 这个选项对处理 gitlink 条目（又称 "子模块"）没有影响，它总是被允许缺失。

note: type: Plain text
en: Allow building of more than one tree object before exiting.  Each tree is separated by a single blank line. The final new-line is optional.  Note - if the `-z` option is used, lines are terminated with NUL.
zh_HANS-CN: 允许在退出前建立一个以上的树对象。 每棵树之间都有一个空行。最后的换行是可选的。 注意 - 如果使用 `-z` 选项，则以 NUL 结束行。

note: type: Plain text
en: git-mv - Move or rename a file, a directory, or a symlink
zh_HANS-CN: git-mv - 移动或重命名一个文件、一个目录或一个符号链接

note: type: Plain text
en: Move or rename a file, directory or symlink.
zh_HANS-CN: 移动或重命名一个文件、目录或符号链接。

note: type: Plain text
en:  git mv [-v] [-f] [-n] [-k] <source> <destination>
     git mv [-v] [-f] [-n] [-k] <source> ... <destination directory>
zh_HANS-CN:  git mv [-v] [-f] [-n] [-k] <源文件> <目标文件>
     git mv [-v] [-f] [-n] [-k] <源文件> ...<目标目录>

note: type: Plain text
en: In the first form, it renames <source>, which must exist and be either a file, symlink or directory, to <destination>.  In the second form, the last argument has to be an existing directory; the given sources will be moved into this directory.
zh_HANS-CN: 在第一种形式中，它将 <源文件>（必须存在且可以是文件、符号链接或目录）重命名为 <目标文件>。在第二种形式中，最后一个参数必须是一个已存在的目录；给定的源文件将被移动到该目录中。

note: type: Plain text
en: The index is updated after successful completion, but the change must still be committed.
zh_HANS-CN: 在移动成功完成后，索引就会被更新，但更改仍需要进行提交才能生效。

note: type: Plain text
en: Force renaming or moving of a file even if the <destination> exists.
zh_HANS-CN: 即使 <目标文件> 存在，也强制重命名或移动文件。

note: type: Plain text
en: Skip move or rename actions which would lead to an error condition. An error happens when a source is neither existing nor controlled by Git, or when it would overwrite an existing file unless `-f` is given.
zh_HANS-CN: 跳过可能导致错误条件的移动或重命名操作。当源文件既不存在也不受Git控制，或者在没有提供 -f 选项的情况下覆盖现有文件时，该指令就会就会发生错误。

note: type: Plain text
en: Do nothing; only show what would happen
zh_HANS-CN: 什么都不做，仅显示将会发生的操作

note: type: Plain text
en: Report the names of files as they are moved.
zh_HANS-CN: 报告文件在移动时的名称的变化。

note: type: Plain text
en: Moving a submodule using a gitfile (which means they were cloned with a Git version 1.7.8 or newer) will update the gitfile and core.worktree setting to make the submodule work in the new location.  It also will attempt to update the submodule.<name>.path setting in the linkgit:gitmodules[5] file and stage that file (unless -n is used).
zh_HANS-CN: 使用 gitfile（意味着它们是使用 Git 1.7.8 或更新版本进行克隆的）来移动子模块将更新 gitfile 和 core.worktree 设置，以使子模块在新位置正常工作。它还将尝试更新 linkgit:gitmodules[5] 文件中的 submodule.<name>.path 设置，并将该文件暂存（除非使用了 -n 选项）。

note: type: Plain text
en: Each time a superproject update moves a populated submodule (e.g. when switching between commits before and after the move) a stale submodule checkout will remain in the old location and an empty directory will appear in the new location. To populate the submodule again in the new location the user will have to run "git submodule update" afterwards. Removing the old directory is only safe when it uses a gitfile, as otherwise the history of the submodule will be deleted too. Both steps will be obsolete when recursive submodule update has been implemented.
zh_HANS-CN: 每当父工程更新导致子模块移动时（例如，在移动之前和之后的提交之间切换时），旧位置将保留一个陈旧的子模块检出，并在新位置出现一个空目录。要在新位置重新填充子模块，用户必须运行 "git submodule update"。只有在旧目录使用 gitfile 时，删除旧目录才是安全的，否则子模块的历史记录也将被删除。当实现递归子模块更新时，这两个步骤将变得不再需要。

note: type: Plain text
en: git-name-rev - Find symbolic names for given revs
zh_HANS-CN: git-name-rev - 为给定的 rev 查找符号名称

note: type: Plain text
en: Finds symbolic names suitable for human digestion for revisions given in any format parsable by 'git rev-parse'.
zh_HANS-CN: 查找适合人类理解的符号名称，这些名称是以 'git rev-parse' 可解析的任何格式给出的修订。

note: type: Plain text
en: Do not use branch names, but only tags to name the commits
zh_HANS-CN: 不要使用分支名称，只用标签来命名提交内容

note: type: Plain text
en: Only use refs whose names match a given shell pattern.  The pattern can be one of branch name, tag name or fully qualified ref name. If given multiple times, use refs whose names match any of the given shell patterns. Use `--no-refs` to clear any previous ref patterns given.
zh_HANS-CN: 只使用名称与给定的 shell 模式相匹配的引用。 该模式可以是分支名称、标签名称或完全合格的引用名之一。如果给定多次，使用名称与任何给定的 shell 模式相匹配的引用。使用 `--no-refs` 来清除之前给出的任何引用模式。

note: type: Plain text
en: Do not use any ref whose name matches a given shell pattern. The pattern can be one of branch name, tag name or fully qualified ref name. If given multiple times, a ref will be excluded when it matches any of the given patterns. When used together with --refs, a ref will be used as a match only when it matches at least one --refs pattern and does not match any --exclude patterns. Use `--no-exclude` to clear the list of exclude patterns.
zh_HANS-CN: 不要使用其名称与给定的壳模式相匹配的任何引用。该模式可以是分支名称、标签名称或完全合格的引用名称之一。如果多次给定，当一个引用与任何给定的模式匹配时，它将被排除。当与 --refs 一起使用时，只有当一个引用至少与一个 --refs 模式相匹配，并且不与任何 --exclude 模式相匹配时，才会被用作匹配。使用 `--no-exclude` 来清除排除模式的列表。

note: type: Plain text
en: List all commits reachable from all refs
zh_HANS-CN: 列出所有引用所可达的所有提交

note: type: Plain text
en: Transform stdin by substituting all the 40-character SHA-1 hexes (say $hex) with "$hex ($rev_name)".  When used with --name-only, substitute with "$rev_name", omitting $hex altogether. This option was called `--stdin` in older versions of Git.
zh_HANS-CN: 通过用 "$hex ($rev_name)" 替换所有 40 个字符的 SHA-1 六位数（比如 $hex）来转换标准输入。 当与 --name-only 一起使用时，用 "$rev_name" 替代，完全省略 $hex。这个选项在旧版本的 Git 中被称为 `--stdin`。

note: type: Plain text
en: Instead of printing both the SHA-1 and the name, print only the name.  If given with --tags the usual tag prefix of "tags/" is also omitted from the name, matching the output of `git-describe` more closely.
zh_HANS-CN: 不要同时打印 SHA-1 和名字，而只打印名字。 如果给与--标签，通常的标签前缀 "tags/" 也会从名称中省略，与 `git-describe` 的输出更接近。

note: type: Plain text
en: Die with error code != 0 when a reference is undefined, instead of printing `undefined`.
zh_HANS-CN: 当一个引用未被定义时，以错误代码不为 0 的方式退出，而不是打印 `undefined`。

note: type: Plain text
en: Given a commit, find out where it is relative to the local refs. Say somebody wrote you about that fantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a.  Of course, you look into the commit, but that only tells you what happened, but not the context.
zh_HANS-CN: 给出一个提交，找出它在本地引用中的相对位置。假设有人给你写了关于 33db5f4d9027a10e477ccf054b2c1ab94f74c85a 的精彩提交。 当然，你会去查这个提交，但这只能告诉你发生了什么，但不能告诉你背景。

note: type: Plain text
en: Enter 'git name-rev':
zh_HANS-CN: 输入 'git name-rev'：

note: type: Plain text
en: Now you are wiser, because you know that it happened 940 revisions before v0.99.
zh_HANS-CN: 现在你更聪明了，因为你知道它发生在 v0.99 之前的 940 次修订。

note: type: Plain text
en: Another nice thing you can do is:
zh_HANS-CN: 你可以做的另一件好事是：

note: type: Plain text
en: git-notes - Add or inspect object notes
zh_HANS-CN: git-notes - 添加或查看对象注释

note: type: Plain text
en: Adds, removes, or reads notes attached to objects, without touching the objects themselves.
zh_HANS-CN: 添加、移除或读取附加在对象上的注释，而不影响对象本身。

note: type: Plain text
en: By default, notes are saved to and read from `refs/notes/commits`, but this default can be overridden.  See the OPTIONS, CONFIGURATION, and ENVIRONMENT sections below.  If this ref does not exist, it will be quietly created when it is first needed to store a note.
zh_HANS-CN: 默认情况下，注释被保存在 `refs/notes/commits` 中，并且可以覆盖此默认设置。请参阅下面的 OPTIONS、CONFIGURATION 和 ENVIRONMENT 部分。如果该引用不存在，当首次需要存储注释时，它将被静默地创建。

note: type: Plain text
en: A typical use of notes is to supplement a commit message without changing the commit itself. Notes can be shown by 'git log' along with the original commit message. To distinguish these notes from the message stored in the commit object, the notes are indented like the message, after an unindented line saying "Notes (<refname>):" (or "Notes:" for `refs/notes/commits`).
zh_HANS-CN: 注释的一个典型用途是在不改变提交本身的情况下补充提交信息。注释可以通过 "git log "与原始提交信息一起显示。为了将这些注释与保存在提交对象中的消息区分开来，注释会像消息一样缩进，在未缩进的一行后面写上 "注释（<参考名称>）："（或 "注释："用于`参考/注释/提交`）。

note: type: Plain text
en: Notes can also be added to patches prepared with `git format-patch` by using the `--notes` option. Such notes are added as a patch commentary after a three dash separator line.
zh_HANS-CN: 注释也可以通过使用`git format-patch`选项添加到补丁中，`--notes`。这样的注释会作为补丁注释添加在三个破折号的分隔线之后。

note: type: Plain text
en: See the "notes.rewrite.<command>" configuration for a way to carry notes across commands that rewrite commits.
zh_HANS-CN: 参见 "notes.rewrite.<command>"配置，以了解在重写提交的命令中携带笔记的方法。

note: type: Title -
en: SUBCOMMANDS
zh_HANS-CN: 次级单位

note: type: Plain text
en: List the notes object for a given object. If no object is given, show a list of all note objects and the objects they annotate (in the format "<note object> <annotated object>").  This is the default subcommand if no subcommand is given.
zh_HANS-CN: 列出给定对象的注释对象。如果没有给定对象，则显示所有注解对象及其注解的对象的列表（格式为"<注解对象><注解对象>"）。  如果没有给出子命令，这是默认的子命令。

note: type: Plain text
en: Copy the notes for the first object onto the second object (defaults to HEAD). Abort if the second object already has notes, or if the first object has none (use -f to overwrite existing notes to the second object). This subcommand is equivalent to: `git notes add [-f] -C $(git notes list <from-object>) <to-object>`
zh_HANS-CN: 将第一个对象的注释复制到第二个对象上（默认为HEAD）。如果第二个对象已经有注解，或者第一个对象没有注解，则放弃（使用-f将现有注解覆盖到第二个对象）。这个子命令等同于。`git notes add [-f] -C $(git notes list <from-object>) <to-object>`。

note: type: Plain text
en: In `--stdin` mode, take lines in the format
zh_HANS-CN: 在`--stdin`模式下，采取格式为

note: type: Plain text
en: on standard input, and copy the notes from each <from-object> to its corresponding <to-object>.  (The optional `<rest>` is ignored so that the command can read the input given to the `post-rewrite` hook.)
zh_HANS-CN: 在标准输入中，将每个<from-object>中的注释复制到相应的<to-object>中。（可选的`<rest>`被忽略，以便命令可以读取给`post-rewrite`钩的输入）。

note: type: Plain text
en: Append new message(s) given by `-m` or `-F` options to an existing note, or add them as a new note if one does not exist, for the object (defaults to HEAD).  When appending to an existing note, a blank line is added before each new message as an inter-paragraph separator.  The separator can be customized with the `--separator` option.
zh_HANS-CN: 将 `-m` 或 `-F` 选项指定的新信息附加到现有注释中，或将不存在的信息作为新注释添加到对象中（默认为 HEAD）。 当添加到现有注释时，每条新信息前都会添加一个空行作为段间分隔符。 分隔符可使用 `--separator` 选项自定义。

note: type: Plain text
en: Edit the notes for a given object (defaults to HEAD).
zh_HANS-CN: 编辑一个给定对象的注释（默认为HEAD）。

note: type: Plain text
en: Show the notes for a given object (defaults to HEAD).
zh_HANS-CN: 显示一个给定对象的注释（默认为HEAD）。

note: type: Plain text
en: Merge the given notes ref into the current notes ref.  This will try to merge the changes made by the given notes ref (called "remote") since the merge-base (if any) into the current notes ref (called "local").
zh_HANS-CN: 将给定的注释参考文献合并到当前的注释参考文献中。  这将尝试把给定的注释（称为 "远程"）自合并基础（如果有的话）以来所做的修改合并到当前的注释（称为 "本地"）。

note: type: Plain text
en: If conflicts arise and a strategy for automatically resolving conflicting notes (see the "NOTES MERGE STRATEGIES" section) is not given, the "manual" resolver is used. This resolver checks out the conflicting notes in a special worktree (`.git/NOTES_MERGE_WORKTREE`), and instructs the user to manually resolve the conflicts there.  When done, the user can either finalize the merge with 'git notes merge --commit', or abort the merge with 'git notes merge --abort'.
zh_HANS-CN: 如果出现冲突，并且没有给出自动解决冲突笔记的策略（见 "NOTES MERGE STRATEGIES "一节），就会使用 "手动 "解决器。这个解决方法在一个特殊的工作树（`.git/NOTES_MERGE_WORKTREE`）中检查出冲突的笔记，并指示用户手动解决那里的冲突。  完成后，用户可以用 "git notes merge --commit "最终完成合并，或者用 "git notes merge --abort "中止合并。

note: type: Plain text
en: Remove the notes for given objects (defaults to HEAD). When giving zero or one object from the command line, this is equivalent to specifying an empty note message to the `edit` subcommand.
zh_HANS-CN: 删除给定对象的注释（默认为HEAD）。当从命令行给出零或一个对象时，这相当于给`edit`子命令指定一个空的注释信息。

note: type: Plain text
en: Remove all notes for non-existing/unreachable objects.
zh_HANS-CN: 删除所有不存在/无法到达的对象的注释。

note: type: Plain text
en: Print the current notes ref. This provides an easy way to retrieve the current notes ref (e.g. from scripts).
zh_HANS-CN: 打印当前的注释参考。这提供了一个简单的方法来检索当前的笔记参考文献（例如从脚本中）。

note: type: Plain text
en: When adding notes to an object that already has notes, overwrite the existing notes (instead of aborting).
zh_HANS-CN: 当向一个已经有注释的对象添加注释时，覆盖现有的注释（而不是中止）。

note: type: Labeled list
en: -C <object>
zh_HANS-CN: -C <对象>

note: type: Labeled list
en: -c <object>
zh_HANS-CN: -c <对象>

note: type: Plain text
en: Like '-C', but with `-c` the editor is invoked, so that the user can further edit the note message.
zh_HANS-CN: 像'-C'一样，但有了`-c'就会调用编辑器，这样用户就可以进一步编辑注释信息。

note: type: Plain text
en: Allow an empty note object to be stored. The default behavior is to automatically remove empty notes.
zh_HANS-CN: 允许存储一个空的笔记对象。默认行为是自动删除空笔记。

note: type: Plain text
en: Specify a string used as a custom inter-paragraph separator (a newline is added at the end as needed). If `--no-separator`, no separators will be added between paragraphs.  Defaults to a blank line.
zh_HANS-CN: 指定用于自定义段落间分隔符的字符串（根据需要在末尾添加换行符）。如果使用 `--no-separator`，则段落之间不添加分隔符。 默认为空行。

note: type: Plain text
en: Strip leading and trailing whitespace from the note message.  Also strip out empty lines other than a single line between paragraphs. For lines starting with `#` will be stripped out in non-editor cases like "-m", "-F" and "-C", but not in editor case like "git notes edit", "-c", etc.
zh_HANS-CN: 从备注信息中删除前导和尾部空白。 还会删除段落之间单行以外的空行。在 "-m"、"-F" 和 "-C" 等非编辑器情况下，以 `#` 开头的行将被删除，但在 "git notes edit"、"-c"等编辑器情况下则不会。

note: type: Plain text
en: Manipulate the notes tree in <ref>.  This overrides `GIT_NOTES_REF` and the "core.notesRef" configuration.  The ref specifies the full refname when it begins with `refs/notes/`; when it begins with `notes/`, `refs/` and otherwise `refs/notes/` is prefixed to form a full name of the ref.
zh_HANS-CN: 操纵<ref>中的笔记树。  这覆盖了`GIT_NOTES_REF`和 "core.notesRef "配置。  当Ref以`refs/notes/`开始时，指定完整的Ref名称；当它以`notes/`开始时，`refs/`，否则`refs/notes/`前缀，形成Ref的全名。

note: type: Plain text
en: Do not consider it an error to request removing notes from an object that does not have notes attached to it.
zh_HANS-CN: 不要认为请求从一个没有附加注释的对象上删除注释是一个错误。

note: type: Plain text
en: Also read the object names to remove notes from the standard input (there is no reason you cannot combine this with object names from the command line).
zh_HANS-CN: 还可以从标准输入中读取对象名称来删除注释（你没有理由不把它与命令行的对象名称结合起来）。

note: type: Plain text
en: Do not remove anything; just report the object names whose notes would be removed.
zh_HANS-CN: 不要删除任何东西；只是报告其注释将被删除的对象名称。

note: type: Plain text
en: When merging notes, resolve notes conflicts using the given strategy. The following strategies are recognized: "manual" (default), "ours", "theirs", "union" and "cat_sort_uniq".  This option overrides the "notes.mergeStrategy" configuration setting.  See the "NOTES MERGE STRATEGIES" section below for more information on each notes merge strategy.
zh_HANS-CN: 合并笔记时，使用给定的策略解决笔记冲突。以下策略是被认可的。"手动"（默认）、"我们的"、"他们的"、"联合 "和 "cat_sort_uniq"。  这个选项覆盖了 "notes.mergeStrategy "的配置设置。  关于每种笔记合并策略的更多信息，请看下面的 "笔记合并策略 "部分。

note: type: Plain text
en: Finalize an in-progress 'git notes merge'. Use this option when you have resolved the conflicts that 'git notes merge' stored in .git/NOTES_MERGE_WORKTREE. This amends the partial merge commit created by 'git notes merge' (stored in .git/NOTES_MERGE_PARTIAL) by adding the notes in .git/NOTES_MERGE_WORKTREE. The notes ref stored in the .git/NOTES_MERGE_REF symref is updated to the resulting commit.
zh_HANS-CN: 最终确定一个正在进行的'git notes merge'。当您解决了'git notes merge'存储在.git/NOTES_MERGE_WORKTREE中的冲突后，使用此选项。这将修正由'git notes merge'创建的部分合并提交（存储在.git/NOTES_MERGE_PARTIAL中），加入.git/NOTES_MERGE_WORKTREE中的注释。存储在 .git/NOTES_MERGE_REF 符号参考中的注释会被更新到结果提交中。

note: type: Plain text
en: Abort/reset an in-progress 'git notes merge', i.e. a notes merge with conflicts. This simply removes all files related to the notes merge.
zh_HANS-CN: 中止/重置正在进行的 "git笔记合并"，即有冲突的笔记合并。这只是删除了所有与笔记合并有关的文件。

note: type: Plain text
en: When merging notes, operate quietly.
zh_HANS-CN: 合并笔记时，要安静地操作。

note: type: Plain text
en: When merging notes, be more verbose.  When pruning notes, report all object names whose notes are removed.
zh_HANS-CN: 当合并笔记时，要更加详细。  当修剪注释时，报告所有被删除注释的对象名称。

note: type: Plain text
en: Commit notes are blobs containing extra information about an object (usually information to supplement a commit's message).  These blobs are taken from notes refs.  A notes ref is usually a branch which contains "files" whose paths are the object names for the objects they describe, with some directory separators included for performance reasons footnote:[Permitted pathnames have the form 'bf'`/`'fe'`/`'30'`/`'...'`/`'680d5a...': a sequence of directory names of two hexadecimal digits each followed by a filename with the rest of the object ID.].
zh_HANS-CN: 提交注释是包含关于一个对象的额外信息（通常是补充提交信息的信息）的 blobs。  这些blobs取自注释参考。  一个注释参考通常是一个包含 "文件 "的分支，这些文件的路径是它们所描述的对象的名称，出于性能的考虑，还包括一些目录分隔符 footnote:[允许的路径名有'bf'`/`'fe'`/`'30'`/`'...`/`'680d5a...'的形式：一串由两个十六进制数字组成的目录名，后面是一个带有其余对象ID的文件名。]

note: type: Plain text
en: Every notes change creates a new commit at the specified notes ref.  You can therefore inspect the history of the notes by invoking, e.g., `git log -p notes/commits`.  Currently the commit message only records which operation triggered the update, and the commit authorship is determined according to the usual rules (see linkgit:git-commit[1]).  These details may change in the future.
zh_HANS-CN: 每一个笔记的变化都会在指定的笔记参考号上创建一个新的提交。  因此，你可以通过调用，例如，`git log -p notes/commits`，来检查笔记的历史。  目前，提交信息只记录了哪个操作触发了更新，而提交者的身份则根据通常的规则确定（见 linkgit:git-commit[1]）。  这些细节在未来可能会发生变化。

note: type: Plain text
en: It is also permitted for a notes ref to point directly to a tree object, in which case the history of the notes can be read with `git log -p -g <refname>`.
zh_HANS-CN: 也允许注释直接指向树状对象，在这种情况下，可以用`git log -p -g <refname>`读取注释的历史。

note: type: Title -
en: NOTES MERGE STRATEGIES
zh_HANS-CN: 注释 合并策略

note: type: Plain text
en: The default notes merge strategy is "manual", which checks out conflicting notes in a special work tree for resolving notes conflicts (`.git/NOTES_MERGE_WORKTREE`), and instructs the user to resolve the conflicts in that work tree.  When done, the user can either finalize the merge with 'git notes merge --commit', or abort the merge with 'git notes merge --abort'.
zh_HANS-CN: 默认的笔记合并策略是 "手动"，它在一个用于解决笔记冲突的特殊工作树（`.git/NOTES_MERGE_WORKTREE`）中检查出冲突的笔记，并指示用户在该工作树中解决冲突。  完成后，用户可以用 "git notes merge --commit "最终完成合并，或者用 "git notes merge --abort "中止合并。

note: type: Plain text
en: Users may select an automated merge strategy from among the following using either -s/--strategy option or configuring notes.mergeStrategy accordingly:
zh_HANS-CN: 用户可以使用-s/--strategy选项或相应地配置notes.mergeStrategy，从以下内容中选择一个自动合并策略。

note: type: Plain text
en: "ours" automatically resolves conflicting notes in favor of the local version (i.e. the current notes ref).
zh_HANS-CN: "我们的 "自动解决冲突的注释，支持本地版本（即当前的注释参考）。

note: type: Plain text
en: "theirs" automatically resolves notes conflicts in favor of the remote version (i.e. the given notes ref being merged into the current notes ref).
zh_HANS-CN: "他们的 "自动解决笔记冲突，有利于远程版本（即给定的笔记参考文献被合并到当前的笔记参考文献中）。

note: type: Plain text
en: "union" automatically resolves notes conflicts by concatenating the local and remote versions.
zh_HANS-CN: "union "通过串联本地和远程版本自动解决注释冲突。

note: type: Plain text
en: "cat_sort_uniq" is similar to "union", but in addition to concatenating the local and remote versions, this strategy also sorts the resulting lines, and removes duplicate lines from the result. This is equivalent to applying the "cat | sort | uniq" shell pipeline to the local and remote versions. This strategy is useful if the notes follow a line-based format where one wants to avoid duplicated lines in the merge result.  Note that if either the local or remote version contain duplicate lines prior to the merge, these will also be removed by this notes merge strategy.
zh_HANS-CN: "cat_sort_uniq "与 "union "类似，但除了连接本地和远程版本之外，这个策略还对结果行进行排序，并从结果中删除重复的行。这相当于对本地和远程版本应用 "cat | sort | uniq "shell流水线。如果笔记是基于行的格式，希望在合并结果中避免重复的行，那么这个策略就很有用。  请注意，如果本地或远程版本在合并前包含重复的行，这些行也会被这个笔记合并策略所删除。

note: type: Plain text
en: You can use notes to add annotations with information that was not available at the time a commit was written.
zh_HANS-CN: 你可以使用注释来添加提交时无法获得的信息的注释。

note: type: delimited block -
en: Notes:
        Tested-by: Johannes Sixt <j6t@kdbg.org>
zh_HANS-CN: 注意事项。
        测试者： Johannes Sixt <j6t@kdbg.org>

note: type: Plain text
en: In principle, a note is a regular Git blob, and any kind of (non-)format is accepted.  You can binary-safely create notes from arbitrary files using 'git hash-object':
zh_HANS-CN: 原则上，笔记是一个普通的Git blob，任何种类的（非）格式都可以接受。  你可以使用 "git hash-object "从任意文件中二进制安全地创建注释。

note: type: Plain text
en: (You cannot simply use `git notes --ref=built add -F a.out HEAD` because that is not binary-safe.)  Of course, it doesn't make much sense to display non-text-format notes with 'git log', so if you use such notes, you'll probably need to write some special-purpose tools to do something useful with them.
zh_HANS-CN: (你不能简单地使用`git notes --ref=built add -F a.out HEAD`，因为这不是二进制安全的。)  当然，用'git log'来显示非文本格式的笔记没有什么意义，所以如果你使用这样的笔记，你可能需要写一些特殊用途的工具来对它们做一些有用的事情。

note: type: Plain text
en: Notes ref to read and manipulate instead of `refs/notes/commits`.  Must be an unabbreviated ref name.  This setting can be overridden through the environment and command line.
zh_HANS-CN: 读取和操作的注释，而不是`refs/notes/commits`。  必须是一个不简略的参考文献名称。  这个设置可以通过环境和命令行来覆盖。

note: type: Plain text
en: Which ref to manipulate notes from, instead of `refs/notes/commits`.  This overrides the `core.notesRef` setting.
zh_HANS-CN: 从哪个参考文献来操作笔记，而不是`refs/notes/commits`。  这覆盖了`core.notesRef'的设置。

note: type: Plain text
en: Colon-delimited list of refs or globs indicating which refs, in addition to the default from `core.notesRef` or `GIT_NOTES_REF`, to read notes from when showing commit messages.  This overrides the `notes.displayRef` setting.
zh_HANS-CN: 以冒号为界的参考文献或globs列表，表示除了默认的`core.notesRef`或`GIT_NOTES_REF`之外，在显示提交信息时要从哪些参考文献读取。  这取代了`notes.displayRef`的设置。

note: type: Plain text
en: A warning will be issued for refs that do not exist, but a glob that does not match any refs is silently ignored.
zh_HANS-CN: 对于不存在的 refs 将会发出警告，但是不匹配任何 refs 的 glob 会被默默地忽略。

note: type: Plain text
en: When copying notes during a rewrite, what to do if the target commit already has a note.  Must be one of `overwrite`, `concatenate`, `cat_sort_uniq`, or `ignore`.  This overrides the `core.rewriteMode` setting.
zh_HANS-CN: 在重写过程中复制注释时，如果目标提交已经有一个注释，该如何处理。  必须是`overwrite`, `concatenate`, `cat_sort_uniq`, 或 `ignore`之一。  这覆盖了`core.rewriteMode`的设置。

note: type: Plain text
en: When rewriting commits, which notes to copy from the original to the rewritten commit.  Must be a colon-delimited list of refs or globs.
zh_HANS-CN: 当重写提交时，要从原始提交中复制哪些注释到重写的提交中。  必须是一个以冒号分隔的 refs 或 globs 列表。

note: type: Plain text
en: If not set in the environment, the list of notes to copy depends on the `notes.rewrite.<command>` and `notes.rewriteRef` settings.
zh_HANS-CN: 如果环境中没有设置，要复制的笔记列表取决于`notes.rewrite.<command>`和`notes.rewriteRef`设置。

note: type: Plain text
en: git-p4 - Import from and submit to Perforce repositories
zh_HANS-CN: git-p4 - 从 Perforce 仓库导入和提交

note: type: Plain text
en: Reads list of objects from the standard input, and writes either one or more packed archives with the specified base-name to disk, or a packed archive to the standard output.
zh_HANS-CN: 从标准输入读取对象列表，并将一个或多个指定基数名称的打包档案写入磁盘，或将一个打包档案写入标准输出。

note: type: Plain text
en: A packed archive is an efficient way to transfer a set of objects between two repositories as well as an access efficient archival format.  In a packed archive, an object is either stored as a compressed whole or as a difference from some other object.  The latter is often called a delta.
zh_HANS-CN: 打包档案是在两个储存库之间转移一组对象的有效方法，也是一种有效的存取档案格式。 在打包的档案中，一个对象要么是作为一个压缩的整体来存储，要么是作为与其他对象的区别来存储。 后者通常被称为 delta。

note: type: Plain text
en: The packed archive format (.pack) is designed to be self-contained so that it can be unpacked without any further information. Therefore, each object that a delta depends upon must be present within the pack.
zh_HANS-CN: 打包的档案格式（.pack）被设计为自成一体，这样它就可以在没有任何进一步信息的情况下被解包。因此，delta 所依赖的每个对象都必须存在于pack 中。

note: type: Plain text
en: A pack index file (.idx) is generated for fast, random access to the objects in the pack. Placing both the index file (.idx) and the packed archive (.pack) in the pack/ subdirectory of $GIT_OBJECT_DIRECTORY (or any of the directories on $GIT_ALTERNATE_OBJECT_DIRECTORIES)  enables Git to read from the pack archive.
zh_HANS-CN: 一个打包的索引文件（.idx）被生成，以便快速、随机地访问打包中的对象。将索引文件（.idx）和打包的归档文件（.pack）放在$GIT_OBJECT_DIRECTORY（或 $GIT_ALTERNATE_OBJECT_DIRECTORIES 上的任何一个目录）的 pack/ 子目录下，可以使 Git 从打包的归档文件中读取。

note: type: Plain text
en: The 'git unpack-objects' command can read the packed archive and expand the objects contained in the pack into "one-file one-object" format; this is typically done by the smart-pull commands when a pack is created on-the-fly for efficient network transport by their peers.
zh_HANS-CN: 'git unpack-objects' 命令可以读取打包后的档案，并将打包后的对象扩展为 “一对一的文件 - 对象” 的格式；这通常是由 smart-pull 命令在即时创建打包时完成的，以便由它们的同行进行有效的网络传输。

note: type: Plain text
en: Write into pairs of files (.pack and .idx), using <base-name> to determine the name of the created file.  When this option is used, the two files in a pair are written in <base-name>-<SHA-1>.{pack,idx} files.  <SHA-1> is a hash based on the pack content and is written to the standard output of the command.
zh_HANS-CN: 写入成对的文件（.pack 和 .idx），使用 <base-name> 来确定创建的文件名。 当使用该选项时，一对中的两个文件被写入 <base-name>-<SHA-1>.{pack,idx} 文件。 <SHA-1> 是一个基于 pack 内容的哈希值，会写入命令的标准输出中。

note: type: Plain text
en: Write the pack contents (what would have been written to .pack file) out to the standard output.
zh_HANS-CN: 将包的内容（本来要写到 .pack 文件中的内容）写到标准输出中。

note: type: Plain text
en: Read the revision arguments from the standard input, instead of individual object names.  The revision arguments are processed the same way as 'git rev-list' with the `--objects` flag uses its `commit` arguments to build the list of objects it outputs.  The objects on the resulting list are packed.  Besides revisions, `--not` or `--shallow <SHA-1>` lines are also accepted.
zh_HANS-CN: 从标准输入读取修订参数，而不是单个对象名称。 修订版参数的处理方式与带有 `--object` 标志的 'git rev-list' 使用其 `commit` 参数来建立其输出的对象列表相同。 结果列表上的对象被打包。 除了修订，还接受 `--not` 或 `--shallow <SHA-1>` 行。

note: type: Plain text
en: This implies `--revs`.  When processing the list of revision arguments read from the standard input, limit the objects packed to those that are not already packed.
zh_HANS-CN: 这暗指 `--revs`。 当处理从标准输入读取的修订参数列表时，将打包的对象限制在那些尚未打包的对象。

note: type: Plain text
en: This implies `--revs`.  In addition to the list of revision arguments read from the standard input, pretend as if all refs under `refs/` are specified to be included.
zh_HANS-CN: 这暗指 `--revs`。 除了从标准输入中读取的修订参数列表外，还假设指定要包括 `refs/`下的所有引用。

note: type: Plain text
en: Include unasked-for annotated tags if the object they reference was included in the resulting packfile.  This can be useful to send new tags to native Git clients.
zh_HANS-CN: 包括未被要求的注释标签，如果它们引用的对象被包含在结果的打包文件中。 这对于向本地 Git 客户端发送新的标签很有用。

note: type: Plain text
en: Read the basenames of packfiles (e.g., `pack-1234abcd.pack`)  from the standard input, instead of object names or revision arguments. The resulting pack contains all objects listed in the included packs (those not beginning with `^`), excluding any objects listed in the excluded packs (beginning with `^`).
zh_HANS-CN: 从标准输入中读取 packfiles（例如：`pack-1234abcd.pack`）的基本名称，而不是对象名称或修订参数。产生的数据包包含所有在包含的数据包中列出的对象（那些不是以 `^` 开头的），排除在排除的数据包中列出的任何对象（以 `^` 开头）。

note: type: Plain text
en: Incompatible with `--revs`, or options that imply `--revs` (such as `--all`), with the exception of `--unpacked`, which is compatible.
zh_HANS-CN: 与 `--revs` 或暗指 `--revs` 的选项（如 `--all`）不兼容，但 `--unpacked` 除外，它是兼容的。

note: type: Plain text
en: Packs unreachable objects into a separate "cruft" pack, denoted by the existence of a `.mtimes` file. Typically used by `git repack --cruft`. Callers provide a list of pack names and indicate which packs will remain in the repository, along with which packs will be deleted (indicated by the `-` prefix). The contents of the cruft pack are all objects not contained in the surviving packs which have not exceeded the grace period (see `--cruft-expiration` below), or which have exceeded the grace period, but are reachable from an other object which hasn't.
zh_HANS-CN: 将无法到达的对象打包到一个单独的 "cruft" 包中，以 `.mtimes` 文件的存在为标志。通常由`git repack --cruft`使用。调用者提供一个包的名称列表，并指出哪些包将保留在版本库中，以及哪些包将被删除（用 `-` 前缀表示）。cruft 包的内容是所有不包含在幸存的包中的对象，它们没有超过宽限期（见下面的 `--cruft-expiration`），或者它们已经超过了宽限期，但可以从其他没有超过宽限期的对象中到达。

note: type: Plain text
en: When the input lists a pack containing all reachable objects (and lists all other packs as pending deletion), the corresponding cruft pack will contain all unreachable objects (with mtime newer than the `--cruft-expiration`) along with any unreachable objects whose mtime is older than the `--cruft-expiration`, but are reachable from an unreachable object whose mtime is newer than the `--cruft-expiration`).
zh_HANS-CN: 当输入列出一个包含所有可达对象的包（并将所有其他包列为待删除），相应的 cruft 包将包含所有不可达对象（其 mtime 比 `--cruft-expiration` 新），以及任何 mtime 比 `--cruft-expiration` 早，但可从 mtime 比 `--cruft-expiration` 新的不可达对象到达的不可达对象）。

note: type: Plain text
en: Incompatible with `--unpack-unreachable`, `--keep-unreachable`, `--pack-loose-unreachable`, `--stdin-packs`, as well as any other options which imply `--revs`. Also incompatible with `--max-pack-size`; when this option is set, the maximum pack size is not inferred from `pack.packSizeLimit`.
zh_HANS-CN: 与 `--unpack-unreachable`, `--keep-unreachable`, `--pack-loose-unreachable`, `--stdin-packs`，以及任何其他暗指 `--revs` 的选项不兼容。也与 `--max-pack-size` 不兼容；当这个选项被设置时，最大的包尺寸不会从`pack.packSizeLimit`中推断出来。

note: type: Plain text
en: If specified, objects are eliminated from the cruft pack if they have an mtime older than `<approxidate>`. If unspecified (and given `--cruft`), then no objects are eliminated.
zh_HANS-CN: 如果指定了，且对象的 mtime 超过 `<approxidate>`，就会从 cruft 包中剔除。如果没有指定（并给出 `--cruft'），那么没有对象被淘汰。

note: type: Plain text
en: These two options affect how the objects contained in the pack are stored using delta compression.  The objects are first internally sorted by type, size and optionally names and compared against the other objects within --window to see if using delta compression saves space.  --depth limits the maximum delta depth; making it too deep affects the performance on the unpacker side, because delta data needs to be applied that many times to get to the necessary object.
zh_HANS-CN: 这两个选项影响了使用 delta 压缩法存储数据包中的对象的方式。 这些对象首先按照类型、大小和可选的名称进行内部排序，并与 --window 内的其他对象进行比较，看使用 delta 压缩是否节省了空间。 --depth 限制了最大的 delta 深度；使其过深会影响到解包方的性能，因为 delta 数据需要应用那么多次才能到达必要的对象。

note: type: Plain text
en: This option provides an additional limit on top of `--window`; the window size will dynamically scale down so as to not take up more than '<n>' bytes in memory.  This is useful in repositories with a mix of large and small objects to not run out of memory with a large window, but still be able to take advantage of the large window for the smaller objects.  The size can be suffixed with "k", "m", or "g".  `--window-memory=0` makes memory usage unlimited.  The default is taken from the `pack.windowMemory` configuration variable.
zh_HANS-CN: 这个选项在 `--window` 的基础上提供了一个额外的限制；窗口的大小将动态地缩小，以便不占用超过 '<n>' 字节的内存。 这对有大有小的对象的存储库很有用，它不会因为大窗口而耗尽内存，但仍然能够利用大窗口来处理小对象。 大小可以以 "k"、"m "或 "g "为后缀。 `--window-memory=0` 使内存使用不受限制。 默认值取自`pack.windowMemory` 配置变量。

note: type: Plain text
en: In unusual scenarios, you may not be able to create files larger than a certain size on your filesystem, and this option can be used to tell the command to split the output packfile into multiple independent packfiles, each not larger than the given size. The size can be suffixed with "k", "m", or "g". The minimum size allowed is limited to 1 MiB.  The default is unlimited, unless the config variable `pack.packSizeLimit` is set. Note that this option may result in a larger and slower repository; see the discussion in `pack.packSizeLimit`.
zh_HANS-CN: 在不寻常的情况下，你可能无法在你的文件系统上创建大于一定大小的文件，这个选项可以用来告诉命令将输出的 packfile 分割成多个独立的 packfile，每个 packfile 都不大于给定的大小。大小可以以 "k"、"m "或 "g "为后缀。允许的最小尺寸被限制为1 MiB。 默认是无限制的，除非配置变量`pack.packSizeLimit` 被设置。注意，这个选项可能会导致仓库变大变慢；参见 `pack.packSizeLimit`中的讨论。

note: type: Plain text
en: This flag causes an object already in a local pack that has a .keep file to be ignored, even if it would have otherwise been packed.
zh_HANS-CN: 这个标志会使一个已经在本地打包的对象被忽略，即使它本来会被打包。

note: type: Plain text
en: This flag causes an object already in the given pack to be ignored, even if it would have otherwise been packed. `<pack-name>` is the pack file name without leading directory (e.g. `pack-123.pack`). The option could be specified multiple times to keep multiple packs.
zh_HANS-CN: 这个标志使已经在给定包中的对象被忽略，即使它本来已经被打包。`<pack-name>` 是不带前导目录的包文件名（例如：`pack-123.pack`）。该选项可以被多次指定以保留多个包。

note: type: Plain text
en: This flag causes an object already in a pack to be ignored even if it would have otherwise been packed.
zh_HANS-CN: 这个标志使已经在包装中的对象被忽略，即使它本来会被包装。

note: type: Plain text
en: This flag causes an object that is borrowed from an alternate object store to be ignored even if it would have otherwise been packed.
zh_HANS-CN: 这个标志导致从另一个对象存储空间借来的对象被忽略，即使它本来会被打包。

note: type: Plain text
en: Only create a packed archive if it would contain at least one object.
zh_HANS-CN: 只有在至少包含一个对象的情况下才会创建一个打包的档案。

note: type: Plain text
en: When --stdout is specified then progress report is displayed during the object count and compression phases but inhibited during the write-out phase. The reason is that in some cases the output stream is directly linked to another command which may wish to display progress status of its own as it processes incoming pack data.  This flag is like --progress except that it forces progress report for the write-out phase as well even if --stdout is used.
zh_HANS-CN: 当指定 --stdout 时，在对象计数和压缩阶段会显示进度报告，但在写出阶段会被抑制。原因是在某些情况下，输出流直接与另一个命令相连，而后者在处理输入的数据时可能希望显示自己的进度状态。 这个标志和 --progress 一样，只是它在写出阶段也强制显示进度报告，即使使用了 --stdout。

note: type: Plain text
en: This is used to imply --all-progress whenever progress display is activated.  Unlike --all-progress this flag doesn't actually force any progress display by itself.
zh_HANS-CN: 当进度显示被激活时，它被用来暗指 --all-progress。 与 --all-progress 不同的是，这个标志本身实际上并不强制显示任何进度。

note: type: Plain text
en: When creating a packed archive in a repository that has existing packs, the command reuses existing deltas.  This sometimes results in a slightly suboptimal pack.  This flag tells the command not to reuse existing deltas but compute them from scratch.
zh_HANS-CN: 当在已有打包的版本库中创建一个打包的归档文件时，该命令会重用现有的三角洲。 这有时会导致一个稍微次优的打包。 这个标志告诉命令不要重用现有的 deltas，而是从头开始计算。

note: type: Plain text
en: This flag tells the command not to reuse existing object data at all, including non deltified object, forcing recompression of everything.  This implies --no-reuse-delta. Useful only in the obscure case where wholesale enforcement of a different compression level on the packed data is desired.
zh_HANS-CN: 这个标志告诉命令不要重复使用现有的对象数据，包括非延迟对象，强迫重新压缩所有东西。 这意味着 --no-reuse-delta。只有在需要对打包的数据全盘执行不同的压缩级别的隐蔽情况下才有用。

note: type: Plain text
en: Specifies compression level for newly-compressed data in the generated pack.  If not specified, pack compression level is determined first by pack.compression, then by core.compression, and defaults to -1, the zlib default, if neither is set.  Add --no-reuse-object if you want to force a uniform compression level on all data no matter the source.
zh_HANS-CN: 为生成的数据包中新压缩的数据指定压缩级别。 如果没有指定，数据包的压缩级别首先由 pack.compression 决定，然后由 core.compression 决定，如果两者都没有设置，则默认为 -1，即 zlib 默认值。 如果你想在所有的数据上强制使用统一的压缩级别，无论其来源如何，请添加 --no-reuse-object。

note: type: Plain text
en: Toggle the "sparse" algorithm to determine which objects to include in the pack, when combined with the "--revs" option. This algorithm only walks trees that appear in paths that introduce new objects.  This can have significant performance benefits when computing a pack to send a small change. However, it is possible that extra objects are added to the pack-file if the included commits contain certain types of direct renames. If this option is not included, it defaults to the value of `pack.useSparse`, which is true unless otherwise specified.
zh_HANS-CN: 与 "--revs" 选项结合使用时，切换 "稀疏" 算法，以确定哪些对象应包含在数据包中。这种算法只行走那些出现在引入新对象的路径中的树。 当计算一个包来发送一个小的变化时，这可能有显著的性能优势。然而，如果所包含的提交包含某些类型的直接重命名，则可能会有额外的对象被添加到包文件中。如果不包括这个选项，它默认为 `pack.useSparse` 的值，除非另有规定，否则为真。

note: type: Plain text
en: Create a "thin" pack by omitting the common objects between a sender and a receiver in order to reduce network transfer. This option only makes sense in conjunction with --stdout.
zh_HANS-CN: 通过省略发送方和接收方之间的共同对象来创建一个 "轻量" 包，以减少网络传输。这个选项只有在与 --stdout 一起使用时才有意义。

note: type: Plain text
en: Note: A thin pack violates the packed archive format by omitting required objects and is thus unusable by Git without making it self-contained. Use `git index-pack --fix-thin` (see linkgit:git-index-pack[1]) to restore the self-contained property.
zh_HANS-CN: 注意：轻量包由于省略了所需的对象而违反了打包的存档格式，因此如果不使其自成一体，Git 就无法使用。使用 `git index-pack --fix-thin` （ linkgit:git-index-pack[1]）来恢复自包含的属性。

note: type: Plain text
en: Optimize a pack that will be provided to a client with a shallow repository.  This option, combined with --thin, can result in a smaller pack at the cost of speed.
zh_HANS-CN: 优化将被提供给客户的浅克隆仓库的数据包。 这个选项和 --thin 结合起来，可以以速度为代价，产生一个更小的包。

note: type: Plain text
en: A packed archive can express the base object of a delta as either a 20-byte object name or as an offset in the stream, but ancient versions of Git don't understand the latter.  By default, 'git pack-objects' only uses the former format for better compatibility.  This option allows the command to use the latter format for compactness.  Depending on the average delta chain length, this option typically shrinks the resulting packfile by 3-5 per-cent.
zh_HANS-CN: 打包后的归档文件可以用 20 字节的对象名称或流中的偏移量来表达 delta 的基础对象，但早期版本的 Git 不理解后者。 默认情况下，'git pack-objects' 只使用前一种格式，以提高兼容性。 这个选项允许该命令使用后者的格式以达到紧凑的目的。 根据 delta 链的平均长度，这个选项通常会将生成的 packfile 缩小 3-5%。

note: type: Plain text
en: Note: Porcelain commands such as `git gc` (see linkgit:git-gc[1]), `git repack` (see linkgit:git-repack[1]) pass this option by default in modern Git when they put objects in your repository into pack files.  So does `git bundle` (see linkgit:git-bundle[1]) when it creates a bundle.
zh_HANS-CN: 注意: 在现版本 Git 中，诸如 `git gc` (参见 linkgit:git-gc[1])、`git repack` (参见 linkgit:git-repack[1])之类的上层命令在将仓库中的对象放入打包文件时，默认会传递这个选项。 当 `git bundle` (参见 linkgit:git-bundle[1])创建一个捆绑包时也会这样做。

note: type: Plain text
en: Specifies the number of threads to spawn when searching for best delta matches.  This requires that pack-objects be compiled with pthreads otherwise this option is ignored with a warning.  This is meant to reduce packing time on multiprocessor machines.  The required amount of memory for the delta search window is however multiplied by the number of threads.  Specifying 0 will cause Git to auto-detect the number of CPU's and set the number of threads accordingly.
zh_HANS-CN: 指定搜索最佳 delta 匹配时产生的线程数。 这要求 pack-objects 使用 pthreads 编译，否则该选项将被忽略并发出警告。 这样做的目的是在多处理器机器上减少打包时间。 然而，delta 搜索窗口所需的内存会乘以线程数。 指定 0 将导致 Git 自动检测 CPU 数量并相应设置线程数量。

note: type: Plain text
en: With this option, parents that are hidden by grafts are packed nevertheless.
zh_HANS-CN: 通过这种方法，被移植物覆盖的父母还是会被打包。

note: type: Plain text
en: Requires `--stdout`.  Omits certain objects (usually blobs) from the resulting packfile.  See linkgit:git-rev-list[1] for valid `<filter-spec>` forms.
zh_HANS-CN: 需要 `--stdout`。 从生成的 packfile 中省略某些对象（通常是 blobs）。 参见 linkgit:git-rev-list[1] 以了解有效的 `<filter-spec>` 形式。

note: type: Plain text
en: Turns off any previous `--filter=` argument.
zh_HANS-CN: 关闭之前的 `--filter=` 参数。

note: type: Labeled list
en: --missing=<missing-action>
zh_HANS-CN: --missing=<missing-action>（缺失）。

note: type: Plain text
en: A debug option to help with future "partial clone" development.  This option specifies how missing objects are handled.
zh_HANS-CN: 一个调试选项，帮助未来的 "部分克隆 "开发。  这个选项指定了如何处理丢失的对象。

note: type: Plain text
en: The form '--missing=error' requests that pack-objects stop with an error if a missing object is encountered.  If the repository is a partial clone, an attempt to fetch missing objects will be made before declaring them missing.  This is the default action.
zh_HANS-CN: 表格 '--missing=error' 请求在遇到丢失对象时以错误停止 pack-objects。 如果仓库是部分克隆，在宣布丢失之前会尝试获取丢失的对象。 这是默认行为。

note: type: Plain text
en: The form '--missing=allow-any' will allow object traversal to continue if a missing object is encountered.  No fetch of a missing object will occur.  Missing objects will silently be omitted from the results.
zh_HANS-CN: 形式 '--missing=allow-any' 将允许在遇到丢失对象时继续遍历对象。 不会获取丢失的对象。 缺少的对象将从结果中被静默省略。

note: type: Plain text
en: The form '--missing=allow-promisor' is like 'allow-any', but will only allow object traversal to continue for EXPECTED promisor missing objects.  No fetch of a missing object will occur.  An unexpected missing object will raise an error.
zh_HANS-CN: 形式 '--missing=allow-promisor' 类似于 'allow-any'，但只允许继续遍历预期 promisor 丢失的对象。 不会获取丢失的对象。 意外丢失的对象将引发错误。

note: type: Plain text
en: Omit objects that are known to be in the promisor remote.  (This option has the purpose of operating only on locally created objects, so that when we repack, we still maintain a distinction between locally created objects [without .promisor] and objects from the promisor remote [with .promisor].)  This is used with partial clone.
zh_HANS-CN: 省略已知在远程 promisor 中的对象。 （该选项的目的是只对本地创建的对象执行操作，这样当我们重新打包时，仍然可以区分本地创建的对象 [不含 .promisor] 和来自远程 promisor [含 .promisor] 的对象)。 该选项与部分克隆一起使用。

note: type: Plain text
en: Objects unreachable from the refs in packs named with --unpacked= option are added to the resulting pack, in addition to the reachable objects that are not in packs marked with *.keep files. This implies `--revs`.
zh_HANS-CN: 除了标有 *.keep 文件的包中没有的可到达对象之外，用 --unpacked= 选项命名的包中的引用无法到达的对象也会被添加到生成的包中。这意味着`--revs`。

note: type: Plain text
en: Pack unreachable loose objects (and their loose counterparts removed). This implies `--revs`.
zh_HANS-CN: 打包不可达的松散对象（并移除它们的松散对应对象）。这意味着`--revs`.

note: type: Plain text
en: Keep unreachable objects in loose form. This implies `--revs`.
zh_HANS-CN: 以松散的形式保存无法访问的对象。这意味着 `--revs`。

note: type: Plain text
en: Restrict delta matches based on "islands". See DELTA ISLANDS below.
zh_HANS-CN: 根据 “岛屿” 限制增量匹配。请参阅下文的增量匹配。

note: type: Plain text
en: When possible, `pack-objects` tries to reuse existing on-disk deltas to avoid having to search for new ones on the fly. This is an important optimization for serving fetches, because it means the server can avoid inflating most objects at all and just send the bytes directly from disk. This optimization can't work when an object is stored as a delta against a base which the receiver does not have (and which we are not already sending). In that case the server "breaks" the delta and has to find a new one, which has a high CPU cost. Therefore it's important for performance that the set of objects in on-disk delta relationships match what a client would fetch.
zh_HANS-CN: 在可能的情况下， `pack-objects` 尝试重用现有的磁盘上的 deltas，以避免临时搜索新的 deltas。这对于服务获取来说是一个重要的优化，因为它意味着服务器可以完全避免膨胀大多数对象，而只是直接从磁盘发送字节。当一个对象以 delta 的形式存储，而接收者并不拥有（而且我们也没有发送）这个基数时，这种优化就不起作用了。在这种情况下，服务器将 “中断” delta，并必须找到一个新的delta，这将产生很高的 CPU 成本。因此，磁盘上 delta 关系中的对象集必须与客户端获取的对象相匹配，这对性能非常重要。

note: type: Plain text
en: In a normal repository, this tends to work automatically. The objects are mostly reachable from the branches and tags, and that's what clients fetch. Any deltas we find on the server are likely to be between objects the client has or will have.
zh_HANS-CN: 在正常的仓库中，这往往是自动进行的。对象大多可以从分支和标签中获取，这也是客户端获取的内容。我们在服务器上发现的任何脱节都可能是客户端已经拥有或将要拥有的对象之间的脱节。

note: type: Plain text
en: But in some repository setups, you may have several related but separate groups of ref tips, with clients tending to fetch those groups independently. For example, imagine that you are hosting several "forks" of a repository in a single shared object store, and letting clients view them as separate repositories through `GIT_NAMESPACE` or separate repos using the alternates mechanism. A naive repack may find that the optimal delta for an object is against a base that is only found in another fork. But when a client fetches, they will not have the base object, and we'll have to find a new delta on the fly.
zh_HANS-CN: 但在某些仓库设置中，您可能有几个相关但独立的引用提示组，客户端倾向于独立获取这些组。例如，假设你在一个共享对象存储空间中托管了多个版本库的 "fork"，并通过`GIT_NAMESPACE`或使用替代机制的独立仓库让客户端将它们视为独立的仓库。天真的 repack 可能会发现，一个对象的最佳 delta 是针对只有在另一个 fork 中才能找到的基数。但是，当客户端获取时，他们将没有基础对象，我们将不得不临时找到一个新的 delta。

note: type: Plain text
en: A similar situation may exist if you have many refs outside of `refs/heads/` and `refs/tags/` that point to related objects (e.g., `refs/pull` or `refs/changes` used by some hosting providers). By default, clients fetch only heads and tags, and deltas against objects found only in those other groups cannot be sent as-is.
zh_HANS-CN: 如果在 `refs/heads/` 和 `refs/tags/` 之外有许多指向相关对象的引用（例如，某些托管提供商使用的 `refs/pull` 或 `refs/changes`），也可能存在类似的情况。默认情况下，客户端只获取 heads 和 tags，因此不能发送只在这些组中找到的对象的 deltas。

note: type: Plain text
en: Delta islands solve this problem by allowing you to group your refs into distinct "islands". Pack-objects computes which objects are reachable from which islands, and refuses to make a delta from an object `A` against a base which is not present in all of `A`'s islands. This results in slightly larger packs (because we miss some delta opportunities), but guarantees that a fetch of one island will not have to recompute deltas on the fly due to crossing island boundaries.
zh_HANS-CN: Delta 岛解决了这个问题，它允许您将您的引用分组为不同的 “岛”。Pack-objects 会计算哪些对象可以从哪些岛屿到达，并拒绝从对象 `A` 针对不存在于所有 `A` 岛屿中的基准进行 delta。这会导致数据包略微变大(因为我们错过了一些 delta 机会)，但保证了对一个岛的取值不会因为跨越岛的边界而不得不重新计算 delta。

note: type: Plain text
en: When repacking with delta islands the delta window tends to get clogged with candidates that are forbidden by the config. Repacking with a big --window helps (and doesn't take as long as it otherwise might because we can reject some object pairs based on islands before doing any computation on the content).
zh_HANS-CN: 当使用 delta 岛重新打包时，delta 窗口往往会被配置禁止的候选对象堵塞。使用大的 --window 进行重新打包会有所帮助（而且不会像其他情况下花费那么长的时间，因为在对内容进行任何计算之前，我们可以根据岛拒绝一些对象对）。

note: type: Plain text
en: Islands are configured via the `pack.island` option, which can be specified multiple times. Each value is a left-anchored regular expressions matching refnames. For example:
zh_HANS-CN: 岛是通过 `pack.island` 选项配置的，可以多次指定。每个值都是匹配 refnames 的左锚正则表达式。例如 :

note: type: Plain text
en: puts heads and tags into an island (whose name is the empty string; see below for more on naming). Any refs which do not match those regular expressions (e.g., `refs/pull/123`) is not in any island. Any object which is reachable only from `refs/pull/` (but not heads or tags) is therefore not a candidate to be used as a base for `refs/heads/`.
zh_HANS-CN: 将 heads 和 tags 放入一个 “岛” 中（其名称为空字符串；有关命名的更多信息，请参阅下文）。任何不匹配这些正则表达式的引用（例如 `refs/pull/123`）都不在任何岛中。因此，任何只能从 `refs/pull/` (而不能从 heads 或 tags) 访问的对象都不能作为 `refs/heads/` 的基础。

note: type: Plain text
en: Refs are grouped into islands based on their "names", and two regexes that produce the same name are considered to be in the same island. The names are computed from the regexes by concatenating any capture groups from the regex, with a '-' dash in between. (And if there are no capture groups, then the name is the empty string, as in the above example.) This allows you to create arbitrary numbers of islands. Only up to 14 such capture groups are supported though.
zh_HANS-CN: 参考文件根据其 “名称” 分组，产生相同名称的两个 regex 被视为在同一个岛中。名称是通过连接 regex 中的任何捕获组和中间的 '-' 破折号来计算的。(如果没有捕获组，则名称为空字符串，如上例）。这允许您创建任意数量的岛屿。但最多只支持 14 个这样的捕获组。

note: type: Plain text
en: For example, imagine you store the refs for each fork in `refs/virtual/ID`, where `ID` is a numeric identifier. You might then configure:
zh_HANS-CN: 例如，假设你在 `refs/virtual/ID` 中存储了每个 fork 的引用，其中 `ID` 是一个数字标识符。然后您可以配置 :

note: type: Plain text
en: That puts the heads and tags for each fork in their own island (named "1234" or similar), and the pull refs for each go into their own "1234-pull".
zh_HANS-CN: 这就将每个分叉的头和标签放在自己的岛（命名为 "1234" 或类似的名字）中，而每个分叉的拉动参考则放在自己的 "1234-pull "中。

note: type: Plain text
en: Note that we pick a single island for each regex to go into, using "last one wins" ordering (which allows repo-specific config to take precedence over user-wide config, and so forth).
zh_HANS-CN: 请注意，我们为每个 regex 选择一个单独的岛，使用 "最后一个获胜" 的排序（这允许特定于仓库的配置优先于用户范围内的配置，等等）。

note: type: Plain text
en: Various configuration variables affect packing, see linkgit:git-config[1] (search for "pack" and "delta").
zh_HANS-CN: 各种配置变量会影响打包，参见 linkgit:git-config[1] (搜索 "pack" 和 "delta")。

note: type: Plain text
en: Notably, delta compression is not used on objects larger than the `core.bigFileThreshold` configuration variable and on files with the attribute `delta` set to false.
zh_HANS-CN: 值得注意的是，delta 压缩不用于大于 `core.bigFileThreshold` 配置变量的对象和属性 `delta` 设置为 false 的文件。

note: type: Plain text
en: `git pack-redundant` has been deprecated and is scheduled for removal in a future version of Git. Because it can only remove entire duplicate packs and not individual duplicate objects, it is generally not a useful tool for reducing repository size. You are better off using `git gc` to do so, which will put objects into a new pack, removing duplicates.
zh_HANS-CN: `git pack-redundant` 已被弃用，并计划在未来的 Git 版本中移除。因为它只能移除整个重复的包，而不能移除单个重复的对象，所以它通常不是减少版本库大小的有用工具。最好使用 `git gc`，它会将对象放入一个新的包，删除重复的对象。

note: type: Plain text
en: Running `pack-redundant` without the `--i-still-use-this` flag will fail in this release. If you believe you have a use case for which `pack-redundant` is better suited and oppose this removal, please contact the Git mailing list at git@vger.kernel.org. More information about the list is available at https://git-scm.com/community.
zh_HANS-CN: 在此版本中，运行不带 `--i-still-use-this` 标志的`pack-redundant` 将失败。如果您认为 `pack-redundant` 更适合您的用例，并反对删除该标志，请联系 Git 邮件列表 git@vger.kernel.org。有关该列表的更多信息，请访问 https://git-scm.com/community。

note: type: Plain text
en: This program computes which packs in your repository are redundant. The output is suitable for piping to `xargs rm` if you are in the root of the repository.
zh_HANS-CN: 该程序计算仓库中哪些包是多余的。如果你在仓库的根目录下，输出结果可以通过管道连接到 `xargs rm`。

note: type: Plain text
en: 'git pack-redundant' accepts a list of objects on standard input. Any objects given will be ignored when checking which packs are required. This makes the following command useful when wanting to remove packs which contain unreachable objects.
zh_HANS-CN: 'git pack-redundant' 接受标准输入的对象列表。在检查需要哪些包时，给定的对象将被忽略。这使得下面的命令在移除包含不可达对象的包时非常有用。

note: type: Plain text
en: Processes all packs. Any filenames on the command line are ignored.
zh_HANS-CN: 处理所有数据包。忽略命令行中的任何文件名。

note: type: Plain text
en: Don't require objects present in packs from alternate object database (odb) directories to be present in local packs.
zh_HANS-CN: 不要求来自备用对象数据库（odb）目录的数据包中的对象也出现在本地数据包中。

note: type: Plain text
en: Outputs some statistics to stderr. Has a small performance penalty.
zh_HANS-CN: 向标注错误流输出一些统计数据。对性能有一点影响。

note: type: Plain text
en: git-pack-refs - Pack heads and tags for efficient repository access
zh_HANS-CN: git-pack-refs - 打包头和标签，以便有效地访问仓库

note: type: Plain text
en: Traditionally, tips of branches and tags (collectively known as 'refs') were stored one file per ref in a (sub)directory under `$GIT_DIR/refs` directory.  While many branch tips tend to be updated often, most tags and some branch tips are never updated.  When a repository has hundreds or thousands of tags, this one-file-per-ref format both wastes storage and hurts performance.
zh_HANS-CN: 传统上，分支和标签的提示（统称为 'refs'）是在 `$GIT_DIR/refs` 目录下的一个（子）目录中，为每个引用储存一个文件。 虽然许多分支的提示经常被更新，但大多数标签和一些分支的提示从未被更新。 当一个仓库库有成百上千的标签时，这种每个引用一个文件的格式既浪费了存储空间，又损害了性能。

note: type: Plain text
en: This command is used to solve the storage and performance problem by storing the refs in a single file, `$GIT_DIR/packed-refs`.  When a ref is missing from the traditional `$GIT_DIR/refs` directory hierarchy, it is looked up in this file and used if found.
zh_HANS-CN: 这个命令是用来解决存储和性能问题的，将引用存储在一个文件中，`$GIT_DIR/packed-refs`。 当传统的 `$GIT_DIR/refs`目录层次中缺少一个引用时，就在这个文件中查找，如果找到就使用。

note: type: Plain text
en: Subsequent updates to branches always create new files under `$GIT_DIR/refs` directory hierarchy.
zh_HANS-CN: 分支的后续更新总是在 `$GIT_DIR/refs` 目录层次下创建新文件。

note: type: Plain text
en: A recommended practice to deal with a repository with too many refs is to pack its refs with `--all` once, and occasionally run `git pack-refs`.  Tags are by definition stationary and are not expected to change.  Branch heads will be packed with the initial `pack-refs --all`, but only the currently active branch heads will become unpacked, and the next `pack-refs` (without `--all`) will leave them unpacked.
zh_HANS-CN: 处理一个有太多引用的仓库的推荐做法是，用 `--all` 来打包它的引用一次，然后偶尔运行 `git pack-refs` 。 根据定义，标签是固定的，不应该改变。 分支头会被初始的 `pack-refs --all` 打包，但只有当前活动的分支头会被解压，下一次 `pack-refs`（没有 `--all`）会让它们被解压。

note: type: Plain text
en: The command usually removes loose refs under `$GIT_DIR/refs` hierarchy after packing them.  This option tells it not to.
zh_HANS-CN: 该命令通常在打包后删除 `$GIT_DIR/refs` 层次下的松散引用。 这个选项告诉它不要这样做。

note: type: Plain text
en: Pack refs based on a `glob(7)` pattern. Repetitions of this option accumulate inclusion patterns. If a ref is both included in `--include` and `--exclude`, `--exclude` takes precedence. Using `--include` will preclude all tags from being included by default. Symbolic refs and broken refs will never be packed. When used with `--all`, it will be a noop. Use `--no-include` to clear and reset the list of patterns.
zh_HANS-CN: 根据 `glob(7)` 模式打包引用。重复使用该选项会累积包含模式。如果一个引用同时包含在 `--include` 和 `--exclude` 中，则 `--exclude` 优先。使用 `--include` 会默认排除所有标记。符号引用和断开的引用将永远不会被打包。与 `--all` 一起使用时，它将是一个 空操作。使用 `--no-include` 清除并重置模式列表。

note: type: Plain text
en: Do not pack refs matching the given `glob(7)` pattern. Repetitions of this option accumulate exclusion patterns. Use `--no-exclude` to clear and reset the list of patterns. If a ref is already packed, including it with `--exclude` will not unpack it.
zh_HANS-CN: 不打包与给定的 `glob(7)` 模式匹配的引用。重复使用此选项会累积排除模式。使用 `--no-exclude` 可以清除并重置模式列表。如果一个引用已经打包，使用 `--exclude`不会将其解包。

note: type: Plain text
en: When used with `--all`, pack only loose refs which do not match any of the provided `--exclude` patterns.
zh_HANS-CN: 与 `--all` 一起使用时，只打包与所提供的 `--exclude` 模式不匹配的松散引用。

note: type: Plain text
en: When used with `--include`, refs provided to `--include`, minus refs that are provided to `--exclude` will be packed.
zh_HANS-CN: 当与 `--include` 一起使用时，提供给 `--include` 的引用减去提供给 `--exclude` 的引用将被打包。

note: type: Plain text
en: Older documentation written before the packed-refs mechanism was introduced may still say things like ".git/refs/heads/<branch> file exists" when it means "branch <branch> exists".
zh_HANS-CN: 在引入 packed-refs 机制之前编写的旧文档可能仍然会说 ".git/refs/heads/<branch>文件存在" 这样的话，而它的意思是 "<branch> 分支存在"。

note: type: Plain text
en: Read a patch from the standard input and compute the patch ID for it.
zh_HANS-CN: 从标准输入读取一个补丁，并计算出它的补丁 ID。

note: type: Plain text
en: A "patch ID" is nothing but a sum of SHA-1 of the file diffs associated with a patch, with line numbers ignored.  As such, it's "reasonably stable", but at the same time also reasonably unique, i.e., two patches that have the same "patch ID" are almost guaranteed to be the same thing.
zh_HANS-CN: "补丁ID" 只不过是一个与补丁相关的文件差异的 SHA-1 之和，行号被忽略。 因此，它是 "相当稳定的"，但同时也是相当独特的，也就是说，两个具有相同 "补丁ID" 的补丁几乎可以保证是同一个东西。

note: type: Plain text
en: The main usecase for this command is to look for likely duplicate commits.
zh_HANS-CN: 这个命令的主要用途是寻找可能的重复提交。

note: type: Plain text
en: When dealing with 'git diff-tree' output, it takes advantage of the fact that the patch is prefixed with the object name of the commit, and outputs two 40-byte hexadecimal strings.  The first string is the patch ID, and the second string is the commit ID.  This can be used to make a mapping from patch ID to commit ID.
zh_HANS-CN: 在处理 'git diff-tree' 输出时，它利用了补丁的前缀是提交的对象名称这一事实，并输出两个 40 字节的十六进制字符串。 第一个字符串是补丁的 ID，第二个字符串是提交的 ID。 这可以用来做一个从补丁ID 到提交 ID 的映射。

note: type: Plain text
en: Calculate the patch-id of the input as it is given, do not strip any whitespace.
zh_HANS-CN: 计算输入的补丁 ID，因为它是给定的，不要剥离任何空白字符。

note: type: Plain text
en: This is the default if patchid.verbatim is true.
zh_HANS-CN: 如果 patchid.verbatim 为真，这是默认的。

note: type: Plain text
en: Use a "stable" sum of hashes as the patch ID. With this option:
zh_HANS-CN: 使用一个 "稳定的" 哈希值之和作为补丁 ID。有了这个选项：

note: type: Plain text
en: Reordering file diffs that make up a patch does not affect the ID.  In particular, two patches produced by comparing the same two trees with two different settings for "-O<orderfile>" result in the same patch ID signature, thereby allowing the computed result to be used as a key to index some meta-information about the change between the two trees;
zh_HANS-CN: 对组成补丁的文件差异进行重新排序并不影响 ID。 特别是，用两个不同的 "-O<orderfile>" 设置比较相同的两棵树所产生的两个补丁，会产生相同的补丁 ID 签名，从而允许计算结果被用作索引两个树之间变化的一些元信息的关键；

note: type: Plain text
en: Result is different from the value produced by git 1.9 and older or produced when an "unstable" hash (see --unstable below) is configured - even when used on a diff output taken without any use of "-O<orderfile>", thereby making existing databases storing such "unstable" or historical patch-ids unusable.
zh_HANS-CN: 结果与 git 1.9 及更早版本产生的值不同，或者在配置了 "不稳定" 哈希值（见下文 --unstable）时产生的值不同——即使在没有使用 "-O<orderfile>" 的情况下用于 diff 输出，从而使存储这种 "不稳定“或历史补丁标识的现有数据库无法使用。

note: type: Plain text
en: All whitespace within the patch is ignored and does not affect the id.
zh_HANS-CN: 补丁中的所有空白都将被忽略，并且不影响 id。

note: type: Plain text
en: This is the default if patchid.stable is set to true.
zh_HANS-CN: 如果 patchid.stable 设置为 true，则默认使用此值。

note: type: Plain text
en: Use an "unstable" hash as the patch ID. With this option, the result produced is compatible with the patch-id value produced by git 1.9 and older and whitespace is ignored.  Users with pre-existing databases storing patch-ids produced by git 1.9 and older (who do not deal with reordered patches) may want to use this option.
zh_HANS-CN: 使用 “不稳定” 哈希值作为补丁 ID。有了这个选项，产生的结果与 git 1.9 及更早版本产生的补丁 ID 值兼容，空白被忽略。 如果您的数据库中已有 git 1.9 及更早版本产生的补丁标识（不处理重新排序的补丁），可能需要使用此选项。

note: type: Plain text
en: This program searches the `$GIT_OBJECT_DIRECTORY` for all objects that currently exist in a pack file as well as the independent object directories.
zh_HANS-CN: 这个程序会搜索 `$GIT_OBJECT_DIRECTORY` 所有当前存在于 pack 文件中的对象以及独立的对象目录。

note: type: Plain text
en: All such extra objects are removed.
zh_HANS-CN: 所有这些额外的对象都会被删除。

note: type: Plain text
en: A pack is a collection of objects, individually compressed, with delta compression applied, stored in a single file, with an associated index file.
zh_HANS-CN: 压缩包是对象的集合，单独压缩，应用 delta 压缩，存储在单个文件中，并带有相关索引文件。

note: type: Plain text
en: Packs are used to reduce the load on mirror systems, backup engines, disk storage, etc.
zh_HANS-CN: 软件包用于减少镜像系统、备份引擎、磁盘存储等的负载。

note: type: Plain text
en: Don't actually remove any objects, only show those that would have been removed.
zh_HANS-CN: 实际不删除任何对象，只显示本应删除的对象。

note: type: Plain text
en: Squelch the progress indicator.
zh_HANS-CN: 关闭进度指示器。

note: type: Plain text
en: In most cases, users should run 'git gc', which calls 'git prune'. See the section "NOTES", below.
zh_HANS-CN: 在大多数情况下，用户应该运行 'git gc'，它调用 'git prune'。参见下文 “注意” 一节。

note: type: Plain text
en: This runs 'git fsck --unreachable' using all the refs available in `refs/`, optionally with additional set of objects specified on the command line, and prunes all unpacked objects unreachable from any of these head objects from the object database.  In addition, it prunes the unpacked objects that are also found in packs by running 'git prune-packed'.  It also removes entries from .git/shallow that are not reachable by any ref.
zh_HANS-CN: 运行 'git fsck --unreachable'，使用 `refs/` 中可用的所有引用，可选地使用命令行中指定的附加对象集，并从对象数据库中删除所有从这些头对象中无法访问的未打包对象。 此外，它还会删除通过运行 'git prune-packed' 在包中找到的未打包对象。 它还会删除 .git/shallow 中任何引用都无法访问的条目。

note: type: Plain text
en: Note that unreachable, packed objects will remain.  If this is not desired, see linkgit:git-repack[1].
zh_HANS-CN: 需要注意的是，无法到达的打包对象将被保留。 如果不希望这样，请参见 linkgit:git-repack[1]。

note: type: Plain text
en: Do not remove anything; just report what it would remove.
zh_HANS-CN: 不删除任何内容；只需报告将删除的内容。

note: type: Plain text
en: Report all removed objects.
zh_HANS-CN: 报告所有移除的对象。

note: type: Plain text
en: Show progress.
zh_HANS-CN: 显示进度。

note: type: Plain text
en: Only expire loose objects older than <time>.
zh_HANS-CN: 仅过期超过 <时间> 的松散对象。

note: type: Plain text
en: In addition to objects reachable from any of our references, keep objects reachable from listed <head>s.
zh_HANS-CN: 除了可从我们的任何引用到达的对象外，还保留可从列出的 <head> 到达的对象。

note: type: Plain text
en: To prune objects not used by your repository or another that borrows from your repository via its `.git/objects/info/alternates`:
zh_HANS-CN: 剪切您的仓库或其他通过 `.git/objects/info/alternates` 借用您仓库的仓库不使用的对象：

note: type: Plain text
en: In most cases, users will not need to call 'git prune' directly, but should instead call 'git gc', which handles pruning along with many other housekeeping tasks.
zh_HANS-CN: 在大多数情况下，用户不需要直接调用 'git prune'，而应该调用 'git gc'，它可以处理剪枝和许多其他内务工作。

note: type: Plain text
en: For a description of which objects are considered for pruning, see 'git fsck''s --unreachable option.
zh_HANS-CN: 关于哪些对象会被考虑剪枝，请参见 'git fsck' 的 --unreachable 选项。

note: type: Plain text
en: Incorporates changes from a remote repository into the current branch.  If the current branch is behind the remote, then by default it will fast-forward the current branch to match the remote.  If the current branch and the remote have diverged, the user needs to specify how to reconcile the divergent branches with `--rebase` or `--no-rebase` (or the corresponding configuration option in `pull.rebase`).
zh_HANS-CN: 将远程版本库的修改并入当前分支。 如果当前分支落后于远程分支，那么默认情况下，它将快速合并当前分支以匹配远程分支。 如果当前分支和远程分支有分歧，用户需要用 `--rebase` 或 `--no-rebase`（或 `pull.rebase` 中的相应配置选项）来指定如何调和分歧的分支。

note: type: Plain text
en: More precisely, `git pull` runs `git fetch` with the given parameters and then depending on configuration options or command line flags, will call either `git rebase` or `git merge` to reconcile diverging branches.
zh_HANS-CN: 更确切地说，`git pull` 运行 `git fetch` 并给出参数，然后根据配置选项或命令行标志，调用 `git rebase` 或 `git merge` 来协调不同的分支。

note: type: Plain text
en: <repository> should be the name of a remote repository as passed to linkgit:git-fetch[1].  <refspec> can name an arbitrary remote ref (for example, the name of a tag) or even a collection of refs with corresponding remote-tracking branches (e.g., refs/heads/{asterisk}:refs/remotes/origin/{asterisk}), but usually it is the name of a branch in the remote repository.
zh_HANS-CN: <仓库> 应该是传递给 linkgit:git-fetch[1] 的远程仓库的名称。 < 用引规范 > 可以命名一个任意的远程引用（例如，一个标签的名称），甚至是一个有相应远程跟踪分支的引用集合（例如，refs/heads/{asterisk}:refs/remotes/origin/{asterisk}），但通常它是远程仓库的一个分支名称。

note: type: Plain text
en: Default values for <repository> and <branch> are read from the "remote" and "merge" configuration for the current branch as set by linkgit:git-branch[1] `--track`.
zh_HANS-CN: <仓库> 和 < 分支 > 的默认值是从 linkgit:git-branch[1] `--track` 设置的当前分支的 "远程" 和 "合并" 配置中读取。

note: type: delimited block -
en: 	  A---B---C master on origin
    	 /
        D---E---F---G master
    	^
    	origin/master in your repository
zh_HANS-CN: 	  A---B---C master on origin
    	 /
        D---E---F---G master
    	^
    	你仓库中的 origin/master

note: type: Plain text
en: Then "`git pull`" will fetch and replay the changes from the remote `master` branch since it diverged from the local `master` (i.e., `E`)  until its current commit (`C`) on top of `master` and record the result in a new commit along with the names of the two parent commits and a log message from the user describing the changes.
zh_HANS-CN: 然后，"`git pull`" 将从远程的 `master` 分支获取并重放自它与本地 `master`（即 `E`）分歧以来的变化，直到它在 `master` 之上的当前提交（`C`），并将结果与两个父提交的名称和用户描述变化的日志信息一起记录在一个新提交中。

note: type: Plain text
en: See linkgit:git-merge[1] for details, including how conflicts are presented and handled.
zh_HANS-CN: 详情见 linkgit:git-merge[1]，包括如何呈现和处理冲突。

note: type: Plain text
en: In Git 1.7.0 or later, to cancel a conflicting merge, use `git reset --merge`.  *Warning*: In older versions of Git, running 'git pull' with uncommitted changes is discouraged: while possible, it leaves you in a state that may be hard to back out of in the case of a conflict.
zh_HANS-CN: 在 Git 1.7.0 或更高版本中，要取消一个冲突的合并，请使用 `git reset --merge`。 * 警告 *：在旧版本的 Git 中，不鼓励在未提交的情况下运行 "git pull"：虽然有可能，但在发生冲突的情况下，会让你处于一个难以恢复的状态。

note: type: Plain text
en: If any of the remote changes overlap with local uncommitted changes, the merge will be automatically canceled and the work tree untouched.  It is generally best to get any local changes in working order before pulling or stash them away with linkgit:git-stash[1].
zh_HANS-CN: 如果任何远程修改与本地未提交的修改重叠，合并将被自动取消，工作目录树不会被改动。  一般来说，最好是在拉取之前把任何本地的修改弄到工作状态，或者用 linkgit:git-stash[1] 把它们贮藏起来。

note: type: Plain text
en: This is passed to both underlying git-fetch to squelch reporting of during transfer, and underlying git-merge to squelch output during merging.
zh_HANS-CN: 这将被传递给底层的 git-fetch，以便在传输过程中抑制报告，以及底层的 git-merge，以便在合并过程中抑制输出。

note: type: Plain text
en: Pass --verbose to git-fetch and git-merge.
zh_HANS-CN: 将 --verbose 传给 git-fetch 和 git-merge。

note: type: Plain text
en: This option controls if new commits of populated submodules should be fetched, and if the working trees of active submodules should be updated, too (see linkgit:git-fetch[1], linkgit:git-config[1] and linkgit:gitmodules[5]).
zh_HANS-CN: 这个选项控制是否应该获取已填充子模块的新提交，以及是否应该更新活动子模块的工作树（见linkgit:git-fetch[1], linkgit:git-config[1] 和 linkgit:gitmodules[5]）。

note: type: Plain text
en: If the checkout is done via rebase, local submodule commits are rebased as well.
zh_HANS-CN: 如果签出是通过变基完成的，那么本地子模块的提交也会被变基。

note: type: Plain text
en: If the update is done via merge, the submodule conflicts are resolved and checked out.
zh_HANS-CN: 如果更新是通过合并完成的，子模块的冲突就会被解决并被检查出来。

note: type: Title ~
en: Options related to merging
zh_HANS-CN: 与合并有关的选项

note: type: Plain text
en: When true, rebase the current branch on top of the upstream branch after fetching. If there is a remote-tracking branch corresponding to the upstream branch and the upstream branch was rebased since last fetched, the rebase uses that information to avoid rebasing non-local changes.
zh_HANS-CN: 为真时，在获取后将当前分支变基到上游分支之上。如果有一个远程跟踪的分支与上游分支相对应，并且上游分支在上次获取后被重新建立了基础，那么变基就会使用该信息以避免重新建立非本地的变化。

note: type: Plain text
en: When set to `merges`, rebase using `git rebase --rebase-merges` so that the local merge commits are included in the rebase (see linkgit:git-rebase[1] for details).
zh_HANS-CN: 当设置为 `merges` 时，使用 `git rebase --rebase-merges` 进行重建，这样本地的合并提交就会包含在重建中（详见 linkgit:git-rebase[1]）。

note: type: Plain text
en: When false, merge the upstream branch into the current branch.
zh_HANS-CN: 如果为false，则将上游分支合并到当前分支中。

note: type: Plain text
en: When `interactive`, enable the interactive mode of rebase.
zh_HANS-CN: 当设置为 `interactive` 时，启用变基的交互模式。

note: type: Plain text
en: See `pull.rebase`, `branch.<name>.rebase` and `branch.autoSetupRebase` in linkgit:git-config[1] if you want to make `git pull` always use `--rebase` instead of merging.
zh_HANS-CN: 如果你想让 `git pull` 总是使用 `--rebase` 而不是合并，请参见 linkgit:git-config[1] 中的 `pull.rebase`, `branch.< 分支名 >.rebase` 和 `branch.autoSetupRebase`。

note: type: Plain text
en: This is a potentially _dangerous_ mode of operation.  It rewrites history, which does not bode well when you published that history already.  Do *not* use this option unless you have read linkgit:git-rebase[1] carefully.
zh_HANS-CN: 这是一种潜在的「危险的」操作模式。  它重写了历史，当你已经发布了这些历史时，这并不是一个好兆头。  除非你仔细阅读了linkgit:git-rebase[1]，否则请「不要」使用这个选项。

note: type: Plain text
en: This is shorthand for --rebase=false.
zh_HANS-CN: 这是对 --rebase=false 的简写。

note: type: Title ~
en: Options related to fetching
zh_HANS-CN: 与获取有关的选项

note: type: Title -
en: DEFAULT BEHAVIOUR
zh_HANS-CN: 默认行为

note: type: Plain text
en: Often people use `git pull` without giving any parameter.  Traditionally, this has been equivalent to saying `git pull origin`.  However, when configuration `branch.<name>.remote` is present while on branch `<name>`, that value is used instead of `origin`.
zh_HANS-CN: 人们经常使用 `git pull` 而不给任何参数。 传统上，这等同于说 `git pull origin`。 然而，当配置 `branch.<分支名>.remote` 在分支 `< 分支名 >` 上出现时，该值会被用来代替 `origin`。

note: type: Plain text
en: In order to determine what URL to use to fetch from, the value of the configuration `remote.<origin>.url` is consulted and if there is not any such variable, the value on the `URL:` line in `$GIT_DIR/remotes/<origin>` is used.
zh_HANS-CN: 为了确定使用什么 URL 来获取，将查询配置 `remote.<远程名>.url` 的值，如果没有这样的变量，将使用 `$GIT_DIR/remotes/< 远程名 >` 中 `URL:` 一行的值。

note: type: Plain text
en: In order to determine what remote branches to fetch (and optionally store in the remote-tracking branches) when the command is run without any refspec parameters on the command line, values of the configuration variable `remote.<origin>.fetch` are consulted, and if there aren't any, `$GIT_DIR/remotes/<origin>` is consulted and its `Pull:` lines are used.  In addition to the refspec formats described in the OPTIONS section, you can have a globbing refspec that looks like this:
zh_HANS-CN: 当命令行上没有任何引用规范参数时，为了确定要获取哪些远程分支（并可选择存储在远程跟踪分支中），会查询配置变量 `remote.<远程名>.fetch` 的值，如果没有，会查询 `$GIT_DIR/remotes/< 远程名 >` 并使用其 `Pull:` 行。 除了在『选项』部分描述的引用规范格式之外，你还可以有一个看起来像这样的引用规范通配符：

note: type: Plain text
en: A globbing refspec must have a non-empty RHS (i.e. must store what were fetched in remote-tracking branches), and its LHS and RHS must end with `/*`.  The above specifies that all remote branches are tracked using remote-tracking branches in `refs/remotes/origin/` hierarchy under the same name.
zh_HANS-CN: 一个引用规范通配符必须有一个非空的 RHS（即必须存储在远程跟踪分支中获取的内容），其 LHS 和 RHS 必须以 `/*` 结尾。 以上规定了所有远程分支都使用同名的 `refs/remotes/origin/` 层次结构中的远程跟踪分支进行跟踪。

note: type: Plain text
en: The rule to determine which remote branch to merge after fetching is a bit involved, in order not to break backward compatibility.
zh_HANS-CN: 为了不破坏后向兼容性，确定在获取后合并哪个远程分支的规则有点复杂。

note: type: Plain text
en: If explicit refspecs were given on the command line of `git pull`, they are all merged.
zh_HANS-CN: 如果在 `git pull` 的命令行中给出了明确的引用规范，它们都会被合并。

note: type: Plain text
en: When no refspec was given on the command line, then `git pull` uses the refspec from the configuration or `$GIT_DIR/remotes/<origin>`.  In such cases, the following rules apply:
zh_HANS-CN: 当命令行没有给出引用规范时，那么 `git pull` 使用配置或 `$GIT_DIR/remotes/<远程名>` 中的引用规范。 在这种情况下，以下规则适用：

note: type: Plain text
en: If `branch.<name>.merge` configuration for the current branch `<name>` exists, that is the name of the branch at the remote site that is merged.
zh_HANS-CN: 如果当前分支 `<分支名>` 的 `branch.< 分支名 >.merge` 配置存在，这就是被合并的远程站点的分支名称。

note: type: Plain text
en: Otherwise the remote branch of the first refspec is merged.
zh_HANS-CN: 否则将合并第一个引用规范的远程分支。

note: type: Plain text
en: Update the remote-tracking branches for the repository you cloned from, then merge one of them into your current branch:
zh_HANS-CN: 更新你所克隆的仓库的远程跟踪分支，然后将其中一个分支合并到你当前的分支：

note: type: Plain text
en: Normally the branch merged in is the HEAD of the remote repository, but the choice is determined by the branch.<name>.remote and branch.<name>.merge options; see linkgit:git-config[1] for details.
zh_HANS-CN: 通常情况下，合并进来的分支是远程仓库的 HEAD，但选择由 branch.<分支名>.remote 和 branch.< 分支名 >.merge 选项决定；详见 linkgit:git-config[1] 。

note: type: Plain text
en: Merge into the current branch the remote branch `next`:
zh_HANS-CN: 将远程分支 `next` 合并到当前分支：

note: type: Plain text
en: This leaves a copy of `next` temporarily in FETCH_HEAD, and updates the remote-tracking branch `origin/next`.  The same can be done by invoking fetch and merge:
zh_HANS-CN: 这将在 FETCH_HEAD 中暂时留下 `next` 的副本，并更新远程跟踪分支 `origin/next`。 同样可以通过调用 fetch 和 merge 来完成：

note: type: Plain text
en: If you tried a pull which resulted in complex conflicts and would want to start over, you can recover with 'git reset'.
zh_HANS-CN: 如果你尝试了一次拉取，导致了复杂的冲突，想重新开始，你可以用 'git reset' 来恢复。

note: type: Plain text
en: Using --recurse-submodules can only fetch new commits in already checked out submodules right now. When e.g. upstream added a new submodule in the just fetched commits of the superproject the submodule itself cannot be fetched, making it impossible to check out that submodule later without having to do a fetch again. This is expected to be fixed in a future Git version.
zh_HANS-CN: 使用 --recurse-submodules 现在只能获取已经签出的子模块的新提交。例如，当上游在刚刚获取的超级项目的提交中添加了一个新的子模块时，子模块本身不能被获取，这使得以后不需要再次获取就能签出该子模块。这个问题有望在未来的 Git 版本中被修复。

note: type: Plain text
en: git-push - Update remote refs along with associated objects
zh_HANS-CN: git-push - 与相关对象一起更新远程分支引用

note: type: Plain text
en: 'git push' [--all | --branches | --mirror | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
    	   [--repo=<repository>] [-f | --force] [-d | --delete] [--prune] [-v | --verbose]
    	   [-u | --set-upstream] [-o <string> | --push-option=<string>]
    	   [--[no-]signed|--signed=(true|false|if-asked)]
    	   [--force-with-lease[=<refname>[:<expect>]] [--force-if-includes]]
    	   [--no-verify] [<repository> [<refspec>...]]
zh_HANS-CN: 'git push' [--all | --branches | --mirror | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
    	   [--repo=<仓库>] [-f | --force] [-d | --delete] [--prune] [-v | --verbose]
    	   [-u | --set-upstream] [-o <字符串> | --push-option=<字符串>]
    	   [--[no-]signed|--signed=(true|false|if-asked)]
    	   [--force-with-lease[=<引用名>[:<expect>]] [--force-if-includes]]
    	   [--no-verify] [<仓库> [<引用规范>...]]

note: type: Plain text
en: Updates remote refs using local refs, while sending objects necessary to complete the given refs.
zh_HANS-CN: 使用本地引用更新远程仓库引用，同时发送完成给定引用的必要对象。

note: type: Plain text
en: You can make interesting things happen to a repository every time you push into it, by setting up 'hooks' there.  See documentation for linkgit:git-receive-pack[1].
zh_HANS-CN: 通过设置 “钩子”，你可以在每次推送到一个仓库时，让它发生有趣的事情。 见 linkgit:git-receive-pack[1] 的文档。

note: type: Plain text
en: 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'.
zh_HANS-CN: 当命令行没有用 `<仓库>` 参数指定推送位置时，会参考当前分支的 `branch.*.remote` 配置来决定推送位置。 如果配置丢失，则默认为 "origin"。

note: type: Plain text
en: When the command line does not specify what to push with `<refspec>...` arguments or `--all`, `--mirror`, `--tags` options, the command finds the default `<refspec>` by consulting `remote.*.push` configuration, and if it is not found, honors `push.default` configuration to decide what to push (See linkgit:git-config[1] for the meaning of `push.default`).
zh_HANS-CN: 当命令行没有用 `<引用规范>...` 参数或 `--all`、`--mirror`、`--tags` 选项指定推送内容时，命令通过查阅 `remote.*.push` 配置找到默认的 `< 引用规范 >`，如果没有找到，则以 `push.default` 配置决定推送内容（关于 `push.default` 的含义，见 linkgit：git-config[1] ）。

note: type: Plain text
en: When neither the command-line nor the configuration specify what to push, the default behavior is used, which corresponds to the `simple` value for `push.default`: the current branch is pushed to the corresponding upstream branch, but as a safety measure, the push is aborted if the upstream branch does not have the same name as the local one.
zh_HANS-CN: 当命令行和配置都没有指定推送的内容时，将使用默认行为，这与 `push.default` 的 `simple` 值相对应：当前分支被推送到相应的上游分支，但作为一项安全措施，如果上游分支的名称与本地分支不一致，推送将被中止。

note: type: Title -
en: OPTIONS[[OPTIONS]]
zh_HANS-CN: 选项[[OPTIONS]]

note: type: Plain text
en: The "remote" repository that is destination of a push operation.  This parameter can be either a URL (see the section <<URLS,GIT URLS>> below) or the name of a remote (see the section <<REMOTES,REMOTES>> below).
zh_HANS-CN: 作为推送操作的目的地的“远程”仓库。 这个参数可以是一个 URL（见下面 <<URLS,GIT URLS>> 一节），也可以是一个远程库的名称（见下面 <<远程仓库,REMOTES>> 一节）。

note: type: Plain text
en: 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>.
zh_HANS-CN: 指定用什么源对象来更新哪个目标参考文献。 <引用规范> 参数的格式是一个可选的加号 `+`，后面是源对象 <src>，后面是冒号 `:`，后面是目标引用 <dst>。

note: type: Plain text
en: The <src> is often the name of the branch you would want to push, but it can be any arbitrary "SHA-1 expression", such as `master~4` or `HEAD` (see linkgit:gitrevisions[7]).
zh_HANS-CN: <src> 通常是你想推送的分支的名字，但它可以是任何任意的“SHA-1 表达式”，比如 `master~4` 或 `HEAD`（见 linkgit:gitrevisions[7]）。

note: type: Plain text
en: 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>`.
zh_HANS-CN: <dst> 远程仓库的哪个引用被这个推送更新。这里不能使用任意的表达式，必须命名一个实际的引用。 如果 `git push [< 仓库 >]` 没有任何 `< 引用规范 >` 参数被设置用 `remote.< 仓库 >.push` 配置变量更新目的地 `<src>` 的某个引用，则`:<dst>` 部分可以省略 —— 这样的推送将更新 `<src>` 通常更新的引用，命令行上没有任何 `< 引用规范 >`。 否则，缺少 `:<dst>` 意味着更新与 `<src>` 相同的引用。

note: type: Plain text
en: If <dst> doesn't start with `refs/` (e.g. `refs/heads/master`) we will try to infer where in `refs/*` on the destination <repository> it belongs based on the type of <src> being pushed and whether <dst> is ambiguous.
zh_HANS-CN: 如果 <dst> 不是以 `refs/` 开头（例如 `refs/heads/master`），我们将根据被推送的 <src> 的类型和 <dst> 是否含糊不清，尝试推断它在目的地 < 仓库 > 的 `refs/*` 中的位置。

note: type: Plain text
en: If <dst> unambiguously refers to a ref on the <repository> remote, then push to that ref.
zh_HANS-CN: 如果 <dst> 明确地指向 < 仓库 > 远程的一个引用，那么就推送到该引用。

note: type: Plain text
en: If <src> resolves to a ref starting with refs/heads/ or refs/tags/, then prepend that to <dst>.
zh_HANS-CN: 如果 <src> 解析为以 refs/heads/ 或 refs/tags/ 开头的引用，则将其前置到 <dst>。

note: type: Plain text
en: Other ambiguity resolutions might be added in the future, but for now any other cases will error out with an error indicating what we tried, and depending on the `advice.pushUnqualifiedRefname` configuration (see linkgit:git-config[1]) suggest what refs/ namespace you may have wanted to push to.
zh_HANS-CN: 其他含糊的解决方案可能会在未来加入，但现在我们所尝试的任何其他情况都会出错，并根据`advice.pushUnqualifiedRefname`配置（见linkgit:git-config[1]）建议你可能想推送到哪个类型的引用中。

note: type: Plain text
en: The object referenced by <src> is used to update the <dst> reference on the remote side. Whether this is allowed depends on where in `refs/*` the <dst> reference lives as described in detail below, in those sections "update" means any modifications except deletes, which as noted after the next few sections are treated differently.
zh_HANS-CN: 由 <src> 引用的对象被用来更新远程端的 <dst> 引用。这是否被允许取决于 <dst> 引用在`refs/*`中的位置，下面将详细描述，在这些章节中，“更新”意味着除了删除之外的任何修改，正如在接下来的几节中所指出的，这将被不同地对待。

note: type: Plain text
en: The `refs/heads/*` namespace will only accept commit objects, and updates only if they can be fast-forwarded.
zh_HANS-CN: `refs/heads/*` 命名空间只接受提交对象，只有在可以快进的情况下才接受更新。

note: type: Plain text
en: The `refs/tags/*` namespace will accept any kind of object (as commits, trees and blobs can be tagged), and any updates to them will be rejected.
zh_HANS-CN: `refs/tags/*` 命名空间将接受任何种类的对象（因为提交、树和二进制对象都可以被标记），对它们的任何更新都将被拒绝。

note: type: Plain text
en: It's possible to push any type of object to any namespace outside of `refs/{tags,heads}/*`. In the case of tags and commits, these will be treated as if they were the commits inside `refs/heads/*` for the purposes of whether the update is allowed.
zh_HANS-CN: 可以将任何类型的对象推送到 `refs/{tags,heads}/*` 之外的任何命名空间。在标签和提交的情况下，这些将被视为 `refs/heads/*` 内的提交，以决定是否允许更新。

note: type: Plain text
en: I.e. a fast-forward of commits and tags outside `refs/{tags,heads}/*` is allowed, even in cases where what's being fast-forwarded is not a commit, but a tag object which happens to point to a new commit which is a fast-forward of the commit the last tag (or commit) it's replacing. Replacing a tag with an entirely different tag is also allowed, if it points to the same commit, as well as pushing a peeled tag, i.e. pushing the commit that existing tag object points to, or a new tag object which an existing commit points to.
zh_HANS-CN: 也就是说，允许在 `refs/{tags,heads}/*` 之外进行快进提交和标签，即使被快进的不是一个提交，而是一个标签对象，它恰好指向一个新的提交，而这个提交是它所替代的最后一个标签（或提交）的快进。用一个完全不同的标签替换一个标签也是允许的，如果它指向同一个提交，以及推送一个剥离的标签，即推送现有标签对象所指向的提交，或现有提交所指向的新标签对象。

note: type: Plain text
en: Tree and blob objects outside of `refs/{tags,heads}/*` will be treated the same way as if they were inside `refs/tags/*`, any update of them will be rejected.
zh_HANS-CN: 在 `refs/{tags,heads}/*` 之外的树和二进制对象的处理方式与在 `refs/tags/*` 之内的相同，它们的任何更新都会被拒绝。

note: type: Plain text
en: All of the rules described above about what's not allowed as an update can be overridden by adding an the optional leading `+` to a refspec (or using `--force` command line option). The only exception to this is that no amount of forcing will make the `refs/heads/*` namespace accept a non-commit object. Hooks and configuration can also override or amend these rules, see e.g. `receive.denyNonFastForwards` in linkgit:git-config[1] and `pre-receive` and `update` in linkgit:githooks[5].
zh_HANS-CN: 上面描述的所有关于不允许更新的规则都可以通过在引用规范前面添加一个可选 `+` 来覆盖（或者使用 `--force` 命令行选项）。唯一的例外是，无论如何强制都不会使 `refs/heads/*` 命名空间接受一个非提交对象。钩子和配置也可以覆盖或修改这些规则，例如见 linkgit:git-config[1] 中的 `receive.denyNonFastForwards` 和 linkgit:githooks[5] 中的 `pre-receive` 和 `update`。

note: type: Plain text
en: Pushing an empty <src> allows you to delete the <dst> ref from the remote repository. Deletions are always accepted without a leading `+` in the refspec (or `--force`), except when forbidden by configuration or hooks. See `receive.denyDeletes` in linkgit:git-config[1] and `pre-receive` and `update` in linkgit:githooks[5].
zh_HANS-CN: 推送一个空的 <src> 允许你从远程版本库中删除 <dst> 的引用。除非配置或钩子禁止，否则在引用规范中没有前面的 `+` (或 `--force`) ，删除总是被接受的。参见 linkgit:git-config[1] 中的 `receive.denyDeletes` 以及 linkgit:githooks[5] 中的 `pre-receive` 和 `update`。

note: type: Plain text
en: 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.
zh_HANS-CN: 特殊的引用规范 `:`（或`+:`以允许非快进式更新）指示 Git 推送“匹配”的分支：对于每一个存在于本地的分支，如果远程仓库已经有一个同名的分支存在，则远程仓库会被更新。

note: type: Plain text
en: `tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
zh_HANS-CN: `tag <tag>` 与 `refs/tags/<tag>:refs/tags/<tag>` 意思相同。

note: type: Plain text
en: Push all branches (i.e. refs under `refs/heads/`); cannot be used with other <refspec>.
zh_HANS-CN: 推送所有分支（即`refs/heads/`下的引用）；不能与其他 < 引用规范 > 一起使用。

note: type: Plain text
en: 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.
zh_HANS-CN: 删除没有本地对应分支的远程分支。例如，如果本地的同名分支不存在了，那么远程分支 `tmp` 将被删除。这也是对引用规范的尊重，例如，`git push --prune remote refs/heads/*:refs/tmp/*` 将确保如果 `refs/heads/foo` 不存在，那么远程的 `refs/tmp/foo` 将被删除。

note: type: Plain text
en: 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.
zh_HANS-CN: 而不是命名每一个要推送的引用，指定`refs/`（包括但不限于`refs/heads/`、`refs/remotes/`和`refs/tags/`）下的所有引用都被镜像到远程仓库。  新创建的本地引用将被推送到远程端，本地更新的引用将被强制更新到远程端，而删除的引用将从远程仓库删除。  如果配置选项 `remote.<remote>.mirror`被设置，这就是默认的。

note: type: Plain text
en: 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.
zh_HANS-CN: 生成机器可读的输出。  每个引用的输出状态行将以制表符分隔，并发送至标准输出而不是标准报错。  将给出引用的完整符号名称。

note: type: Plain text
en: All listed refs are deleted from the remote repository. This is the same as prefixing all refs with a colon.
zh_HANS-CN: 所有列出的引用都从远程仓库中删除。这与在所有引用前加冒号的做法相同。

note: type: Plain text
en: All refs under `refs/tags` are pushed, in addition to refspecs explicitly listed on the command line.
zh_HANS-CN: 除了命令行上明确列出的引用规范之外，`refs/tags` 下的所有引用都被推送。

note: type: Plain text
en: 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 linkgit:git-config[1].
zh_HANS-CN: 推送所有在没有这个选项的情况下会被推送的引用，同时也推送 `refs/tags` 中的注释标签，这些标签在远程中缺失，但却指向被推送的引用中可以到达的提交号。  这也可以用配置变量 `push.followTags` 来指定。  更多信息，见 linkgit:git-config[1] 中的 `push.followTags`。

note: type: Plain text
en: 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 linkgit:git-receive-pack[1] for the details on the receiving end.
zh_HANS-CN: 对推送请求进行 GPG 签名，以更新接收方的引用，使其能够被钩子检查和/或被记录下来。  如果指定 `false` 或 `--no-signed`，将不尝试签名。  如果指定 `true` 或 `--signed`，且服务器不支持签名推送，推送将失败。  如果设置为 `if-asked`，仅当服务器支持签名推送时才签名。  如果实际调用 `gpg --sign` 失败，推送也将失败。  关于接收端的细节，见 linkgit:git-receive-pack[1]。

note: type: Plain text
en: 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.
zh_HANS-CN: 如果有的话，在远程仓库使用一个原子事务。  要么所有的引用都被更新，要么出错时，没有引用被更新。  如果服务器不支持原子推送，推送将会失败。

note: type: Plain text
en: 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.
zh_HANS-CN: 将给定的字符串传输给服务器，服务器将它们传递给 pre-receive 以及 post-receive 钩子。给定的字符串不能包含 NUL 或 LF 字符。  当给出多个 `--push-option=< 选项 >` 时，它们将按照命令行中列出的顺序全部发送给对方。  当命令行中没有给出 `--push-option=< 选项 >` 时，将使用配置变量`push.pushOption` 的值来代替。

note: type: Plain text
en: 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.
zh_HANS-CN: 到远端的 'git-receive-pack' 程序的路径。  当通过 ssh 推送到远程版本库，而你没有在默认的 $PATH 目录下的程序时，有时会很有用。

note: type: Labeled list
en: --force-with-lease=<refname>:<expect>
zh_HANS-CN: --force-with-lease=< 引用名 >:< 期望>

note: type: Plain text
en: Usually, "git push" refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it.
zh_HANS-CN: 通常，"git push" 会拒绝更新一个不是用来覆盖它的本地引用的远程父引用。

note: type: Plain text
en: This option overrides this restriction if the current value of the remote ref is the expected value.  "git push" fails otherwise.
zh_HANS-CN: 如果远程引用的当前值是预期值，该选项会覆盖这一限制。否则，"git push" 会失败。

note: type: Plain text
en: 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.
zh_HANS-CN: 想象一下，你必须对你已经发表的内容进行重新定位。  你必须绕过“必须快速合并”的规则，以便用重写的历史替换你最初发布的历史。  如果在你重新发布的时候，有其他人在你原来的历史之上构建，那么远程分支的顶端可能会随着他们的提交而前进，而盲目地用 `--force` 推送会丢失他们的改动。

note: type: Plain text
en: This option allows you to say that you expect the history you are updating is what you rebased and want to replace. If the remote ref still points at the commit you specified, you can be sure that no other people did anything to the ref. It is like taking a "lease" on the ref without explicitly locking it, and the remote ref is updated only if the "lease" is still valid.
zh_HANS-CN: 这个选项允许你说，你希望你更新的历史是你重新建立的，并希望取代它。如果远程引用仍然指向你指定的提交，你就可以确定没有其他人对该引用做了什么。这就像在没有明确锁定的情况下对引用进行“租赁”，只有在 “租赁”仍然有效的情况下才会更新远程引用。

note: type: Plain text
en: `--force-with-lease` alone, without specifying the details, will protect all remote refs that are going to be updated by requiring their current value to be the same as the remote-tracking branch we have for them.
zh_HANS-CN: `--force-with-lease`，不指定细节，将保护所有将被更新的远程引用，要求它们的当前值与我们为它们准备的远程跟踪分支相同。

note: type: Plain text
en: `--force-with-lease=<refname>`, without specifying the expected value, will protect the named ref (alone), if it is going to be updated, by requiring its current value to be the same as the remote-tracking branch we have for it.
zh_HANS-CN: `--force-with-lease=< 引用名 >`，没有指定预期值，将保护命名的引用（单独），如果它要被更新，要求其当前值与我们对它的远程跟踪分支相同。

note: type: Plain text
en: `--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.
zh_HANS-CN: `--force-with-lease=< 引用名 >:< 期望 >`将保护指定的引用（单独），如果它要被更新，要求它的当前值与指定的值`< 期望 >`相同（允许与我们对引用名的远程跟踪分支不同，或者在使用这种形式时，我们甚至不需要有这样一个远程跟踪分支）。  如果`< 期望 >`是空字符串，那么命名的引用必须不存在。

note: type: Plain text
en: Note that all forms other than `--force-with-lease=<refname>:<expect>` that specifies the expected current value of the ref explicitly are still experimental and their semantics may change as we gain experience with this feature.
zh_HANS-CN: 请注意，除了`--force-with-lease=< 引用名 >:< 期望 >`以外的所有形式都是明确指定引用的预期当前值，这些形式仍然是试验性的，它们的语义可能会随着我们对这个功能的经验积累而改变。

note: type: Plain text
en: "--no-force-with-lease" will cancel all the previous --force-with-lease on the command line.
zh_HANS-CN: "--no-force-with-lease " 将取消之前在命令行上所有的 --force-with-lease。

note: type: Plain text
en: A general note on safety: supplying this option without an expected value, i.e. as `--force-with-lease` or `--force-with-lease=<refname>` interacts very badly with anything that implicitly runs `git fetch` on the remote to be pushed to in the background, e.g. `git fetch origin` on your repository in a cronjob.
zh_HANS-CN: 关于安全性的一般说明：在没有预期值的情况下提供这个选项，即 `--force-with-lease` 或`--force-with-lease=< 引用名 >`，会与任何在后台隐式运行 `git fetch` 的远端推送的进程产生非常不好的互动，例如仓库中 cronjob 的 `git fetch origin`。

note: type: Plain text
en: The protection it offers over `--force` is ensuring that subsequent changes your work wasn't based on aren't clobbered, but this is trivially defeated if some background process is updating refs in the background. We don't have anything except the remote tracking info to go by as a heuristic for refs you're expected to have seen & are willing to clobber.
zh_HANS-CN: 与 `--force` 相比，它提供的保护是确保你的工作不基于后续的变化，但如果有后台进程在后台更新引用，这一点就很容易被破坏。除了远程跟踪信息外，我们没有任何你期望看到并愿意去破解可以作为启发式引用的东西。

note: type: Plain text
en: If your editor or some other system is running `git fetch` in the background for you a way to mitigate this is to simply set up another remote:
zh_HANS-CN: 如果你的编辑器或其他系统在后台为你运行`git fetch`，减轻这种情况的方法是简单地设置另一个远程：

note: type: Plain text
en: Now when the background process runs `git fetch origin` the references on `origin-push` won't be updated, and thus commands like:
zh_HANS-CN: 现在，当后台进程运行 `git fetch origin` 时，`origin-push`上的引用将不会被更新，因此，像这样的命令：

note: type: Plain text
en: Will fail unless you manually run `git fetch origin-push`. This method is of course entirely defeated by something that runs `git fetch --all`, in that case you'd need to either disable it or do something more tedious like:
zh_HANS-CN: 除非你手动运行 `git fetch origin-push`，否则会失败。当然，这种方法完全可以被运行 `git fetch --all` 的东西打败，在这种情况下，你需要禁用它或者做一些更繁琐的事情，比如：

note: type: Plain text
en: 	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
zh_HANS-CN: 	git fetch              # 从远程仓库更新 'master' 分支
    	git tag base master    # 标记基点
    	git rebase -i master   # 重写某些提交
    	git push --force-with-lease=master:base master:master

note: type: Plain text
en: I.e. create a `base` tag for versions of the upstream code that you've seen and are willing to overwrite, then rewrite history, and finally force push changes to `master` if the remote version is still at `base`, regardless of what your local `remotes/origin/master` has been updated to in the background.
zh_HANS-CN: 也就是说，为你已经看到并愿意覆盖的上游仓库创建一个`base` 标签，然后重写历史，最后如果远程版本仍然在 `base`，则强制推送修改到`master`，不管你本地的 `remotes/origin/master` 在后台更新了什么。

note: type: Plain text
en: Alternatively, specifying `--force-if-includes` as an ancillary option along with `--force-with-lease[=<refname>]` (i.e., without saying what exact commit the ref on the remote side must be pointing at, or which refs on the remote side are being protected) at the time of "push" will verify if updates from the remote-tracking refs that may have been implicitly updated in the background are integrated locally before allowing a forced update.
zh_HANS-CN: 另外，在“推送”时将 `--force-if-includes` 作为辅助选项与 `--force-with-lease[=< 引用名 >]` 一起指定（即不说远程的引用必须指向什么确切的提交，或远程的哪些引用被保护），将验证远程跟踪引用的更新是否在允许强制更新之前被整合在本地。

note: type: Plain text
en: 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.
zh_HANS-CN: 通常情况下，命令会拒绝更新一个不属于用来覆盖它的本地引用祖先的远程引用。  另外，当使用 `--force-with-lease` 选项时，命令会拒绝更新一个当前值与预期不符的远程引用。

note: type: Plain text
en: This flag disables these checks, and can cause the remote repository to lose commits; use it with care.
zh_HANS-CN: 这个标志禁用了这些检查，并可能导致远程版本库丢失提交，使用时要小心。

note: type: Plain text
en: 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.
zh_HANS-CN: 注意，`--force` 适用于所有被推送的引用，因此在 `push.default` 设置为 `matching` 的情况下使用它，或者在 `remote.*.push` 配置了多个推送目的地的情况下，可能会覆盖当前分支以外的引用（包括严格落后于其远程对应的本地引用）。  要强制推送到一个分支，请在推送的引用规范前面使用 `+`（例如 `git push origin +master`，强制推送到 `master` 分支）。详情见上面的 `< 引用规范 >...` 部分。

note: type: Plain text
en: Force an update only if the tip of the remote-tracking ref has been integrated locally.
zh_HANS-CN: 只有远程跟踪的引用顶端被整合到本地才强制更新。

note: type: Plain text
en: This option enables a check that verifies if the tip of the remote-tracking ref is reachable from one of the "reflog" entries of the local branch based in it for a rewrite. The check ensures that any updates from the remote have been incorporated locally by rejecting the forced update if that is not the case.
zh_HANS-CN: 这个选项启用了一个检查，以验证远程跟踪引用的顶端是否可以从本地分支的“引用日志”条目中到达，以便进行重写。该检查确保来自远程的任何更新都已纳入本地，如果不是这样，则拒绝强制更新。

note: type: Plain text
en: If the option is passed without specifying `--force-with-lease`, or specified along with `--force-with-lease=<refname>:<expect>`, it is a "no-op".
zh_HANS-CN: 如果该选项没有指定 `--force-with-lease`，或者与 `--force-with-lease=< 引用名 >:< 期望 >`一起指定，则是“无选项”的。

note: type: Plain text
en: Specifying `--no-force-if-includes` disables this behavior.
zh_HANS-CN: 指定 `---no-force-if-includes` 就可以禁止这种行为。

note: type: Plain text
en: This option is equivalent to the <repository> argument. If both are specified, the command-line argument takes precedence.
zh_HANS-CN: 这个选项等同于 < 仓库 > 参数。如果两者都被指定，则以命令行参数为优先。

note: type: Plain text
en: For every branch that is up to date or successfully pushed, add upstream (tracking) reference, used by argument-less linkgit:git-pull[1] and other commands. For more information, see `branch.<name>.merge` in linkgit:git-config[1].
zh_HANS-CN: 对于每一个已经更新或成功推送的分支，添加上游（跟踪）引用，由无参数的 linkgit:git-pull[1] 和其他命令使用。更多信息，见 linkgit:git-config[1] 中的 `branch.< 分支名 >.merge`。

note: type: Plain text
en: These options are passed to linkgit:git-send-pack[1]. A thin transfer significantly reduces the amount of sent data when the sender and receiver share many of the same objects in common. The default is `--thin`.
zh_HANS-CN: 这些选项被传递给 linkgit:git-send-pack[1]。当发送方和接收方有许多共同的对象时，稀松传输会大大减少发送的数据量。默认是 `--thin`。

note: type: Plain text
en: Suppress all output, including the listing of updated refs, unless an error occurs. Progress is not reported to the standard error stream.
zh_HANS-CN: 抑制所有的输出，包括更新的引用的列表，除非发生错误。进度不会报告给标准错误流。

note: type: Plain text
en: 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.
zh_HANS-CN: 可以用来确保要推送的修订版所使用的所有子模块提交都在远程跟踪分支上可用。  如果使用 'check'，Git 将验证所有在要推送的修订版中发生变化的子模块提交是否在该子模块的至少一个远程上可用。如果缺少任何提交，推送将被中止并以非零状态退出。如果使用 'on-demand'，所有在要推送的修订版中发生变化的子模块都会被推送。如果 on-demand 不能推送所有必要的修订版，它也将被中止并以非零状态退出。如果使用 'only'，所有的子模块将被推送，父级项目则不被推送。当不需要子模块递归时，一个 "no" 的值或使用 `--no-recurse-submodules` 可以用来覆盖 push.recurseSubmodules 配置变量。

note: type: Plain text
en: When using 'on-demand' or 'only', if a submodule has a "push.recurseSubmodules={on-demand,only}" or "submodule.recurse" configuration, further recursion will occur. In this case, "only" is treated as "on-demand".
zh_HANS-CN: 当使用 "on-demand" 或 "only" 时，如果一个子模块有 "push.recurseSubmodules={on-demand,only}" 或 "submodule.recurse"配置，将发生进一步递归。在这种情况下，"only" 被视为 "on-demand"。

note: type: Plain text
en: Toggle the pre-push hook (see linkgit:githooks[5]).  The default is --verify, giving the hook a chance to prevent the push.  With --no-verify, the hook is bypassed completely.
zh_HANS-CN: 切换 pre-push 钩子（见 linkgit:githooks[5]）。  默认是 --verify，给钩子一个机会来阻止推送。  如果使用 --no-verify，钩子会被完全绕过。

note: type: Plain text
en: The status of the push is output in tabular form, with each line representing the status of a single ref. Each line is of the form:
zh_HANS-CN: 推送的状态以表格的形式输出，每一行代表一个引用的状态。每一行的形式是：

note: type: Plain text
en: If --porcelain is used, then each line of the output is of the form:
zh_HANS-CN: 如果使用了 --porcelain ，那么输出的每一行都是这样的：

note: type: Plain text
en: The status of up-to-date refs is shown only if --porcelain or --verbose option is used.
zh_HANS-CN: 只有在使用 --porcelain 或 --verbose 选项时，才会显示最新引用的状态。

note: type: Plain text
en: for a successfully pushed fast-forward;
zh_HANS-CN: 表示推送成功的快速合并；

note: type: Plain text
en: for a successfully deleted ref;
zh_HANS-CN: 表示一个成功删除的引用；

note: type: Plain text
en: for a successfully pushed new ref;
zh_HANS-CN: 表示成功推送的引用；

note: type: Plain text
en: for a ref that was rejected or failed to push; and
zh_HANS-CN: 表示一个被拒绝或推送失败的引用；并且

note: type: Plain text
en: for a ref that was up to date and did not need pushing.
zh_HANS-CN: 表示一个最新的、不需要推送的引用。

note: type: Plain text
en: For a successfully pushed ref, the summary shows the old and new values of the ref in a form suitable for using as an argument to `git log` (this is `<old>..<new>` in most cases, and `<old>...<new>` for forced non-fast-forward updates).
zh_HANS-CN: 对于一个成功获取的引用，摘要以适合作为 `git log` 参数的形式显示该引用的新旧值（在大多数情况下是 `<旧>..<新>`，对于强制非快速合并是 `<旧>...<新>`）。

note: type: Plain text
en: For a failed update, more details are given:
zh_HANS-CN: 对于失败的更新，会给出更多的细节：

note: type: Plain text
en: Git did not try to send the ref at all, typically because it is not a fast-forward and you did not force the update.
zh_HANS-CN: Git 根本没有尝试发送引用，典型的原因是它不是快速合并并且你没有强制更新。

note: type: Labeled list
en: remote rejected
zh_HANS-CN: 远程拒绝

note: type: Plain text
en: 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 linkgit:git-config[1].
zh_HANS-CN: 远程仓库拒绝更新。  通常是由远程仓库的钩子引起的，或者是因为远程仓库有以下安全选项：`receive.denyCurrentBranch`（用于推送到已检出的分支），`receive.denyNonFastForwards`（用于强制非快进更新），`receive.denyDeletes` 或者 `receive.denyDeleteCurrent`。  见 linkgit:git-config[1]。

note: type: Labeled list
en: remote failure
zh_HANS-CN: 远程故障

note: type: Plain text
en: The remote end did not report the successful update of the ref, perhaps because of a temporary error on the remote side, a break in the network connection, or other transient error.
zh_HANS-CN: 远程端没有报告引用的成功更新，可能是因为远程端的临时错误，网络连接中断，或其他瞬时错误。

note: type: Plain text
en: The name of the local ref being pushed, minus its `refs/<type>/` prefix. In the case of deletion, the name of the local ref is omitted.
zh_HANS-CN: 被推送的本地引用的名称，减去其 `refs/< 类型 >/` 前缀。在删除的情况下，本地引用的名称被省略。

note: type: Plain text
en: The name of the remote ref being updated, minus its `refs/<type>/` prefix.
zh_HANS-CN: 被更新的本地引用的名称，去掉其 `refs/< 类型 >/` 前缀。

note: type: Plain text
en: A human-readable explanation. In the case of successfully pushed refs, no explanation is needed. For a failed ref, the reason for failure is described.
zh_HANS-CN: 一个人类可读的解释。在成功推送引用的情况下，不需要解释。对于操作失败的引用，要描述失败的原因。

note: type: Title -
en: NOTE ABOUT FAST-FORWARDS
zh_HANS-CN: 关于快速合并的说明

note: type: Plain text
en: When an update changes a branch (or more in general, a ref) that used to point at commit A to point at another commit B, it is called a fast-forward update if and only if B is a descendant of A.
zh_HANS-CN: 当一个更新将原来指向提交 A 的分支（或更普遍的，一个引用）改为指向另一个提交 B 时，当且仅当 B 是 A 的后代时，它被称为快速合并。

note: type: Plain text
en: 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.
zh_HANS-CN: 在从 A 到 B 的快速合并中，原始提交 A 所建立的提交集是新提交 B 所建立的提交集的一个子集。  因此，它不会丢失任何历史。

note: type: Plain text
en: 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:
zh_HANS-CN: 相反，非快速合并更新会丢失历史。  例如，假设你和别人从同一个提交 X 开始，你建立了一个通往提交 B 的历史，而另一个人建立了一个通往提交 A 的历史。  这段历史看起来像这样：

note: type: Plain text
en: Further suppose that the other person already pushed changes leading to A back to the original repository from which you two obtained the original commit X.
zh_HANS-CN: 进一步假设对方已经将 A 导致的修改推送回原仓库，你们俩从原仓库中获得原始提交 X。

note: type: Plain text
en: 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.
zh_HANS-CN: 另一个人所做的推送，将原来指向提交 X 的分支更新为指向提交 A 的分支。

note: type: Plain text
en: 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.
zh_HANS-CN: 但如果你试图推送，你会试图用提交 B 来更新分支（现在指向 A）。这不是快速合并。  如果你这样做了，提交 A 引入的修改就会丢失，因为大家现在都会在 B 的基础上开始构建。

note: type: Plain text
en: The command by default does not allow an update that is not a fast-forward to prevent such loss of history.
zh_HANS-CN: 该命令默认不允许非快速合并的更新，以防止这种历史的损失。

note: type: Plain text
en: If you do not want to lose your work (history from X to B) or the work by the other person (history from X to A), you would need to first fetch the history from the repository, create a history that contains changes done by both parties, and push the result back.
zh_HANS-CN: 如果你不想丢失你的工作（从 X 到 B 的历史）或对方的工作（从 X 到 A 的历史），你需要先从仓库中获取历史，创建一个包含双方修改的历史，并将结果推送回去。

note: type: Plain text
en: 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.
zh_HANS-CN: 您可以执行 "git pull"，解决潜在的冲突，然后将结果 "git push"。  一个 "git pull "会在提交 A 和 B 之间创建一个合并提交 C。

note: type: Plain text
en: Updating A with the resulting merge commit will fast-forward and your push will be accepted.
zh_HANS-CN: 用所产生的合并提交更新 A，将快速合并，你的推送将被接受。

note: type: Plain text
en: 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.
zh_HANS-CN: 另外，你也可以用 "git pull --rebase" 将 X 和 B 之间的改动重新归档到 A 之上，然后将结果推送回来。  重置将创建一个新的提交 D，将 X 和 B 之间的修改建立在 A 的基础上。

note: type: Plain text
en: Again, updating A with this commit will fast-forward and your push will be accepted.
zh_HANS-CN: 同样的，用这个提交更新 A 会快速合并，你的推送会被接受。

note: type: Plain text
en: There is another common situation where you may encounter non-fast-forward rejection when you try to push, and it is possible even when you are pushing into a repository nobody else pushes into. After you push commit A yourself (in the first picture in this section), replace it with "git commit --amend" to produce commit B, and you try to push it out, because forgot that you have pushed A out already. In such a case, and only if you are certain that nobody in the meantime fetched your earlier commit A (and started building on top of it), you can run "git push --force" to overwrite it. In other words, "git push --force" is a method reserved for a case where you do mean to lose history.
zh_HANS-CN: 还有一种常见的情况是，当你试图推送时，可能会遇到非快速合并拒绝，即使你推送到一个没有人推送的版本库中也有可能。在你自己推送了提交 A（在本节的第一幅图中），用 "git commit --amend" 替换后产生了提交 B，你试图推送它，因为忘记了你已经推送了 A。在这种情况下，只有当您确定在此期间没有人取走您先前的提交 A（并在其基础上开始构建），您才能运行 "git push --force" 来覆盖它。换句话说，"git push --force" 是一种保留给你确实想失去历史的情况的方法。

note: type: Plain text
en: Works like `git push <remote>`, where <remote> is the current branch's remote (or `origin`, if no remote is configured for the current branch).
zh_HANS-CN: 像`git push < 远端 >`那样工作，其中 < 远端 > 是当前分支的远程仓库（或者`origin`，如果没有为当前分支配置远程仓库）。

note: type: Plain text
en: Without additional configuration, pushes the current branch to the configured upstream (`branch.<name>.merge` configuration variable) if it has the same name as the current branch, and errors out without pushing otherwise.
zh_HANS-CN: 不需要额外配置，如果它与当前分支同名，并且错误输出而不推送其他分支，则将其推送到配置过的上游仓库（`branch.<分支名>.merge` 配置变量）。

note: type: Plain text
en: The default behavior of this command when no <refspec> is given can be configured by setting the `push` option of the remote, or the `push.default` configuration variable.
zh_HANS-CN: 当没有给出< 引用规范 >时，该命令的默认行为可以通过设置远程仓库的 `push` 选项或 `push.default`配置变量来配置。

note: type: Plain text
en: 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`.
zh_HANS-CN: 例如，要默认只将当前分支推送到 `origin`，使用 `git config remote.origin.push HEAD`。  任何有效的< 引用规范 >（比如下面例子中的那些）都可以被配置为 `git push origin` 的默认值。

note: type: Plain text
en: Push "matching" branches to `origin`. See <refspec> in the <<OPTIONS,OPTIONS>> section above for a description of "matching" branches.
zh_HANS-CN: 将 “匹配” 的分支推送到 `origin`。关于 “匹配” 分支的描述，请参见上面 <<选项,OPTIONS>> 部分的 <<引用规范>>。

note: type: Plain text
en: 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.
zh_HANS-CN: 在源仓库中找到一个与 `master` 相匹配的引用（最可能的是找到 `refs/heads/master`），并在 `origin` 仓库中用它更新相同的引用（例如`refs/heads/master`）。  如果 `master` 不存在，它将被创建。

note: type: Plain text
en: A handy way to push the current branch to the same name on the remote.
zh_HANS-CN: 一个方便的方法是将当前分支推送到远程的相同名称。

note: type: Plain text
en: 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`.
zh_HANS-CN: 使用与 "master" 相匹配的源引用（例如，`refs/heads/master`）来更新 `mothership` 仓库中与 `satellite/master` 相匹配的引用（很可能是 `refs/remotes/satellite/master`）；对 `dev` 和 `satellite/dev`做同样的操作。

note: type: Plain text
en: See the section describing `<refspec>...` above for a discussion of the matching semantics.
zh_HANS-CN: 关于匹配语义的讨论，请参见上面描述 `<引用规范>...` 的部分。

note: type: Plain text
en: This is to emulate `git fetch` run on the `mothership` using `git push` that is run in the opposite direction in order to integrate the work done on `satellite`, and is often necessary when you can only make connection in one way (i.e. satellite can ssh into mothership but mothership cannot initiate connection to satellite because the latter is behind a firewall or does not run sshd).
zh_HANS-CN: 这是为了模拟在`母舰` 上运行的 `git fetch` ，使用 `git push` 以相反的方向运行，以便整合 `卫星` 上完成的工作，当你只能以一种方式进行连接时（即卫星可以ssh到母舰，但母舰不能启动与卫星的连接，因为后者在防火墙后面或不运行 sshd），这往往是必要的。

note: type: Plain text
en: After running this `git push` on the `satellite` machine, you would ssh into the `mothership` and run `git merge` there to complete the emulation of `git pull` that were run on `mothership` to pull changes made on `satellite`.
zh_HANS-CN: 在 `卫星` 机器上运行这个 `git push` 后，你将 ssh 进入 `母舰` 并在那里运行 `git merge` ，以完成对 `母舰` 上运行的 `git pull` 的模拟，以拉取 `卫星` 上的修改。

note: type: Plain text
en: Push the current branch to the remote ref matching `master` in the `origin` repository. This form is convenient to push the current branch without thinking about its local name.
zh_HANS-CN: 推送当前分支到远程引用匹配 `master` 的 `origin` 仓库中。这种形式可以方便地推送当前分支，而不必考虑其本地名称。

note: type: Plain text
en: 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.
zh_HANS-CN: 通过复制当前的 `master` 分支，在 `origin` 仓库创建 `experimental` 分支。  只有在本地名称和远程名称不同的情况下，在远程仓库中创建新的分支或标签时才需要这个表单；否则，参考名称本身就可以了。

note: type: Plain text
en: Find a ref that matches `experimental` in the `origin` repository (e.g. `refs/heads/experimental`), and delete it.
zh_HANS-CN: 在 `origin` 仓库（例如`refs/heads/experimental`）中找到一个与 `experimental` 相匹配的引用，并将其删除。

note: type: Plain text
en: 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:
zh_HANS-CN: 用开发分支更新仓库的主分支，允许非快速合并更新。  *这可能会使未引用的提交在源码库中悬空。*考虑以下情况，即不可能进行快速合并：

note: type: Plain text
en: The above command would change the origin repository to
zh_HANS-CN: 上面的命令将 origin 仓库更改为

note: type: Plain text
en: 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.
zh_HANS-CN: 提交 A 和 B 将不再属于具有符号名称的分支，因此将不可访问。因此，这些提交将被原始存储库上的“ gitgc”命令删除。

note: type: Plain text
en: git-quiltimport - Applies a quilt patchset onto the current branch
zh_HANS-CN: git-quiltimport - 在当前分支上应用被子补丁集

note: type: Plain text
en: Applies a quilt patchset onto the current Git branch, preserving the patch boundaries, patch order, and patch descriptions present in the quilt patchset.
zh_HANS-CN: 在当前 Git 分支上应用拼接补丁集，保留拼接补丁集中的补丁边界、补丁顺序和补丁描述。

note: type: Plain text
en: For each patch the code attempts to extract the author from the patch description.  If that fails it falls back to the author specified with --author.  If the --author flag was not given the patch description is displayed and the user is asked to interactively enter the author of the patch.
zh_HANS-CN: 对于每个补丁，代码会尝试从补丁描述中提取作者。 如果失败，则返回到用 --author 指定的作者。 如果没有给定 --author 标志，则显示补丁描述，并要求用户交互式输入补丁的作者。

note: type: Plain text
en: If a subject is not found in the patch description the patch name is preserved as the 1 line subject in the Git description.
zh_HANS-CN: 如果在补丁描述中找不到主题，补丁名称将保留为 Git 描述中的一行主题。

note: type: Plain text
en: Walk through the patches in the series and warn if we cannot find all of the necessary information to commit a patch.  At the time of this writing only missing author information is warned about.
zh_HANS-CN: 浏览系列补丁，并在无法找到提交补丁所需的全部信息时发出警告。 在写这篇文章的时候，只有缺少作者信息的补丁才会被警告。

note: type: Plain text
en: The author name and email address to use when no author information can be found in the patch description.
zh_HANS-CN: 在补丁说明中找不到作者信息时使用的作者姓名和电子邮件地址。

note: type: Plain text
en: The directory to find the quilt patches.
zh_HANS-CN: 查找被子补丁的目录。

note: type: Plain text
en: The default for the patch directory is patches or the value of the `$QUILT_PATCHES` environment variable.
zh_HANS-CN: 补丁目录的默认值是 patches 或 `$QUILT_PATCHES` 环境变量的值。

note: type: Plain text
en: The quilt series file.
zh_HANS-CN: 被子系列文件。

note: type: Plain text
en: The default for the series file is <patches>/series or the value of the `$QUILT_SERIES` environment variable.
zh_HANS-CN: 系列文件的默认值是 <patches>/series 或 `$QUILT_SERIES` 环境变量的值。

note: type: Plain text
en: git-range-diff - Compare two commit ranges (e.g. two versions of a branch)
zh_HANS-CN: git-range-diff - 比较两个提交范围（例如一个分支的两个版本）

note: type: Plain text
en: This command shows the differences between two versions of a patch series, or more generally, two commit ranges (ignoring merge commits).
zh_HANS-CN: 该命令显示补丁系列的两个版本之间的差异，或者更笼统地说，两个提交范围之间的差异（忽略合并提交）。

note: type: Plain text
en: In the presence of `<path>` arguments, these commit ranges are limited accordingly.
zh_HANS-CN: 如果存在 `<path>` 参数，这些提交范围将受到相应的限制。

note: type: Plain text
en: To that end, it first finds pairs of commits from both commit ranges that correspond with each other. Two commits are said to correspond when the diff between their patches (i.e. the author information, the commit message and the commit diff) is reasonably small compared to the patches' size. See ``Algorithm`` below for details.
zh_HANS-CN: 为此，它首先从两个提交范围中找到相互对应的提交对。当两个补丁之间的差值（即作者信息、提交信息和提交差值）相对于补丁的大小相当小时，这两个提交就被认为是对应的。详见下面的 ``算法``。

note: type: Plain text
en: Finally, the list of matching commits is shown in the order of the second commit range, with unmatched commits being inserted just after all of their ancestors have been shown.
zh_HANS-CN: 最后，匹配的提交列表会按照第二个提交范围的顺序显示，未匹配的提交会在其所有祖先提交显示之后插入。

note: type: Plain text
en: There are three ways to specify the commit ranges:
zh_HANS-CN: 指定提交范围有三种方法 :

note: type: Plain text
en: `<range1> <range2>`: Either commit range can be of the form `<base>..<rev>`, `<rev>^!` or `<rev>^-<n>`. See `SPECIFYING RANGES` in linkgit:gitrevisions[7] for more details.
zh_HANS-CN: `<range1> <range2>`： 提交范围可以是 `<base>...<rev>`、`<rev>^!` 或 `<rev>^-<n>`。详见 linkgit:gitrevisions[7] 中的 `指定范围`。

note: type: Plain text
en: `<rev1>...<rev2>`. This is equivalent to `<rev2>..<rev1> <rev1>..<rev2>`.
zh_HANS-CN: `<rev1>...<rev2>`。这等同于 `<rev2>...<rev1> <rev1>...<rev2>`.

note: type: Plain text
en: `<base> <rev1> <rev2>`: This is equivalent to `<base>..<rev1> <base>..<rev2>`.
zh_HANS-CN: `<base> <rev1> <rev2>`： 等同于 `<base>..<rev1> <base>..<rev2>`.

note: type: Plain text
en: When the commit diffs differ, `git range-diff` recreates the original diffs' coloring, and adds outer -/+ diff markers with the *background* being red/green to make it easier to see e.g.  when there was a change in what exact lines were added.
zh_HANS-CN: 当提交的差异不同时，`git range-diff`会重现原始差异的颜色，并添加外层的 -/+ 差异标记，*背景* 为红/绿色，以便于查看，例如，当具体添加了哪些行时。

note: type: Plain text
en: Additionally, the commit diff lines that are only present in the first commit range are shown "dimmed" (this can be overridden using the `color.diff.<slot>` config setting where `<slot>` is one of `contextDimmed`, `oldDimmed` and `newDimmed`), and the commit diff lines that are only present in the second commit range are shown in bold (which can be overridden using the config settings `color.diff.<slot>` with `<slot>` being one of `contextBold`, `oldBold` or `newBold`).
zh_HANS-CN: 此外，只出现在第一个提交范围内的提交差异行会显示为 "dimmed"（这可以使用 `color.diff. <slot>` 配置设置，其中 `<slot>` 是`contextDimmed`、`oldDimmed` 和 `newDimmed` 中的一个），而仅出现在第二个提交范围内的提交差异行以粗体显示（这可以通过配置设置 `color.diff.<slot>` 来覆盖，其中 `<slot>` 是 `contextBold`、`oldBold` 和 `newBold` 中的一个）。

note: type: Plain text
en: This is known to `range-diff` as "dual coloring". Use `--no-dual-color` to revert to color all lines according to the outer diff markers (and completely ignore the inner diff when it comes to color).
zh_HANS-CN: 这在 `range-diff` 中被称为 "双重着色"。使用 `--no-dual-color` 可以还原为根据外部差异标记对所有线条着色（在着色时完全忽略内部差异）。

note: type: Plain text
en: Set the creation/deletion cost fudge factor to `<percent>`.  Defaults to 60. Try a larger value if `git range-diff` erroneously considers a large change a total rewrite (deletion of one commit and addition of another), and a smaller one in the reverse case.  See the ``Algorithm`` section below for an explanation why this is needed.
zh_HANS-CN: 将创建/删除成本误差因子设置为 `<percent>`。 默认为 60。如果 `git range-diff` 错误地认为一个大的改动是完全重写 (删除一个提交，增加另一个提交)，可以使用较大的值，反之则使用较小的值。 请参阅下面的 ``算法`` 部分以了解为什么需要这个值。

note: type: Plain text
en: Suppress commits that are missing from the first specified range (or the "left range" when using the `<rev1>...<rev2>` format).
zh_HANS-CN: 忽略第一个指定范围（或使用 `<rev1>...<rev2>` 格式时的 "左侧范围"）中丢失的提交。

note: type: Plain text
en: Suppress commits that are missing from the second specified range (or the "right range" when using the `<rev1>...<rev2>` format).
zh_HANS-CN: 忽略第二个指定范围（或使用 `<rev1>...<rev2>` 格式时的 "右侧范围"）中丢失的提交。

note: type: Plain text
en: This flag is passed to the `git log` program (see linkgit:git-log[1]) that generates the patches.
zh_HANS-CN: 这个标志将传递给生成补丁的 `git log` 程序（参见 linkgit:git-log[1]）。

note: type: Plain text
en: Compare the commits specified by the two ranges, where `<range1>` is considered an older version of `<range2>`.
zh_HANS-CN: 比较两个范围指定的提交，其中 `<range1>` 被认为是 `<range2>` 的旧版本。

note: type: Plain text
en: Equivalent to passing `<rev2>..<rev1>` and `<rev1>..<rev2>`.
zh_HANS-CN: 相当于传递 `<rev2>...<rev1>` 和 `<rev1>...<rev2>`。

note: type: Plain text
en: Equivalent to passing `<base>..<rev1>` and `<base>..<rev2>`.  Note that `<base>` does not need to be the exact branch point of the branches. Example: after rebasing a branch `my-topic`, `git range-diff my-topic@{u} my-topic@{1} my-topic` would show the differences introduced by the rebase.
zh_HANS-CN: 等同于传递 `<base>...<rev1>` 和 `<base>...<rev2>`。 注意 `<base>` 不需要是分支的确切分支点。例如： 在重定向分支 `my-topic` 之后， `git range-diff my-topic@{u} my-topic@{1} my-topic` 将显示重定向带来的差异。

note: type: Plain text
en: `git range-diff` also accepts the regular diff options (see linkgit:git-diff[1]), most notably the `--color=[<when>]` and `--no-color` options. These options are used when generating the "diff between patches", i.e. to compare the author, commit message and diff of corresponding old/new commits. There is currently no means to tweak most of the diff options passed to `git log` when generating those patches.
zh_HANS-CN: `git range-diff` 也接受常规的 diff 选项 (参见 linkgit:git-diff[1])，特别是 `--color=[<when>]` 和 `--no-color` 选项。这些选项用于生成 “补丁间的差异”，即比较新旧提交的作者、提交信息和差异。目前还没有办法调整生成补丁时传递给 `git log` 的大部分 diff 选项。

note: type: Title -
en: OUTPUT STABILITY
zh_HANS-CN: 输出稳定性

note: type: Plain text
en: The output of the `range-diff` command is subject to change. It is intended to be human-readable porcelain output, not something that can be used across versions of Git to get a textually stable `range-diff` (as opposed to something like the `--stable` option to linkgit:git-patch-id[1]). There's also no equivalent of linkgit:git-apply[1] for `range-diff`, the output is not intended to be machine-readable.
zh_HANS-CN: `range-diff` 命令的输出可能会改变。它的目的是提供人类可读的上层命令输出，而不是可以在不同版本的 Git 中使用以获得文本稳定的 `range-diff` (与 linkgit:git-patch-id[1] 的 `--stable` 选项不同)。对于 `range-diff` 来说，也没有与 linkgit:git-apply[1] 等价的东西，其输出不是机器可读的。

note: type: Plain text
en: This is particularly true when passing in diff options. Currently some options like `--stat` can, as an emergent effect, produce output that's quite useless in the context of `range-diff`. Future versions of `range-diff` may learn to interpret such options in a manner specific to `range-diff` (e.g. for `--stat` producing human-readable output which summarizes how the diffstat changed).
zh_HANS-CN: 当传递 diff 选项时尤其如此。目前，一些选项，例如 `--stat`，会在 `range-diff` 的上下文中产生无用的输出。未来版本的 `range-diff` 可能会学习如何以 `range-diff` 特有的方式来解释这些选项 (例如， `--stat` 产生人类可读的输出，总结了 diffstat 的变化情况)。

note: type: Plain text
en: This command uses the `diff.color.*` and `pager.range-diff` settings (the latter is on by default).  See linkgit:git-config[1].
zh_HANS-CN: 该命令使用 `diff.color.*` 和 `pager.range-diff` 设置（后者默认开启）。 参见 linkgit:git-config[1]。

note: type: Plain text
en: When a rebase required merge conflicts to be resolved, compare the changes introduced by the rebase directly afterwards using:
zh_HANS-CN: 当重置需要解决合并冲突时，直接比较重置后引入的更改，使用 :

note: type: Plain text
en: A typical output of `git range-diff` would look like this:
zh_HANS-CN: `git range-diff` 的典型输出如下：

note: type: delimited block -
en:     -+What is unexpected is that it will also crash.
        ++Unexpectedly, it also crashes. This is a bug, and the jury is
        ++still out there how to fix it best. See ticket #314 for details.
zh_HANS-CN:     -+出乎意料的是，它也会崩溃。
        ++出乎意料的是，它也会崩溃。这是一个bug，陪审团还在讨论如何最好地修复它。
        ++如何最好地修复它，还没有定论。详见 #314 号记录。

note: type: Plain text
en: In this example, there are 3 old and 3 new commits, where the developer removed the 3rd, added a new one before the first two, and modified the commit message of the 2nd commit as well its diff.
zh_HANS-CN: 在这个例子中，有 3 个旧提交和 3 个新提交，开发者删除了第 3 个提交，在前两个提交之前添加了一个新提交，并修改了第 2 个提交的提交信息及其差异。

note: type: Plain text
en: When the output goes to a terminal, it is color-coded by default, just like regular `git diff`'s output. In addition, the first line (adding a commit) is green, the last line (deleting a commit) is red, the second line (with a perfect match) is yellow like the commit header of `git show`'s output, and the third line colors the old commit red, the new one green and the rest like `git show`'s commit header.
zh_HANS-CN: 当输出到终端时，默认是用颜色编码的，就像普通的 `git diff` 输出一样。此外，第一行（添加提交）是绿色的，最后一行（删除提交）是红色的，第二行（完全匹配）是黄色的，就像 `git show` 输出的提交头一样，第三行旧提交是红色的，新提交是绿色的，其余的就像 `git show` 的提交头一样。

note: type: Plain text
en: A naive color-coded diff of diffs is actually a bit hard to read, though, as it colors the entire lines red or green. The line that added "What is unexpected" in the old commit, for example, is completely red, even if the intent of the old commit was to add something.
zh_HANS-CN: 不过，用颜色编码的原 diff 实际上有点难读，因为它会把整行都染成红色或绿色。例如，在旧提交中添加了 "What is unexpected" 的那行就完全是红色的，即使旧提交的意图是添加一些东西。

note: type: Plain text
en: To help with that, `range` uses the `--dual-color` mode by default. In this mode, the diff of diffs will retain the original diff colors, and prefix the lines with -/+ markers that have their *background* red or green, to make it more obvious that they describe how the diff itself changed.
zh_HANS-CN: 为了解决这个问题，`range` 默认使用 `--dual-color` 模式。在这种模式下，diffs 的 diff 将保留原始的 diff 颜色，并在行的前缀加上 -/+ 标记，其 *背景* 为红色或绿色，以便更明显地描述 diff 本身是如何改变的。

note: type: Title -
en: Algorithm
zh_HANS-CN: 算法

note: type: Plain text
en: The general idea is this: we generate a cost matrix between the commits in both commit ranges, then solve the least-cost assignment.
zh_HANS-CN: 总体思路是这样的：我们在两个提交范围内的提交之间生成一个成本矩阵，然后求解最小成本分配。

note: type: Plain text
en: The cost matrix is populated thusly: for each pair of commits, both diffs are generated and the "diff of diffs" is generated, with 3 context lines, then the number of lines in that diff is used as cost.
zh_HANS-CN: 成本矩阵是这样填充的：对于每一对提交，生成两个差异，并生成 “差异的差异”，其中包含 3 行上下文，然后将差异中的行数作为成本。

note: type: Plain text
en: To avoid false positives (e.g. when a patch has been removed, and an unrelated patch has been added between two iterations of the same patch series), the cost matrix is extended to allow for that, by adding fixed-cost entries for wholesale deletes/adds.
zh_HANS-CN: 为了避免假阳性（例如，当一个补丁被删除，而在同一补丁系列的两次迭代之间又添加了一个不相关的补丁），成本矩阵通过为整体删除/添加添加固定成本条目进行扩展，以考虑到这一点。

note: type: Plain text
en: Example: Let commits `1--2` be the first iteration of a patch series and `A--C` the second iteration. Let's assume that `A` is a cherry-pick of `2,` and `C` is a cherry-pick of `1` but with a small modification (say, a fixed typo). Visualize the commits as a bipartite graph:
zh_HANS-CN: 示例： 假设 `1--2` 是补丁系列的第一次迭代，`A--C`是第二次迭代。假设 `A`是从 `2` 中挑选出来的，而 `C` 是从 `1` 中挑选出来的，但做了一点修改（比如，一个固定的错别字）。将提交可视化为一个二元图：

note: type: Plain text
en: We are looking for a "best" explanation of the new series in terms of the old one. We can represent an "explanation" as an edge in the graph:
zh_HANS-CN: 我们正在寻找新系列对旧系列的 “最佳” 解释。我们可以将 “解释” 表示为图中的一条边：

note: type: Plain text
en: This explanation comes for "free" because there was no change. Similarly `C` could be explained using `1`, but that comes at some cost c>0 because of the modification:
zh_HANS-CN: 这个解释是 “免费” 的，因为没有任何改变。同样地，`C` 可以用 `1`来解释，但由于修改，这需要付出一定的代价 c>0 :

note: type: Plain text
en: In mathematical terms, what we are looking for is some sort of a minimum cost bipartite matching; `1` is matched to `C` at some cost, etc. The underlying graph is in fact a complete bipartite graph; the cost we associate with every edge is the size of the diff between the two commits' patches. To explain also new commits, we introduce dummy nodes on both sides:
zh_HANS-CN: 用数学术语来说，我们要寻找的是某种最小代价的双栅格匹配；`1` 以某种代价匹配到 `C`，等等。底层图实际上是一个完整的双向图；我们与每条边相关联的代价是两个提交补丁之间的差值大小。为了解释新提交，我们在两边都引入了虚节点：

note: type: Plain text
en: The cost of an edge `o--C` is the size of `C`'s diff, modified by a fudge factor that should be smaller than 100%. The cost of an edge `o--o` is free. The fudge factor is necessary because even if `1` and `C` have nothing in common, they may still share a few empty lines and such, possibly making the assignment `1--C`, `o--o` slightly cheaper than `1--o`, `o--C` even if `1` and `C` have nothing in common. With the fudge factor we require a much larger common part to consider patches as corresponding.
zh_HANS-CN: 边 `o--C` 的代价是 `C` 的差值大小，再加上一个应小于 100% 的修正系数。边 `o--o` 的代价是免费的。修正系数是必要的，因为即使 `1` 和 `C` 没有共同点，它们仍可能共享一些空行等，这可能会使赋值 `1--C`, `o--o` 比 `1--o`, `o--C` 稍微便宜一些，即使 `1` 和 `C` 没有共同点。有了模糊因子，我们需要更大的公共部分才能将补丁视为一对的。

note: type: Plain text
en: The overall time needed to compute this algorithm is the time needed to compute n+m commit diffs and then n*m diffs of patches, plus the time needed to compute the least-cost assignment between n and m diffs. Git uses an implementation of the Jonker-Volgenant algorithm to solve the assignment problem, which has cubic runtime complexity. The matching found in this case will look like this:
zh_HANS-CN: 计算该算法所需的总时间是计算 n+m 个提交差异和 n*m 个补丁差异所需的时间，再加上计算 n 和 m 个差异之间的最小成本赋值所需的时间。Git 使用 Jonker-Volgenant 算法来解决分配问题，该算法的运行复杂度为立方。在这种情况下找到的匹配结果是这样的 :

note: type: Plain text
en: git-rebase - Reapply commits on top of another base tip
zh_HANS-CN: git-rebase - 在另一个基础提示之上重新应用提交内容

note: type: Plain text
en: If `<branch>` is specified, `git rebase` will perform an automatic `git switch <branch>` before doing anything else.  Otherwise it remains on the current branch.
zh_HANS-CN: 如果指定了 `<branch>`，`git rebase` 会自动执行 `git switch <branch>`，然后再做其他事情。 否则，它会保留在当前分支上。

note: type: Plain text
en: If `<upstream>` is not specified, the upstream configured in `branch.<name>.remote` and `branch.<name>.merge` options will be used (see linkgit:git-config[1] for details) and the `--fork-point` option is assumed.  If you are currently not on any branch or if the current branch does not have a configured upstream, the rebase will abort.
zh_HANS-CN: 如果未指定 `<upstream>`，将使用 `branch.<name>.remote` 和 `branch.<name>.merge` 选项中配置的上游（详见 linkgit:git-config[1]），并假定使用 `-fork-point`选项。  如果您当前不在任何分支上，或者当前分支没有配置上游，变基操作会中止。

note: type: Plain text
en: All changes made by commits in the current branch but that are not in `<upstream>` are saved to a temporary area.  This is the same set of commits that would be shown by `git log <upstream>..HEAD`; or by `git log 'fork_point'..HEAD`, if `--fork-point` is active (see the description on `--fork-point` below); or by `git log HEAD`, if the `--root` option is specified.
zh_HANS-CN: 当前分支中的所有提交所做的改动，但不在 `<upstream>` 中的，都会被保存到一个临时区域。  这与 `git log <upstream>..HEAD` 或 `git log 'fork_point'..HEAD` 所显示的提交相同（如果启用了 `-fork-point`，请参阅下文关于 `-fork-point`的描述）；或者，如果指定了 `--root` 选项，则与 `git log HEAD` 所显示的提交相同。

note: type: Plain text
en: The current branch is reset to `<upstream>` or `<newbase>` if the `--onto` option was supplied.  This has the exact same effect as `git reset --hard <upstream>` (or `<newbase>`). `ORIG_HEAD` is set to point at the tip of the branch before the reset.
zh_HANS-CN: 如果提供了 `--onto` 选项，当前分支会重置为 `<upstream>` 或 `<newbase>`。  这与 `git reset --hard <upstream>`（或 `<newbase>`）的效果完全相同。`ORIG_HEAD` 设置为指向重置前分支的顶端。

note: type: Plain text
en: `ORIG_HEAD` is not guaranteed to still point to the previous branch tip at the end of the rebase if other commands that write that pseudo-ref (e.g. `git reset`) are used during the rebase. The previous branch tip, however, is accessible using the reflog of the current branch (i.e. `@{1}`, see linkgit:gitrevisions[7]).
zh_HANS-CN: 如果在重置过程中使用了其他写入伪引用的命令（例如 `git reset`），就不能保证 `ORIG_HEAD` 在重置结束时仍然指向前一个分支的分支提示。不过，使用当前分支的 引用日志（即 `@{1}`，参见 linkgit:gitrevisions[7]）可以访问前一个分支的分支提示。

note: type: Plain text
en: The commits that were previously saved into the temporary area are then reapplied to the current branch, one by one, in order. Note that any commits in `HEAD` which introduce the same textual changes as a commit in `HEAD..<upstream>` are omitted (i.e., a patch already accepted upstream with a different commit message or timestamp will be skipped).
zh_HANS-CN: 然后，先前保存在临时区域的提交将按顺序逐一重新应用到当前分支。请注意，`HEAD` 中任何与 `HEAD...<upstream>` 中的提交有相同文字改动的提交都会被省略（也就是说，上游已经接受的补丁，如果提交信息或时间戳不同，就会被跳过）。

note: type: Plain text
en: It is possible that a merge failure will prevent this process from being completely automatic.  You will have to resolve any such merge failure and run `git rebase --continue`.  Another option is to bypass the commit that caused the merge failure with `git rebase --skip`.  To check out the original `<branch>` and remove the `.git/rebase-apply` working files, use the command `git rebase --abort` instead.
zh_HANS-CN: 合并失败有可能导致该过程无法完全自动进行。  您必须解决合并失败问题，然后运行 `git rebase --continue`。  另一种方法是使用 `git rebase --skip` 绕过导致合并失败的提交。  要检查原始的 `<branch>` 并移除 `.git/rebase-apply` 工作文件，请使用 `git rebase --abort` 命令。

note: type: Plain text
en: Assume the following history exists and the current branch is "topic":
zh_HANS-CN: 假设存在以下历史记录，当前分支为 "topic"：

note: type: Plain text
en: From this point, the result of either of the following commands:
zh_HANS-CN: 从这一点来看，以下任一命令的结果都是如此：

note: type: Plain text
en: would be:
zh_HANS-CN: 那就是 :

note: type: Plain text
en: *NOTE:* The latter form is just a short-hand of `git checkout topic`
    followed by `git rebase master`. When rebase exits `topic` will
    remain the checked-out branch.
zh_HANS-CN: *注：* 后一种形式只是 `git checkout topic` 的简写。
    后接 `git rebase master`。当 rebase 退出时，`topic` 将
    仍是已签出的分支。

note: type: Plain text
en: If the upstream branch already contains a change you have made (e.g., because you mailed a patch which was applied upstream), then that commit will be skipped and warnings will be issued (if the 'merge' backend is used).  For example, running `git rebase master` on the following history (in which `A'` and `A` introduce the same set of changes, but have different committer information):
zh_HANS-CN: 如果上游分支已经包含了您所做的修改（例如，因为您邮寄的补丁被应用到了上游），那么该提交将被跳过，并发出警告（如果使用了 “合并” 后台）。 例如，在以下历史记录上运行 `git rebase master`（其中 `A'` 和 `A` 引入了相同的变更集，但提交者信息不同）：

note: type: Plain text
en: will result in:
zh_HANS-CN: 将导致 :

note: type: Plain text
en: Here is how you would transplant a topic branch based on one branch to another, to pretend that you forked the topic branch from the latter branch, using `rebase --onto`.
zh_HANS-CN: 下面是如何使用 `rebase --onto` 将基于一个分支的特性分支移植到另一个分支，以假装特性分支是从后一个分支分叉而来。

note: type: Plain text
en: First let's assume your 'topic' is based on branch 'next'.  For example, a feature developed in 'topic' depends on some functionality which is found in 'next'.
zh_HANS-CN: 首先，我们假设 'topic' 基于 'next' 分支。 例如，'topic' 中开发的功能依赖于 'next' 中的某些功能。

note: type: Plain text
en: We want to make 'topic' forked from branch 'master'; for example, because the functionality on which 'topic' depends was merged into the more stable 'master' branch. We want our tree to look like this:
zh_HANS-CN: 我们想让 'topic' 从分支 'master' 中分叉出来；例如，因为 'topic' 所依赖的功能已经合并到了更稳定的分支 'master' 中。我们希望我们的提交树看起来像这样 :

note: type: Plain text
en: We can get this using the following command:
zh_HANS-CN: 我们可以使用以下命令来获取 :

note: type: Plain text
en: then the command
zh_HANS-CN: 那么命令

note: type: Plain text
en: would result in:
zh_HANS-CN: 将导致 :

note: type: Plain text
en: This is useful when topicB does not depend on topicA.
zh_HANS-CN: 这在主题 B 不依赖于主题 A 的情况下非常有用。

note: type: Plain text
en: A range of commits could also be removed with rebase.  If we have the following situation:
zh_HANS-CN: 也可以用变基删除一系列提交。 如果我们遇到以下情况 :

note: type: Plain text
en: would result in the removal of commits F and G:
zh_HANS-CN: 将导致删除 F 和 G 项：

note: type: Plain text
en: This is useful if F and G were flawed in some way, or should not be part of topicA.  Note that the argument to `--onto` and the `<upstream>` parameter can be any valid commit-ish.
zh_HANS-CN: 如果 F 和 G 在某些方面有缺陷，或者不应该是 topicA 的一部分，这一点就很有用。 请注意，`--onto` 参数和 `<upstream>` 参数可以是任何有效的提交。

note: type: Plain text
en: In case of conflict, `git rebase` will stop at the first problematic commit and leave conflict markers in the tree.  You can use `git diff` to locate the markers (<<<<<<) and make edits to resolve the conflict.  For each file you edit, you need to tell Git that the conflict has been resolved, typically this would be done with
zh_HANS-CN: 如果出现冲突，`git rebase` 会在第一个有问题的提交处停止，并在树中留下冲突标记。 你可以用 `git diff` 找到这些标记 (<<<<<<)，并进行编辑以解决冲突。 每编辑一个文件，都需要告诉 Git 冲突已被解决，通常可以用

note: type: Plain text
en: After resolving the conflict manually and updating the index with the desired resolution, you can continue the rebasing process with
zh_HANS-CN: 手动解决冲突并以所需的分辨率更新索引后，您可以使用

note: type: Plain text
en: Alternatively, you can undo the 'git rebase' with
zh_HANS-CN: 或者，您也可以通过以下方法撤销 'git rebase' 操作

note: type: Plain text
en: The options in this section cannot be used with any other option, including not with each other:
zh_HANS-CN: 本节中的选项不能与任何其他选项一起使用，包括不能相互使用：

note: type: Plain text
en: Restart the rebasing process after having resolved a merge conflict.
zh_HANS-CN: 解决合并冲突后，重新启动重新分区进程。

note: type: Plain text
en: Restart the rebasing process by skipping the current patch.
zh_HANS-CN: 跳过当前补丁，重新启动重新分区进程。

note: type: Plain text
en: Abort the rebase operation and reset HEAD to the original branch. If `<branch>` was provided when the rebase operation was started, then `HEAD` will be reset to `<branch>`. Otherwise `HEAD` will be reset to where it was when the rebase operation was started.
zh_HANS-CN: 终止变基操作并将 HEAD 重置为原始分支。如果在启动变基操作时提供了 `<分支>`，那么 `HEAD` 将被重置为 `<分支>`。否则，`HEAD` 将被重置为启动变基操作时的位置。

note: type: Plain text
en: Abort the rebase operation but `HEAD` is not reset back to the original branch. The index and working tree are also left unchanged as a result. If a temporary stash entry was created using `--autostash`, it will be saved to the stash list.
zh_HANS-CN: 放弃变基操作，但 `HEAD` 不会重置回原始分支。索引和工作树也会因此保持不变。如果使用 `--autostash` 创建了临时储藏条目，它将被保存到储藏列表中。

note: type: Plain text
en: Edit the todo list during an interactive rebase.
zh_HANS-CN: 在交互式变基过程中编辑待办事项列表。

note: type: Plain text
en: Show the current patch in an interactive rebase or when rebase is stopped because of conflicts. This is the equivalent of `git show REBASE_HEAD`.
zh_HANS-CN: 在交互式变基或因冲突而停止变基时显示当前补丁。相当于 `git show REBASE_HEAD`。

note: type: Plain text
en: Starting point at which to create the new commits. If the `--onto` option is not specified, the starting point is `<upstream>`.  May be any valid commit, and not just an existing branch name.
zh_HANS-CN: 创建新提交的起点。如果未指定 `--onto` 选项，则起点为 `<upstream>`。 可以是任何有效的提交，而不仅仅是现有的分支名称。

note: type: Plain text
en: As a special case, you may use "A\...B" as a shortcut for the merge base of A and B if there is exactly one merge base. You can leave out at most one of A and B, in which case it defaults to HEAD.
zh_HANS-CN: 作为一种特殊情况，如果 A 和 B 的合并库只有一个，则可以使用 "A\...B "作为合并库的快捷方式。您最多可以省略 A 和 B 中的一个，在这种情况下，它默认为 HEAD。

note: type: Plain text
en: Set the starting point at which to create the new commits to the merge base of `<upstream>` and `<branch>`. Running `git rebase --keep-base <upstream> <branch>` is equivalent to running `git rebase --reapply-cherry-picks --no-fork-point --onto <upstream>...<branch> <upstream> <branch>`.
zh_HANS-CN: 将创建新提交的起点设为 `<upstream>` 和 `<branch>` 的合并库。运行 `git rebase --keep-base <upstream> <branch>` 相当于运行 `git rebase --reapply-cherry-picks --no-fork-point --onto <upstream>...<branch> <upstream> <branch>` 。

note: type: Plain text
en: This option is useful in the case where one is developing a feature on top of an upstream branch. While the feature is being worked on, the upstream branch may advance and it may not be the best idea to keep rebasing on top of the upstream but to keep the base commit as-is. As the base commit is unchanged this option implies `--reapply-cherry-picks` to avoid losing commits.
zh_HANS-CN: 该选项适用于在上游分支上开发功能的情况。在开发功能的过程中，上游分支可能会前进，这时最好的办法可能不是继续在上游分支上重新加载，而是保持基本提交不变。由于基本提交保持不变，该选项意味着 `--reapply-cherry-picks`，以避免丢失提交。

note: type: Plain text
en: Although both this option and `--fork-point` find the merge base between `<upstream>` and `<branch>`, this option uses the merge base as the _starting point_ on which new commits will be created, whereas `--fork-point` uses the merge base to determine the _set of commits_ which will be rebased.
zh_HANS-CN: 虽然该选项和 `-fork-point` 都能找到 `<upstream>` 和 `<branch>` 之间的合并基数，但该选项使用合并基数作为创建新提交的_起点_，而 `-fork-point`则使用合并基数来确定将被重定向的_提交集_。

note: type: Plain text
en: See also INCOMPATIBLE OPTIONS below.
zh_HANS-CN: 另请参阅下面的不兼容选项。

note: type: Plain text
en: Upstream branch to compare against.  May be any valid commit, not just an existing branch name. Defaults to the configured upstream for the current branch.
zh_HANS-CN: 要与之比较的上游分支。 可以是任何有效的提交，而不仅仅是现有的分支名称。默认为当前分支配置的上游分支。

note: type: Plain text
en: Working branch; defaults to `HEAD`.
zh_HANS-CN: 工作分支；默认为 `HEAD`。

note: type: Plain text
en: Use applying strategies to rebase (calling `git-am` internally).  This option may become a no-op in the future once the merge backend handles everything the apply one does.
zh_HANS-CN: 使用应用策略来变基（内部调用 `git-am`）。 一旦合并后端处理了应用后端所做的一切，这个选项将来可能就不再适用了。

note: type: Plain text
en: How to handle commits that are not empty to start and are not clean cherry-picks of any upstream commit, but which become empty after rebasing (because they contain a subset of already upstream changes).  With drop (the default), commits that become empty are dropped.  With keep, such commits are kept.  With ask (implied by `--interactive`), the rebase will halt when an empty commit is applied allowing you to choose whether to drop it, edit files more, or just commit the empty changes.  Other options, like `--exec`, will use the default of drop unless `-i`/`--interactive` is explicitly specified.
zh_HANS-CN: 如何处理开始时不是空的提交，也不是对上游提交的纯粹撷取，但在重排序后变为空的提交（因为它们包含了上游修改的子集）。 如果使用 drop（默认），则会丢弃变为空的提交。 如果使用 keep，则会保留此类提交。 如果使用 ask（隐含 `--interactive`），当应用空提交时，变基停止，允许你选择是丢弃它、编辑更多文件，还是只提交空改动。 其他选项，如 `--exec`，除非明确指定了 `-i`/`-interactive`，否则将使用默认的 drop。

note: type: Plain text
en: Note that commits which start empty are kept (unless `--no-keep-empty` is specified), and commits which are clean cherry-picks (as determined by `git log --cherry-mark ...`) are detected and dropped as a preliminary step (unless `--reapply-cherry-picks` or `--keep-base` is passed).
zh_HANS-CN: 需要注意的是，开始时为空的提交会被保留（除非指定了 `--no-keep-empty`），而干净的 cherry-picks 提交（由 `git log --cherry-mark ...`）会被检测到并作为第一步被丢弃（除非通过了 `--reapply-cherry-picks`或 `--keep-base`）。

note: type: Plain text
en: Do not keep commits that start empty before the rebase (i.e. that do not change anything from its parent) in the result.  The default is to keep commits which start empty, since creating such commits requires passing the `--allow-empty` override flag to `git commit`, signifying that a user is very intentionally creating such a commit and thus wants to keep it.
zh_HANS-CN: 不在结果中保留重置前开始为空的提交（即不改变父提交的任何内容）。 默认情况下保留开始时为空的提交，因为创建此类提交需要向 `git commit` 传递 `--allow-empty` 覆盖标志，表明用户非常有意地创建此类提交，因此希望保留它。

note: type: Plain text
en: Usage of this flag will probably be rare, since you can get rid of commits that start empty by just firing up an interactive rebase and removing the lines corresponding to the commits you don't want.  This flag exists as a convenient shortcut, such as for cases where external tools generate many empty commits and you want them all removed.
zh_HANS-CN: 使用这个标记的情况可能很少，因为你只需启动交互式变基，并删除与你不想要的提交对应的行，就能删除开始时为空的提交。 该标记是一种方便的快捷方式，比如当外部工具生成许多空提交，而你希望将它们全部删除时。

note: type: Plain text
en: For commits which do not start empty but become empty after rebasing, see the `--empty` flag.
zh_HANS-CN: 如果提交开始时不是空的，但重定向后变成空的，参阅 `--empty` 标志。

note: type: Plain text
en: Reapply all clean cherry-picks of any upstream commit instead of preemptively dropping them. (If these commits then become empty after rebasing, because they contain a subset of already upstream changes, the behavior towards them is controlled by the `--empty` flag.)
zh_HANS-CN: 重新应用任何上游提交中所有干净的拣选，而不是先发制人地丢弃它们。(如果这些提交在重排后成为空提交，因为它们包含了上游修改的子集，则对它们的行为由 `--empty` 标志控制）。

note: type: Plain text
en: In the absence of `--keep-base` (or if `--no-reapply-cherry-picks` is given), these commits will be automatically dropped.  Because this necessitates reading all upstream commits, this can be expensive in repositories with a large number of upstream commits that need to be read. When using the 'merge' backend, warnings will be issued for each dropped commit (unless `--quiet` is given). Advice will also be issued unless `advice.skippedCherryPicks` is set to false (see linkgit:git-config[1]).
zh_HANS-CN: 如果没有 `--keep-base`（或给出了 `--no-reapply-cherry-picks`），这些提交将被自动放弃。 由于这需要读取所有上游提交，对于需要读取大量上游提交的仓库来说，代价可能会很高。使用 'merge' 后端时，每次丢弃提交都会发出警告（除非给出 `--quiet`）。除非将 `advice.skippedCherryPicks` 设为 false，否则也会发出警告（参见 linkgit:git-config[1]）。

note: type: Plain text
en: `--reapply-cherry-picks` allows rebase to forgo reading all upstream commits, potentially improving performance.
zh_HANS-CN: `--reapply-cherry-picks` 允许变基操作放弃读取所有上游提交，从而可能提高性能。

note: type: Plain text
en: No-op.  Rebasing commits with an empty message used to fail and this option would override that behavior, allowing commits with empty messages to be rebased.  Now commits with an empty message do not cause rebasing to halt.
zh_HANS-CN: 无操作。 过去，重写带空信息的提交会失败，而该选项会覆盖这一行为，允许重写带空信息的提交。 现在，带空信息的提交不会导致重定向失败。

note: type: Plain text
en: Using merging strategies to rebase (default).
zh_HANS-CN: 使用合并策略重定向（默认）。

note: type: Plain text
en: Note that a rebase merge works by replaying each commit from the working branch on top of the `<upstream>` branch.  Because of this, when a merge conflict happens, the side reported as 'ours' is the so-far rebased series, starting with `<upstream>`, and 'theirs' is the working branch.  In other words, the sides are swapped.
zh_HANS-CN: 请注意，变基合并是通过在 `<上游>` 分支上重放工作分支的每次提交来实现的。 因此，当发生合并冲突时，被报告为 'ours' 的一方是迄今为止以 `<上游>` 为起点的重定向系列，而 'theirs' 则是工作分支。 换句话说，双方是对调的。

note: type: Plain text
en: Use the given merge strategy, instead of the default `ort`.  This implies `--merge`.
zh_HANS-CN: 使用给定的合并策略，而不是默认的 `ort`。暗指 `--merge`。

note: type: Plain text
en: Because `git rebase` replays each commit from the working branch on top of the `<upstream>` branch using the given strategy, using the `ours` strategy simply empties all patches from the `<branch>`, which makes little sense.
zh_HANS-CN: 由于 `git rebase` 会使用给定的策略在 `<上游>` 分支之上重复工作分支的每次提交，因此使用 `ours` 策略只会清空 `<分支>` 中的所有补丁，这没有什么意义。

note: type: Plain text
en: Pass the <strategy-option> through to the merge strategy.  This implies `--merge` and, if no strategy has been specified, `-s ort`.  Note the reversal of 'ours' and 'theirs' as noted above for the `-m` option.
zh_HANS-CN: 将 <策略选项> 传递给合并策略。 这意味着 `--merge`，如果没有指定策略，则是 `--s ort`。 请注意 'ours' 和 'theirs' 的颠倒，就像上面的 `-m`选项一样。

note: type: Plain text
en: Show a diffstat of what changed upstream since the last rebase. The diffstat is also controlled by the configuration option rebase.stat.
zh_HANS-CN: 显示上次变基后上游变化的差异状态。差异状态也由配置选项 rebase.stat 控制。

note: type: Plain text
en: Do not show a diffstat as part of the rebase process.
zh_HANS-CN: 不要将差异状态作为变基过程的一部分。

note: type: Plain text
en: This option bypasses the pre-rebase hook.  See also linkgit:githooks[5].
zh_HANS-CN: 该选项会绕过 pre-rebase 钩子。 另请参阅 linkgit:githooks[5]。

note: type: Plain text
en: Allows the pre-rebase hook to run, which is the default.  This option can be used to override `--no-verify`.  See also linkgit:githooks[5].
zh_HANS-CN: 允许运行 pre-rebase 钩子，这是默认选项。 该选项可用于覆盖 `--no-verify`。 另请参见 linkgit:githooks[5]。

note: type: Plain text
en: Ensure at least `<n>` lines of surrounding context match before and after each change.  When fewer lines of surrounding context exist they all must match.  By default no context is ever ignored.  Implies `--apply`.
zh_HANS-CN: 确保每次更改前后至少有 `<n>` 行周围上下文匹配。 如果周围的上下文行数较少，则必须全部匹配。 默认情况下，不会忽略任何上下文。 暗指 `--apply`。

note: type: Plain text
en: Individually replay all rebased commits instead of fast-forwarding over the unchanged ones.  This ensures that the entire history of the rebased branch is composed of new commits.
zh_HANS-CN: 单独重放所有重定向的提交，而不是快进不变的提交。 这样就能确保重建分支的整个历史都是由新提交组成的。

note: type: Plain text
en: You may find this helpful after reverting a topic branch merge, as this option recreates the topic branch with fresh commits so it can be remerged successfully without needing to "revert the reversion" (see the link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] for details).
zh_HANS-CN: 在还原主题分支合并后，你可能会发现这很有帮助，因为该选项会用新提交的内容重新创建主题分支，这样就可以成功地重新合并，而无需 “恢复原状”（详见link:howto/revert-a-faulty-merge.html[如何还原故障合并]）。

note: type: Plain text
en: Use reflog to find a better common ancestor between `<upstream>` and `<branch>` when calculating which commits have been introduced by `<branch>`.
zh_HANS-CN: 在计算哪些提交由 `<分支>` 引入时，使用引用日志在 `<上游仓库>` 和 `<分支>` 之间找到更好的共同祖先。

note: type: Plain text
en: When `--fork-point` is active, 'fork_point' will be used instead of `<upstream>` to calculate the set of commits to rebase, where 'fork_point' is the result of `git merge-base --fork-point <upstream> <branch>` command (see linkgit:git-merge-base[1]).  If 'fork_point' ends up being empty, the `<upstream>` will be used as a fallback.
zh_HANS-CN: 当启用 `--fork-point` 时，将使用 'fork_point' 而不是 `<上游仓库>` 来计算要重置的提交集，其中 'fork_point' 是 `git merge-base --fork-point <上游仓库> <分支>` 命令的结果（参见 linkgit:git-merge-base[1]）。 如果 'fork_point' 最终为空，`<上游仓库>` 将作为备用。

note: type: Plain text
en: If `<upstream>` or `--keep-base` is given on the command line, then the default is `--no-fork-point`, otherwise the default is `--fork-point`. See also `rebase.forkpoint` in linkgit:git-config[1].
zh_HANS-CN: 如果在命令行中提供了 `<上游仓库> ` 或 `--keep-base ` 参数，则默认为 `--no-fork-point`，否则默认为 `--fork-point`。另请参阅 linkgit:git-config[1] 中的 `rebase.forkpoint`。

note: type: Plain text
en: If your branch was based on `<upstream>` but `<upstream>` was rewound and your branch contains commits which were dropped, this option can be used with `--keep-base` in order to drop those commits from your branch.
zh_HANS-CN: 如果你的分支基于 `<上游仓库>`，但 `<上游仓库>` 被回退了，而你的分支包含了被删除的提交，那么可以使用 `--keep-base` 选项来从你的分支中删除那些提交。

note: type: Plain text
en: Ignore whitespace differences when trying to reconcile differences. Currently, each backend implements an approximation of this behavior:
zh_HANS-CN: 在尝试协调差异时空格的差异。目前，每个后端都实现了对此行为的近似处理：

note: type: Labeled list
en: apply backend
zh_HANS-CN: 应用后端

note: type: Plain text
en: When applying a patch, ignore changes in whitespace in context lines. Unfortunately, this means that if the "old" lines being replaced by the patch differ only in whitespace from the existing file, you will get a merge conflict instead of a successful patch application.
zh_HANS-CN: 在应用补丁时，忽略上下文行中的空格更改。不幸的是，这意味着如果补丁中要替换的“旧”行与现有文件中的行仅在空格方面有差异，你将得到一个合并冲突而不是成功的补丁应用。

note: type: Labeled list
en: merge backend
zh_HANS-CN: 合并后端

note: type: Plain text
en: Treat lines with only whitespace changes as unchanged when merging.  Unfortunately, this means that any patch hunks that were intended to modify whitespace and nothing else will be dropped, even if the other side had no changes that conflicted.
zh_HANS-CN: 在合并时，将仅包含空格更改的行视为未更改。不幸的是，这意味着任何旨在修改空格而不涉及其他更改的补丁块将被丢弃，即使另一方没有发生冲突的更改。

note: type: Plain text
en: This flag is passed to the `git apply` program (see linkgit:git-apply[1]) that applies the patch.  Implies `--apply`.
zh_HANS-CN: 这个标志被传递给应用补丁的 `git apply` 程序（参阅 linkgit:git-apply[1]）。它隐含了 `--apply`。

note: type: Plain text
en: Instead of using the current time as the committer date, use the author date of the commit being rebased as the committer date. This option implies `--force-rebase`.
zh_HANS-CN: 不使用当前时间作为提交者日期，而是使用被重定向的提交的作者日期作为提交者日期。该选项暗含 `--force-rebase` 选项。

note: type: Plain text
en: Instead of using the author date of the original commit, use the current time as the	author date of the rebased commit.  This option implies `--force-rebase`.
zh_HANS-CN: 不使用原始提交的作者日期，而使用当前时间作为重建提交的作者日期。 此选项暗含 `--force-rebase` 选项。

note: type: Plain text
en: Add a `Signed-off-by` trailer to all the rebased commits. Note that if `--interactive` is given then only commits marked to be picked, edited or reworded will have the trailer added.
zh_HANS-CN: 在所有重写的提交中添加 `Signed-off-by` 尾注。请注意，如果给定了 `--interactive`，则只有标记为被选中、编辑或重写的提交才会添加尾注。

note: type: Plain text
en: Make a list of the commits which are about to be rebased.  Let the user edit that list before rebasing.  This mode can also be used to split commits (see SPLITTING COMMITS below).
zh_HANS-CN: 列出即将重写的提交列表。 让用户在重写前编辑该列表。 这种模式也可用于拆分提交（见下文的拆分提交）。

note: type: Plain text
en: The commit list format can be changed by setting the configuration option rebase.instructionFormat.  A customized instruction format will automatically have the long commit hash prepended to the format.
zh_HANS-CN: 提交列表格式可通过设置配置选项 rebase.instructionFormat 进行更改。 自定义的指令格式会自动在格式前加上长提交哈希值。

note: type: Plain text
en: By default, a rebase will simply drop merge commits from the todo list, and put the rebased commits into a single, linear branch.  With `--rebase-merges`, the rebase will instead try to preserve the branching structure within the commits that are to be rebased, by recreating the merge commits. Any resolved merge conflicts or manual amendments in these merge commits will have to be resolved/re-applied manually. `--no-rebase-merges` can be used to countermand both the `rebase.rebaseMerges` config option and a previous `--rebase-merges`.
zh_HANS-CN: 默认情况下，变基操作会简单地从待办事项列表中删除合并提交，并将被重置的提交放入一个单一的线性分支中。 使用 `--rebase-merges` 后，变基操作会通过重新创建合并提交，尝试保留要被重置的提交中的分支结构。在这些合并提交中，任何已解决的合并冲突或手动修正都必须手动解决/重新应用。`--no--rebase-merges` 可以用来抵消 `rebase.rebaseMerges` 配置选项和之前的 `--rebase-merges 选项。

note: type: Plain text
en: When rebasing merges, there are two modes: `rebase-cousins` and `no-rebase-cousins`. If the mode is not specified, it defaults to `no-rebase-cousins`. In `no-rebase-cousins` mode, commits which do not have `<upstream>` as direct ancestor will keep their original branch point, i.e.  commits that would be excluded by linkgit:git-log[1]'s `--ancestry-path` option will keep their original ancestry by default. In `rebase-cousins` mode, such commits are instead rebased onto `<upstream>` (or `<onto>`, if specified).
zh_HANS-CN: 重定向合并时，有两种模式： `rebase-cousins` 和 `no-rebase-cousins`。如果未指定模式，则默认为 `no-rebase-cousins`。在 `no-rebase-cousins` 模式下，没有 `<上游仓库>` 作为直接祖先的提交将保留其原始分支点，也就是说，被 linkgit:git-log[1] 的 `--ancestry-path` 选项排除在外的提交将默认保留其原始祖先。在 `rebase-cousins` 模式下，此类提交会被重定向到 `<上游仓库>`（或是`<onto>`，如果指定了）。

note: type: Plain text
en: It is currently only possible to recreate the merge commits using the `ort` merge strategy; different merge strategies can be used only via explicit `exec git merge -s <strategy> [...]` commands.
zh_HANS-CN: 目前只能使用 `ort` 合并策略重新创建合并提交；只有通过明确的 `exec git merge -s <strategy> [...]` 命令才能使用不同的合并策略。

note: type: Plain text
en: See also REBASING MERGES and INCOMPATIBLE OPTIONS below.
zh_HANS-CN: 另请参阅下面的重置合并和不兼容选项。

note: type: Labeled list
en: -x <cmd>
zh_HANS-CN: -x <命令>

note: type: Plain text
en: Append "exec <cmd>" after each line creating a commit in the final history. `<cmd>` will be interpreted as one or more shell commands. Any command that fails will interrupt the rebase, with exit code 1.
zh_HANS-CN: 在最终历史记录中创建提交的每一行后添加 "exec <命令>"。`<命令>` 将被解释为一个或多个 shell 命令。任何失败的命令都会中断重置，退出代码为 1。

note: type: Plain text
en: You may execute several commands by either using one instance of `--exec` with several commands:
zh_HANS-CN: 您可以通过使用一个包含多个命令的 `--exec` 实例来执行多个命令：

note: type: Plain text
en: or by giving more than one `--exec`:
zh_HANS-CN: 或给出多个 `--exec`：

note: type: Plain text
en: If `--autosquash` is used, `exec` lines will not be appended for the intermediate commits, and will only appear at the end of each squash/fixup series.
zh_HANS-CN: 如果使用了 `--autosquash`，则不会为中间提交附加 `exec` 行，而只会出现在每个 squash/fixup 系列的末尾。

note: type: Plain text
en: This uses the `--interactive` machinery internally, but it can be run without an explicit `--interactive`.
zh_HANS-CN: 它在内部使用 `--interactive` 机制，但也可以在没有显式 `--interactive` 的情况下运行。

note: type: Plain text
en: Rebase all commits reachable from `<branch>`, instead of limiting them with an `<upstream>`.  This allows you to rebase the root commit(s) on a branch.
zh_HANS-CN: 重置从 `<分支>` 到的所有提交，而不是用 `<上游分支>` 来限制它们。 这样就可以重定向分支上的根提交。

note: type: Plain text
en: When the commit log message begins with "squash! ..." or "fixup! ..." or "amend! ...", and there is already a commit in the todo list that matches the same `...`, automatically modify the todo list of `rebase -i`, so that the commit marked for squashing comes right after the commit to be modified, and change the action of the moved commit from `pick` to `squash` or `fixup` or `fixup -C` respectively. A commit matches the `...` if the commit subject matches, or if the `...` refers to the commit's hash. As a fall-back, partial matches of the commit subject work, too. The recommended way to create fixup/amend/squash commits is by using the `--fixup`, `--fixup=amend:` or `--fixup=reword:` and `--squash` options respectively of linkgit:git-commit[1].
zh_HANS-CN: 当提交日志信息以 "squash！..." 或 "fixup！..." 或 "amend！......"，并且待办事项列表中已经有一个与相同的 `...` 匹配的提交时，就会自动修改 `rebase -i` 的待办事项列表，使标记为压扁的提交紧跟在要修改的提交之后，并将移动提交的操作从 `pick` 分别改为 `squash` 或 `fixup` 或 `fixup -C`。如果提交主题匹配 `...`，或者 `...` 指的是提交的哈希值，则该提交匹配 `...`。作为后备，提交主题的部分匹配也会起作用。建议使用 linkgit:git-commit[1] 的 `--fixup`、`--fixup=amend:` 或 `--fixup=reword:`、`--squash` 选项来创建 fixup/amend/squash 提交。

note: type: Plain text
en: If the `--autosquash` option is enabled by default using the configuration variable `rebase.autoSquash`, this option can be used to override and disable this setting.
zh_HANS-CN: 如果默认情况下使用配置变量 `rebase.autoSquash` 启用了 `--autosquash` 选项，则可以使用此选项覆盖并禁用此设置。

note: type: Plain text
en: Automatically create a temporary stash entry before the operation begins, and apply it after the operation ends.  This means that you can run rebase on a dirty worktree.  However, use with care: the final stash application after a successful rebase might result in non-trivial conflicts.
zh_HANS-CN: 在操作开始前自动创建临时存储条目，并在操作结束后应用它。 这意味着你可以在脏工作树上运行变基操作。 不过，请谨慎使用：成功重储后的最终储藏应用可能会导致非实质性冲突。

note: type: Plain text
en: Automatically reschedule `exec` commands that failed. This only makes sense in interactive mode (or when an `--exec` option was provided).
zh_HANS-CN: 自动重新安排执行失败的 `exec` 命令。这只有在交互模式下（或提供了 `--exec` 选项时）才有意义。

note: type: Plain text
en: Even though this option applies once a rebase is started, it's set for the whole rebase at the start based on either the `rebase.rescheduleFailedExec` configuration (see linkgit:git-config[1] or "CONFIGURATION" below) or whether this option is provided. Otherwise an explicit `--no-reschedule-failed-exec` at the start would be overridden by the presence of `rebase.rescheduleFailedExec=true` configuration.
zh_HANS-CN: 尽管该选项在启动一个变基操作时就会应用，但它会在启动时根据 `rebase.rescheduleFailedExec` 配置（参见 linkgit:git-config[1] 或下面的 “配置”）或是否提供了该选项为整个变基的设置。否则，如果存在 `rebase.rescheduleFailedExec=true` 配置，一开始明确的 `--no-reschedule-failed-exec` 就会被覆盖。

note: type: Plain text
en: Automatically force-update any branches that point to commits that are being rebased. Any branches that are checked out in a worktree are not updated in this way.
zh_HANS-CN: 自动强制更新任何指向正在重定向的提交的分支。任何在工作区中签出的分支都不会以这种方式更新。

note: type: Plain text
en: If the configuration variable `rebase.updateRefs` is set, then this option can be used to override and disable this setting.
zh_HANS-CN: 如果设置了配置变量 `rebase.updateRefs`, 则可使用此选项覆盖并禁用此设置。

note: type: Title -
en: INCOMPATIBLE OPTIONS
zh_HANS-CN: 不兼容选项

note: type: Plain text
en: The following options:
zh_HANS-CN: 下列选项：

note: type: Plain text
en: are incompatible with the following options:
zh_HANS-CN: 与下列选项不兼容：

note: type: Plain text
en: In addition, the following pairs of options are incompatible:
zh_HANS-CN: 此外，以下几对选项是不兼容的：

note: type: Title -
en: BEHAVIORAL DIFFERENCES
zh_HANS-CN: 行为差异

note: type: Plain text
en: `git rebase` has two primary backends: 'apply' and 'merge'.  (The 'apply' backend used to be known as the 'am' backend, but the name led to confusion as it looks like a verb instead of a noun.  Also, the 'merge' backend used to be known as the interactive backend, but it is now used for non-interactive cases as well.  Both were renamed based on lower-level functionality that underpinned each.) There are some subtle differences in how these two backends behave:
zh_HANS-CN: `git rebase` 有两个主要的后台：‘应用’ 和 ‘合并’（‘应用’ 后台曾被称为 'am' 后台，但这个名字看起来像动词而非名词，因此引起了混淆）。 此外，‘合并’ 后台曾被称为交互式后台，但现在也用于非交互式情况。 两者都是根据各自的底层功能重新命名的）。这两个后台在行为方式上有一些微妙的区别：

note: type: Plain text
en: The 'apply' backend unfortunately drops intentionally empty commits, i.e.  commits that started empty, though these are rare in practice.  It also drops commits that become empty and has no option for controlling this behavior.
zh_HANS-CN: 不幸的是，‘应用’ 后台会丢弃故意为空的提交，即开始时为空的提交，不过这种情况在实践中并不多见。 它还会丢弃变为空的提交，而且没有控制这种行为的选项。

note: type: Plain text
en: The 'merge' backend keeps intentionally empty commits by default (though with `-i` they are marked as empty in the todo list editor, or they can be dropped automatically with `--no-keep-empty`).
zh_HANS-CN: 默认情况下，‘合并’ 后台会保留故意为空的提交（不过，如果使用 `-i` 选项，这些提交会在待办事项列表编辑器中标记为空，或者使用 `--no-keep-empty` 自动删除）。

note: type: Plain text
en: Similar to the apply backend, by default the merge backend drops commits that become empty unless `-i`/`--interactive` is specified (in which case it stops and asks the user what to do).  The merge backend also has an `--empty={drop,keep,ask}` option for changing the behavior of handling commits that become empty.
zh_HANS-CN: 与应用后端类似，合并后端默认情况下也会丢弃变为空的提交，除非指定了 `-i` 或 `--interactive` 选项（在这种情况下，合并会停止并询问用户该怎么做）。 合并后端还有一个 `--empty={drop,keep,ask}` 选项，用于改变处理变为空的提交的行为。

note: type: Title ~
en: Directory rename detection
zh_HANS-CN: 目录重命名检测

note: type: Plain text
en: Due to the lack of accurate tree information (arising from constructing fake ancestors with the limited information available in patches), directory rename detection is disabled in the 'apply' backend.  Disabled directory rename detection means that if one side of history renames a directory and the other adds new files to the old directory, then the new files will be left behind in the old directory without any warning at the time of rebasing that you may want to move these files into the new directory.
zh_HANS-CN: 由于缺乏准确的目录树信息（利用补丁中的有限信息构建假祖先），‘应用’ 后台禁用了目录重命名检测。 禁用目录重命名检测意味着，如果历史记录的一方重命名了一个目录，而另一方在旧目录中添加了新文件，那么新文件就会被留在旧目录中，而不会在重新编排时发出任何警告，提醒您可能需要将这些文件移到新目录中。

note: type: Plain text
en: Directory rename detection works with the 'merge' backend to provide you warnings in such cases.
zh_HANS-CN: 目录重命名检测与 ‘合并’ 后台协同工作，在这种情况下会向你发出警告。

note: type: Plain text
en: The 'apply' backend works by creating a sequence of patches (by calling `format-patch` internally), and then applying the patches in sequence (calling `am` internally).  Patches are composed of multiple hunks, each with line numbers, a context region, and the actual changes.  The line numbers have to be taken with some fuzz, since the other side will likely have inserted or deleted lines earlier in the file.  The context region is meant to help find how to adjust the line numbers in order to apply the changes to the right lines.  However, if multiple areas of the code have the same surrounding lines of context, the wrong one can be picked.  There are real-world cases where this has caused commits to be reapplied incorrectly with no conflicts reported.  Setting `diff.context` to a larger value may prevent such types of problems, but increases the chance of spurious conflicts (since it will require more lines of matching context to apply).
zh_HANS-CN: ‘应用’ 后台的工作方式是创建一系列补丁（在内部调用 `format-patch`），然后依次应用这些补丁（在内部调用 `am`）。 补丁由多个块组成，每个块包含行号、上下文区域和实际更改。 行号的获取必须谨慎，因为另一方很可能在文件中插入或删除了更早的行。 上下文区域的目的是帮助找到如何调整行号，以便将更改应用到正确的行上。 但是，如果代码的多个区域有相同的上下文行，就可能选错。 在现实世界中，这种情况曾导致提交被错误地重新应用，而没有报告任何冲突。 将 `diff.context` 设置为更大的值可能会避免此类问题，但会增加发生虚假冲突的几率（因为需要更多行匹配的上下文才能应用）。

note: type: Plain text
en: The 'merge' backend works with a full copy of each relevant file, insulating it from these types of problems.
zh_HANS-CN: ‘合并’ 后台使用每个相关文件的完整副本，从而避免了此类问题。

note: type: Plain text
en: When there are content conflicts, the merge machinery tries to annotate each side's conflict markers with the commits where the content came from.  Since the 'apply' backend drops the original information about the rebased commits and their parents (and instead generates new fake commits based off limited information in the generated patches), those commits cannot be identified; instead it has to fall back to a commit summary.  Also, when `merge.conflictStyle` is set to `diff3` or `zdiff3`, the 'apply' backend will use "constructed merge base" to label the content from the merge base, and thus provide no information about the merge base commit whatsoever.
zh_HANS-CN: 当出现内容冲突时，合并机制会尝试在每一方的冲突标记上标注内容来源的提交。 由于 ‘应用’ 后台丢弃了关于重建的提交及其父提交的原始信息（而是根据生成的补丁中的有限信息生成新的假提交），因此无法识别这些提交，而只能使用提交摘要。 此外，当 `merge.conflictStyle` 设置为 `diff3` 或 `zdiff3` 时，‘应用’ 后端将使用 "constructed merge base"（构建的合并基础）来标注来自合并基础的内容，因此不会提供任何关于合并基础提交的信息。

note: type: Plain text
en: The 'merge' backend works with the full commits on both sides of history and thus has no such limitations.
zh_HANS-CN: ‘合并’ 后台使用历史上双方的完整提交，因此没有这些限制。

note: type: Plain text
en: The 'apply' backend has not traditionally called the post-commit hook, while the 'merge' backend has.  Both have called the post-checkout hook, though the 'merge' backend has squelched its output.  Further, both backends only call the post-checkout hook with the starting point commit of the rebase, not the intermediate commits nor the final commit.  In each case, the calling of these hooks was by accident of implementation rather than by design (both backends were originally implemented as shell scripts and happened to invoke other commands like `git checkout` or `git commit` that would call the hooks).  Both backends should have the same behavior, though it is not entirely clear which, if any, is correct.  We will likely make rebase stop calling either of these hooks in the future.
zh_HANS-CN: 传统上，‘应用’ 后台并不调用提交后（post-commit）钩子，而 ‘合并’ 后台却调用了。 虽然 ‘合并’ 后台已取消了其输出，但两者都调用了检出后（post-checkout）钩子。 此外，这两个后端都只调用了变基操作的起点提交，而不是中间提交或最终提交的检出后（post-checkout）钩子。 在每种情况下，调用这些钩子都是偶然的，而不是设计出来的（两个后台最初都是以 shell 脚本的形式实现的，碰巧调用了其他会调用钩子的命令，如 `git checkout` 或 `git commit`）。 这两个后台应该具有相同的行为，但目前还不完全清楚哪一个才是正确的。 我们将来可能会让变基操作停止调用这些钩子。

note: type: Title ~
en: Interruptability
zh_HANS-CN: 可中断性

note: type: Plain text
en: The 'apply' backend has safety problems with an ill-timed interrupt; if the user presses Ctrl-C at the wrong time to try to abort the rebase, the rebase can enter a state where it cannot be aborted with a subsequent `git rebase --abort`.  The 'merge' backend does not appear to suffer from the same shortcoming.  (See https://lore.kernel.org/git/20200207132152.GC2868@szeder.dev/ for details.)
zh_HANS-CN: 如果用户在错误的时间按下 Ctrl-C 试图终止重置，重置就会进入无法通过后续的 `git rebase --abort` 终止的状态。 ‘合并’ 后台似乎不存在同样的缺陷。 (详见 https://lore.kernel.org/git/20200207132152.GC2868@szeder.dev/）

note: type: Title ~
en: Commit Rewording
zh_HANS-CN: 重写提交

note: type: Plain text
en: When a conflict occurs while rebasing, rebase stops and asks the user to resolve.  Since the user may need to make notable changes while resolving conflicts, after conflicts are resolved and the user has run `git rebase --continue`, the rebase should open an editor and ask the user to update the commit message.  The 'merge' backend does this, while the 'apply' backend blindly applies the original commit message.
zh_HANS-CN: 当重建过程中发生冲突时，变基操作停止并要求用户解决。 由于用户可能需要在解决冲突的同时做一些显著的改动，因此在冲突解决且用户运行了 `git rebase --continue` 之后，变基时应打开一个编辑器并要求用户更新提交信息。 ‘合并’ 后台会这样做，而 ‘应用’ 后台则会盲目应用原始的提交信息。

note: type: Title ~
en: Miscellaneous differences
zh_HANS-CN: 其他差异

note: type: Plain text
en: There are a few more behavioral differences that most folks would probably consider inconsequential but which are mentioned for completeness:
zh_HANS-CN: 还有一些行为上的差异，大多数人可能会认为无关紧要，但为了完整起见，还是要提一下：

note: type: Plain text
en: Reflog: The two backends will use different wording when describing the changes made in the reflog, though both will make use of the word "rebase".
zh_HANS-CN: 引用日志： 两个后台在描述引用日志中的更改时会使用不同的措辞，但都会使用 “变基（rebase）” 一词。

note: type: Plain text
en: Progress, informational, and error messages: The two backends provide slightly different progress and informational messages.  Also, the apply backend writes error messages (such as "Your files would be overwritten...") to stdout, while the merge backend writes them to stderr.
zh_HANS-CN: 进度、信息和错误信息： 两个后端提供的进度和信息略有不同。 此外，应用后端会将错误信息（如 “您的文件将被覆盖......”）写入标准输出流，而合并后台则写入标准错误流。

note: type: Plain text
en: State directories: The two backends keep their state in different directories under `.git/`
zh_HANS-CN: 状态目录：两个后台将状态保存在不同的目录中，分别位于`.git/`下

note: type: Plain text
en: When the rebase is run, it will first execute a `pre-rebase` hook if one exists.  You can use this hook to do sanity checks and reject the rebase if it isn't appropriate.  Please see the template `pre-rebase` hook script for an example.
zh_HANS-CN: 在运行变基命令时，如果存在 `pre-rebase` （变基前）钩子，它会首先执行该钩子。 您可以使用此钩子进行正确性检查，并在不合适时拒绝重置。 有关示例，请参阅模板 `pre-rebase`（变基前） 钩子脚本。

note: type: Plain text
en: Upon completion, `<branch>` will be the current branch.
zh_HANS-CN: 完成后，`<分支>` 将成为当前分支。

note: type: Plain text
en: Rebasing interactively means that you have a chance to edit the commits which are rebased.  You can reorder the commits, and you can remove them (weeding out bad or otherwise unwanted patches).
zh_HANS-CN: 交互式重定向意味着你有机会编辑被重定向的提交。 你可以重新排列提交的顺序，也可以删除它们（剔除坏的或不需要的补丁）。

note: type: Plain text
en: The interactive mode is meant for this type of workflow:
zh_HANS-CN: 互动模式就是为这种工作流程设计的：

note: type: Plain text
en: have a wonderful idea
zh_HANS-CN: 灵机一动

note: type: Plain text
en: hack on the code
zh_HANS-CN: 敲代码

note: type: Plain text
en: prepare a series for submission
zh_HANS-CN: 编写提交系列

note: type: Plain text
en: where point 2. consists of several instances of
zh_HANS-CN: 其中第 2 点由以下几个实例组成

note: type: Plain text
en: regular use
zh_HANS-CN: 常规使用

note: type: Plain text
en: finish something worthy of a commit
zh_HANS-CN: 完成值得提交的事情

note: type: Plain text
en: independent fixup
zh_HANS-CN: 独立修复

note: type: Plain text
en: realize that something does not work
zh_HANS-CN: 发现有什么东西没有用

note: type: Plain text
en: commit it
zh_HANS-CN: 提交

note: type: Plain text
en: Sometimes the thing fixed in b.2. cannot be amended to the not-quite perfect commit it fixes, because that commit is buried deeply in a patch series.  That is exactly what interactive rebase is for: use it after plenty of "a"s and "b"s, by rearranging and editing commits, and squashing multiple commits into one.
zh_HANS-CN: 有时，b.2.中修正的内容无法修正到它所修正的并不完美的提交中，因为该提交深埋在一系列补丁中。 这正是交互式变基的用途：在大量的 "a" 和 "b" 之后使用它，重新排列和编辑提交，将多个提交合并为一个提交。

note: type: Plain text
en: Start it with the last commit you want to retain as-is:
zh_HANS-CN: 从您希望保留原样的最后一次提交开始：

note: type: Plain text
en: An editor will be fired up with all the commits in your current branch (ignoring merge commits), which come after the given commit.  You can reorder the commits in this list to your heart's content, and you can remove them.  The list looks more or less like this:
zh_HANS-CN: 编辑器会弹出当前分支的所有提交（忽略合并提交），这些提交都在给定提交之后。 你可以随心所欲地调整列表中提交的顺序，也可以删除它们。 列表大致如下：

note: type: delimited block -
en: pick deadbee The oneline of this commit
    pick fa1afe1 The oneline of the next commit
    ...
zh_HANS-CN: 选择 deadbee ，本次提交的上线
    选中 fa1afe1 ，下一次提交的上线
    ...

note: type: Plain text
en: The oneline descriptions are purely for your pleasure; 'git rebase' will not look at them but at the commit names ("deadbee" and "fa1afe1" in this example), so do not delete or edit the names.
zh_HANS-CN: 上线描述纯粹是为了方便您查看；'git rebase' 不会查看这些描述，只会查看提交名称（本例中为 "deadbee" 和 "fa1afe1"），因此请勿删除或编辑这些名称。

note: type: Plain text
en: By replacing the command "pick" with the command "edit", you can tell `git rebase` to stop after applying that commit, so that you can edit the files and/or the commit message, amend the commit, and continue rebasing.
zh_HANS-CN: 用 "edit" 命令替换 "pick" 命令后，你可以告诉 `git rebase` 在应用该提交后停止，这样你就可以编辑文件和/或提交信息，修改提交，然后继续重置。

note: type: Plain text
en: To interrupt the rebase (just like an "edit" command would do, but without cherry-picking any commit first), use the "break" command.
zh_HANS-CN: 要中断重置（就像 "edit" 命令一样，但不会先选择任何提交），请使用 "break "命令。

note: type: Plain text
en: If you just want to edit the commit message for a commit, replace the command "pick" with the command "reword".
zh_HANS-CN: 如果只想编辑提交信息，请用 "reword" 命令替换 "pick" 命令。

note: type: Plain text
en: To drop a commit, replace the command "pick" with "drop", or just delete the matching line.
zh_HANS-CN: 要放弃提交，请用 "drop" 替换 "pick" 命令，或直接删除匹配的行。

note: type: Plain text
en: If you want to fold two or more commits into one, replace the command "pick" for the second and subsequent commits with "squash" or "fixup".  If the commits had different authors, the folded commit will be attributed to the author of the first commit.  The suggested commit message for the folded commit is the concatenation of the first commit's message with those identified by "squash" commands, omitting the messages of commits identified by "fixup" commands, unless "fixup -c" is used.  In that case the suggested commit message is only the message of the "fixup -c" commit, and an editor is opened allowing you to edit the message.  The contents (patch) of the "fixup -c" commit are still incorporated into the folded commit. If there is more than one "fixup -c" commit, the message from the final one is used.  You can also use "fixup -C" to get the same behavior as "fixup -c" except without opening an editor.
zh_HANS-CN: 如果要将两个或更多提交折叠为一个提交，请用 "squash" 或 "fixup" 代替命令 "pick" 来处理第二个及后续提交。 如果提交的作者不同，折叠后的提交将归属于第一个提交的作者。 除非使用了 "fixup -c" 命令，否则折叠提交的建议提交信息是第一个提交信息与 "squash" 命令确定的提交信息的合并，省略了 "fixup" 命令确定的提交信息。 在这种情况下，建议的提交信息只是 "fixup -c" 提交的信息，而且会打开一个编辑器允许你编辑信息。 "fixup -c" 提交的内容（补丁）仍然包含在折叠提交中。如果有多个 "fixup -c" 提交，则使用最后一个提交的信息。 您也可以使用 "fixup -C" 获得与 "fixup -c" 相同的效果，但不需要打开编辑器。

note: type: Plain text
en: `git rebase` will stop when "pick" has been replaced with "edit" or when a command fails due to merge errors. When you are done editing and/or resolving conflicts you can continue with `git rebase --continue`.
zh_HANS-CN: 当 "pick" 命令被替换为 "编辑" 命令或命令因合并错误而失败时，`git rebase` 将停止。完成编辑和/或解决冲突后，可以使用 `git rebase --continue` 继续。

note: type: Plain text
en: For example, if you want to reorder the last 5 commits, such that what was `HEAD~4` becomes the new `HEAD`. To achieve that, you would call `git rebase` like this:
zh_HANS-CN: 例如，如果您想重新排列最近 5 次提交的顺序，让原来的 `HEAD~4` 变成新的 `HEAD`。要做到这一点，可以这样调用 `git rebase`：

note: type: Plain text
en: And move the first patch to the end of the list.
zh_HANS-CN: 并将第一个补丁移到列表末尾。

note: type: Plain text
en: You might want to recreate merge commits, e.g. if you have a history like this:
zh_HANS-CN: 例如，如果您有这样的历史记录，您可能需要重新创建合并提交：

note: type: Plain text
en: Suppose you want to rebase the side branch starting at "A" to "Q". Make sure that the current `HEAD` is "B", and call
zh_HANS-CN: 假设要将从 "A" 开始的侧分支重置为 "Q"。确保当前的 `HEAD` 是 "B"，然后调用

note: type: Plain text
en: Reordering and editing commits usually creates untested intermediate steps.  You may want to check that your history editing did not break anything by running a test, or at least recompiling at intermediate points in history by using the "exec" command (shortcut "x").  You may do so by creating a todo list like this one:
zh_HANS-CN: 重新排序和编辑提交通常会产生未经测试的中间步骤。 您可能想通过运行测试来检查您的历史编辑是否破坏了任何东西，或者至少使用 "exec" 命令（快捷键 "x"）在历史的中间点重新编译。 为此，您可以创建类似这样的待办事项列表：

note: type: delimited block -
en: pick deadbee Implement feature XXX
    fixup f1a5c00 Fix to feature XXX
    exec make
    pick c0ffeee The oneline of the next commit
    edit deadbab The oneline of the commit after
    exec cd subdir; make test
    ...
zh_HANS-CN: 选择 deadbee 执行功能 XXX
    修复 f1a5c00 修复功能 XXX
    执行 make
    选取 c0ffeee 下一次提交的上线
    编辑 deadbab 之后提交的上线
    exec cd subdir; make test
    ...

note: type: Plain text
en: The interactive rebase will stop when a command fails (i.e. exits with non-0 status) to give you an opportunity to fix the problem. You can continue with `git rebase --continue`.
zh_HANS-CN: 当命令失败（即以非 0 状态退出）时，交互式变基操作就会停止，以便您有机会解决问题。您可以使用 `git rebase --continue` 继续。

note: type: Plain text
en: The "exec" command launches the command in a shell (the one specified in `$SHELL`, or the default shell if `$SHELL` is not set), so you can use shell features (like "cd", ">", ";" ...). The command is run from the root of the working tree.
zh_HANS-CN: "exec" 命令在 shell（在 `$SHELL` 中指定的 shell，如果未设置 `$SHELL`，则使用默认 shell）中执行命令，因此可以使用 shell 功能（如 "cd"、">"、";"......）。命令从工作区的根目录运行。

note: type: Plain text
en: This command lets you check that intermediate commits are compilable.  The todo list becomes like that:
zh_HANS-CN: 该命令用于检查中间提交是否可编译。 待办事项列表就会变成这样：

note: type: delimited block -
en: pick 5928aea one
    exec make test
    pick 04d0fda two
    exec make test
    pick ba46169 three
    exec make test
    pick f4593f9 four
    exec make test
zh_HANS-CN: 选择 5928aea one
    exec make test
    选 04d0fda 二
    exec make test
    选择 ba46169 三
    执行制作测试
    选择 f4593F9 四
    exec make test

note: type: Title -
en: SPLITTING COMMITS
zh_HANS-CN: 拆分提交

note: type: Plain text
en: In interactive mode, you can mark commits with the action "edit".  However, this does not necessarily mean that `git rebase` expects the result of this edit to be exactly one commit.  Indeed, you can undo the commit, or you can add other commits.  This can be used to split a commit into two:
zh_HANS-CN: 在交互模式下，可以用 "edit"（编辑）来标记提交。 不过，这并不一定意味着 `git rebase` 希望编辑的结果是一个提交。 事实上，你可以撤销提交，也可以添加其他提交。 这可以用来将一个提交一分为二：

note: type: Plain text
en: Start an interactive rebase with `git rebase -i <commit>^`, where `<commit>` is the commit you want to split.  In fact, any commit range will do, as long as it contains that commit.
zh_HANS-CN: 使用 `git rebase -i <提交>^` 开始交互式变基，其中 `<提交>`是要分割的提交。 事实上，只要包含该提交，任何提交范围都可以。

note: type: Plain text
en: Mark the commit you want to split with the action "edit".
zh_HANS-CN: 用 "edit" 操作标记要分割的提交。

note: type: Plain text
en: When it comes to editing that commit, execute `git reset HEAD^`.  The effect is that the `HEAD` is rewound by one, and the index follows suit.  However, the working tree stays the same.
zh_HANS-CN: 在编辑该提交时，执行 `git reset HEAD^`。 其效果是将 `HEAD` 重绕一圈，索引也跟着重绕一圈。 但工作区保持不变。

note: type: Plain text
en: Now add the changes to the index that you want to have in the first commit.  You can use `git add` (possibly interactively) or `git gui` (or both) to do that.
zh_HANS-CN: 现在，将您希望在第一次提交中的改动添加到索引中。 你可以使用 `git add` （可能是交互式的）或 `git gui` （或两者）来完成。

note: type: Plain text
en: Commit the now-current index with whatever commit message is appropriate now.
zh_HANS-CN: 以任何合适的提交信息提交当前索引。

note: type: Plain text
en: Repeat the last two steps until your working tree is clean.
zh_HANS-CN: 重复最后两个步骤，直到工作区干净为止。

note: type: Plain text
en: Continue the rebase with `git rebase --continue`.
zh_HANS-CN: 使用 `git rebase --continue` 继续变基。

note: type: Plain text
en: If you are not absolutely sure that the intermediate revisions are consistent (they compile, pass the testsuite, etc.) you should use `git stash` to stash away the not-yet-committed changes after each commit, test, and amend the commit if fixes are necessary.
zh_HANS-CN: 如果不能绝对确定中间修订是一致的（编译、通过 testsuite 等），则应使用 `git stash` 在每次提交、测试之后，将尚未提交的改动保存起来，并在必要时修改提交。

note: type: Title -
en: RECOVERING FROM UPSTREAM REBASE
zh_HANS-CN: 从上有仓库变基中恢复

note: type: Plain text
en: Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea: anyone downstream of it is forced to manually fix their history.  This section explains how to do the fix from the downstream's point of view.  The real fix, however, would be to avoid rebasing the upstream in the first place.
zh_HANS-CN: 变基（或以任何其他形式改写）他人基于其工作的分支是个坏主意：其下游的任何人都不得不手动修正自己的历史。 本节将从下游的角度解释如何进行修复。 不过，真正的修复方法是首先避免重置上游分支。

note: type: Plain text
en: To illustrate, suppose you are in a situation where someone develops a 'subsystem' branch, and you are working on a 'topic' that is dependent on this 'subsystem'.  You might end up with a history like the following:
zh_HANS-CN: 举例说明，假设有人开发了一个 ‘子系统’ 分支，而你正在开发一个依赖于该 ‘子系统’ 的 ‘主题’。 你可能会有如下的历史记录：

note: type: Plain text
en: If 'subsystem' is rebased against 'master', the following happens:
zh_HANS-CN: 如果 ‘子系统’ 针对 'master' 进行重定向，会出现以下情况：

note: type: Plain text
en: If you now continue development as usual, and eventually merge 'topic' to 'subsystem', the commits from 'subsystem' will remain duplicated forever:
zh_HANS-CN: 如果现在像往常一样继续开发，并最终将 ‘主题’ 合并到 ‘子系统’，那么 ‘子系统’ 中的提交将永远重复：

note: type: Plain text
en: Such duplicates are generally frowned upon because they clutter up history, making it harder to follow.  To clean things up, you need to transplant the commits on 'topic' to the new 'subsystem' tip, i.e., rebase 'topic'.  This becomes a ripple effect: anyone downstream from 'topic' is forced to rebase too, and so on!
zh_HANS-CN: 这种重复通常是不受欢迎的，因为它们会使历史记录变得杂乱无章，难以跟踪。 要清理这些重复提交，就需要将 ‘主题’ 上的提交移植到新的 ‘子系统’ tip 上，即重置 ‘主题’。 这就会产生连锁反应：‘主题’ 的任何下游提交都会被迫重置，依此类推！

note: type: Plain text
en: There are two kinds of fixes, discussed in the following subsections:
zh_HANS-CN: 有两种修复方法，将在下面的小节中讨论：

note: type: Labeled list
en: Easy case: The changes are literally the same.
zh_HANS-CN: 简单的例子： 变化完全相同。

note: type: Plain text
en: This happens if the 'subsystem' rebase was a simple rebase and had no conflicts.
zh_HANS-CN: 如果 ‘子系统’ 变基是简单的重置，没有冲突，就会出现这种情况。

note: type: Labeled list
en: Hard case: The changes are not the same.
zh_HANS-CN: 较难的例子： 变化不一样。

note: type: Plain text
en: This happens if the 'subsystem' rebase had conflicts, or used `--interactive` to omit, edit, squash, or fixup commits; or if the upstream used one of `commit --amend`, `reset`, or a full history rewriting command like https://github.com/newren/git-filter-repo[`filter-repo`].
zh_HANS-CN: 如果 ‘子系统’ 变基有冲突，或者使用了 `--interactive` 来省略、编辑、压制或修复提交，或者上游使用了 `commit --amend`, `reset` 或完整历史重写命令（如 https://github.com/newren/git-filter-repo[`filter-repo`]），就会发生这种情况。

note: type: Title ~
en: The easy case
zh_HANS-CN: 简单案例

note: type: Plain text
en: Only works if the changes (patch IDs based on the diff contents) on 'subsystem' are literally the same before and after the rebase 'subsystem' did.
zh_HANS-CN: 只有当 ‘子系统’ 上的更改（基于差异内容的补丁 ID）在 ‘子系统’ 变基前后完全相同时才有效。

note: type: Plain text
en: In that case, the fix is easy because 'git rebase' knows to skip changes that are already present in the new upstream (unless `--reapply-cherry-picks` is given). So if you say (assuming you're on 'topic')
zh_HANS-CN: 在这种情况下，修复就很简单了，因为 'git rebase' 知道跳过新上游中已经存在的改动（除非给出 `--reapply-cherry-picks` 选项）。所以，如果你说（假设你在 ‘主题’ 分支上）

note: type: Plain text
en: you will end up with the fixed history
zh_HANS-CN: 您将获得固定的历史记录

note: type: Title ~
en: The hard case
zh_HANS-CN: 困难的例子

note: type: Plain text
en: Things get more complicated if the 'subsystem' changes do not exactly correspond to the ones before the rebase.
zh_HANS-CN: 如果 ‘子系统’ 的变化与重置前的变化不完全一致，情况就会变得更加复杂。

note: type: Plain text
en: While an "easy case recovery" sometimes appears to be successful
          even in the hard case, it may have unintended consequences.  For
          example, a commit that was removed via `git rebase
          --interactive` will be **resurrected**!
zh_HANS-CN: 虽然 ‘简单恢复案例’ 有时看似成功
          即使在疑难案件中，也可能产生意想不到的后果。 
          例如，通过 `git rebase
          --interactive` 删除的提交将被**恢复**！

note: type: Plain text
en: The idea is to manually tell `git rebase` "where the old 'subsystem' ended and your 'topic' began", that is, what the old merge base between them was.  You will have to find a way to name the last commit of the old 'subsystem', for example:
zh_HANS-CN: 我们的想法是手动告诉 `git rebase` “旧的 ‘子系统’ 分支在哪里结束，而您的 ‘主题’ 分支在哪里开始”，也就是说，它们之间的旧合并基础是什么。 例如，你必须找到一种方法来命名旧 ‘子系统’ 分支的最后一次提交：

note: type: Plain text
en: With the 'subsystem' reflog: after `git fetch`, the old tip of 'subsystem' is at `subsystem@{1}`.  Subsequent fetches will increase the number.  (See linkgit:git-reflog[1].)
zh_HANS-CN: 使用 ‘子系统’ 引用日志：在 `git fetch` 之后，‘子系统’ 的旧 tip 位于 `subsystem@{1}`。 随后的获取将增加这个数字。 (参见 linkgit:git-reflog[1]）

note: type: Plain text
en: Relative to the tip of 'topic': knowing that your 'topic' has three commits, the old tip of 'subsystem' must be `topic~3`.
zh_HANS-CN: 与 ‘主题’ 分支的 tip 有关：由于 ‘topic’ 分支有三次提交，所以 ‘子系统’ 分支的旧提示必须是 `topic~3`。

note: type: Plain text
en: You can then transplant the old `subsystem..topic` to the new tip by saying (for the reflog case, and assuming you are on 'topic' already):
zh_HANS-CN: 然后，您可以将旧的 `subsystem..topic`（子系统..主题）移植到新的提示中，方法是（对于引用日志的情况，假设您已经在 ‘主题’ 分支中）：

note: type: Plain text
en: The ripple effect of a "hard case" recovery is especially bad: 'everyone' downstream from 'topic' will now have to perform a "hard case" recovery too!
zh_HANS-CN: “困难例子” 恢复的连锁反应尤其糟糕：‘主题’ 下游的 ‘每个人’ 现在也必须执行 “困难例子” 恢复！

note: type: Title -
en: REBASING MERGES
zh_HANS-CN: 变基合并

note: type: Plain text
en: The interactive rebase command was originally designed to handle individual patch series. As such, it makes sense to exclude merge commits from the todo list, as the developer may have merged the then-current `master` while working on the branch, only to rebase all the commits onto `master` eventually (skipping the merge commits).
zh_HANS-CN: 交互式变基命令最初是为处理单个补丁系列而设计的。因此，将合并提交排除在待办事项列表之外是有道理的，因为开发人员在分支上工作时，可能已经合并了当时的 `master`，只是最终将所有提交重置到了 `master`上（跳过了合并提交）。

note: type: Plain text
en: However, there are legitimate reasons why a developer may want to recreate merge commits: to keep the branch structure (or "commit topology") when working on multiple, inter-related branches.
zh_HANS-CN: 不过，开发人员想要重新创建合并提交也有合理的原因：在多个相互关联的分支上工作时，为了保持分支结构（或 “提交拓扑”）。

note: type: Plain text
en: In the following example, the developer works on a topic branch that refactors the way buttons are defined, and on another topic branch that uses that refactoring to implement a "Report a bug" button. The output of `git log --graph --format=%s -5` may look like this:
zh_HANS-CN: 在下面的示例中，开发人员在一个重构了按钮定义方式的特性分支上工作，并在另一个特性分支上使用重构实现了 “报告错误” 按钮。`git log --graph --format=%s -5` 的输出可能是这样的：

note: type: Plain text
en: The developer might want to rebase those commits to a newer `master` while keeping the branch topology, for example when the first topic branch is expected to be integrated into `master` much earlier than the second one, say, to resolve merge conflicts with changes to the DownloadButton class that made it into `master`.
zh_HANS-CN: 开发人员可能希望在保留分支拓扑的同时，将这些提交重定向到更新的 `master` 分支，例如，当第一个特性分支比第二个分支更早集成到 `master` 分支时，开发人员可能希望解决与 “下载按钮” 类的合并冲突，因为 “下载按钮” 类已经集成到了 `master` 分支。

note: type: Plain text
en: This rebase can be performed using the `--rebase-merges` option.  It will generate a todo list looking like this:
zh_HANS-CN: 可以使用 `--rebase-merges` 选项进行重置。 它将生成如下的待办事项列表：

note: type: delimited block -
en: label onto
zh_HANS-CN: 标签上的

note: type: delimited block -
en: # Branch: refactor-button
    reset onto
    pick 123456 Extract a generic Button class from the DownloadButton one
    pick 654321 Use the Button class for all buttons
    label refactor-button
zh_HANS-CN: # 分支：重构按钮
    重置到
    选 123456 从下载按钮类中提取一个通用按钮类
    选取 654321 对所有按钮使用按钮类
    label refactor-button（重构按钮）

note: type: delimited block -
en: # Branch: report-a-bug
    reset refactor-button # Use the Button class for all buttons
    pick abcdef Add the feedback button
    label report-a-bug
zh_HANS-CN: # 分支：报告一个错误
    reset refactor-button （重构按钮）# 所有按钮都使用按钮类
    pick abcdef 添加反馈按钮
    label report-a-bug（报告一个错误）

note: type: delimited block -
en: reset onto
    merge -C a1b2c3 refactor-button # Merge 'refactor-button'
    merge -C 6f5e4d report-a-bug # Merge 'report-a-bug'
zh_HANS-CN: 重置到
    merge -C a1b2c3 refactor-button # 合并 “重构按钮”
    merge -C 6f5e4d report-a-bug # 合并 “报告一个错误”

note: type: Plain text
en: In contrast to a regular interactive rebase, there are `label`, `reset` and `merge` commands in addition to `pick` ones.
zh_HANS-CN: 与常规的交互式变基不同，除了 `pick`（选取）命令外，还有 `label`（标签）、`reset`（重置） 和 `merge`（合并） 命令。

note: type: Plain text
en: The `merge` command will merge the specified revision(s) into whatever is HEAD at that time. With `-C <original-commit>`, the commit message of the specified merge commit will be used. When the `-C` is changed to a lower-case `-c`, the message will be opened in an editor after a successful merge so that the user can edit the message.
zh_HANS-CN: `merge`（合并）命令会将指定的版本合并到当时的 HEAD 中。使用 `-C <源提交>` 时，将使用指定合并提交的提交信息。如果将 `-C` 改为小写的 `-c`，合并成功后，提交信息将在编辑器中打开，以便用户编辑信息。

note: type: Plain text
en: If a `merge` command fails for any reason other than merge conflicts (i.e.  when the merge operation did not even start), it is rescheduled immediately.
zh_HANS-CN: 如果 `merge`（合并）命令因合并冲突以外的任何原因失败（即合并操作甚至没有开始），则会立即重新安排。

note: type: Plain text
en: By default, the `merge` command will use the `ort` merge strategy for regular merges, and `octopus` for octopus merges.  One can specify a default strategy for all merges using the `--strategy` argument when invoking rebase, or can override specific merges in the interactive list of commands by using an `exec` command to call `git merge` explicitly with a `--strategy` argument.  Note that when calling `git merge` explicitly like this, you can make use of the fact that the labels are worktree-local refs (the ref `refs/rewritten/onto` would correspond to the label `onto`, for example) in order to refer to the branches you want to merge.
zh_HANS-CN: 默认情况下，`merge`（合并）命令将对常规合并使用 `ort ` 合并策略，对多路合并使用 `octopus` 合并策略。 我们可以在调用变基命令时使用 `--strategy` 参数为所有合并指定一个默认策略，也可以在交互式命令列表中使用 `exec` 命令显式地调用 `git merge` 并加上 `--strategy` 参数来覆盖特定的合并策略。 需要注意的是，像这样显式调用 `git merge` 时，可以利用标签是工作区本地引用（例如，引用 `refs/rewritten/onto` 将对应标签 `onto`）这一事实来引用要合并的分支。

note: type: Plain text
en: Note: the first command (`label onto`) labels the revision onto which the commits are rebased; The name `onto` is just a convention, as a nod to the `--onto` option.
zh_HANS-CN: 注意：第一条命令（`label onto`）会标注提交所基于的修订版本；`onto ` 只是一个约定俗成的名称，是对 `--onto` 选项的一种提示。

note: type: Plain text
en: It is also possible to introduce completely new merge commits from scratch by adding a command of the form `merge <merge-head>`. This form will generate a tentative commit message and always open an editor to let the user edit it. This can be useful e.g. when a topic branch turns out to address more than a single concern and wants to be split into two or even more topic branches. Consider this todo list:
zh_HANS-CN: 也可以通过添加 `merge <合并起点>` 命令，从头开始引入全新的合并提交。这种形式会生成暂定提交信息，并始终打开编辑器让用户编辑。例如，当一个特性分支要解决的问题不止一个，需要拆分成两个甚至更多特性分支时，这个命令就很有用。请看这个待办事项列表：

note: type: delimited block -
en: pick 192837 Switch from GNU Makefiles to CMake
    pick 5a6c7e Document the switch to CMake
    pick 918273 Fix detection of OpenSSL in CMake
    pick afbecd http: add support for TLS v1.3
    pick fdbaec Fix detection of cURL in CMake on Windows
zh_HANS-CN: pick 192837 从 GNU Makefiles 切换到 CMake
    pick 5a6c7e 记录切换到 CMake 的过程
    pick 918273 修复 CMake 中的 OpenSSL 检测问题
    pick afbecd http：添加对 TLS v1.3 的支持
    pick fdbaec 在 Windows 上修复 CMake 对 cURL 的检测

note: type: Plain text
en: The one commit in this list that is not related to CMake may very well have been motivated by working on fixing all those bugs introduced by switching to CMake, but it addresses a different concern. To split this branch into two topic branches, the todo list could be edited like this:
zh_HANS-CN: 该列表中与 CMake 无关的一个提交很可能是为了修复所有因改用 CMake 而引入的错误，但它解决的是另一个问题。要把这个分支分成两个主题分支，可以这样编辑待办事项列表：

note: type: delimited block -
en: pick afbecd http: add support for TLS v1.3
    label tlsv1.3
zh_HANS-CN: 选择 afbecd http：添加对 TLS v1.3 的支持
    label tlsv1.3

note: type: delimited block -
en: reset onto
    pick 192837 Switch from GNU Makefiles to CMake
    pick 918273 Fix detection of OpenSSL in CMake
    pick fdbaec Fix detection of cURL in CMake on Windows
    pick 5a6c7e Document the switch to CMake
    label cmake
zh_HANS-CN: reset onto
    pick 192837 从 GNU Makefiles 切换到 CMake
    pick 918273 修复 CMake 中的 OpenSSL 检测问题
    pick fdbaec 在 Windows 上修复 CMake 对 cURL 的检测
    pick 5a6c7e 记录切换到 CMake 的过程
    label cmake

note: type: Plain text
en: 'git reflog' [show] [<log-options>] [<ref>]
    'git reflog expire' [--expire=<time>] [--expire-unreachable=<time>]
    	[--rewrite] [--updateref] [--stale-fix]
    	[--dry-run | -n] [--verbose] [--all [--single-worktree] | <refs>...]
    'git reflog delete' [--rewrite] [--updateref]
    	[--dry-run | -n] [--verbose] <ref>@{<specifier>}...
    'git reflog exists' <ref>
zh_HANS-CN: 'git reflog' [show] [<日志选项>] [<引用>]
    'git reflog expire' [--expire=<时间>] [--expire-unreachable=<时间>]
    	[--rewrite] [--updateref] [--stale-fix]
    	[--dry-run | -n] [--verbose] [--all [--single-worktree] | <引用>...]
    'git reflog delete' [--rewrite] [--updateref]
    	[--dry-run | -n] [--verbose] <引用>@{<标注>}...
    'git reflog exists' <引用>

note: type: Plain text
en: This command manages the information recorded in the reflogs.
zh_HANS-CN: 该命令管理记录在引用日志中的信息。

note: type: Plain text
en: Reference logs, or "reflogs", record when the tips of branches and other references were updated in the local repository. Reflogs are useful in various Git commands, to specify the old value of a reference. For example, `HEAD@{2}` means "where HEAD used to be two moves ago", `master@{one.week.ago}` means "where master used to point to one week ago in this local repository", and so on. See linkgit:gitrevisions[7] for more details.
zh_HANS-CN: 引用日志（或称 "reflogs"）记录了本地仓库中分支和其他引用的提示更新时间。参考日志在各种 Git 命令中都很有用，可以用来指定引用的旧值。例如，`HEAD@{2}` 表示 “两步前 HEAD 所在的位置”，`master@{one.week.previous}` 表示 “一周前本仓库中 master 所在的位置”，等等。详见 linkgit:gitrevisions[7]。

note: type: Plain text
en: The "show" subcommand (which is also the default, in the absence of any subcommands) shows the log of the reference provided in the command-line (or `HEAD`, by default). The reflog covers all recent actions, and in addition the `HEAD` reflog records branch switching.  `git reflog show` is an alias for `git log -g --abbrev-commit --pretty=oneline`; see linkgit:git-log[1] for more information.
zh_HANS-CN: "show" 子命令（也是默认命令，在没有任何子命令的情况下）显示命令行中提供的引用日志（或默认的 `HEAD`）。引用日志包括所有最近的操作，此外，`HEAD` 引用日志还记录分支切换。 `git reflog show` 是 `git log -g --abbrev-commit --pretty=oneline` 的别名；详见 linkgit:git-log[1]。

note: type: Plain text
en: The "expire" subcommand prunes older reflog entries. Entries older than `expire` time, or entries older than `expire-unreachable` time and not reachable from the current tip, are removed from the reflog.  This is typically not used directly by end users -- instead, see linkgit:git-gc[1].
zh_HANS-CN: "expire" 子命令用于删除旧的引用日志条目。超过 `expire` 时间的条目，或超过 `expire-unreachable` 时间且当前 tip 无法访问的条目，都会从引用日志中删除。 终端用户通常不会直接使用该子项，请参见 linkgit:git-gc[1]。

note: type: Plain text
en: The "delete" subcommand deletes single entries from the reflog. Its argument must be an _exact_ entry (e.g. "`git reflog delete master@{2}`"). This subcommand is also typically not used directly by end users.
zh_HANS-CN: "delete" 子命令用于删除应用日志中的单个条目。其参数必须是一个_exact_条目（例如"`git reflog delete master@{2}`"）。最终用户通常也不会直接使用该子命令。

note: type: Plain text
en: The "exists" subcommand checks whether a ref has a reflog.  It exits with zero status if the reflog exists, and non-zero status if it does not.
zh_HANS-CN: "exists" 子命令检查引用是否有引用日志。 如果引用日志存在，则以零状态退出；如果不存在，则以非零状态退出。

note: type: Title ~
en: Options for `show`
zh_HANS-CN: `show`（显示）的选项

note: type: Plain text
en: `git reflog show` accepts any of the options accepted by `git log`.
zh_HANS-CN: `git reflog show` 接受 `git log` 接受的任何选项。

note: type: Title ~
en: Options for `expire`
zh_HANS-CN: `expire` 的选项

note: type: Plain text
en: Process the reflogs of all references.
zh_HANS-CN: 处理所有引用的引用日志。

note: type: Plain text
en: By default when `--all` is specified, reflogs from all working trees are processed. This option limits the processing to reflogs from the current working tree only.
zh_HANS-CN: 默认情况下，如果指定了 `--all`选项，所有工作区的引用日志都会被处理。此选项限制只处理当前工作区的引用日志。

note: type: Labeled list
en: --expire=<time>
zh_HANS-CN: --expire=<时间>

note: type: Plain text
en: Prune entries older than the specified time. If this option is not specified, the expiration time is taken from the configuration setting `gc.reflogExpire`, which in turn defaults to 90 days. `--expire=all` prunes entries regardless of their age; `--expire=never` turns off pruning of reachable entries (but see `--expire-unreachable`).
zh_HANS-CN: 剪除超过指定时间的条目。如果未指定此选项，则过期时间取自配置设置 `gc.reflogExpire`，默认为 90 天。`expire=all` 会剪除任何年龄的条目；`--expire=never` 会关闭剪除可到达条目的功能（但请参阅 `--expire-unreachable`）。

note: type: Labeled list
en: --expire-unreachable=<time>
zh_HANS-CN: --expire-unreachable=<时间>

note: type: Plain text
en: Prune entries older than `<time>` that are not reachable from the current tip of the branch. If this option is not specified, the expiration time is taken from the configuration setting `gc.reflogExpireUnreachable`, which in turn defaults to 30 days. `--expire-unreachable=all` prunes unreachable entries regardless of their age; `--expire-unreachable=never` turns off early pruning of unreachable entries (but see `--expire`).
zh_HANS-CN: 剪除从分支当前顶端无法到达的超过 `<时间>` 的条目。如果未指定此选项，则过期时间取自配置设置 `gc.reflogExpireUnreachable`，默认为 30 天。`--expire-unreachable=all` 会修剪无法访问的条目，无论其年龄大小；`--expire-unreachable=never` 会关闭对无法访问条目的早期修剪（但请参见 `--expire`）。

note: type: Plain text
en: Update the reference to the value of the top reflog entry (i.e.  <ref>@\{0\}) if the previous top entry was pruned.  (This option is ignored for symbolic references.)
zh_HANS-CN: 如果前一个顶层条目已被剪枝，则将引用更新为顶层引用日志条目的值（即 <引用>@\{0\}）。 (符号引用将忽略此选项）

note: type: Plain text
en: If a reflog entry's predecessor is pruned, adjust its "old" SHA-1 to be equal to the "new" SHA-1 field of the entry that now precedes it.
zh_HANS-CN: 如果重写日志条目的前一个条目被剪枝，则调整其 “旧” SHA-1，使其等于现在排在其前面的条目的 “新” SHA-1 字段。

note: type: Plain text
en: Prune any reflog entries that point to "broken commits". A broken commit is a commit that is not reachable from any of the reference tips and that refers, directly or indirectly, to a missing commit, tree, or blob object.
zh_HANS-CN: 删除任何指向 “中断提交” 的引用日志条目。中断提交是指从任何引用提示都无法到达的提交，它直接或间接地指向丢失的提交、树或二进制对象。

note: type: Plain text
en: This computation involves traversing all the reachable objects, i.e. it has the same cost as 'git prune'.  It is primarily intended to fix corruption caused by garbage collecting using older versions of Git, which didn't protect objects referred to by reflogs.
zh_HANS-CN: 这种计算涉及遍历所有可到达的对象，也就是说，其代价与 'git prune' 相同。 它的主要目的是修复旧版本 Git 垃圾回收所造成的损坏，因为旧版本的 Git 无法保护引用日志所引用的对象。

note: type: Plain text
en: Do not actually prune any entries; just show what would have been pruned.
zh_HANS-CN: 不要实际修剪任何条目，只需显示本应修剪的内容。

note: type: Plain text
en: Print extra information on screen.
zh_HANS-CN: 在屏幕上打印额外信息。

note: type: Title ~
en: Options for `delete`
zh_HANS-CN: `delete`（删除）的选项

note: type: Plain text
en: Manage the set of repositories ("remotes") whose branches you track.
zh_HANS-CN: 管理仓库（"远程"）的集合，这些仓库的分支由你跟踪。

note: type: Plain text
en: Be a little more verbose and show remote url after name.  For promisor remotes, also show which filter (`blob:none` etc.)  are configured.  NOTE: This must be placed between `remote` and subcommand.
zh_HANS-CN: 更详细一点，在名称后显示远程 URL。对于允诺者远程，还要显示配置了哪个过滤器(` blob: none` 等)。注意: 这必须放在 `remote` 和子命令之间。

note: type: Plain text
en: With no arguments, shows a list of existing remotes.  Several subcommands are available to perform operations on the remotes.
zh_HANS-CN: 不带参数，显示现有远程的列表。有几个子命令可用于对远程执行操作。

note: type: Plain text
en: Add a remote named <name> for the repository at <URL>.  The command `git fetch <name>` can then be used to create and update remote-tracking branches <name>/<branch>.
zh_HANS-CN: 在 <URL> 为存储库添加一个名为 <名称> 的远程名称。然后可以使用命令 `git get <名称>`创建和更新远程跟踪分支 <名称>/<分支> 。

note: type: Plain text
en: With `-f` option, `git fetch <name>` is run immediately after the remote information is set up.
zh_HANS-CN: 使用 `-f` 选项，在设置远程信息之后立即运行 `git get <名称>`。

note: type: Plain text
en: With `--tags` option, `git fetch <name>` imports every tag from the remote repository.
zh_HANS-CN: 使用 `--tag` 选项，`git get <名称>` 从远程仓库导入每个标记。

note: type: Plain text
en: With `--no-tags` option, `git fetch <name>` does not import tags from the remote repository.
zh_HANS-CN: 使用 `--no-tags` 选项，`git fetch <名称>` 不会从远程仓库导入标签。

note: type: Plain text
en: By default, only tags on fetched branches are imported (see linkgit:git-fetch[1]).
zh_HANS-CN: 默认情况下，只导入获取的分支上的标记（参见 linkgit:git-fetch[1]）。

note: type: Plain text
en: With `-t <branch>` option, instead of the default glob refspec for the remote to track all branches under the `refs/remotes/<name>/` namespace, a refspec to track only `<branch>` is created.  You can give more than one `-t <branch>` to track multiple branches without grabbing all branches.
zh_HANS-CN: 使用 `-t <分支>` 选项，将创建一个仅跟踪 `refs/remotes/<名称>/` 命名空间下的所有分支的引用规范，而不是用于远程跟踪的默认引用规范通配符。您可以提供多个 `-t <分支>` 来跟踪多个分支，而不需要获取所有分支。

note: type: Plain text
en: With `-m <master>` option, a symbolic-ref `refs/remotes/<name>/HEAD` is set up to point at remote's `<master>` branch. See also the set-head command.
zh_HANS-CN: 使用 `-m <master>` 选项，可以设置一个符号引用 `/remotes/<名称>/HEAD` 来指向远程仓库的 `<master>` 分支。另请参见 set-head 命令。

note: type: Plain text
en: When a fetch mirror is created with `--mirror=fetch`, the refs will not be stored in the 'refs/remotes/' namespace, but rather everything in 'refs/' on the remote will be directly mirrored into 'refs/' in the local repository. This option only makes sense in bare repositories, because a fetch would overwrite any local commits.
zh_HANS-CN: 当用 `--mirror=fetch` 创建一个 fetch 镜像时， 引用不会被存储在 'refs/remotes/' 命名空间中，而是远程的 'refs/' 中的所有内容将直接被镜像到本地版本库的 'refs/' 中。这个选项只有在裸库中才有意义，因为获取会覆盖任何本地提交。

note: type: Plain text
en: When a push mirror is created with `--mirror=push`, then `git push` will always behave as if `--mirror` was passed.
zh_HANS-CN: 当用 `--mirror=push` 创建推送镜像时，`git push` 的行为就像传递 `--mirror` 一样。

note: type: Plain text
en: Rename the remote named <old> to <new>. All remote-tracking branches and configuration settings for the remote are updated.
zh_HANS-CN: 将名为 < 旧名称 > 的远程重命名为 < 新名称 > 。所有远程跟踪的分支和远程的配置设置都被更新。

note: type: Plain text
en: In case <old> and <new> are the same, and <old> is a file under `$GIT_DIR/remotes` or `$GIT_DIR/branches`, the remote is converted to the configuration file format.
zh_HANS-CN: 如果 <旧名称 >和< 新名称 >相同，并且< 旧名称 >是 `$GIT_DIR/remotes` 或 `$GIT_DIR/branches` 下的文件，远程将被转换为配置文件格式。

note: type: Plain text
en: Remove the remote named <name>. All remote-tracking branches and configuration settings for the remote are removed.
zh_HANS-CN: 删除名为 < 名称 > 的远程。该远程的所有远程跟踪分支和配置设置都被删除。

note: type: Plain text
en: Sets or deletes the default branch (i.e. the target of the symbolic-ref `refs/remotes/<name>/HEAD`) for the named remote. Having a default branch for a remote is not required, but allows the name of the remote to be specified in lieu of a specific branch. For example, if the default branch for `origin` is set to `master`, then `origin` may be specified wherever you would normally specify `origin/master`.
zh_HANS-CN: 设置或删除命名远程仓库的默认分支（即符号引用 `refs/remotes/<名称>/HEAD` 的目标）。不需要为远程仓库设置默认分支，但允许指定远程仓库的名称来代替特定分支。例如，如果 `origin` 的默认分支设置为 `master`，则可以在通常指定 `origin/master` 的任何位置指定 `origin`。

note: type: Plain text
en: With `-d` or `--delete`, the symbolic ref `refs/remotes/<name>/HEAD` is deleted.
zh_HANS-CN: 设置 `-d` 或 `--delete` 选项，符号引用 `refs/remotes/<名称>/HEAD` 将被删除.

note: type: Plain text
en: With `-a` or `--auto`, the remote is queried to determine its `HEAD`, then the symbolic-ref `refs/remotes/<name>/HEAD` is set to the same branch. e.g., if the remote `HEAD` is pointed at `next`, `git remote set-head origin -a` will set the symbolic-ref `refs/remotes/origin/HEAD` to `refs/remotes/origin/next`. This will only work if `refs/remotes/origin/next` already exists; if not it must be fetched first.
zh_HANS-CN: 使用 `-a` 或 `--auto`，查询远程仓库以确定其 `HEAD`，然后将符号引用 `refs/remotes/<名称>/HEAD` 设置为同一分支。 例如，如果远程 `HEAD` 指向`next`，`git remote set-head origin -a`会将符号引用 `refs/remotes/origin/HEAD` 设置为 `refs/remotes/origin/next`。这仅在 `refs/remotes/origin/next` 已经存在时才有效；如果不是，则必须首先获取它。

note: type: Plain text
en: Use `<branch>` to set the symbolic-ref `refs/remotes/<name>/HEAD` explicitly. e.g., `git remote set-head origin master` will set the symbolic-ref `refs/remotes/origin/HEAD` to `refs/remotes/origin/master`. This will only work if `refs/remotes/origin/master` already exists; if not it must be fetched first.
zh_HANS-CN: 使用 `<branch>` 显式地设置符号引用 `refs/remotes/<名称>/HEAD`。例如，`git remote set-head source master` 会将这个符号引用 ` refs/remotes/source/HEAD`设置为 `ref/remotes/source/master`。这只有在 `refs/remote/source/master` 已经存在的情况下才能工作；如果不存在，则必须首先获取它。

note: type: Plain text
en: Changes the list of branches tracked by the named remote.  This can be used to track a subset of the available remote branches after the initial setup for a remote.
zh_HANS-CN: 改变命名的远程所追踪的分支列表。 这可以用来在最初设置一个远程分支后，追踪一个可用的远程分支子集。

note: type: Plain text
en: The named branches will be interpreted as if specified with the `-t` option on the `git remote add` command line.
zh_HANS-CN: 被命名的分支将被解释为在 `git remote add`命令中用 `-t` 选项指定的。

note: type: Plain text
en: With `--add`, instead of replacing the list of currently tracked branches, adds to that list.
zh_HANS-CN: 使用 `--add`，不是替换当前跟踪分支列表，而是添加到该列表中。

note: type: Plain text
en: Retrieves the URLs for a remote. Configurations for `insteadOf` and `pushInsteadOf` are expanded here. By default, only the first URL is listed.
zh_HANS-CN: 检索一个远程的 URLs。`insteadOf` 和 `pushInsteadOf` 的配置在此列出。默认情况下，只有第一个 URL 被列出。

note: type: Plain text
en: With `--push`, push URLs are queried rather than fetch URLs.
zh_HANS-CN: 使用 `--push`，查询的是推送的URLs，而不是获取的URLs。

note: type: Plain text
en: With `--all`, all URLs for the remote will be listed.
zh_HANS-CN: 使用 `--all`选项，远程仓库的所有 URL 将被列出。

note: type: Plain text
en: Changes URLs for the remote. Sets first URL for remote <name> that matches regex <oldurl> (first URL if no <oldurl> is given) to <newurl>. If <oldurl> doesn't match any URL, an error occurs and nothing is changed.
zh_HANS-CN: 改变远程的URLs。将远程 <名称> 的第一个匹配正则表达式 <旧url> 的URL（如果没有给出 <旧url>，则为第一个URL）设置为 <新url>。如果 <旧url> 不匹配任何URL，就会发生错误，并且什么都不会被改变。

note: type: Plain text
en: With `--push`, push URLs are manipulated instead of fetch URLs.
zh_HANS-CN: 使用 `--push` ，推送 URLs 被操作，而不是获取 URLs。

note: type: Plain text
en: With `--add`, instead of changing existing URLs, new URL is added.
zh_HANS-CN: 使用 `--add`，不改变现有的 URLs，而是添加新的 URL。

note: type: Plain text
en: With `--delete`, instead of changing existing URLs, all URLs matching regex <URL> are deleted for remote <name>.  Trying to delete all non-push URLs is an error.
zh_HANS-CN: 使用 `--delete`选项，不是改变现有的 URL，而是删除远程 <名称> 的所有正则匹配 <URL> 的 URL。 试图删除所有非推送 URLs 是错的。

note: type: Plain text
en: Note that the push URL and the fetch URL, even though they can be set differently, must still refer to the same place.  What you pushed to the push URL should be what you would see if you immediately fetched from the fetch URL.  If you are trying to fetch from one place (e.g. your upstream) and push to another (e.g.  your publishing repository), use two separate remotes.
zh_HANS-CN: 请注意，推送 URL 和获取 URL，即使它们的设置不同，也必须指的是同一个地方。 你推送到推送 URL 的内容应该是你立即从获取的 URL 中获取的内容。 如果你试图从一个地方（如你的上游）获取并推送到另一个地方（如你的发布库），请使用两个独立的远程。

note: type: Plain text
en: Gives some information about the remote <name>.
zh_HANS-CN: 提供关于远程 <名称> 的一些信息。

note: type: Plain text
en: With `-n` option, the remote heads are not queried first with `git ls-remote <name>`; cached information is used instead.
zh_HANS-CN: 使用 `-n` 选项，就不会先用 `git ls-remote <名称>` 查询远程头指针，而是使用缓存的信息。

note: type: Plain text
en: Deletes stale references associated with <name>. By default, stale remote-tracking branches under <name> are deleted, but depending on global configuration and the configuration of the remote we might even prune local tags that haven't been pushed there. Equivalent to `git fetch --prune <name>`, except that no new references will be fetched.
zh_HANS-CN: 删除与 <名称> 相关的陈旧引用。默认情况下，<名称>下的陈旧远程跟踪分支会被删除，但根据全局配置和远程的配置，我们甚至可能修剪没有被推送到那里的本地标签。相当于 `git fetch --prune <名称>`，只是不会取到新的引用。

note: type: Plain text
en: See the PRUNING section of linkgit:git-fetch[1] for what it'll prune depending on various configuration.
zh_HANS-CN: 参见 linkgit:git-fetch[1] 的剪枝部分，了解它将根据不同的配置修剪什么。

note: type: Plain text
en: With `--dry-run` option, report what branches would be pruned, but do not actually prune them.
zh_HANS-CN: 使用 `--dry-run` 选项，报告哪些分支将被修剪，但实际上不修剪它们。

note: type: Plain text
en: Fetch updates for remotes or remote groups in the repository as defined by `remotes.<group>`. If neither group nor remote is specified on the command line, the configuration parameter remotes.default will be used; if remotes.default is not defined, all remotes which do not have the configuration parameter `remote.<name>.skipDefaultUpdate` set to true will be updated.  (See linkgit:git-config[1]).
zh_HANS-CN: 为仓库中由 `remotes.<组>` 定义的远程或远程组获取更新。如果在命令行中既没有指定组也没有指定远程，将使用配置参数 remotes.default；如果没有定义 remotes.default，所有没有将配置参数 `remote.<名称>.skipDefaultUpdate` 设置为 true 的远程将被更新。 (参见 linkgit:git-config[1]）。

note: type: Plain text
en: With `--prune` option, run pruning against all the remotes that are updated.
zh_HANS-CN: 使用 `--prune` 选项，对所有被更新的远程进行修剪。

note: type: Plain text
en: The remote configuration is achieved using the `remote.origin.url` and `remote.origin.fetch` configuration variables.  (See linkgit:git-config[1]).
zh_HANS-CN: 远程配置是通过 `remote.origin.url` 和 `remote.origin.fetch` 配置变量实现的。 (见 linkgit:git-config[1]）。

note: type: Plain text
en: On success, the exit status is `0`.
zh_HANS-CN: 成功的时候，退出状态码为 `0`。

note: type: Plain text
en: When subcommands such as 'add', 'rename', and 'remove' can't find the remote in question, the exit status is `2`. When the remote already exists, the exit status is `3`.
zh_HANS-CN: 当诸如 'add'、'rename' 和 'remove' 等子命令不能找到相关的远程，退出状态码为 `2`。当远程已经存在时，退出状态码是 `3`。

note: type: Plain text
en: On any other error, the exit status may be any other non-zero value.
zh_HANS-CN: 对于其他错误，退出状态码可能是任何其他非零值。

note: type: Plain text
en: Add a new remote, fetch, and check out a branch from it
zh_HANS-CN: 添加一个新的远程，获取并检出一个分支

note: type: Plain text
en: Imitate 'git clone' but track only selected branches
zh_HANS-CN: 模仿 'git clone'，但只跟踪选定的分支

note: type: Plain text
en: This command is used to combine all objects that do not currently reside in a "pack", into a pack.  It can also be used to re-organize existing packs into a single, more efficient pack.
zh_HANS-CN: 该命令用于将当前不在 “数据包” 中的所有对象合并到一个数据包中。 它还可以用来将现有的数据包重新组织成一个更有效的数据包。

note: type: Plain text
en: Instead of incrementally packing the unpacked objects, pack everything referenced into a single pack.  Especially useful when packing a repository that is used for private development. Use with `-d`.  This will clean up the objects that `git prune` leaves behind, but `git fsck --full --dangling` shows as dangling.
zh_HANS-CN: 将所有引用对象打包成一个包，而不是逐步打包未打包的对象。 在打包用于私人开发的版本库时尤其有用。与 `-d` 一起使用。 这将清理 `git prune` 留下的对象，但 `git fsck --full --dangling` 显示为悬空。

note: type: Plain text
en: Note that users fetching over dumb protocols will have to fetch the whole new pack in order to get any contained object, no matter how many other objects in that pack they already have locally.
zh_HANS-CN: 请注意，通过哑协议获取的用户必须获取整个新数据包，才能获得其中包含的任何对象，无论他们本地已经拥有多少该数据包中的其他对象。

note: type: Plain text
en: Promisor packfiles are repacked separately: if there are packfiles that have an associated ".promisor" file, these packfiles will be repacked into another separate pack, and an empty ".promisor" file corresponding to the new separate pack will be written.
zh_HANS-CN: Promisor 包文件将单独重新打包：如果有的包文件有一个相关的 ".promisor " 文件，这些包文件将被重新打包到另一个单独的包中，并写入一个与新的单独包相对应的空 ".promisor " 文件。

note: type: Plain text
en: Same as `-a`, unless `-d` is used.  Then any unreachable objects in a previous pack become loose, unpacked objects, instead of being left in the old pack.  Unreachable objects are never intentionally added to a pack, even when repacking.  This option prevents unreachable objects from being immediately deleted by way of being left in the old pack and then removed.  Instead, the loose unreachable objects will be pruned according to normal expiry rules with the next 'git gc' invocation. See linkgit:git-gc[1].
zh_HANS-CN: 与 `-a` 相同，除非使用了 `-d`。 这样，以前的数据包中任何无法到达的对象都会变成松散的、未打包的对象，而不是留在旧数据包中。 即使在重新打包时，也不会有意将无法到达的对象添加到数据包中。 该选项可以防止无法到达的对象留在旧数据包中后被立即删除。 相反，松散的不可达对象将在下一次调用 'git gc' 时根据正常的过期规则进行修剪。参见 linkgit:git-gc[1]。

note: type: Plain text
en: After packing, if the newly created packs make some existing packs redundant, remove the redundant packs.  Also run 'git prune-packed' to remove redundant loose object files.
zh_HANS-CN: 打包后，如果新创建的包使得某些现有包变得多余，则删除多余的包。 同时运行 'git prune-packed' 删除多余的松散对象文件。

note: type: Plain text
en: Same as `-a`, unless `-d` is used. Then any unreachable objects are packed into a separate cruft pack. Unreachable objects can be pruned using the normal expiry rules with the next `git gc` invocation (see linkgit:git-gc[1]). Incompatible with `-k`.
zh_HANS-CN: 与 `-a` 相同，除非使用了 `-d`。然后，任何无法访问的对象都会被打包到一个单独的压缩包中。无法访问的对象可以在下一次调用 `git gc` 时使用正常的过期规则进行剪枝（参见 linkgit:git-gc[1]）。与 `-k` 不兼容。

note: type: Plain text
en: Expire unreachable objects older than `<approxidate>` immediately instead of waiting for the next `git gc` invocation.  Only useful with `--cruft -d`.
zh_HANS-CN: 立即过期超过 `<approxidate>` 的不可访问对象，而不是等待下一次调用 `git gc`。 仅在使用 `--cruft -d` 选项时有用。

note: type: Plain text
en: Write a cruft pack containing pruned objects (if any) to the directory `<dir>`. This option is useful for keeping a copy of any pruned objects in a separate directory as a backup. Only useful with `--cruft -d`.
zh_HANS-CN: 将包含修剪对象（如果有）的压缩包写入目录 `<路径>`。该选项可用于在单独的目录中保留剪枝对象的副本作为备份。仅在使用 `--cruft -d` 时有用。

note: type: Plain text
en: Pass the `--local` option to 'git pack-objects'. See linkgit:git-pack-objects[1].
zh_HANS-CN: 向 'git pack-objects' 传递 `--local` 选项。参见 linkgit:git-pack-objects[1]。

note: type: Plain text
en: Pass the `--no-reuse-delta` option to `git-pack-objects`, see linkgit:git-pack-objects[1].
zh_HANS-CN: 向 `git-pack-objects` 传递 `--no-reuse-delta` 选项，参见 linkgit:git-pack-objects[1]。

note: type: Plain text
en: Pass the `--no-reuse-object` option to `git-pack-objects`, see linkgit:git-pack-objects[1].
zh_HANS-CN: 向 `git-pack-objects` 传递 `--no-reuse-object` 选项，参见 linkgit:git-pack-objects[1]。

note: type: Plain text
en: Show no progress over the standard error stream and pass the `-q` option to 'git pack-objects'. See linkgit:git-pack-objects[1].
zh_HANS-CN: 在标准错误流中不显示进度，并向 'git pack-objects' 传递 `-q` 选项。参见 linkgit:git-pack-objects[1]。

note: type: Plain text
en: Do not update the server information with 'git update-server-info'.  This option skips updating local catalog files needed to publish this repository (or a direct copy of it)  over HTTP or FTP.  See linkgit:git-update-server-info[1].
zh_HANS-CN: 不使用 'git update-server-info' 更新服务器信息。 该选项会跳过更新通过 HTTP 或 FTP 发布该仓库（或其直接副本）所需的本地目录文件。 参见 linkgit:git-update-server-info[1]。

note: type: Plain text
en: These two options affect how the objects contained in the pack are stored using delta compression. The objects are first internally sorted by type, size and optionally names and compared against the other objects within `--window` to see if using delta compression saves space. `--depth` limits the maximum delta depth; making it too deep affects the performance on the unpacker side, because delta data needs to be applied that many times to get to the necessary object.
zh_HANS-CN: 这两个选项会影响如何使用 delta 压缩来存储数据包中的对象。对象首先会按类型、大小和可选名称进行内部排序，然后与 `--window`中的其他对象进行比较，以确定使用 delta 压缩是否能节省空间。`--depth` 限制了 delta 深度的最大值；过深会影响解包器的性能，因为需要多次应用 delta 数据才能找到所需的对象。

note: type: Plain text
en: This option is passed through to `git pack-objects`.
zh_HANS-CN: 该选项将传递给 `git pack-objects`。

note: type: Plain text
en: This option provides an additional limit on top of `--window`; the window size will dynamically scale down so as to not take up more than '<n>' bytes in memory.  This is useful in repositories with a mix of large and small objects to not run out of memory with a large window, but still be able to take advantage of the large window for the smaller objects.  The size can be suffixed with "k", "m", or "g".  `--window-memory=0` makes memory usage unlimited.  The default is taken from the `pack.windowMemory` configuration variable.  Note that the actual memory usage will be the limit multiplied by the number of threads used by linkgit:git-pack-objects[1].
zh_HANS-CN: 该选项在 `--window` 的基础上提供了额外的限制；窗口大小会动态缩减，以避免占用超过 '<n>' 字节的内存。 这对于大小对象混杂的版本库非常有用，既不会因为窗口过大而耗尽内存，又能利用大窗口处理小对象。 大小后缀可以是 "k"、"m" 或 "g"。`window-memory=0` 表示内存使用不受限制。 默认值取自 `pack.windowMemory` 配置变量。 请注意，实际内存使用量将是 linkgit:git-pack-objects[1] 使用的线程数乘以限制值。

note: type: Plain text
en: Maximum size of each output pack file. The size can be suffixed with "k", "m", or "g". The minimum size allowed is limited to 1 MiB.  If specified, multiple packfiles may be created, which also prevents the creation of a bitmap index.  The default is unlimited, unless the config variable `pack.packSizeLimit` is set. Note that this option may result in a larger and slower repository; see the discussion in `pack.packSizeLimit`.
zh_HANS-CN: 每个输出包文件的最大大小。大小可以后缀为 "k"、"m" 或 "g"。允许的最小大小限制为 1MB。 如果指定，可能会创建多个数据包文件，这也会阻止位图索引的创建。 默认值是无限大，除非设置了配置变量 `pack.packSizeLimit`。请注意，该选项可能会导致版本库变大、变慢；请参阅 `pack.packSizeLimit` 中的讨论。

note: type: Plain text
en: Write a reachability bitmap index as part of the repack. This only makes sense when used with `-a`, `-A` or `-m`, as the bitmaps must be able to refer to all reachable objects. This option overrides the setting of `repack.writeBitmaps`. This option has no effect if multiple packfiles are created, unless writing a MIDX (in which case a multi-pack bitmap is created).
zh_HANS-CN: 作为重新打包的一部分，写入可达性位图索引。这只有在与 `-a`、`-A` 或 `-m` 参数一起使用时才有意义，因为位图必须能够指向所有可达对象。此选项会覆盖 `repack.writeBitmaps` 的设置。如果创建了多个包文件，此选项将不起作用，除非正在写入一个 MIDX（在这种情况下将创建一个多包位图）。

note: type: Plain text
en: Include objects in `.keep` files when repacking.  Note that we still do not delete `.keep` packs after `pack-objects` finishes.  This means that we may duplicate objects, but this makes the option safe to use when there are concurrent pushes or fetches.  This option is generally only useful if you are writing bitmaps with `-b` or `repack.writeBitmaps`, as it ensures that the bitmapped packfile has the necessary objects.
zh_HANS-CN: 重新打包时将对象包含在 `.keep` 文件中。 请注意，在 `pack-objects` 完成后，我们仍不会删除 `.keep` 包。 这意味着我们可能会重复对象，但这使得该选项在有并发推送或获取时可以安全使用。 通常只有在使用 `-b` 或 `repack.writeBitmaps` 编写位图时，该选项才会有用，因为它可以确保位图包文件中包含必要的对象。

note: type: Plain text
en: Exclude the given pack from repacking. This is the equivalent of having `.keep` file on the pack. `<pack-name>` is the pack file name without leading directory (e.g. `pack-123.pack`).  The option could be specified multiple times to keep multiple packs.
zh_HANS-CN: 将给定的软件包排除在重新打包之外。这相当于在软件包中加入 `.keep` 文件。`<包名>`是软件包文件名，不含前导目录（如 `pack-123.pack`）。 可多次指定该选项以保留多个软件包。

note: type: Plain text
en: When loosening unreachable objects, do not bother loosening any objects older than `<when>`. This can be used to optimize out the write of any objects that would be immediately pruned by a follow-up `git prune`.
zh_HANS-CN: 当松动无法访问的对象时，不要费心松动任何早于 `<时候>`的对象。这可以用来优化写入对象的过程，因为后续的 `git prune` 会立即剪枝这些对象。

note: type: Plain text
en: When used with `-ad`, any unreachable objects from existing packs will be appended to the end of the packfile instead of being removed. In addition, any unreachable loose objects will be packed (and their loose counterparts removed).
zh_HANS-CN: 与 `-ad` 一起使用时，现有数据包中任何无法访问的对象将被附加到数据包文件的末尾，而不是被移除。此外，任何无法访问的松散对象也将被打包（并移除其松散对应对象）。

note: type: Plain text
en: Pass the `--delta-islands` option to `git-pack-objects`, see linkgit:git-pack-objects[1].
zh_HANS-CN: 向 `git-pack-objects` 传递 `--delta-islands` 选项，参见 linkgit:git-pack-objects[1]。

note: type: Labeled list
en: -g=<factor>
zh_HANS-CN: -g=<条件>

note: type: Labeled list
en: --geometric=<factor>
zh_HANS-CN: --geometric=<条件>

note: type: Plain text
en: Arrange resulting pack structure so that each successive pack contains at least `<factor>` times the number of objects as the next-largest pack.
zh_HANS-CN: 排列生成的数据包结构，使每个连续的数据包包含的对象数量至少是下一个最大数据包的 `<条件>` 倍。

note: type: Plain text
en: `git repack` ensures this by determining a "cut" of packfiles that need to be repacked into one in order to ensure a geometric progression. It picks the smallest set of packfiles such that as many of the larger packfiles (by count of objects contained in that pack) may be left intact.
zh_HANS-CN: `git repack` 通过 “切割” 需要重新打包成一个的文件包来确保几何级数的增长。它会挑选最小的文件包集合，以便尽可能多地保留较大的文件包（按该文件包所含对象的数量计算）。

note: type: Plain text
en: Unlike other repack modes, the set of objects to pack is determined uniquely by the set of packs being "rolled-up"; in other words, the packs determined to need to be combined in order to restore a geometric progression.
zh_HANS-CN: 与其他重新包装模式不同的是，需要包装的对象集是由 “卷起” 的包装集唯一决定的；换句话说，为了恢复几何级数，确定需要组合的包装。

note: type: Plain text
en: When `--unpacked` is specified, loose objects are implicitly included in this "roll-up", without respect to their reachability. This is subject to change in the future. This option (implying a drastically different repack mode) is not guaranteed to work with all other combinations of option to `git repack`.
zh_HANS-CN: 当指定了 `--unpacked` 时，松散的对象会被隐含地包含在这个 “卷积” 中，而不考虑它们的可达性。这一点将来可能会改变。此选项（意味着一种截然不同的重新打包模式）并不保证与 `git repack` 的所有其他选项组合一起使用。

note: type: Plain text
en: When writing a multi-pack bitmap, `git repack` selects the largest resulting pack as the preferred pack for object selection by the MIDX (see linkgit:git-multi-pack-index[1]).
zh_HANS-CN: 在编写多包位图时，`git repack` 会选择生成的最大包作为 MIDX 选择对象的首选包（参见 linkgit:git-multi-pack-index[1]）。

note: type: Plain text
en: Write a multi-pack index (see linkgit:git-multi-pack-index[1])  containing the non-redundant packs.
zh_HANS-CN: 编写包含非冗余软件包的多软件包索引（参见 linkgit:git-multi-pack-index[1]）。

note: type: Plain text
en: By default, the command passes `--delta-base-offset` option to 'git pack-objects'; this typically results in slightly smaller packs, but the generated packs are incompatible with versions of Git older than version 1.4.4. If you need to share your repository with such ancient Git versions, either directly or via the dumb http protocol, then you need to set the configuration variable `repack.UseDeltaBaseOffset` to "false" and repack. Access from old Git versions over the native protocol is unaffected by this option as the conversion is performed on the fly as needed in that case.
zh_HANS-CN: 默认情况下，该命令会在 'git pack-objects' 中传递 `--delta-base-offset` 选项；这通常会导致生成的数据包略小，但生成的数据包与版本 1.4.4 以上的 Git 版本不兼容。如果你需要直接或通过笨重的 http 协议与这些古老的 Git 版本共享你的仓库，那么你需要将配置变量 `repack.UseDeltaBaseOffset` 设为 "false"，然后重新打包。通过本地协议访问旧版本的 Git 不受此选项影响，因为在这种情况下，转换是根据需要即时进行的。

note: type: Plain text
en: Delta compression is not used on objects larger than the `core.bigFileThreshold` configuration variable and on files with the attribute `delta` set to false.
zh_HANS-CN: 对于大于 `core.bigFileThreshold` 配置变量的对象和属性 `delta` 设置为 false 的文件，不会使用 Delta 压缩。

note: type: Plain text
en: git-replace - Create, list, delete refs to replace objects
zh_HANS-CN: git-replace - 创建、列出、删除用于替换对象的引用

note: type: Plain text
en: Adds a 'replace' reference in `refs/replace/` namespace.
zh_HANS-CN: 在 `refs/replace/` 命名空间中添加 'replace' 引用。

note: type: Plain text
en: The name of the 'replace' reference is the SHA-1 of the object that is replaced. The content of the 'replace' reference is the SHA-1 of the replacement object.
zh_HANS-CN: 'replace' 引用的名称是被替换对象的 SHA-1 'replace' 引用的内容是被替换对象的 SHA-1 值。

note: type: Plain text
en: The replaced object and the replacement object must be of the same type.  This restriction can be bypassed using `-f`.
zh_HANS-CN: 被替换对象和替换对象必须是同一类型。 使用 `-f` 可以绕过这一限制。

note: type: Plain text
en: Unless `-f` is given, the 'replace' reference must not yet exist.
zh_HANS-CN: 除非给出 `-f`，否则 'replace' 引用必须不存在。

note: type: Plain text
en: There is no other restriction on the replaced and replacement objects.  Merge commits can be replaced by non-merge commits and vice versa.
zh_HANS-CN: 被替换和替换对象没有其他限制。 合并提交可以被非合并提交替换，反之亦然。

note: type: Plain text
en: Replacement references will be used by default by all Git commands except those doing reachability traversal (prune, pack transfer and fsck).
zh_HANS-CN: 除了进行可达性遍历的命令（剪枝、打包转移和 fsck）外，所有 Git 命令都将默认使用替换引用。

note: type: Plain text
en: It is possible to disable use of replacement references for any command using the `--no-replace-objects` option just after 'git'.
zh_HANS-CN: 使用 'git' 后面的 `--no-replace-objects` 选项，可以禁止在任何命令中使用替换引用。

note: type: Plain text
en: For example if commit 'foo' has been replaced by commit 'bar':
zh_HANS-CN: 例如，如果提交 'foo' 已被提交 'bar' 取代：

note: type: Plain text
en: shows information about commit 'foo', while:
zh_HANS-CN: 显示有关提交 'foo' 的信息，而：

note: type: Plain text
en: shows information about commit 'bar'.
zh_HANS-CN: 显示有关提交 'bar' 的信息。

note: type: Plain text
en: The `GIT_NO_REPLACE_OBJECTS` environment variable can be set to achieve the same effect as the `--no-replace-objects` option.
zh_HANS-CN: 可以设置 `GIT_NO_REPLACE_OBJECTS` 环境变量，以达到与 `--no-replace-objects` 选项相同的效果。

note: type: Plain text
en: If an existing replace ref for the same object exists, it will be overwritten (instead of failing).
zh_HANS-CN: 如果同一对象已有一个替换引用，它将被覆盖（而不是失效）。

note: type: Plain text
en: Delete existing replace refs for the given objects.
zh_HANS-CN: 删除给定对象的现有替换引用。

note: type: Plain text
en: When editing, provide the raw object contents rather than pretty-printed ones. Currently this only affects trees, which will be shown in their binary form. This is harder to work with, but can help when repairing a tree that is so corrupted it cannot be pretty-printed. Note that you may need to configure your editor to cleanly read and write binary data.
zh_HANS-CN: 编辑时，请提供原始对象内容，而不是格式化打印的内容。目前这只影响目录树，因为目录树将以二进制形式显示。这比较难处理，但在修复已损坏到无法格式化打印的目录树时可以有所帮助。需要注意的是，你可能需要对编辑器进行配置，以便干净利落地读写二进制数据。

note: type: Plain text
en: Create a graft commit. A new commit is created with the same content as <commit> except that its parents will be [<parent>...] instead of <commit>'s parents. A replacement ref is then created to replace <commit> with the newly created commit. Use `--convert-graft-file` to convert a `$GIT_DIR/info/grafts` file and use replace refs instead.
zh_HANS-CN: 创建嫁接提交。新创建的提交内容与 <提交> 相同，只是它的父提交将是 [<父提交>...]，而不是 <提交> 的父提交。然后会创建一个替换引用，用新创建的提交替换 <提交>。使用 `--convert-graft-file`，转换 `$GIT_DIR/info/grafts` 文件并使用替换引用代替。

note: type: Plain text
en: Creates graft commits for all entries in `$GIT_DIR/info/grafts` and deletes that file upon success. The purpose is to help users with transitioning off of the now-deprecated graft file.
zh_HANS-CN: 为 `$GIT_DIR/info/grafts` 中的所有条目创建嫁接提交，并在成功后删除该文件。目的是帮助用户从现已过时的 graft 文件过渡。

note: type: Plain text
en: List replace refs for objects that match the given pattern (or all if no pattern is given).  Typing "git replace" without arguments, also lists all replace refs.
zh_HANS-CN: 列出与给定模式匹配的对象的替换反射（如果没有给定模式，则列出所有对象）。 输入不带参数的 "git replace"，也会列出所有替换反射。

note: type: Plain text
en: When listing, use the specified <format>, which can be one of 'short', 'medium' and 'long'. When omitted, the format defaults to 'short'.
zh_HANS-CN: 列表时，使用指定的 <格式>，它可以是 'short'（短）、'medium'（中）和 'long'（长）格式之一。如果省略，格式默认为 'short'（短）。

note: type: Plain text
en: The following format are available:
zh_HANS-CN: 提供以下格式：

note: type: Title -
en: CREATING REPLACEMENT OBJECTS
zh_HANS-CN: 创建替换对象

note: type: Plain text
en: linkgit:git-hash-object[1], linkgit:git-rebase[1], and https://github.com/newren/git-filter-repo[git-filter-repo], among other git commands, can be used to create replacement objects from existing objects. The `--edit` option can also be used with 'git replace' to create a replacement object by editing an existing object.
zh_HANS-CN: linkgit:git-hash-object[1]、linkgit:git-rebase[1]、https://github.com/newren/git-filter-repo[git-filter-repo] 等 git 命令可以用来从现有对象创建替换对象。此外，`--edit` 选项也可以与 'git replace' 一起使用，通过编辑现有对象来创建替换对象。

note: type: Plain text
en: If you want to replace many blobs, trees or commits that are part of a string of commits, you may just want to create a replacement string of commits and then only replace the commit at the tip of the target string of commits with the commit at the tip of the replacement string of commits.
zh_HANS-CN: 如果您想替换属于提交串一部分的许多二进制对象、目录树或提交，您可能只想创建一个替换提交串，然后只用替换提交串顶端的提交替换目标提交串顶端的提交。

note: type: Plain text
en: Comparing blobs or trees that have been replaced with those that replace them will not work properly. And using `git reset --hard` to go back to a replaced commit will move the branch to the replacement commit instead of the replaced commit.
zh_HANS-CN: 比较被替换的二进制对象或目录树与替换它们的二进制对象或目录树将无法正常工作。使用 `git reset --hard` 回到被替换的提交，会将分支移动到替换提交，而不是被替换的提交。

note: type: Plain text
en: There may be other problems when using 'git rev-list' related to pending objects.
zh_HANS-CN: 使用 'git rev-list' 时，可能会遇到与待处理对象相关的其他问题。

note: type: Plain text
en: git-request-pull - Generates a summary of pending changes
zh_HANS-CN: git-request-pull - 生成待处理更改的摘要

note: type: Plain text
en: 'git request-pull' [-p] <start> <URL> [<end>]
zh_HANS-CN: 'git request-pull' [-p] <开始> <URL> [<结束>］

note: type: Plain text
en: Generate a request asking your upstream project to pull changes into their tree.  The request, printed to the standard output, begins with the branch description, summarizes the changes and indicates from where they can be pulled.
zh_HANS-CN: 生成一个请求，要求你的上游项目将变更拉入他们的分支树。 该请求会打印到标准输出中，以分支描述开头，总结变更内容，并指出可以从哪里拉取变更。

note: type: Plain text
en: The upstream project is expected to have the commit named by `<start>` and the output asks it to integrate the changes you made since that commit, up to the commit named by `<end>`, by visiting the repository named by `<URL>`.
zh_HANS-CN: 上游项目预计会有以 `<开始>` 命名的提交，输出会要求它通过访问以 `<URL>` 命名的仓库，整合您自该提交后所做的更改，直至以 `<结束>` 命名的提交。

note: type: Plain text
en: Include patch text in the output.
zh_HANS-CN: 在输出中包含补丁文本。

note: type: Plain text
en: Commit to start at.  This names a commit that is already in the upstream history.
zh_HANS-CN: 从提交开始。 这将命名一个已在上游历史中的提交。

note: type: Plain text
en: The repository URL to be pulled from.
zh_HANS-CN: 要提取的仓库 URL。

note: type: Plain text
en: Commit to end at (defaults to HEAD).  This names the commit at the tip of the history you are asking to be pulled.
zh_HANS-CN: 提交结束于（默认为 HEAD）。 这将命名您要求提取的历史最前沿的提交。

note: type: Plain text
en: When the repository named by `<URL>` has the commit at a tip of a ref that is different from the ref you have locally, you can use the `<local>:<remote>` syntax, to have its local name, a colon `:`, and its remote name.
zh_HANS-CN: 当以 `<URL>` 命名的仓库的提交位于与本地仓库不同的引用的顶端时，可以使用 `<本地>:<远程>` 语法，以获得其本地名称、冒号 `:`和远程名称。

note: type: Plain text
en: Imagine that you built your work on your `master` branch on top of the `v1.0` release, and want it to be integrated to the project.  First you push that change to your public repository for others to see:
zh_HANS-CN: 想象一下，您在 `v1.0` 版本的基础上建立了自己的 `master` 分支，并希望将其集成到项目中。 首先，你将该变更推送到公共仓库，供其他人查看：

note: type: Plain text
en: Then, you run this command:
zh_HANS-CN: 然后，运行这条命令：

note: type: Plain text
en: which will produce a request to the upstream, summarizing the changes between the `v1.0` release and your `master`, to pull it from your public repository.
zh_HANS-CN: 会向上游发出请求，总结从 `v1.0` 版本到您的 `master` 版本之间的变化，以便从您的公共仓库中提取。

note: type: Plain text
en: If you pushed your change to a branch whose name is different from the one you have locally, e.g.
zh_HANS-CN: 如果您将更改推送到的分支名称与本地分支不同，例如

note: type: Plain text
en: then you can ask that to be pulled with
zh_HANS-CN: 然后，您可以用

note: type: Plain text
en: In a workflow employing relatively long lived topic branches, the developer sometimes needs to resolve the same conflicts over and over again until the topic branches are done (either merged to the "release" branch, or sent out and accepted upstream).
zh_HANS-CN: 在采用相对较长的特性分支的工作流程中，开发人员有时需要反复解决相同的冲突，直到特性分支完成（要么合并到 “发布” 分支，要么发送到上游并被接受）。

note: type: Plain text
en: This command assists the developer in this process by recording conflicted automerge results and corresponding hand resolve results on the initial manual merge, and applying previously recorded hand resolutions to their corresponding automerge results.
zh_HANS-CN: 在此过程中，该命令通过记录冲突的自动合并结果和初始手动合并的相应手工解析结果，并将先前记录的手工解析结果应用于相应的自动合并结果，来帮助开发人员。

note: type: Plain text
en: You need to set the configuration variable `rerere.enabled` in order to enable this command.
zh_HANS-CN: 您需要设置配置变量 `rerere.enabled` 才能启用该命令。

note: type: Plain text
en: Normally, 'git rerere' is run without arguments or user-intervention.  However, it has several commands that allow it to interact with its working state.
zh_HANS-CN: 通常，'git rerere' 的运行不需要参数或用户干预。 不过，它有几条命令允许它与工作状态交互。

note: type: Labeled list
en: 'clear'
zh_HANS-CN: 'clear'（清除）

note: type: Plain text
en: Reset the metadata used by rerere if a merge resolution is to be aborted.  Calling 'git am [--skip|--abort]' or 'git rebase [--skip|--abort]' will automatically invoke this command.
zh_HANS-CN: 如果要中止合并解析，重置 rerere 使用的元数据。 调用 'git am [--skip|--abort]' 或 'git rebase [--skip|--abort]' 会自动调用此命令。

note: type: Labeled list
en: 'forget' <pathspec>
zh_HANS-CN: 'forget' <路径规范>

note: type: Plain text
en: Reset the conflict resolutions which rerere has recorded for the current conflict in <pathspec>.
zh_HANS-CN: 重置 rerere 在 <路径规范> 中记录的当前冲突的冲突决议。

note: type: Plain text
en: Display diffs for the current state of the resolution.  It is useful for tracking what has changed while the user is resolving conflicts.  Additional arguments are passed directly to the system 'diff' command installed in PATH.
zh_HANS-CN: 显示当前冲突解决状态的差异。 这对于跟踪用户在解决冲突时发生了哪些变化非常有用。 附加参数会直接传递给安装在 PATH 中的系统 'diff' 命令。

note: type: Plain text
en: Print paths with conflicts whose merge resolution rerere will record.
zh_HANS-CN: 打印有冲突的路径，rerere 将记录其合并解决方案。

note: type: Plain text
en: Print paths with conflicts that have not been autoresolved by rerere.  This includes paths whose resolutions cannot be tracked by rerere, such as conflicting submodules.
zh_HANS-CN: 打印 rerere 尚未自动解决冲突的路径。 这包括 rerere 无法跟踪其解决的路径，如冲突的子模块。

note: type: Plain text
en: Prune records of conflicted merges that occurred a long time ago.  By default, unresolved conflicts older than 15 days and resolved conflicts older than 60 days are pruned.  These defaults are controlled via the `gc.rerereUnresolved` and `gc.rerereResolved` configuration variables respectively.
zh_HANS-CN: 修剪很久以前发生的冲突合并记录。 默认情况下，超过 15 天的未解决冲突和超过 60 天的已解决冲突会被剪除。 这些默认值分别由 `gc.rerereUnresolved` 和 `gc.rerereResolved` 配置变量控制。

note: type: Plain text
en: When your topic branch modifies an overlapping area that your master branch (or upstream) touched since your topic branch forked from it, you may want to test it with the latest master, even before your topic branch is ready to be pushed upstream:
zh_HANS-CN: 当你的特性分支修改了主分支（或上游分支）从特性分支分叉出来后接触过的重叠区域时，你可能想用最新的主分支进行测试，甚至在特性分支准备好推送到上游之前：

note: type: Plain text
en: For such a test, you need to merge master and topic somehow.  One way to do it is to pull master into the topic branch:
zh_HANS-CN: 要进行这样的测试，需要以某种方式合并主分支和特性分支。 一种方法是将主分支拉入特性分支：

note: type: Plain text
en: The commits marked with `*` touch the same area in the same file; you need to resolve the conflicts when creating the commit marked with `+`.  Then you can test the result to make sure your work-in-progress still works with what is in the latest master.
zh_HANS-CN: 标有 `*` 的提交涉及同一文件中的同一区域；您需要在创建标有 `+` 的提交时解决冲突。 然后，您就可以测试结果，以确保您正在进行的工作仍能与最新的 master 中的内容一起运行。

note: type: Plain text
en: After this test merge, there are two ways to continue your work on the topic.  The easiest is to build on top of the test merge commit `+`, and when your work in the topic branch is finally ready, pull the topic branch into master, and/or ask the upstream to pull from you.  By that time, however, the master or the upstream might have been advanced since the test merge `+`, in which case the final commit graph would look like this:
zh_HANS-CN: 测试合并后，有两种方法可以继续主题工作。 最简单的方法是建立在测试合并提交 `+` 之上，当你在特性分支中的工作最终准备就绪时，将特性分支拉入主分支，和/或请求上游从你那里拉取。 不过，到那时，主分支或上游分支可能已经在测试合并 `+` 后提前了，在这种情况下，最终的提交图会是这样的：

note: type: Plain text
en: When your topic branch is long-lived, however, your topic branch would end up having many such "Merge from master" commits on it, which would unnecessarily clutter the development history.  Readers of the Linux kernel mailing list may remember that Linus complained about such too frequent test merges when a subsystem maintainer asked to pull from a branch full of "useless merges".
zh_HANS-CN: 然而，当你的特性分支寿命很长时，你的特性分支上就会有很多这样的 “从主分支合并” 提交，这将不必要地扰乱开发历史。 Linux 内核邮件列表的读者可能还记得，当一个子系统维护者要求从一个充满 “无用合并” 的分支中拉取代码时，Linus 抱怨过这种过于频繁的测试合并。

note: type: Plain text
en: As an alternative, to keep the topic branch clean of test merges, you could blow away the test merge, and keep building on top of the tip before the test merge:
zh_HANS-CN: 作为一种替代方法，为了使主题分支不受测试合并的影响，可以删除测试合并，并在测试合并之前继续在提示之上构建：

note: type: Plain text
en: This would leave only one merge commit when your topic branch is finally ready and merged into the master branch.  This merge would require you to resolve the conflict, introduced by the commits marked with `*`.  However, this conflict is often the same conflict you resolved when you created the test merge you blew away.  'git rerere' helps you resolve this final conflicted merge using the information from your earlier hand resolve.
zh_HANS-CN: 这样，当你的特性分支最终准备就绪并合并到主分支时，就只剩下一个合并提交了。 这次合并需要解决标有 `*` 的提交所带来的冲突。 然而，这个冲突往往就是你在创建测试合并时解决的冲突。 'git rerere' 可以帮助你使用之前手工解决的信息来解决最终的冲突合并。

note: type: Plain text
en: Running the 'git rerere' command immediately after a conflicted automerge records the conflicted working tree files, with the usual conflict markers `<<<<<<<`, `=======`, and `>>>>>>>` in them.  Later, after you are done resolving the conflicts, running 'git rerere' again will record the resolved state of these files.  Suppose you did this when you created the test merge of master into the topic branch.
zh_HANS-CN: 在自动合成冲突后立即运行 'git rerere' 命令，会记录下冲突的工作树文件，并在其中加上通常的冲突标记`<<<<<<<`、`=======` 和 `>>>>>>>`。 稍后，当你解决完冲突后，再次运行 'git rerere' 就会记录下这些文件已解决的状态。 假设你在创建将 master 合并到主题分支的测试时做了这个操作。

note: type: Plain text
en: Next time, after seeing the same conflicted automerge, running 'git rerere' will perform a three-way merge between the earlier conflicted automerge, the earlier manual resolution, and the current conflicted automerge.  If this three-way merge resolves cleanly, the result is written out to your working tree file, so you do not have to manually resolve it.  Note that 'git rerere' leaves the index file alone, so you still need to do the final sanity checks with `git diff` (or `git diff -c`) and 'git add' when you are satisfied.
zh_HANS-CN: 下一次，在看到相同的自动生成器冲突后，运行 'git rerere' 将在之前的自动生成器冲突、之前的手动解决和当前的自动生成器冲突之间执行一次三向合并。 如果这次三方合并解决得很干净，结果就会写入工作区的文件中，因此你就不必再手动解决了。 请注意，'git rerere' 不会影响索引文件，因此您仍需要使用 `git diff`（或 `git diff -c`）和 `git add` 进行最后的正确性检查。

note: type: Plain text
en: As a convenience measure, 'git merge' automatically invokes 'git rerere' upon exiting with a failed automerge and 'git rerere' records the hand resolve when it is a new conflict, or reuses the earlier hand resolve when it is not.  'git commit' also invokes 'git rerere' when committing a merge result.  What this means is that you do not have to do anything special yourself (besides enabling the rerere.enabled config variable).
zh_HANS-CN: 为了方便起见，'git merge' 会在自动合并失败退出时自动调用 'git rerere'，如果是新的冲突，'git rerere' 会记录手工解析，如果不是，则重用之前的手工解析。 在提交合并结果时，'git commit' 也会调用 'git rerere' 。 这意味着，除了启用 rerere.enabled 配置变量外，你无需做任何特别的事情。

note: type: Plain text
en: In our example, when you do the test merge, the manual resolution is recorded, and it will be reused when you do the actual merge later with the updated master and topic branch, as long as the recorded resolution is still applicable.
zh_HANS-CN: 在我们的示例中，当你进行测试合并时，手动解决方法会被记录下来，只要记录下来的解决方法仍然适用，就会在稍后与更新的主分支和主题分支进行实际合并时重复使用。

note: type: Plain text
en: The information 'git rerere' records is also used when running 'git rebase'.  After blowing away the test merge and continuing development on the topic branch:
zh_HANS-CN: 'git rerere' 记录的信息也会在运行 'git rebase' 时使用。 将测试合并后，继续在主题分支上进行开发：

note: type: Plain text
en: you could run `git rebase master topic`, to bring yourself up to date before your topic is ready to be sent upstream.  This would result in falling back to a three-way merge, and it would conflict the same way as the test merge you resolved earlier.  'git rerere' will be run by 'git rebase' to help you resolve this conflict.
zh_HANS-CN: 您可以运行 `git rebase master topic`，在您的主题准备好被发送到上游之前更新自己。 这将导致退回到三方合并，而且会和之前的测试合并产生冲突。 ' git rebase' 会运行 'git rerere' 来帮你解决这个冲突。

note: type: Plain text
en: git-reset - Reset current HEAD to the specified state
zh_HANS-CN: git-reset - 重置当前HEAD到指定的状态

note: type: Plain text
en: In the first three forms, copy entries from `<tree-ish>` to the index.  In the last form, set the current branch head (`HEAD`) to `<commit>`, optionally modifying index and working tree to match.  The `<tree-ish>`/`<commit>` defaults to `HEAD` in all forms.
zh_HANS-CN: 在前三种形式中，从`<treeish>`复制条目到索引。  在最后一个表格中，将当前的分支头(`HEAD`)设置为`<commit>`，可以选择修改索引和工作树来匹配。  `<tree-ish>`/`<commit>`在所有表格中默认为`HEAD`。

note: type: Plain text
en: These forms reset the index entries for all paths that match the `<pathspec>` to their state at `<tree-ish>`.  (It does not affect the working tree or the current branch.)
zh_HANS-CN: 这些表格将所有符合`<pathspec>`的路径的索引项重置为`<treeish>`时的状态。  (它不影响工作树或当前分支)。

note: type: Plain text
en: This means that `git reset <pathspec>` is the opposite of `git add <pathspec>`. This command is equivalent to `git restore [--source=<tree-ish>] --staged <pathspec>...`.
zh_HANS-CN: 这意味着，`git reset <pathspec>`与`git add <pathspec>`相反。该命令等同于`git restore [--source=<treeish>] --staged <pathspec>...`。

note: type: Plain text
en: After running `git reset <pathspec>` to update the index entry, you can use linkgit:git-restore[1] to check the contents out of the index to the working tree. Alternatively, using linkgit:git-restore[1] and specifying a commit with `--source`, you can copy the contents of a path out of a commit to the index and to the working tree in one go.
zh_HANS-CN: 运行 `git reset <pathspec>` 来更新索引条目后，您可以使用 linkgit:git-restore[1] 来检查索引中的内容到工作树上。另外，使用 linkgit:git-restore[1] 并用 `--source` 指定一个提交，你可以一次性将一个路径的内容从提交中复制到索引和工作树上。

note: type: Plain text
en: Interactively select hunks in the difference between the index and `<tree-ish>` (defaults to `HEAD`).  The chosen hunks are applied in reverse to the index.
zh_HANS-CN: 在索引和`<tree-ish>`（默认为`HEAD`）之间的差异中交互式地选择猎物。  选择的猎物将被反向应用到索引中。

note: type: Plain text
en: This means that `git reset -p` is the opposite of `git add -p`, i.e.  you can use it to selectively reset hunks. See the ``Interactive Mode'' section of linkgit:git-add[1] to learn how to operate the `--patch` mode.
zh_HANS-CN: 这意味着 `git reset -p` 与 `git add -p` 相反，也就是说，你可以用它来有选择地重置 hunks。参见 linkgit:git-add[1] 的 ``互动模式''部分，了解如何操作`--patch`模式。

note: type: Plain text
en: Does not touch the index file or the working tree at all (but resets the head to `<commit>`, just like all modes do). This leaves all your changed files "Changes to be committed", as `git status` would put it.
zh_HANS-CN: 完全不碰索引文件或工作树（但将头部重置为`<commit>`，就像所有模式一样）。这使你的所有更改的文件都是 "待提交的更改"，正如`git status`所说的。

note: type: Plain text
en: Resets the index but not the working tree (i.e., the changed files are preserved but not marked for commit) and reports what has not been updated. This is the default action.
zh_HANS-CN: 重置索引，但不重置工作树（即保留已修改的文件，但不标记为提交）并报告未更新的内容。这是默认动作。

note: type: Plain text
en: Resets the index and updates the files in the working tree that are different between `<commit>` and `HEAD`, but keeps those which are different between the index and working tree (i.e. which have changes which have not been added).  If a file that is different between `<commit>` and the index has unstaged changes, reset is aborted.
zh_HANS-CN: 重置索引并更新工作树中在`<commit>`和`HEAD`之间不同的文件，但保留那些在索引和工作树之间不同的文件（即那些有未被添加的修改）。  如果一个在`<commit>`和索引之间不同的文件有未分阶段的变化，重置将被中止。

note: type: Plain text
en: In other words, `--merge` does something like a `git read-tree -u -m <commit>`, but carries forward unmerged index entries.
zh_HANS-CN: 换句话说，`--merge`做的是类似于`git read-tree -u -m <commit>`的事情，但会转发未合并的索引条目。

note: type: Plain text
en: Resets index entries and updates files in the working tree that are different between `<commit>` and `HEAD`.  If a file that is different between `<commit>` and `HEAD` has local changes, reset is aborted.
zh_HANS-CN: 重置索引项并更新工作树中`<commit>`和`HEAD`之间不同的文件。  如果一个在`<commit>`和`HEAD`之间不同的文件有本地修改，重置将被中止。

note: type: Plain text
en: When the working tree is updated, using --recurse-submodules will also recursively reset the working tree of all active submodules according to the commit recorded in the superproject, also setting the submodules' HEAD to be detached at that commit.
zh_HANS-CN: 当工作树被更新时，使用 --recurse-submodules 也将根据超级项目中记录的提交，递归地重置所有活动的子模块的工作树，同时也将子模块的 HEAD 设置为在该提交中被分离。

note: type: Plain text
en: See "Reset, restore and revert" in linkgit:git[1] for the differences between the three commands.
zh_HANS-CN: 关于这三个命令的区别，见linkgit:git[1]中的 "重置、恢复和还原"。

note: type: Plain text
en: Refresh the index after a mixed reset. Enabled by default.
zh_HANS-CN: 在混合重置后刷新索引，默认启用。

note: type: Labeled list
en: Undo add
zh_HANS-CN: 撤销添加

note: type: Plain text
en: You are happily working on something, and find the changes in these files are in good order.  You do not want to see them when you run `git diff`, because you plan to work on other files and changes with these files are distracting.
zh_HANS-CN: 你正在愉快地工作，发现这些文件中的修改都很有秩序。  你不希望在运行`git diff'时看到它们，因为你打算在其他文件上工作，而这些文件的变化会让你分心。

note: type: Plain text
en: Somebody asks you to pull, and the changes sound worthy of merging.
zh_HANS-CN: 有人要求你拉，而且这些变化听起来值得合并。

note: type: Plain text
en: However, you already dirtied the index (i.e. your index does not match the `HEAD` commit).  But you know the pull you are going to make does not affect `frotz.c` or `filfre.c`, so you revert the index changes for these two files.  Your changes in working tree remain there.
zh_HANS-CN: 然而，你已经破坏了索引（也就是说，你的索引与`HEAD`提交不匹配）。  但你知道你要做的拉动并不影响`frotz.c`或`filfre.c`，所以你恢复了这两个文件的索引修改。  你在工作树上的修改仍然存在。

note: type: Plain text
en: Then you can pull and merge, leaving `frotz.c` and `filfre.c` changes still in the working tree.
zh_HANS-CN: 然后你可以拉出并合并，留下`frotz.c`和`filfre.c`的修改仍在工作树上。

note: type: Labeled list
en: Undo a commit and redo
zh_HANS-CN: 撤销一个提交并重做

note: type: Plain text
en: This is most often done when you remembered what you just committed is incomplete, or you misspelled your commit message, or both.  Leaves working tree as it was before "reset".
zh_HANS-CN: 这通常是在你记得你刚提交的内容不完整，或者你的提交信息拼错了，或者两者都是。  留下工作树在 "重置 "之前的样子。

note: type: Plain text
en: Make corrections to working tree files.
zh_HANS-CN: 对工作树文件进行修正。

note: type: Plain text
en: "reset" copies the old head to `.git/ORIG_HEAD`; redo the commit by starting with its log message.  If you do not need to edit the message further, you can give `-C` option instead.
zh_HANS-CN: "reset "将旧的头部复制到`.git/ORIG_HEAD`；从其日志信息开始重做提交。  如果你不需要进一步编辑信息，你可以给`-C`选项代替。

note: type: Plain text
en: See also the `--amend` option to linkgit:git-commit[1].
zh_HANS-CN: 参见linkgit:git-commit[1]的`--amend`选项。

note: type: Labeled list
en: Undo a commit, making it a topic branch
zh_HANS-CN: 撤销一个提交，使其成为一个主题分支

note: type: Plain text
en: You have made some commits, but realize they were premature to be in the `master` branch.  You want to continue polishing them in a topic branch, so create `topic/wip` branch off of the current `HEAD`.
zh_HANS-CN: 你已经做了一些提交，但意识到它们在 "master "分支中还不成熟。  你想在一个主题分支中继续完善它们，所以在当前的`HEAD'之外创建了`topic/wip'分支。

note: type: Plain text
en: Rewind the master branch to get rid of those three commits.
zh_HANS-CN: 回溯主分支，去掉这三个提交。

note: type: Plain text
en: Switch to `topic/wip` branch and keep working.
zh_HANS-CN: 切换到`topic/wip`分支并继续工作。

note: type: Labeled list
en: Undo commits permanently
zh_HANS-CN: 永久撤销提交

note: type: delimited block -
en: $ git commit ...
    $ git reset --hard HEAD~3   <1>
zh_HANS-CN: $ git commit ...
    $ git reset --hard HEAD~3 <1>

note: type: Plain text
en: The last three commits (`HEAD`, `HEAD^`, and `HEAD~2`) were bad and you do not want to ever see them again.  Do *not* do this if you have already given these commits to somebody else.  (See the "RECOVERING FROM UPSTREAM REBASE" section in linkgit:git-rebase[1] for the implications of doing so.)
zh_HANS-CN: 最后三个提交（`HEAD`，`HEAD^`，和`HEAD~2`）是坏的，你不希望再看到它们。  如果你已经把这些提交给了别人，请不要**这样做。  参见 linkgit:git-rebase[1] 中的 "RECOVERING FROM UPSTREAM REBASE" 一节，了解这样做的意义）。

note: type: Labeled list
en: Undo a merge or pull
zh_HANS-CN: 撤销合并或拉动

note: type: delimited block -
en: $ git pull                         <1>
    Auto-merging nitfol
    CONFLICT (content): Merge conflict in nitfol
    Automatic merge failed; fix conflicts and then commit the result.
    $ git reset --hard                 <2>
    $ git pull . topic/branch          <3>
    Updating from 41223... to 13134...
    Fast-forward
    $ git reset --hard ORIG_HEAD       <4>
zh_HANS-CN: $ git pull <1>
    自动合并nitfol
    CONFLICT（内容）。nitfol的合并冲突
    自动合并失败；修复冲突，然后提交结果。
    $ git reset --hard <2>
    $ git pull . topic/branch <3>
    从41223...更新到13134...
    快进
    $ git reset --hard ORIG_HEAD <4>

note: type: Plain text
en: Try to update from the upstream resulted in a lot of conflicts; you were not ready to spend a lot of time merging right now, so you decide to do that later.
zh_HANS-CN: 试图从上游更新导致了很多冲突；你现在还没有准备好花费大量的时间来合并，所以你决定以后再做这个。

note: type: Plain text
en: "pull" has not made merge commit, so `git reset --hard` which is a synonym for `git reset --hard HEAD` clears the mess from the index file and the working tree.
zh_HANS-CN: "pull "没有进行合并提交，所以`git reset --hard`是`git reset --hard HEAD`的同义词，它清除了索引文件和工作树上的混乱。

note: type: Plain text
en: Merge a topic branch into the current branch, which resulted in a fast-forward.
zh_HANS-CN: 将一个主题分支合并到当前分支，这导致了快进。

note: type: Plain text
en: But you decided that the topic branch is not ready for public consumption yet.  "pull" or "merge" always leaves the original tip of the current branch in `ORIG_HEAD`, so resetting hard to it brings your index file and the working tree back to that state, and resets the tip of the branch to that commit.
zh_HANS-CN: 但你决定这个主题分支还不适合公开使用。  "pull "或 "merge "总是在`ORIG_HEAD`中留下当前分支的原始提示，所以硬重置到它会使你的索引文件和工作树回到那个状态，并将分支的提示重置到那个提交。

note: type: Labeled list
en: Undo a merge or pull inside a dirty working tree
zh_HANS-CN: 撤消合并或拉动肮脏的工作树的行为

note: type: Plain text
en: Even if you may have local modifications in your working tree, you can safely say `git pull` when you know that the change in the other branch does not overlap with them.
zh_HANS-CN: 即使你的工作树中可能有局部的修改，当你知道另一个分支中的修改没有与之重叠时，你可以放心地说`git pull`。

note: type: Plain text
en: After inspecting the result of the merge, you may find that the change in the other branch is unsatisfactory.  Running `git reset --hard ORIG_HEAD` will let you go back to where you were, but it will discard your local changes, which you do not want.  `git reset --merge` keeps your local changes.
zh_HANS-CN: 在检查了合并的结果后，你可能会发现另一个分支的修改不尽人意。  运行`git reset --hard ORIG_HEAD`可以让你回到原来的位置，但它会丢弃你的本地修改，这是你不想要的。  `git reset --merge`会保留你的本地修改。

note: type: Labeled list
en: Interrupted workflow
zh_HANS-CN: 中断的工作流程

note: type: Plain text
en: Suppose you are interrupted by an urgent fix request while you are in the middle of a large change.  The files in your working tree are not in any shape to be committed yet, but you need to get to the other branch for a quick bugfix.
zh_HANS-CN: 假设你在做一个大的改动时被一个紧急的修复请求打断了。  你工作树上的文件还没到可以提交的地步，但你需要到另一个分支去快速修复错误。

note: type: delimited block -
en: $ git switch feature  ;# you were working in "feature" branch and
    $ work work work      ;# got interrupted
    $ git commit -a -m "snapshot WIP"                 <1>
    $ git switch master
    $ fix fix fix
    $ git commit ;# commit with real log
    $ git switch feature
    $ git reset --soft HEAD^ ;# go back to WIP state  <2>
    $ git reset                                       <3>
zh_HANS-CN: $ git switch feature ;# 你在 "feature "分支工作，并且
    $ work work work;# 被打断了
    $ git commit -a -m "snapshot WIP" <1
    $ git switch master
    $ fix fix fix
    $ git commit ;# 提交时有真实日志
    $ git switch feature
    $ git reset --soft HEAD^ ;# 回到 WIP 状态 <2>
    $ git reset <3>

note: type: Plain text
en: This commit will get blown away so a throw-away log message is OK.
zh_HANS-CN: 这个提交会被吹走，所以扔掉的日志信息是可以的。

note: type: Plain text
en: This removes the 'WIP' commit from the commit history, and sets your working tree to the state just before you made that snapshot.
zh_HANS-CN: 这将从提交历史中删除 "WIP "提交，并将你的工作树设置为刚刚做出快照之前的状态。

note: type: Plain text
en: At this point the index file still has all the WIP changes you committed as 'snapshot WIP'.  This updates the index to show your WIP files as uncommitted.
zh_HANS-CN: 在这一点上，索引文件仍然有你提交的所有WIP修改，作为 "快照WIP"。  这样就可以更新索引，将你的WIP文件显示为未提交的。

note: type: Plain text
en: See also linkgit:git-stash[1].
zh_HANS-CN: 也请参见 linkgit:git-stash[1]。

note: type: Labeled list
en: Reset a single file in the index
zh_HANS-CN: 重置索引中的单个文件

note: type: Plain text
en: Suppose you have added a file to your index, but later decide you do not want to add it to your commit. You can remove the file from the index while keeping your changes with git reset.
zh_HANS-CN: 假设你在索引中添加了一个文件，但后来决定不想把它加入你的提交中。你可以用git reset将该文件从索引中删除，同时保留你的修改。

note: type: delimited block -
en: $ git reset -- frotz.c                      <1>
    $ git commit -m "Commit files in index"     <2>
    $ git add frotz.c                           <3>
zh_HANS-CN: $ git reset -- frotz.c <1>.
    $ git commit -m "将文件存入索引" <2>
    $ git add frotz.c <3>

note: type: Plain text
en: This removes the file from the index while keeping it in the working directory.
zh_HANS-CN: 这将从索引中删除该文件，同时将其保留在工作目录中。

note: type: Plain text
en: This commits all other changes in the index.
zh_HANS-CN: 这将提交索引中的所有其他变化。

note: type: Plain text
en: Adds the file to the index again.
zh_HANS-CN: 再次将该文件添加到索引中。

note: type: Labeled list
en: Keep changes in working tree while discarding some previous commits
zh_HANS-CN: 在工作树中保留修改，同时丢弃一些以前的提交内容

note: type: Plain text
en: Suppose you are working on something and you commit it, and then you continue working a bit more, but now you think that what you have in your working tree should be in another branch that has nothing to do with what you committed previously. You can start a new branch and reset it while keeping the changes in your working tree.
zh_HANS-CN: 假设你正在做某件事，并提交了它，然后你又继续做了一会儿，但现在你认为你工作树中的内容应该在另一个分支中，而这个分支与你之前提交的内容毫无关系。你可以启动一个新的分支，并重置它，同时保留工作树中的变化。

note: type: Plain text
en: This commits your first edits in `branch1`.
zh_HANS-CN: 这将提交你在 `branch1`中的第一次编辑。

note: type: Plain text
en: In the ideal world, you could have realized that the earlier commit did not belong to the new topic when you created and switched to `branch2` (i.e. `git switch -c branch2 start`), but nobody is perfect.
zh_HANS-CN: 在理想的世界里，你可以在创建并切换到 "分支2"（即 "git switch -c branch2 start"）时意识到先前的提交不属于新主题，但人无完人。

note: type: Plain text
en: But you can use `reset --keep` to remove the unwanted commit after you switched to `branch2`.
zh_HANS-CN: 但你可以用`reset --keep`来删除你切换到`branch2`后不需要的提交。

note: type: Labeled list
en: Split a commit apart into a sequence of commits
zh_HANS-CN: 将一个提交分割成一连串的提交

note: type: Plain text
en: Suppose that you have created lots of logically separate changes and committed them together. Then, later you decide that it might be better to have each logical chunk associated with its own commit. You can use git reset to rewind history without changing the contents of your local files, and then successively use `git add -p` to interactively select which hunks to include into each commit, using `git commit -c` to pre-populate the commit message.
zh_HANS-CN: 假设你创建了很多逻辑上独立的修改，并将它们一起提交。然后，后来你决定让每个逻辑块与自己的提交相关联可能更好。你可以使用 git reset 来回溯历史，而不改变本地文件的内容，然后连续使用 `git add -p` 来交互式地选择哪些块包含在每个提交中，使用 `git commit -c` 来预先填入提交信息。

note: type: delimited block -
en: $ git reset -N HEAD^                        <1>
    $ git add -p                                <2>
    $ git diff --cached                         <3>
    $ git commit -c HEAD@{1}                    <4>
    ...                                         <5>
    $ git add ...                               <6>
    $ git diff --cached                         <7>
    $ git commit ...                            <8>
zh_HANS-CN: $ git reset -N HEAD^ <1>
    $ git add -p <2>
    $ git diff --cached <3>
    $ git commit -c HEAD@{1}.                    <4>
    ...                                         <5>
    $ git add ...                               <6>
    $ git diff --cached <7>
    $ git commit ...                            <8>

note: type: Plain text
en: First, reset the history back one commit so that we remove the original commit, but leave the working tree with all the changes. The -N ensures that any new files added with `HEAD` are still marked so that `git add -p` will find them.
zh_HANS-CN: 首先，将历史记录向后重设一次提交，这样我们就删除了原始提交，但保留了工作树上的所有修改。N确保任何用`HEAD`添加的新文件仍然被标记，以便`git add -p`能够找到它们。

note: type: Plain text
en: Next, we interactively select diff hunks to add using the `git add -p` facility. This will ask you about each diff hunk in sequence and you can use simple commands such as "yes, include this", "No don't include this" or even the very powerful "edit" facility.
zh_HANS-CN: 接下来，我们使用 "git add -p "工具，交互式地选择要添加的diff hunks。这将依次询问每个差异块，你可以使用简单的命令，如 "是，包括这个"，"不，不包括这个"，甚至是非常强大的 "编辑 "工具。

note: type: Plain text
en: Once satisfied with the hunks you want to include, you should verify what has been prepared for the first commit by using `git diff --cached`. This shows all the changes that have been moved into the index and are about to be committed.
zh_HANS-CN: 一旦对你想要包括的hunks感到满意，你应该通过使用`git diff --cached`来验证为第一次提交准备了什么。这将显示所有已经移入索引并即将提交的修改。

note: type: Plain text
en: Next, commit the changes stored in the index. The `-c` option specifies to pre-populate the commit message from the original message that you started with in the first commit. This is helpful to avoid retyping it. The `HEAD@{1}` is a special notation for the commit that `HEAD` used to be at prior to the original reset commit (1 change ago).  See linkgit:git-reflog[1] for more details. You may also use any other valid commit reference.
zh_HANS-CN: 接下来，提交存储在索引中的修改。`-c`选项指定从你第一次提交时的原始信息中预先填入提交信息。这对避免重复输入很有帮助。`HEAD@{1}`是一个特殊的符号，表示`HEAD`在最初的重置提交（1次变更前）之前曾经处于的提交。  更多细节见 linkgit:git-reflog[1]。你也可以使用任何其他有效的提交参考。

note: type: Plain text
en: You can repeat steps 2-4 multiple times to break the original code into any number of commits.
zh_HANS-CN: 你可以多次重复第2-4步，将原始代码分解成任意数量的提交。

note: type: Plain text
en: Now you've split out many of the changes into their own commits, and might no longer use the patch mode of `git add`, in order to select all remaining uncommitted changes.
zh_HANS-CN: 现在你已经把许多修改拆成了自己的提交，可能不再使用`git add`的补丁模式，以便选择所有剩余的未提交的修改。

note: type: Plain text
en: Once again, check to verify that you've included what you want to. You may also wish to verify that git diff doesn't show any remaining changes to be committed later.
zh_HANS-CN: 再一次检查以确认你已经包含了你想要的东西。你可能还想确认git diff没有显示任何剩余的修改，以便以后提交。

note: type: Plain text
en: And finally create the final commit.
zh_HANS-CN: 最后创建最后的提交。

note: type: Plain text
en: The tables below show what happens when running:
zh_HANS-CN: 下面的表格显示了运行时发生的情况：

note: type: Plain text
en: to reset the `HEAD` to another commit (`target`) with the different reset options depending on the state of the files.
zh_HANS-CN: 来重置`HEAD`到另一个提交（`target`），根据文件的状态，有不同的重置选项。

note: type: Plain text
en: In these tables, `A`, `B`, `C` and `D` are some different states of a file. For example, the first line of the first table means that if a file is in state `A` in the working tree, in state `B` in the index, in state `C` in `HEAD` and in state `D` in the target, then `git reset --soft target` will leave the file in the working tree in state `A` and in the index in state `B`.  It resets (i.e. moves) the `HEAD` (i.e. the tip of the current branch, if you are on one) to `target` (which has the file in state `D`).
zh_HANS-CN: 在这些表中，`A`、`B`、`C`和`D`是一个文件的一些不同状态。例如，第一个表格的第一行意味着如果一个文件在工作树中处于`A`状态，在索引中处于`B`状态，在`HEAD`中处于`C`状态，在目标中处于`D`状态，那么`git reset --soft target`将使文件在工作树中处于`A`状态，在索引中处于`B`状态。  它重设（即移动）`HEAD`（即当前分支的顶端，如果你在一个分支上）到`target`（它的文件处于`D`状态）。

note: type: delimited block .
en: working index HEAD target         working index HEAD
    ----------------------------------------------------
     A       B     C    D     --soft   A       B     D
    			  --mixed  A       D     D
    			  --hard   D       D     D
    			  --merge (disallowed)
    			  --keep  (disallowed)
zh_HANS-CN: 工作索引 HEAD 目标工作索引 HEAD
    ----------------------------------------------------
     A B C D --软的 A B D
    			  -混合型 A D D
    			  --硬的 D D D
    			  --合并 (不允许)
    			  --保持 (不允许)

note: type: delimited block .
en: working index HEAD target         working index HEAD
    ----------------------------------------------------
     A       B     C    C     --soft   A       B     C
    			  --mixed  A       C     C
    			  --hard   C       C     C
    			  --merge (disallowed)
    			  --keep   A       C     C
zh_HANS-CN: 工作索引 HEAD 目标工作索引 HEAD
    ----------------------------------------------------
     A B C C --软的 A B C
    			  -混合型 A C C
    			  --硬性 C C C
    			  --合并(不允许)
    			  --保持A C C

note: type: delimited block .
en: working index HEAD target         working index HEAD
    ----------------------------------------------------
     B       B     C    D     --soft   B       B     D
    			  --mixed  B       D     D
    			  --hard   D       D     D
    			  --merge  D       D     D
    			  --keep  (disallowed)
zh_HANS-CN: 工作索引 HEAD 目标工作索引 HEAD
    ----------------------------------------------------
     B B C D --软B B D
    			  -混合型 B D D
    			  --硬的 D D D
    			  --合并 D D D
    			  --保持(不允许)

note: type: delimited block .
en: working index HEAD target         working index HEAD
    ----------------------------------------------------
     B       B     C    C     --soft   B       B     C
    			  --mixed  B       C     C
    			  --hard   C       C     C
    			  --merge  C       C     C
    			  --keep   B       C     C
zh_HANS-CN: 工作索引 HEAD 目标工作索引 HEAD
    ----------------------------------------------------
     B B C C --软B B C
    			  -混合型 B C C
    			  --硬性 C C C
    			  --合并 C C C
    			  --保持B C C

note: type: delimited block .
en: working index HEAD target         working index HEAD
    ----------------------------------------------------
     B       C     C    D     --soft   B       C     D
    			  --mixed  B       D     D
    			  --hard   D       D     D
    			  --merge (disallowed)
    			  --keep  (disallowed)
zh_HANS-CN: 工作索引 HEAD 目标工作索引 HEAD
    ----------------------------------------------------
     B C C D --软B C D
    			  -混合型 B D D
    			  --硬的 D D D
    			  --合并 (不允许)
    			  --保持 (不允许)

note: type: delimited block .
en: working index HEAD target         working index HEAD
    ----------------------------------------------------
     B       C     C    C     --soft   B       C     C
    			  --mixed  B       C     C
    			  --hard   C       C     C
    			  --merge  B       C     C
    			  --keep   B       C     C
zh_HANS-CN: 工作索引 HEAD 目标工作索引 HEAD
    ----------------------------------------------------
     B C C C --软B C C
    			  -混合型 B C C
    			  --硬性 C C C
    			  --合并 B C C
    			  --保持B C C

note: type: Plain text
en: `reset --merge` is meant to be used when resetting out of a conflicted merge. Any mergy operation guarantees that the working tree file that is involved in the merge does not have a local change with respect to the index before it starts, and that it writes the result out to the working tree. So if we see some difference between the index and the target and also between the index and the working tree, then it means that we are not resetting out from a state that a mergy operation left after failing with a conflict. That is why we disallow `--merge` option in this case.
zh_HANS-CN: `reset --merge`是指在重设冲突的合并时使用。任何合并操作都会保证参与合并的工作树文件在开始之前没有相对于索引的局部变化，并且会将结果写入工作树。因此，如果我们看到索引和目标之间，以及索引和工作树之间有一些差异，那么这意味着我们没有从一个合并操作失败后留下的冲突状态中重新设置出来。这就是为什么我们在这种情况下不允许使用`--合并`选项。

note: type: Plain text
en: `reset --keep` is meant to be used when removing some of the last commits in the current branch while keeping changes in the working tree. If there could be conflicts between the changes in the commit we want to remove and the changes in the working tree we want to keep, the reset is disallowed. That's why it is disallowed if there are both changes between the working tree and `HEAD`, and between `HEAD` and the target. To be safe, it is also disallowed when there are unmerged entries.
zh_HANS-CN: `reset --keep 意思是在删除当前分支中的一些最后的提交，同时保留工作树中的修改时使用。如果我们想删除的提交和我们想保留的工作树上的修改之间可能存在冲突，那么重置是不允许的。这就是为什么如果工作树和`HEAD'之间，以及`HEAD'和目标之间都有变化，那么就不允许重置。为了安全起见，当有未合并的条目时，也不允许这样做。

note: type: Plain text
en: The following tables show what happens when there are unmerged entries:
zh_HANS-CN: 下表显示了有未合并的条目时发生的情况。

note: type: delimited block .
en: working index HEAD target         working index HEAD
    ----------------------------------------------------
     X       U     A    B     --soft  (disallowed)
    			  --mixed  X       B     B
    			  --hard   B       B     B
    			  --merge  B       B     B
    			  --keep  (disallowed)
zh_HANS-CN: 工作索引 HEAD 目标工作索引 HEAD
    ----------------------------------------------------
     X U A B --软（不允许）。
    			  --混合型 X B B
    			  --硬的 B B B
    			  --合并 B B B
    			  --保持(不允许)

note: type: delimited block .
en: working index HEAD target         working index HEAD
    ----------------------------------------------------
     X       U     A    A     --soft  (disallowed)
    			  --mixed  X       A     A
    			  --hard   A       A     A
    			  --merge  A       A     A
    			  --keep  (disallowed)
zh_HANS-CN: 工作索引 HEAD 目标工作索引 HEAD
    ----------------------------------------------------
     X U A A --软(不允许)
    			  --混合型 X A A
    			  --硬性 A A A
    			  --合并 A A A
    			  --保持(不允许)

note: type: Plain text
en: `X` means any state and `U` means an unmerged index.
zh_HANS-CN: `X`指任何状态，`U`指未合并的索引。

note: type: Plain text
en: git-restore - Restore working tree files
zh_HANS-CN: git-restore - 恢复工作树文件

note: type: Plain text
en: 'git restore' [<options>] [--source=<tree>] [--staged] [--worktree] [--] <pathspec>...
    'git restore' [<options>] [--source=<tree>] [--staged] [--worktree] --pathspec-from-file=<file> [--pathspec-file-nul]
    'git restore' (-p|--patch) [<options>] [--source=<tree>] [--staged] [--worktree] [--] [<pathspec>...]
zh_HANS-CN: 'git restore' [<options>] [--source=<tree>] [--staged] [--worktree] [--] <pathspec>...
    'git restore' [<options>] [--source=<tree>] [--staged] [--worktree] --pathspec-from-file=<file> [--pathspec-file-nul] 。
    'git restore' (-p|--patch) [<options>] [--source=<tree>] [--staged] [--worktree] [--] [<pathspec>...]

note: type: Plain text
en: Restore specified paths in the working tree with some contents from a restore source. If a path is tracked but does not exist in the restore source, it will be removed to match the source.
zh_HANS-CN: 用还原源的一些内容还原工作树中的指定路径。如果一个路径被跟踪，但在还原源中不存在，它将被删除以匹配源。

note: type: Plain text
en: The command can also be used to restore the content in the index with `--staged`, or restore both the working tree and the index with `--staged --worktree`.
zh_HANS-CN: 该命令还可以用来用`--staged`恢复索引中的内容，或者用`--staged --worktree`同时恢复工作树和索引。

note: type: Plain text
en: By default, if `--staged` is given, the contents are restored from `HEAD`, otherwise from the index. Use `--source` to restore from a different commit.
zh_HANS-CN: 默认情况下，如果给了`--staged`，内容将从`HEAD`恢复，否则从索引恢复。使用`--source`来恢复不同的提交。

note: type: Plain text
en: THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
zh_HANS-CN: 这个命令是试验性的。其行为可能会改变。

note: type: Labeled list
en: --source=<tree>
zh_HANS-CN: --source=<tree>（来源）。

note: type: Plain text
en: Restore the working tree files with the content from the given tree. It is common to specify the source tree by naming a commit, branch or tag associated with it.
zh_HANS-CN: 用给定树的内容恢复工作树的文件。通常是通过命名与之相关的提交、分支或标签来指定源树。

note: type: Plain text
en: If not specified, the contents are restored from `HEAD` if `--staged` is given, otherwise from the index.
zh_HANS-CN: 如果没有指定，如果给了`--staged`，则从`HEAD`恢复内容，否则从索引恢复。

note: type: Plain text
en: Interactively select hunks in the difference between the restore source and the restore location. See the ``Interactive Mode'' section of linkgit:git-add[1] to learn how to operate the `--patch` mode.
zh_HANS-CN: 交互式地选择还原源和还原位置之间的差异中的猎物。参见 linkgit:git-add[1] 的 "互动模式 "部分，了解如何操作"--补丁 "模式。

note: type: Plain text
en: Note that `--patch` can accept no pathspec and will prompt to restore all modified paths.
zh_HANS-CN: 请注意，`--patch`可以不接受任何pathspec，并会提示恢复所有修改的路径。

note: type: Plain text
en: Specify the restore location. If neither option is specified, by default the working tree is restored. Specifying `--staged` will only restore the index. Specifying both restores both.
zh_HANS-CN: 指定恢复的位置。如果两个选项都没有指定，默认情况下会还原工作树。指定`--staged`将只恢复索引。指定两个选项将同时还原。

note: type: Plain text
en: Quiet, suppress feedback messages. Implies `--no-progress`.
zh_HANS-CN: 安静，抑制反馈信息。意味着"--没有进展"。

note: type: Plain text
en: When restoring files in the working tree from the index, use stage #2 ('ours') or #3 ('theirs') for unmerged paths.
zh_HANS-CN: 当从索引中恢复工作树中的文件时，对未合并的路径使用阶段#2（'我们的'）或#3（'他们的'）。

note: type: Plain text
en: Note that during `git rebase` and `git pull --rebase`, 'ours' and 'theirs' may appear swapped. See the explanation of the same options in linkgit:git-checkout[1] for details.
zh_HANS-CN: 注意，在`git rebase`和`git pull --rebase`过程中，'我们的'和'他们的'可能会出现互换。详见 linkgit:git-checkout[1] 中对相同选项的解释。

note: type: Plain text
en: When restoring files on the working tree from the index, recreate the conflicted merge in the unmerged paths.
zh_HANS-CN: 当从索引恢复工作树上的文件时，在未合并的路径中重新创建冲突的合并。

note: type: Plain text
en: When restoring files on the working tree from the index, do not abort the operation if there are unmerged entries and neither `--ours`, `--theirs`, `--merge` or `--conflict` is specified. Unmerged paths on the working tree are left alone.
zh_HANS-CN: 当从索引中恢复工作树上的文件时，如果有未合并的条目，并且没有指定`--我们的`、`--他们的`、`--合并`或`--冲突`，不要中止操作。工作树上未合并的路径将被忽略。

note: type: Plain text
en: In sparse checkout mode, by default is to only update entries matched by `<pathspec>` and sparse patterns in $GIT_DIR/info/sparse-checkout. This option ignores the sparse patterns and unconditionally restores any files in `<pathspec>`.
zh_HANS-CN: 在稀疏检出模式下，默认情况下只更新由`<pathspec>`和$GIT_DIR/info/sparse-checkout中稀疏模式匹配的条目。这个选项忽略了稀疏模式，无条件地恢复了`<pathspec>`中的任何文件。

note: type: Plain text
en: If `<pathspec>` names an active submodule and the restore location includes the working tree, the submodule will only be updated if this option is given, in which case its working tree will be restored to the commit recorded in the superproject, and any local modifications overwritten. If nothing (or `--no-recurse-submodules`) is used, submodules working trees will not be updated. Just like linkgit:git-checkout[1], this will detach `HEAD` of the submodule.
zh_HANS-CN: 如果`<pathspec>`命名了一个活动的子模块，并且恢复的位置包括工作树，只有在给出这个选项的情况下，子模块才会被更新，在这种情况下，它的工作树将被恢复到超级项目中记录的提交，并且任何本地修改都会被覆盖。如果什么都不使用（或`--no-recurse-submodules`），子模块的工作树将不会被更新。就像linkgit:git-checkout[1]，这将分离子模块的`HEAD`。

note: type: Plain text
en: In overlay mode, the command never removes files when restoring. In no-overlay mode, tracked files that do not appear in the `--source` tree are removed, to make them match `<tree>` exactly. The default is no-overlay mode.
zh_HANS-CN: 在覆盖模式下，该命令在恢复时不会删除文件。在无覆盖模式下，不出现在"--源 "树中的被追踪文件会被删除，以使它们与"<tree>"完全匹配。默认是无覆盖模式。

note: type: Plain text
en: The following sequence switches to the `master` branch, reverts the `Makefile` to two revisions back, deletes hello.c by mistake, and gets it back from the index.
zh_HANS-CN: 下面的序列切换到 "master "分支，将 "Makefile "恢复到两个修订版，错误地删除了hello.c，并从索引中取回它。

note: type: Plain text
en: restore hello.c from the index
zh_HANS-CN: 从索引中恢复 hello.c

note: type: Plain text
en: If you want to restore _all_ C source files to match the version in the index, you can say
zh_HANS-CN: 如果你想恢复_所有的C源文件，使之与索引中的版本一致，你可以说

note: type: Plain text
en: Note the quotes around `*.c`.  The file `hello.c` will also be restored, even though it is no longer in the working tree, because the file globbing is used to match entries in the index (not in the working tree by the shell).
zh_HANS-CN: 注意 "*.c "周围的引号。  文件`hello.c`也将被恢复，尽管它已经不在工作树中了，因为文件globbing是用来匹配索引中的条目的（不是由shell在工作树中）。

note: type: Plain text
en: To restore all files in the current directory
zh_HANS-CN: 要恢复当前目录下的所有文件

note: type: Plain text
en: or to restore all working tree files with 'top' pathspec magic (see linkgit:gitglossary[7])
zh_HANS-CN: 或者用'top'pathspec魔法恢复所有工作树文件（见linkgit:gitglossary[7]）。

note: type: Plain text
en: To restore a file in the index to match the version in `HEAD` (this is the same as using linkgit:git-reset[1])
zh_HANS-CN: 将索引中的文件恢复到与`HEAD`中的版本一致（这与使用linkgit:git-reset[1]相同）。

note: type: Plain text
en: or you can restore both the index and the working tree (this the same as using linkgit:git-checkout[1])
zh_HANS-CN: 或者你可以同时恢复索引和工作树（这与使用linkgit:git-checkout[1]相同）。

note: type: Plain text
en: or the short form which is more practical but less readable:
zh_HANS-CN: 或更实用但可读性较差的简短形式。

note: type: Plain text
en: git-revert - Revert some existing commits
zh_HANS-CN: git-revert - 还原某些现有提交

note: type: Plain text
en: Given one or more existing commits, revert the changes that the related patches introduce, and record some new commits that record them.  This requires your working tree to be clean (no modifications from the HEAD commit).
zh_HANS-CN: 给定一个或多个现有提交，还原相关补丁引入的更改，并记录一些新提交来记录这些更改。 这要求你的工作区是干净的（没有对 HEAD 提交的修改）。

note: type: Plain text
en: Note: 'git revert' is used to record some new commits to reverse the effect of some earlier commits (often only a faulty one).  If you want to throw away all uncommitted changes in your working directory, you should see linkgit:git-reset[1], particularly the `--hard` option.  If you want to extract specific files as they were in another commit, you should see linkgit:git-restore[1], specifically the `--source` option. Take care with these alternatives as both will discard uncommitted changes in your working directory.
zh_HANS-CN: 注意：'git revert' 用于记录一些新的提交，以扭转先前提交（通常只是错误的提交）的影响。 如果您想丢弃工作目录中所有未提交的改动，请参阅 linkgit:git-reset[1]，尤其是 `--hard` 选项。 如果你想提取其他提交中的特定文件，请参阅 linkgit:git-restore[1]，尤其是 `--source`选项。使用这些选项时要小心，因为它们都会丢弃工作目录中未提交的改动。

note: type: Plain text
en: Commits to revert.  For a more complete list of ways to spell commit names, see linkgit:gitrevisions[7].  Sets of commits can also be given but no traversal is done by default, see linkgit:git-rev-list[1] and its `--no-walk` option.
zh_HANS-CN: 要还原的提交。 更完整的提交名拼写方式，请参见 linkgit:gitrevisions[7]。 也可以给出提交集，但默认情况下不进行遍历，参见 linkgit:git-rev-list[1] 及其 `--no-walk`选项。

note: type: Plain text
en: With this option, 'git revert' will let you edit the commit message prior to committing the revert. This is the default if you run the command from a terminal.
zh_HANS-CN: 有了这个选项，'git revert' 会让你在提交之前编辑提交信息。如果从终端运行该命令，默认情况下也是如此。

note: type: Labeled list
en: -m parent-number
zh_HANS-CN: -m 父编号

note: type: Plain text
en: Usually you cannot revert a merge because you do not know which side of the merge should be considered the mainline.  This option specifies the parent number (starting from 1) of the mainline and allows revert to reverse the change relative to the specified parent.
zh_HANS-CN: 通常情况下，由于不知道合并的哪一方应被视为主线，因此无法还原合并。 该选项指定了主线的父线编号（从 1 开始），允许还原指令相对于指定的父线反向更改。

note: type: Plain text
en: Reverting a merge commit declares that you will never want the tree changes brought in by the merge.  As a result, later merges will only bring in tree changes introduced by commits that are not ancestors of the previously reverted merge.  This may or may not be what you want.
zh_HANS-CN: 还原合并提交就意味着你永远不需要合并带来的目录树变化。 因此，以后的合并只会引入目录树变化，而这些变化不是由先前已还原合并的祖先提交引入的。 这可能是你想要的，也可能不是。

note: type: Plain text
en: See the link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] for more details.
zh_HANS-CN: 更多详情，请参阅 link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge 如何操作]。

note: type: Plain text
en: With this option, 'git revert' will not start the commit message editor.
zh_HANS-CN: 使用该选项后，'git revert' 将不会启动提交信息编辑器。

note: type: Plain text
en: Usually the command automatically creates some commits with commit log messages stating which commits were reverted.  This flag applies the changes necessary to revert the named commits to your working tree and the index, but does not make the commits.  In addition, when this option is used, your index does not have to match the HEAD commit.  The revert is done against the beginning state of your index.
zh_HANS-CN: 通常，该命令会自动创建一些提交，并在提交日志信息中说明哪些提交被还原。 该标记会对工作区和索引进行必要的修改，以还原指定的提交，但不会进行提交。 此外，使用该选项时，索引不必与 HEAD 提交相匹配。 还原是针对索引的起始状态进行的。

note: type: Plain text
en: This is useful when reverting more than one commits' effect to your index in a row.
zh_HANS-CN: 这在连续恢复多个提交对索引的影响时非常有用。

note: type: Plain text
en: Instead of starting the body of the log message with "This reverts <full object name of the commit being reverted>.", refer to the commit using "--pretty=reference" format (cf. linkgit:git-log[1]).  The `revert.reference` configuration variable can be used to enable this option by default.
zh_HANS-CN: 而不是以 “他还原了 <完整的提交对象名称>。” 作为日志信息的开头，而是使用 "--pretty=reference" 格式来引用提交（参见 linkgit:git-log[1]）。 `revert.reference` 配置变量可用于默认启用此选项。

note: type: Plain text
en: Revert the changes specified by the fourth last commit in HEAD and create a new commit with the reverted changes.
zh_HANS-CN: 还原 HEAD 中倒数第四个提交指定的更改，并创建一个包含还原更改的新提交。

note: type: Plain text
en: Revert the changes done by commits from the fifth last commit in master (included) to the third last commit in master (included), but do not create any commit with the reverted changes. The revert only modifies the working tree and the index.
zh_HANS-CN: 将 master 中倒数第五次提交（包含）到 master 中倒数第三次提交（包含）的改动还原，但不创建任何包含还原改动的提交。还原只会修改工作区和索引。

note: type: Plain text
en: git-rev-list - Lists commit objects in reverse chronological order
zh_HANS-CN: git-rev-list 按照时间倒序列出提交对象

note: type: Plain text
en: Print the list of commits reachable from the current branch.
zh_HANS-CN: 打印可从当前分支访问的提交列表。

note: type: Labeled list
en: --exclude=<glob-pattern>
zh_HANS-CN: --exclude=<glob-pattern>（排除）。

note: type: Plain text
en: Do not include refs matching '<glob-pattern>' that the next `--all`, `--branches`, `--tags`, `--remotes`, or `--glob` would otherwise consider. Repetitions of this option accumulate exclusion patterns up to the next `--all`, `--branches`, `--tags`, `--remotes`, or `--glob` option (other options or arguments do not clear accumulated patterns).
zh_HANS-CN: 不包括匹配"<glob-pattern>"的参考文献，否则下一个`--all`、`--branches`、`--tags`、`--remotes`或`--glob`会考虑这些参考文献。重复这个选项可以累积排除模式，直到下一个`----all`、`---branches`、`---tags`、`---remotes`或`---glob`选项（其他选项或参数不清除累积模式）。

note: type: Plain text
en: The patterns given should not begin with `refs/heads`, `refs/tags`, or `refs/remotes` when applied to `--branches`, `--tags`, or `--remotes`, respectively, and they must begin with `refs/` when applied to `--glob` or `--all`. If a trailing '/{asterisk}' is intended, it must be given explicitly.
zh_HANS-CN: 当应用于"--分支"、"--标签 "或"--远程 "时，给出的模式不应该以 "refs/heads"、"refs/tags "或 "refs/remotes "开头，而当应用于"--glob "或 "all "时，必须以 "refs/"开头。如果打算使用尾部的"/{asterisk}"，必须明确给出。

note: type: Plain text
en: Remove files matching pathspec from the index, or from the working tree and the index. `git rm` will not remove a file from just your working directory. (There is no option to remove a file only from the working tree and yet keep it in the index; use `/bin/rm` if you want to do that.) The files being removed have to be identical to the tip of the branch, and no updates to their contents can be staged in the index, though that default behavior can be overridden with the `-f` option.  When `--cached` is given, the staged content has to match either the tip of the branch or the file on disk, allowing the file to be removed from just the index. When sparse-checkouts are in use (see linkgit:git-sparse-checkout[1]), `git rm` will only remove paths within the sparse-checkout patterns.
zh_HANS-CN: 从索引中，或从工作树和索引中删除与pathspec匹配的文件。`git rm`不会只从你的工作目录中删除一个文件。(没有选项可以只从工作树中删除一个文件，但在索引中保留它；如果你想这样做，就用`/bin/rm`)。被删除的文件必须与分支的顶端相同，而且它们的内容不能在索引中进行更新，尽管可以用`-f`选项覆盖这一默认行为。  当给定`--cached`时，缓存的内容必须与分支的顶端或磁盘上的文件相匹配，允许文件只从索引中被删除。当使用稀疏检查时（见linkgit:git-sparse-checkout[1]），`git rm`将只删除稀疏检查模式内的路径。

note: type: Plain text
en: Files to remove.  A leading directory name (e.g. `dir` to remove `dir/file1` and `dir/file2`) can be given to remove all files in the directory, and recursively all sub-directories, but this requires the `-r` option to be explicitly given.
zh_HANS-CN: 要删除的文件。  可以给一个领先的目录名（例如，`dir`删除`dir/file1`和`dir/file2`）来删除该目录下的所有文件，并递归所有子目录，但这需要明确给出`-r`选项。

note: type: Plain text
en: The command removes only the paths that are known to Git.
zh_HANS-CN: 该命令只删除Git已知的路径。

note: type: Plain text
en: File globbing matches across directory boundaries.  Thus, given two directories `d` and `d2`, there is a difference between using `git rm 'd*'` and `git rm 'd/*'`, as the former will also remove all of directory `d2`.
zh_HANS-CN: 文件球化可以跨越目录边界进行匹配。  因此，给定两个目录`d`和`d2`，使用`git rm 'd*'`和`git rm 'd/*'`是有区别的，因为前者会同时删除`d2`目录的所有内容。

note: type: Plain text
en: Override the up-to-date check.
zh_HANS-CN: 覆盖最新的检查。

note: type: Plain text
en: Don't actually remove any file(s).  Instead, just show if they exist in the index and would otherwise be removed by the command.
zh_HANS-CN: 实际上不要删除任何文件。  相反，只是显示它们是否存在于索引中，否则会被命令删除。

note: type: Plain text
en: Allow recursive removal when a leading directory name is given.
zh_HANS-CN: 当给出一个领先的目录名称时，允许递归删除。

note: type: Plain text
en: Use this option to unstage and remove paths only from the index.  Working tree files, whether modified or not, will be left alone.
zh_HANS-CN: 使用这个选项，只从索引中解开阶段并删除路径。  工作树文件，无论是否被修改过，都将被单独留下。

note: type: Plain text
en: Exit with a zero status even if no files matched.
zh_HANS-CN: 即使没有文件匹配，也以零状态退出。

note: type: Title -
en: REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM
zh_HANS-CN: 删除从文件系统中消失的文件

note: type: Plain text
en: There is no option for `git rm` to remove from the index only the paths that have disappeared from the filesystem. However, depending on the use case, there are several ways that can be done.
zh_HANS-CN: `git rm`没有选项可以从索引中只删除已经从文件系统中消失的路径。然而，根据不同的使用情况，有几种方法可以做到这一点。

note: type: Title ~
en: Using ``git commit -a''
zh_HANS-CN: 使用``git commit -a''

note: type: Plain text
en: If you intend that your next commit should record all modifications of tracked files in the working tree and record all removals of files that have been removed from the working tree with `rm` (as opposed to `git rm`), use `git commit -a`, as it will automatically notice and record all removals.  You can also have a similar effect without committing by using `git add -u`.
zh_HANS-CN: 如果你想让你的下一次提交记录工作树中所有被跟踪的文件的修改，并记录所有用`rm`从工作树中删除的文件（而不是`git rm`），请使用`git commit -a`，它将自动注意并记录所有的删除。  你也可以通过使用`git add -u`在不提交的情况下获得类似的效果。

note: type: Title ~
en: Using ``git add -A''
zh_HANS-CN: 使用``git add -A''

note: type: Plain text
en: When accepting a new code drop for a vendor branch, you probably want to record both the removal of paths and additions of new paths as well as modifications of existing paths.
zh_HANS-CN: 当接受一个供应商分支的新代码投放时，你可能想同时记录删除路径和增加新路径以及修改现有路径的内容。

note: type: Plain text
en: Typically you would first remove all tracked files from the working tree using this command:
zh_HANS-CN: 通常情况下，你会先用这个命令从工作树上删除所有被追踪的文件。

note: type: Plain text
en: and then untar the new code in the working tree. Alternately you could 'rsync' the changes into the working tree.
zh_HANS-CN: 然后解开工作树上的新代码。另外，你也可以通过 "rsync "把修改的内容放到工作树上。

note: type: Plain text
en: After that, the easiest way to record all removals, additions, and modifications in the working tree is:
zh_HANS-CN: 之后，记录工作树中所有的删除、添加和修改的最简单方法是。

note: type: Plain text
en: If all you really want to do is to remove from the index the files that are no longer present in the working tree (perhaps because your working tree is dirty so that you cannot use `git commit -a`), use the following command:
zh_HANS-CN: 如果你真正想做的只是从索引中删除那些不再出现在工作树中的文件（也许是因为你的工作树很脏，所以你不能使用`git commit -a`），使用以下命令。

note: type: Plain text
en: Only submodules using a gitfile (which means they were cloned with a Git version 1.7.8 or newer) will be removed from the work tree, as their repository lives inside the .git directory of the superproject. If a submodule (or one of those nested inside it)  still uses a .git directory, `git rm` will move the submodules git directory into the superprojects git directory to protect the submodule's history. If it exists the submodule.<name> section in the linkgit:gitmodules[5] file will also be removed and that file will be staged (unless --cached or -n are used).
zh_HANS-CN: 只有使用 gitfile 的子模块（这意味着它们是用 1.7.8 或更新的 Git 版本克隆的）才会从工作树中移除，因为它们的仓库住在超级项目的 .git 目录中。如果一个子模块（或嵌套在它里面的一个）仍然使用.git目录，`git rm`将把子模块的git目录移到超级项目的git目录中，以保护子模块的历史。如果它存在，linkgit:gitmodules[5]文件中的submodule.<name>部分也将被移除，该文件将被暂存（除非使用了-cached或-n）。

note: type: Plain text
en: A submodule is considered up to date when the HEAD is the same as recorded in the index, no tracked files are modified and no untracked files that aren't ignored are present in the submodules work tree.  Ignored files are deemed expendable and won't stop a submodule's work tree from being removed.
zh_HANS-CN: 当HEAD与索引中记录的相同时，一个子模块被认为是最新的，没有跟踪的文件被修改，在子模块的工作树中没有没有被忽略的未跟踪的文件。  忽略的文件被认为是可消耗的，不会阻止一个子模块的工作树被删除。

note: type: Plain text
en: If you only want to remove the local checkout of a submodule from your work tree without committing the removal, use linkgit:git-submodule[1] `deinit` instead. Also see linkgit:gitsubmodules[7] for details on submodule removal.
zh_HANS-CN: 如果你只想从你的工作树中移除一个子模块的本地签出而不提交移除，使用linkgit:git-submodule[1] `deinit`代替。也请看 linkgit:gitsubmodules[7] 了解关于子模块移除的细节。

note: type: Plain text
en: Removes all `*.txt` files from the index that are under the `Documentation` directory and any of its subdirectories.
zh_HANS-CN: 从索引中删除所有`*.txt`文件，这些文件在`Documentation`目录和它的任何子目录下。

note: type: Plain text
en: Note that the asterisk `*` is quoted from the shell in this example; this lets Git, and not the shell, expand the pathnames of files and subdirectories under the `Documentation/` directory.
zh_HANS-CN: 注意，在这个例子中，星号`*`被引自shell；这让Git，而不是shell，扩展`Documentation/`目录下的文件和子目录的路径名。

note: type: Plain text
en: Because this example lets the shell expand the asterisk (i.e. you are listing the files explicitly), it does not remove `subdir/git-foo.sh`.
zh_HANS-CN: 因为这个例子让shell展开星号（即你明确列出了文件），它没有删除`subdir/git-foo.sh`。

note: type: Plain text
en: Each time a superproject update removes a populated submodule (e.g. when switching between commits before and after the removal) a stale submodule checkout will remain in the old location. Removing the old directory is only safe when it uses a gitfile, as otherwise the history of the submodule will be deleted too. This step will be obsolete when recursive submodule update has been implemented.
zh_HANS-CN: 每次超级项目更新删除一个已填充的子模块（例如，在删除前后的提交之间切换时），一个陈旧的子模块检出将保留在旧的位置。只有在使用gitfile时，删除旧目录才是安全的，否则子模块的历史也会被删除。当递归子模块更新被实施后，这个步骤将被淘汰。

note: type: Plain text
en: 'git send-email' [<options>] <file|directory>...
    'git send-email' [<options>] <format-patch options>
    'git send-email' --dump-aliases
zh_HANS-CN: 'git send-email' [<选项>] <文件或是目录>...
    git send-email' [<选项>] <格式补丁选项>
    git send-email' --dump-aliases

note: type: Plain text
en: Takes the patches given on the command line and emails them out.  Patches can be specified as files, directories (which will send all files in the directory), or directly as a revision list.  In the last case, any format accepted by linkgit:git-format-patch[1] can be passed to git send-email, as well as options understood by linkgit:git-format-patch[1].
zh_HANS-CN: 获取命令行中给出的补丁并将其发送出去。 补丁可以指定为文件、目录（将发送目录中的所有文件），或直接指定为修订列表。 在最后一种情况下，linkgit:git-format-patch[1] 接受的任何格式，以及 linkgit:git-format-patch[1] 可以理解的选项，都可以传递给 git send-email。

note: type: Plain text
en: The header of the email is configurable via command-line options.  If not specified on the command line, the user will be prompted with a ReadLine enabled interface to provide the necessary information.
zh_HANS-CN: 电子邮件的标题可通过命令行选项进行配置。 如果未在命令行中指定，系统将在启用读取行的界面上提示用户提供必要的信息。

note: type: Plain text
en: There are two formats accepted for patch files:
zh_HANS-CN: 补丁文件有两种格式：

note: type: Plain text
en: mbox format files
zh_HANS-CN: mbox 格式文件

note: type: Plain text
en: This is what linkgit:git-format-patch[1] generates.  Most headers and MIME formatting are ignored.
zh_HANS-CN: 这就是 linkgit:git-format-patch[1] 生成的内容。 大部分头文件和 MIME 格式都会被忽略。

note: type: Plain text
en: The original format used by Greg Kroah-Hartman's 'send_lots_of_email.pl' script
zh_HANS-CN: Greg Kroah-Hartman 的 'send_lots_of_email.pl' 脚本使用的原始格式

note: type: Plain text
en: This format expects the first line of the file to contain the "Cc:" value and the "Subject:" of the message as the second line.
zh_HANS-CN: 这种格式希望文件的第一行包含 "Cc:"（抄送）值，第二行包含邮件的 "主题："。

note: type: Plain text
en: Review and edit each patch you're about to send. Default is the value of `sendemail.annotate`. See the CONFIGURATION section for `sendemail.multiEdit`.
zh_HANS-CN: 审核并编辑您即将发送的每个补丁。默认为 `sendemail.annotate` 的值。有关 `sendemail.multiEdit` 请参阅配置部分。

note: type: Plain text
en: Specify a "Bcc:" value for each email. Default is the value of `sendemail.bcc`.
zh_HANS-CN: 为每封电子邮件指定一个 "Bcc："（密送）值。默认为 `sendemail.bcc` 的值。

note: type: Plain text
en: This option may be specified multiple times.
zh_HANS-CN: 该选项可指定多次。

note: type: Plain text
en: Specify a starting "Cc:" value for each email.  Default is the value of `sendemail.cc`.
zh_HANS-CN: 为每封电子邮件指定一个起始 "Cc："（抄送）值。 默认值为 `sendemail.cc`。

note: type: Plain text
en: Invoke a text editor (see GIT_EDITOR in linkgit:git-var[1])  to edit an introductory message for the patch series.
zh_HANS-CN: 调用文本编辑器（参见 linkgit:git-var[1] 中的 GIT_EDITOR）编辑补丁系列的介绍信息。

note: type: Plain text
en: When `--compose` is used, git send-email will use the From, Subject, and In-Reply-To headers specified in the message. If the body of the message (what you type after the headers and a blank line) only contains blank (or Git: prefixed) lines, the summary won't be sent, but From, Subject, and In-Reply-To headers will be used unless they are removed.
zh_HANS-CN: 使用 `--compose` 时，git send-email 将使用邮件中指定的发件人、主题和收件人标题。如果邮件正文（在标题和空行之后输入的内容）只包含空行（或 Git: 前缀），摘要将不会被发送，但发件人、主题和收件人标题将被使用，除非它们被移除。

note: type: Plain text
en: Missing From or In-Reply-To headers will be prompted for.
zh_HANS-CN: 将提示是否有缺失的发件人或收件人标题。

note: type: Plain text
en: See the CONFIGURATION section for `sendemail.multiEdit`.
zh_HANS-CN: 请参阅 `sendemail.multiEdit` 的配置部分。

note: type: Plain text
en: Specify the sender of the emails.  If not specified on the command line, the value of the `sendemail.from` configuration option is used.  If neither the command-line option nor `sendemail.from` are set, then the user will be prompted for the value.  The default for the prompt will be the value of GIT_AUTHOR_IDENT, or GIT_COMMITTER_IDENT if that is not set, as returned by "git var -l".
zh_HANS-CN: 指定电子邮件的发件人。 如果未在命令行中指定，则使用配置选项 `sendemail.from` 的值。 如果命令行选项和 `sendemail.from` 均未设置，则会提示用户输入值。 提示的默认值是 GIT_AUTHOR_IDENT 的值，如果没有设置 GIT_COMMITTER_IDENT，则使用 "git var -l" 返回的值。

note: type: Plain text
en: Specify the address where replies from recipients should go to.  Use this if replies to messages should go to another address than what is specified with the --from parameter.
zh_HANS-CN: 指定收件人回复的地址。 如果邮件的回复地址与 --from 参数指定的地址不同，请使用此参数。

note: type: Plain text
en: Make the first mail (or all the mails with `--no-thread`) appear as a reply to the given Message-ID, which avoids breaking threads to provide a new patch series.  The second and subsequent emails will be sent as replies according to the `--[no-]chain-reply-to` setting.
zh_HANS-CN: 使第一封邮件（或所有带有 `--[no-thread]`（无线程）的邮件）作为给定 Message-ID 的回复出现，从而避免为提供新的补丁系列而中断线程。 第二封及其后的邮件将根据 "--[no-]chain-reply-to "设置作为回复发送。

note: type: Plain text
en: So for example when `--thread` and `--no-chain-reply-to` are specified, the second and subsequent patches will be replies to the first one like in the illustration below where `[PATCH v2 0/3]` is in reply to `[PATCH 0/2]`:
zh_HANS-CN: 例如，如果指定了 `--thread` 和 `--no-chain-reply-to`，则第二个和后续补丁将是对第一个补丁的回复，如下图所示，`[PATCH v2 0/3]` 是对 `[PATCH 0/2]` 的回复：

note: type: Plain text
en: Only necessary if --compose is also set.  If --compose is not set, this will be prompted for.
zh_HANS-CN: 只有同时设置了 --compose 时才有必要。 如果未设置 --compose，则会提示。

note: type: Plain text
en: Specify the initial subject of the email thread.  Only necessary if --compose is also set.  If --compose is not set, this will be prompted for.
zh_HANS-CN: 指定电子邮件线程的初始主题。 只有同时设置了 --compose 时才需要。 如果未设置 --compose，系统将提示输入。

note: type: Plain text
en: Specify the primary recipient of the emails generated. Generally, this will be the upstream maintainer of the project involved. Default is the value of the `sendemail.to` configuration value; if that is unspecified, and --to-cmd is not specified, this will be prompted for.
zh_HANS-CN: 指定所生成电子邮件的主要收件人。一般来说，这将是相关项目的上游维护者。默认值是 `sendemail.to` 配置值的值，如果未指定该值，且未指定 --to-cmd 参数，则会提示该值。

note: type: Plain text
en: When encountering a non-ASCII message or subject that does not declare its encoding, add headers/quoting to indicate it is encoded in <encoding>.  Default is the value of the 'sendemail.assume8bitEncoding'; if that is unspecified, this will be prompted for if any non-ASCII files are encountered.
zh_HANS-CN: 当遇到未声明其编码的非 ASCII 邮件或主题时，添加标头/引号以表明它是以 <编码> 编码的。 默认值是 'sendemail.assume8bitEncoding ' 的值；如果未指定该值，则在遇到任何非 ASCII 文件时会提示使用该值。

note: type: Plain text
en: Note that no attempts whatsoever are made to validate the encoding.
zh_HANS-CN: 请注意，我们不会尝试验证编码。

note: type: Plain text
en: Specify encoding of compose message. Default is the value of the 'sendemail.composeencoding'; if that is unspecified, UTF-8 is assumed.
zh_HANS-CN: 指定撰写邮件的编码。默认值是 'sendemail.composingencoding' 的值；如果未指定，则假定为 UTF-8。

note: type: Plain text
en: Specify the transfer encoding to be used to send the message over SMTP.  7bit will fail upon encountering a non-ASCII message.  quoted-printable can be useful when the repository contains files that contain carriage returns, but makes the raw patch email file (as saved from a MUA) much harder to inspect manually.  base64 is even more fool proof, but also even more opaque.  auto will use 8bit when possible, and quoted-printable otherwise.
zh_HANS-CN: 指定通过 SMTP 发送邮件时使用的传输编码。 如仓本库中包含含有回车的文件，quoted-printable 会很有用，但会使原始补丁邮件文件（从 MUA 中保存）更难手动检查。

note: type: Plain text
en: Default is the value of the `sendemail.transferEncoding` configuration value; if that is unspecified, default to `auto`.
zh_HANS-CN: 默认为 `sendemail.transferEncoding` 配置值的值，如果未指定，则默认为 `auto`。

note: type: Plain text
en: Add (or prevent adding) the "X-Mailer:" header.  By default, the header is added, but it can be turned off by setting the `sendemail.xmailer` configuration variable to `false`.
zh_HANS-CN: 添加（或阻止添加）"X-Mailer: " 标头。 默认情况下会添加，但可以通过将配置变量 `sendemail.xmailer` 设为 `false`来关闭。

note: type: Plain text
en: Specify the envelope sender used to send the emails.  This is useful if your default address is not the address that is subscribed to a list. In order to use the 'From' address, set the value to "auto". If you use the sendmail binary, you must have suitable privileges for the -f parameter.  Default is the value of the `sendemail.envelopeSender` configuration variable; if that is unspecified, choosing the envelope sender is left to your MTA.
zh_HANS-CN: 指定用于发送电子邮件的信封发件人。 如果您的默认地址不是订阅列表的地址，这将非常有用。为了使用 'From'（发件人）地址，请将值设置为 "auto"。如果使用 sendmail 二进制文件，必须为 -f 参数设置适当的权限。 默认值是 `sendemail.envelopeSender` 配置变量的值；如果未指定，则由 MTA 选择信封发件人。

note: type: Plain text
en: Specify a command to run to send the email. The command should be sendmail-like; specifically, it must support the `-i` option.  The command will be executed in the shell if necessary.  Default is the value of `sendemail.sendmailcmd`.  If unspecified, and if --smtp-server is also unspecified, git-send-email will search for `sendmail` in `/usr/sbin`, `/usr/lib` and $PATH.
zh_HANS-CN: 指定发送电子邮件时要运行的命令。该命令应类似于 sendmail；具体来说，它必须支持 `-i` 选项。 如有必要，该命令将在 shell 中执行。 默认值为 `sendemail.sendmailcmd`。 如果未指定，并且 --smtp-server 也未指定，git-send-email 将在 `/usr/sbin`、`/usr/lib` 和 $PATH 中搜索 `sendmail`。

note: type: Plain text
en: Specify in what way encrypting begins for the SMTP connection.  Valid values are 'ssl' and 'tls'. Any other value reverts to plain (unencrypted) SMTP, which defaults to port 25.  Despite the names, both values will use the same newer version of TLS, but for historic reasons have these names. 'ssl' refers to "implicit" encryption (sometimes called SMTPS), that uses port 465 by default.  'tls' refers to "explicit" encryption (often known as STARTTLS), that uses port 25 by default. Other ports might be used by the SMTP server, which are not the default. Commonly found alternative port for 'tls' and unencrypted is 587. You need to check your provider's documentation or your server configuration to make sure for your own case. Default is the value of `sendemail.smtpEncryption`.
zh_HANS-CN: 指定 SMTP 连接的加密方式。 有效值为 'ssl' 和 'tls'。任何其他值都将恢复为普通（未加密）SMTP，默认端口为 25。 尽管名称不同，但这两个值都将使用相同的 TLS 更新版本，只是由于历史原因才使用了这些名称。'ssl' 指 “隐式” 加密（有时称为 SMTPS），默认使用 465 端口。 'tls' 指 “显式” 加密（通常称为 STARTTLS），默认使用 25 端口。SMTP 服务器还可能使用其他端口，但这些端口并非默认端口。常见的 'tls' 和未加密的替代端口是 587。您需要查看供应商的文档或服务器配置，以确定自己的情况。默认值为 `sendemail.smtpEncryption`。

note: type: Plain text
en: Specifies the Fully Qualified Domain Name (FQDN) used in the HELO/EHLO command to the SMTP server.  Some servers require the FQDN to match your IP address.  If not set, git send-email attempts to determine your FQDN automatically.  Default is the value of `sendemail.smtpDomain`.
zh_HANS-CN: 指定发送到 SMTP 服务器的 HELO/EHLO 命令中使用的完全限定域名 (FQDN)。 有些服务器要求 FQDN 与您的 IP 地址匹配。 如果未设置，git send-email 会尝试自动确定您的 FQDN。 默认值为 `sendemail.smtpDomain`。

note: type: Labeled list
en: --smtp-auth=<mechanisms>
zh_HANS-CN: --smtp-auth=<验证机制>

note: type: Plain text
en: Whitespace-separated list of allowed SMTP-AUTH mechanisms. This setting forces using only the listed mechanisms. Example:
zh_HANS-CN: 以空白分隔的允许 SMTP-AUTH 机制列表。此设置只强制使用列出的机制。例如：

note: type: Plain text
en: If at least one of the specified mechanisms matches the ones advertised by the SMTP server and if it is supported by the utilized SASL library, the mechanism is used for authentication. If neither 'sendemail.smtpAuth' nor `--smtp-auth` is specified, all mechanisms supported by the SASL library can be used. The special value 'none' maybe specified to completely disable authentication independently of `--smtp-user`
zh_HANS-CN: 如果指定的机制中至少有一种与 SMTP 服务器公布的机制相匹配，且受所使用的 SASL 库支持，则该机制将用于身份验证。如果既未指定 'sendemail.smtpAuth'，也未指定 `--smtp-auth`参数，则可使用 SASL 库支持的所有机制。如果指定了特殊值 'none'，则可以完全禁用与 `--smtp-user` 参数无关的身份验证

note: type: Plain text
en: Password for SMTP-AUTH. The argument is optional: If no argument is specified, then the empty string is used as the password. Default is the value of `sendemail.smtpPass`, however `--smtp-pass` always overrides this value.
zh_HANS-CN: SMTP-AUTH 的密码。参数为可选参数：如果未指定参数，则使用空字符串作为密码。默认值是 `sendemail.smtpPass` 的值，但 `--smtp-pass` 始终会覆盖该值。

note: type: Plain text
en: Furthermore, passwords need not be specified in configuration files or on the command line. If a username has been specified (with `--smtp-user` or a `sendemail.smtpUser`), but no password has been specified (with `--smtp-pass` or `sendemail.smtpPass`), then a password is obtained using 'git-credential'.
zh_HANS-CN: 此外，无需在配置文件或命令行中指定密码。如果已指定用户名（使用 `--smtp-user` 或 `sendemail.smtpUser`），但未指定密码（使用 `--smtp-pass` 或 `sendemail.smtpPass`），则使用 'git-credential' 获取密码。

note: type: Plain text
en: Disable SMTP authentication. Short hand for `--smtp-auth=none`
zh_HANS-CN: 禁用 SMTP 验证。`--smtp-auth=none` 的简称

note: type: Labeled list
en: --smtp-server=<host>
zh_HANS-CN: --smtp-server=<主机>

note: type: Plain text
en: If set, specifies the outgoing SMTP server to use (e.g.  `smtp.example.com` or a raw IP address).  If unspecified, and if `--sendmail-cmd` is also unspecified, the default is to search for `sendmail` in `/usr/sbin`, `/usr/lib` and $PATH if such a program is available, falling back to `localhost` otherwise.
zh_HANS-CN: 如果设置，则指定要使用的外发 SMTP 服务器（例如 `smtp.example.com` 或原始 IP 地址）。 如果未指定，而且`-sendmail-cmd` 也未指定，默认情况下会在`/usr/sbin`、`/usr/lib` 和 $PATH 中搜索 `sendmail`（如果有），否则会返回到 `localhost`。

note: type: Plain text
en: For backward compatibility, this option can also specify a full pathname of a sendmail-like program instead; the program must support the `-i` option.  This method does not support passing arguments or using plain command names.  For those use cases, consider using `--sendmail-cmd` instead.
zh_HANS-CN: 为了向后兼容，该选项也可以指定一个类似于 sendmail 的程序的完整路径名；该程序必须支持 `-i` 选项。 这种方法不支持传递参数或使用纯命令名。 在这些情况下，请考虑使用 `-sendmail-cmd`。

note: type: Plain text
en: Specifies a port different from the default port (SMTP servers typically listen to smtp port 25, but may also listen to submission port 587, or the common SSL smtp port 465); symbolic port names (e.g. "submission" instead of 587)  are also accepted. The port can also be set with the `sendemail.smtpServerPort` configuration variable.
zh_HANS-CN: 指定一个不同于默认端口的端口（SMTP 服务器通常监听 smtp 端口 25，但也可能监听 submission 端口 587 或常用的 SSL smtp 端口 465）；也接受符号端口名称（如用 "submission" 代替 587）。端口也可以通过 `sendemail.smtpServerPort` 配置变量来设置。

note: type: Labeled list
en: --smtp-server-option=<option>
zh_HANS-CN: --smtp-server-option=<选项>

note: type: Plain text
en: If set, specifies the outgoing SMTP server option to use.  Default value can be specified by the `sendemail.smtpServerOption` configuration option.
zh_HANS-CN: 如果设置，则指定要使用的外发 SMTP 服务器选项。 默认值可由 `sendemail.smtpServerOption` 配置选项指定。

note: type: Plain text
en: The --smtp-server-option option must be repeated for each option you want to pass to the server. Likewise, different lines in the configuration files must be used for each option.
zh_HANS-CN: 对于要传递给服务器的每个选项，都必须重复使用 --smtp-server-option 选项。同样，每个选项必须在配置文件中使用不同的行。

note: type: Plain text
en: Legacy alias for '--smtp-encryption ssl'.
zh_HANS-CN: '--smtp-encryption ssl' 的遗留别名。

note: type: Plain text
en: Path to a store of trusted CA certificates for SMTP SSL/TLS certificate validation (either a directory that has been processed by 'c_rehash', or a single file containing one or more PEM format certificates concatenated together: see verify(1) -CAfile and -CApath for more information on these). Set it to an empty string to disable certificate verification. Defaults to the value of the `sendemail.smtpsslcertpath` configuration variable, if set, or the backing SSL library's compiled-in default otherwise (which should be the best choice on most platforms).
zh_HANS-CN: 用于 SMTP SSL/TLS 证书验证的可信 CA 证书存储的路径（可以是已被 'c_rehash' 处理过的目录，也可以是包含一个或多个 PEM 格式证书的单个文件：请参阅 verify(1) -CAfile 和 -CApath，了解更多相关信息）。将其设置为空字符串可禁用证书验证。如果设置了，默认值为 `sendemail.smtpsslcertpath` 配置变量的值，否则默认值为备用 SSL 库编译后的默认值（这应该是大多数平台上的最佳选择）。

note: type: Plain text
en: Username for SMTP-AUTH. Default is the value of `sendemail.smtpUser`; if a username is not specified (with `--smtp-user` or `sendemail.smtpUser`), then authentication is not attempted.
zh_HANS-CN: SMTP-AUTH 的用户名。默认值是 `sendemail.smtpUser` 的值；如果未指定用户名（使用 `--smtp-user` 或 `sendemail.smtpUser`），则不会尝试验证。

note: type: Plain text
en: Enable (1) or disable (0) debug output. If enabled, SMTP commands and replies will be printed. Useful to debug TLS connection and authentication problems.
zh_HANS-CN: 启用 (1) 或禁用 (0) 调试输出。如果启用，将打印 SMTP 命令和回复。用于调试 TLS 连接和身份验证问题。

note: type: Labeled list
en: --batch-size=<num>
zh_HANS-CN: --batch-size=<数值>

note: type: Plain text
en: Some email servers (e.g. smtp.163.com) limit the number emails to be sent per session (connection) and this will lead to a failure when sending many messages.  With this option, send-email will disconnect after sending $<num> messages and wait for a few seconds (see --relogin-delay)  and reconnect, to work around such a limit.  You may want to use some form of credential helper to avoid having to retype your password every time this happens.  Defaults to the `sendemail.smtpBatchSize` configuration variable.
zh_HANS-CN: 某些邮件服务器（如 smtp.163.com）限制每次会话（连接）发送的邮件数量，这将导致发送大量邮件时出现故障。 有了这个选项，send-email 会在发送 $<数值> 邮件后断开连接，等待几秒钟（参见 --relogin-delay ），然后重新连接，以规避这种限制。 你可能需要使用某种形式的凭证助手，以避免每次都要重新输入密码。 默认为 `sendemail.smtpBatchSize` 配置变量。

note: type: Plain text
en: Waiting $<int> seconds before reconnecting to SMTP server. Used together with --batch-size option.  Defaults to the `sendemail.smtpReloginDelay` configuration variable.
zh_HANS-CN: 重新连接 SMTP 服务器前等待 $<整数> 秒。与 --batch-size 选项一起使用。 默认为 `sendemail.smtpReloginDelay` 配置变量。

note: type: Title ~
en: Automating
zh_HANS-CN: 自动化

note: type: Plain text
en: Clears any list of "To:", "Cc:", "Bcc:" addresses previously set via config.
zh_HANS-CN: 清除之前通过配置设置的 "To:"（收件人）、"Cc:"（抄送人）、"Bcc:"（密送人）地址列表。

note: type: Plain text
en: Clears the previously read value of `sendemail.identity` set via config, if any.
zh_HANS-CN: 清除先前读取的通过配置设置的 `sendemail.identity` 值（如果有）。

note: type: Plain text
en: Specify a command to execute once per patch file which should generate patch file specific "To:" entries.  Output of this command must be single email address per line.  Default is the value of 'sendemail.tocmd' configuration value.
zh_HANS-CN: 指定每个补丁文件执行一次的命令，该命令应生成补丁文件特定的 "To:"（收件人）条目。 该命令的输出必须是每行一个电子邮件地址。 默认值为 'sendemail.tocmd' 配置值。

note: type: Plain text
en: Specify a command to execute once per patch file which should generate patch file specific "Cc:" entries.  Output of this command must be single email address per line.  Default is the value of `sendemail.ccCmd` configuration value.
zh_HANS-CN: 指定每个补丁文件执行一次的命令，该命令应生成补丁文件特定的 "Cc:"（抄送人）条目。 该命令的输出必须是每行一个电子邮件地址。 默认值为 `sendemail.ccCmd` 配置值。

note: type: Plain text
en: Specify a command that is executed once per outgoing message and output RFC 2822 style header lines to be inserted into them. When the `sendemail.headerCmd` configuration variable is set, its value is always used. When --header-cmd is provided at the command line, its value takes precedence over the `sendemail.headerCmd` configuration variable.
zh_HANS-CN: 指定一条命令，每封发送邮件执行一次，并输出 RFC 2822 样式的标题行插入其中。如果设置了 `sendemail.headerCmd` 配置变量，则始终使用其值。在命令行中提供 --header-cmd 参数时，其值优先于 `sendemail.headerCmd` 配置变量。

note: type: Plain text
en: Disable any header command in use.
zh_HANS-CN: 禁用任何正在使用的标题命令。

note: type: Plain text
en: If this is set, each email will be sent as a reply to the previous email sent.  If disabled with "--no-chain-reply-to", all emails after the first will be sent as replies to the first email sent.  When using this, it is recommended that the first file given be an overview of the entire patch series. Disabled by default, but the `sendemail.chainReplyTo` configuration variable can be used to enable it.
zh_HANS-CN: 如果设置了此项，每封邮件都将作为对前一封邮件的回复发送。 如果使用 "--no-chain-reply-to" 禁用该选项，则第一封邮件之后的所有邮件都将作为对第一封邮件的回复发送。 使用此功能时，建议给出的第一个文件是整个补丁系列的概述。默认情况下已禁用，但可以使用 `sendemail.chainReplyTo` 配置变量启用它。

note: type: Plain text
en: A configuration identity. When given, causes values in the 'sendemail.<identity>' subsection to take precedence over values in the 'sendemail' section. The default identity is the value of `sendemail.identity`.
zh_HANS-CN: 配置标识。给定后，'sendemail.<认证>' 分节中的值将优先于 'sendemail' 部分中的值。默认身份是 `sendemail.identity` 的值。

note: type: Plain text
en: If this is set, add emails found in the `Signed-off-by` trailer or Cc: lines to the cc list. Default is the value of `sendemail.signedoffbycc` configuration value; if that is unspecified, default to --signed-off-by-cc.
zh_HANS-CN: 如果设置了此选项，请将“ Signed-off-by”预告或抄送：行中的电子邮件添加到抄送列表中。默认为`sendmail.signedoffbycc`配置值的值；如果未指定，则默认为--signed-off-by-cc。

note: type: Plain text
en: If this is set, emails found in Cc: headers in the first patch of the series (typically the cover letter) are added to the cc list for each email set. Default is the value of 'sendemail.cccover' configuration value; if that is unspecified, default to --no-cc-cover.
zh_HANS-CN: 如果设置了此项，在系列邮件的第一个补丁（通常是封面信）的抄送标题中找到的电子邮件将被添加到每个邮件集的抄送列表中。默认值为 'sendemail.cccover' 配置值；如果未指定，默认值为 --no-cc-cover。

note: type: Plain text
en: If this is set, emails found in To: headers in the first patch of the series (typically the cover letter) are added to the to list for each email set. Default is the value of 'sendemail.tocover' configuration value; if that is unspecified, default to --no-to-cover.
zh_HANS-CN: 如果设置了此项，在系列邮件的第一个补丁（通常是封面信函）的收件人标题中找到的邮件将被添加到每个邮件集的收件人列表中。默认值为 'sendemail.tocover' 配置值；如果未指定，默认值为--no-to-cover。

note: type: Plain text
en: Specify an additional category of recipients to suppress the auto-cc of:
zh_HANS-CN: 指定一个额外的收件人类别，以禁止自动收件：

note: type: Plain text
en: 'author' will avoid including the patch author.
zh_HANS-CN: 'author' 将避免包含补丁作者。

note: type: Plain text
en: 'self' will avoid including the sender.
zh_HANS-CN: 'self' 将避免包括发件人。

note: type: Plain text
en: 'cc' will avoid including anyone mentioned in Cc lines in the patch header except for self (use 'self' for that).
zh_HANS-CN: 'cc' 将避免包括补丁头中抄送行提到的任何人，但自己除外（使用 'self' 即可）。

note: type: Plain text
en: 'bodycc' will avoid including anyone mentioned in Cc lines in the patch body (commit message) except for self (use 'self' for that).
zh_HANS-CN: 'bodycc' 将避免在补丁正文（提交信息）中包含抄送行中提到的任何人，但自己除外（为此使用 'self'）。

note: type: Plain text
en: 'misc-by' will avoid including anyone mentioned in Acked-by, Reviewed-by, Tested-by and other "-by" lines in the patch body, except Signed-off-by (use 'sob' for that).
zh_HANS-CN: 'misc-by' 将避免包含补丁正文中的 Acked-by、Reviewed-by、Tested-by 和其他 "-by " 行提到的任何人，但 Signed-off-by 除外（使用 'sob' ）。

note: type: Plain text
en: 'cccmd' will avoid running the --cc-cmd.
zh_HANS-CN: 'cccmd' 将避免运行 --cc-cmd 命令。

note: type: Plain text
en: 'body' is equivalent to 'sob' + 'bodycc' + 'misc-by'.
zh_HANS-CN: 'body' 等同于 'sob' + 'bodycc' + 'misc-by'。

note: type: Plain text
en: 'all' will suppress all auto cc values.
zh_HANS-CN: 'all' 会抑制所有自动抄送值。

note: type: Plain text
en: Default is the value of `sendemail.suppresscc` configuration value; if that is unspecified, default to 'self' if --suppress-from is specified, as well as 'body' if --no-signed-off-cc is specified.
zh_HANS-CN: 默认值是 `sendemail.suppresscc` 配置值的值，如果未指定，则在指定 --suppress-from 参数时默认为 'self'，在指定 --no-signed-off-cc 参数时默认为 'body'。

note: type: Plain text
en: If this is set, do not add the From: address to the cc: list.  Default is the value of `sendemail.suppressFrom` configuration value; if that is unspecified, default to --no-suppress-from.
zh_HANS-CN: 如果设置了此项，则不会将发件人地址添加到抄送地址列表中。 默认值是 `sendemail.suppressFrom` 配置值的值，如果未指定，则默认为 --no-suppress-from 参数。

note: type: Plain text
en: If this is set, the In-Reply-To and References headers will be added to each email sent.  Whether each mail refers to the previous email (`deep` threading per 'git format-patch' wording) or to the first email (`shallow` threading) is governed by "--[no-]chain-reply-to".
zh_HANS-CN: 如果设置了此项，每封邮件都会添加 In-Reply-To 和 References 标头。 每封邮件是引用前一封邮件（'git format-patch' 中的 `deep` 线程），还是引用第一封邮件（`shallow` 线程），由 "--[no-]chain-reply-to" 决定。

note: type: Plain text
en: It is up to the user to ensure that no In-Reply-To header already exists when 'git send-email' is asked to add it (especially note that 'git format-patch' can be configured to do the threading itself).  Failure to do so may not produce the expected result in the recipient's MUA.
zh_HANS-CN: 当 'git send-email' 被要求添加 In-Reply-To 头信息时，用户应确保该头条信息不存在（特别要注意的是，'git format-patch' 可被配置为自行进行线程处理）。 否则可能无法在收件人的 MUA 中产生预期结果。

note: type: Title ~
en: Administering
zh_HANS-CN: 管理

note: type: Plain text
en: Confirm just before sending:
zh_HANS-CN: 发送前确认：

note: type: Plain text
en: 'always' will always confirm before sending
zh_HANS-CN: 'always' 总会在发送前确认

note: type: Plain text
en: 'never' will never confirm before sending
zh_HANS-CN: 'never' 在发送前不会确认

note: type: Plain text
en: 'cc' will confirm before sending when send-email has automatically added addresses from the patch to the Cc list
zh_HANS-CN: 如果发送邮件已自动将补丁中的地址添加到抄送列表中，'cc' 将在发送前进行确认

note: type: Plain text
en: 'compose' will confirm before sending the first message when using --compose.
zh_HANS-CN: 当使用 --compose 选项时，'compose' 会在发送第一条信息前进行确认。

note: type: Plain text
en: 'auto' is equivalent to 'cc' + 'compose'
zh_HANS-CN: 'auto' 等同于 'cc' + 'compose'

note: type: Plain text
en: Default is the value of `sendemail.confirm` configuration value; if that is unspecified, default to 'auto' unless any of the suppress options have been specified, in which case default to 'compose'.
zh_HANS-CN: 默认值是 `sendemail.confirm` 配置值的值，如果未指定，则默认为 'auto'，除非指定了任何抑制选项，在这种情况下默认为 'compose'。

note: type: Plain text
en: Do everything except actually send the emails.
zh_HANS-CN: 除了实际发送邮件外，什么都做。

note: type: Plain text
en: When an argument may be understood either as a reference or as a file name, choose to understand it as a format-patch argument (`--format-patch`)  or as a file name (`--no-format-patch`). By default, when such a conflict occurs, git send-email will fail.
zh_HANS-CN: 当参数可以理解为引用或文件名时，选择将其理解为格式补丁参数（`--format-patch`）或文件名（`--no-format-patch`）。默认情况下，当出现这种冲突时，git send-email 操作将失败。

note: type: Plain text
en: Make git-send-email less verbose.  One line per email should be all that is output.
zh_HANS-CN: 让 git-send-email 少输出一些。 每封邮件只输出一行即可。

note: type: Plain text
en: Perform sanity checks on patches.  Currently, validation means the following:
zh_HANS-CN: 对补丁进行正确性检查。 目前，验证的含义如下：

note: type: Plain text
en: Invoke the sendemail-validate hook if present (see linkgit:githooks[5]).
zh_HANS-CN: 调用 sendemail-validate （发送邮件验证）钩子（如果存在）（参见 linkgit:githooks[5])。

note: type: Plain text
en: Warn of patches that contain lines longer than
zh_HANS-CN: 警告含有长于

note: type: Plain text
en: 998 characters unless a suitable transfer encoding
    ('auto', 'base64', or 'quoted-printable') is used;
    this is due to SMTP limits as described by
    http://www.ietf.org/rfc/rfc5322.txt.
zh_HANS-CN: 998 个字符，除非使用了合适的传输编码
    ('auto'、'base64' 或 'quoted-printable'）都会使用；
    这是因为 SMTP 的限制，如
    http://www.ietf.org/rfc/rfc5322.txt。

note: type: Plain text
en: Default is the value of `sendemail.validate`; if this is not set, default to `--validate`.
zh_HANS-CN: 默认为 `sendemail.validate` 的值；如果未设置，则默认为 `--validate` 参数。

note: type: Plain text
en: Send emails even if safety checks would prevent it.
zh_HANS-CN: 即使安全检查不允许，也要发送电子邮件。

note: type: Plain text
en: Instead of the normal operation, dump the shorthand alias names from the configured alias file(s), one per line in alphabetical order. Note, this only includes the alias name and not its expanded email addresses.  See 'sendemail.aliasesfile' for more information about aliases.
zh_HANS-CN: 不执行正常操作，而是从配置的别名文件中按字母顺序每行转存一个速记别名。注意，这只包括别名，不包括其扩展的电子邮件地址。 有关别名的更多信息，请参阅 'sendemail.aliasesfile'。

note: type: Title ~
en: Use gmail as the smtp server
zh_HANS-CN: 使用 gmail 作为 smtp 服务器

note: type: Plain text
en: To use 'git send-email' to send your patches through the GMail SMTP server, edit ~/.gitconfig to specify your account settings:
zh_HANS-CN: 要使用 'git send-email' 通过 GMail SMTP 服务器发送补丁，请编辑 ~/.gitconfig 指定账户设置：

note: type: Plain text
en: If you have multi-factor authentication set up on your Gmail account, you can generate an app-specific password for use with 'git send-email'. Visit https://security.google.com/settings/security/apppasswords to create it.
zh_HANS-CN: 如果您的 Gmail 账户设置了多因素身份验证，您可以生成一个应用程序专用密码，供 'git send-email' 使用。请访问 https://security.google.com/settings/security/apppasswords 创建密码。

note: type: Plain text
en: Once your commits are ready to be sent to the mailing list, run the following commands:
zh_HANS-CN: 一旦您的提交已准备好发送至邮件列表，请运行以下命令：

note: type: Plain text
en: The first time you run it, you will be prompted for your credentials.  Enter the app-specific or your regular password as appropriate.  If you have credential helper configured (see linkgit:git-credential[1]), the password will be saved in the credential store so you won't have to type it the next time.
zh_HANS-CN: 首次运行时，系统会提示您输入凭据。 请根据情况输入特定于应用程序的密码或常规密码。 如果配置了凭据助手（参见 linkgit:git-credential[1]），密码会保存在凭据存储区，下次就不用再输入了。

note: type: Plain text
en: Note: the following core Perl modules that may be installed with your distribution of Perl are required: MIME::Base64, MIME::QuotedPrint, Net::Domain and Net::SMTP.  These additional Perl modules are also required: Authen::SASL and Mail::Address.
zh_HANS-CN: 注意：需要安装以下 Perl 核心模块，这些模块可能已随 Perl 发行版一起安装： MIME::Base64、MIME::QuotedPrint、Net::Domain 和 Net::SMTP。 还需要安装这些额外的 Perl 模块： Authen::SASL 和 Mail::Address。

note: type: Plain text
en: git-send-pack - Push objects over Git protocol to another repository
zh_HANS-CN: git-send-pack - 通过 Git 协议将对象推送到另一个仓库

note: type: Plain text
en: git-shell - Restricted login shell for Git-only SSH access
zh_HANS-CN: git-shell - 仅限 Git SSH 访问的受限登录 shell

note: type: Plain text
en: 'chsh' -s $(command -v git-shell) <user>
    'git clone' <user>`@localhost:/path/to/repo.git`
    'ssh' <user>`@localhost`
zh_HANS-CN: 'chsh' -s $(command -v git-shell) <用户>
    'git clone' <用户>`@localhost:/path/to/repo.git`
    'ssh' <用户>`@localhost`

note: type: Plain text
en: This is a login shell for SSH accounts to provide restricted Git access.  It permits execution only of server-side Git commands implementing the pull/push functionality, plus custom commands present in a subdirectory named `git-shell-commands` in the user's home directory.
zh_HANS-CN: 这是 SSH 账户的登录 shell，提供受限的 Git 访问权限。 它只允许执行实现拉/推功能的服务器端 Git 命令，以及用户主目录中名为 `git-shell-commands` 子目录下的自定义命令。

note: type: Labeled list
en: 'git receive-pack <argument>'
zh_HANS-CN: 'git receive-pack <参数>'

note: type: Labeled list
en: 'git upload-pack <argument>'
zh_HANS-CN: 'git upload-pack <参数>'

note: type: Labeled list
en: 'git upload-archive <argument>'
zh_HANS-CN: 'git upload-archive <参数>'

note: type: Plain text
en: Call the corresponding server-side command to support the client's 'git push', 'git fetch', or 'git archive --remote' request.
zh_HANS-CN: 调用相应的服务器端命令，以支持客户端的 'git push'、'git fetch' 或 'git archive --remote' 请求。

note: type: Labeled list
en: 'cvs server'
zh_HANS-CN: ‘cvs 服务器’

note: type: Plain text
en: Imitate a CVS server.  See linkgit:git-cvsserver[1].
zh_HANS-CN: 模仿 CVS 服务器。 参见 linkgit:git-cvsserver[1]。

note: type: Plain text
en: If a `~/git-shell-commands` directory is present, 'git shell' will also handle other, custom commands by running "`git-shell-commands/<command> <arguments>`" from the user's home directory.
zh_HANS-CN: 如果有 `~/git-shell-commands` 目录，'git shell' 也会处理其他自定义命令，方法是从用户的主目录运行 "`git-shell-commands/<命令> <参数>`"。

note: type: Title -
en: INTERACTIVE USE
zh_HANS-CN: 交互式使用

note: type: Plain text
en: By default, the commands above can be executed only with the `-c` option; the shell is not interactive.
zh_HANS-CN: 默认情况下，上述命令只能通过 `-c` 选项执行；shell 不是交互式的。

note: type: Plain text
en: If a `~/git-shell-commands` directory is present, 'git shell' can also be run interactively (with no arguments).  If a `help` command is present in the `git-shell-commands` directory, it is run to provide the user with an overview of allowed actions.  Then a "git> " prompt is presented at which one can enter any of the commands from the `git-shell-commands` directory, or `exit` to close the connection.
zh_HANS-CN: 如果有 `~/git-shell-commands` 目录，'git shell' 也可以交互式运行（不带参数）。 如果 `git-shell-commands` 目录中有 `help` 命令，则会运行该命令向用户提供允许操作的概览。 然后会出现 "git>" 提示，用户可以在此输入`git-shell-commands`目录下的任何命令，或`exit`关闭连接。

note: type: Plain text
en: Generally this mode is used as an administrative interface to allow users to list repositories they have access to, create, delete, or rename repositories, or change repository descriptions and permissions.
zh_HANS-CN: 一般情况下，该模式用作管理界面，允许用户列出他们可以访问的资源库，创建、删除或重命名资源库，或更改资源库说明和权限。

note: type: Plain text
en: If a `no-interactive-login` command exists, then it is run and the interactive shell is aborted.
zh_HANS-CN: 如果存在 `no-interactive-login` 命令，则运行该命令并终止交互式 shell。

note: type: Plain text
en: To disable interactive logins, displaying a greeting instead:
zh_HANS-CN: 禁用交互式登录，显示问候语：

note: type: Plain text
en: To enable git-cvsserver access (which should generally have the `no-interactive-login` example above as a prerequisite, as creating the git-shell-commands directory allows interactive logins):
zh_HANS-CN: 要启用 git-cvsserver 访问权限（一般应以上面的 `no-interactive-login` 示例为前提，因为创建 git-shell-commands 目录允许交互式登录）：

note: type: Plain text
en: Summarizes 'git log' output in a format suitable for inclusion in release announcements. Each commit will be grouped by author and title.
zh_HANS-CN: 将'git log'输出总结为适合纳入发布公告的格式。每个提交将按作者和标题分组。

note: type: Plain text
en: Additionally, "[PATCH]" will be stripped from the commit description.
zh_HANS-CN: 此外，"[PATCH]"将从提交描述中被剥离。

note: type: Plain text
en: If no revisions are passed on the command line and either standard input is not a terminal or there is no current branch, 'git shortlog' will output a summary of the log read from standard input, without reference to the current repository.
zh_HANS-CN: 如果命令行上没有传递修订版，而且标准输入不是终端，或者没有当前分支，'git shortlog'将输出从标准输入读取的日志摘要，而不参考当前版本库。

note: type: Plain text
en: Sort output according to the number of commits per author instead of author alphabetic order.
zh_HANS-CN: 根据每个作者的提交数量对输出进行排序，而不是按照作者的字母顺序。

note: type: Plain text
en: Suppress commit description and provide a commit count summary only.
zh_HANS-CN: 抑制提交描述，只提供提交计数摘要。

note: type: Plain text
en: Show the email address of each author.
zh_HANS-CN: 显示每个作者的电子邮件地址。

note: type: Plain text
en: Instead of the commit subject, use some other information to describe each commit.  '<format>' can be any string accepted by the `--format` option of 'git log', such as '* [%h] %s'.  (See the "PRETTY FORMATS" section of linkgit:git-log[1].)
zh_HANS-CN: 代替提交主题，使用一些其他信息来描述每个提交。  <format>'可以是任何被'git log'的`--format'选项接受的字符串，比如'* [%h] %s'。  参见linkgit:git-log[1]的 "PRETTY FORMATS "部分）。

note: type: Plain text
en: Each pretty-printed commit will be rewrapped before it is shown.
zh_HANS-CN: 每个漂亮的印刷品承诺在展示之前都会被重新包装。

note: type: Plain text
en: Show dates formatted according to the given date string. (See the `--date` option in the "Commit Formatting" section of linkgit:git-log[1]). Useful with `--group=format:<format>`.
zh_HANS-CN: 显示根据给定日期字符串格式化的日期。(参见linkgit:git-log[1]中 "提交格式化"部分的`--date`选项）。与 `--group=format:<format>`一起使用会非常有用。

note: type: Plain text
en: Group commits based on `<type>`. If no `--group` option is specified, the default is `author`. `<type>` is one of:
zh_HANS-CN: 根据`<类型>`对提交进行分组。如果没有指定`--组'选项，默认为`作者'。`<类型>`是以下之一。

note: type: Plain text
en: `author`, commits are grouped by author
zh_HANS-CN: "作者"，提交内容按作者分组

note: type: Plain text
en: `committer`, commits are grouped by committer (the same as `-c`)
zh_HANS-CN: 提交人"，提交内容按提交人分组（与 "c "相同）。

note: type: Plain text
en: `trailer:<field>`, the `<field>` is interpreted as a case-insensitive commit message trailer (see linkgit:git-interpret-trailers[1]). For example, if your project uses `Reviewed-by` trailers, you might want to see who has been reviewing with `git shortlog -ns --group=trailer:reviewed-by`.
zh_HANS-CN: `trailer:<field>`，`<field>`被解释为不区分大小写的提交消息预告片（见 linkgit:git-interpret-trailers[1]）。例如，如果你的项目使用 `Reviewed-by` 拖车，你可能想用 `git shortlog -ns --group=trailer:reviewed-by` 来查看谁在审核。

note: type: Plain text
en: `format:<format>`, any string accepted by the `--format` option of 'git log'. (See the "PRETTY FORMATS" section of linkgit:git-log[1].)
zh_HANS-CN: `格式：<format>`可以是任何被'git log'的`--format'选项接受的字符串，比如'* [%h] %s'。 参见linkgit:git-log[1]的 "PRETTY FORMATS "部分）。

note: type: Plain text
en: Note that commits that do not include the trailer will not be counted.  Likewise, commits with multiple trailers (e.g., multiple signoffs) may be counted more than once (but only once per unique trailer value in that commit).
zh_HANS-CN: 请注意，不包括拖车的提交将不被计算在内。  同样地，有多个拖车的提交（例如多个签收）可以被计算一次（但该提交中每个独特的拖车值只能计算一次）。

note: type: Plain text
en: Shortlog will attempt to parse each trailer value as a `name <email>` identity. If successful, the mailmap is applied and the email is omitted unless the `--email` option is specified. If the value cannot be parsed as an identity, it will be taken literally and completely.
zh_HANS-CN: Shortlog将尝试把每个拖车值解析为`name <email>`的身份。如果成功，将应用mailmap，除非指定`--email`选项，否则将省略email。如果该值不能被解析为一个身份，那么它将被完全视为字面意思。

note: type: Plain text
en: If `--group` is specified multiple times, commits are counted under each value (but again, only once per unique value in that commit). For example, `git shortlog --group=author --group=trailer:co-authored-by` counts both authors and co-authors.
zh_HANS-CN: 如果"--组 "被多次指定，每个值下的提交都会被计算（但同样，每个提交中的唯一值只能计算一次）。例如，`git shortlog --group=author --group=trailer:co-authored-by`同时计算作者和共同作者。

note: type: Plain text
en: This is an alias for `--group=committer`.
zh_HANS-CN: 这是`--group=committer`的一个别名。

note: type: Plain text
en: Linewrap the output by wrapping each line at `width`.  The first line of each entry is indented by `indent1` spaces, and the second and subsequent lines are indented by `indent2` spaces. `width`, `indent1`, and `indent2` default to 76, 6 and 9 respectively.
zh_HANS-CN: 通过以`width`包裹每一行来对输出进行换行。  每个条目的第一行缩进`缩进1`个空格，第二行和后续行缩进`缩进2`个空格。`width`, `indent1`, 和`indent2`分别默认为76, 6和9。

note: type: Plain text
en: If width is `0` (zero) then indent the lines of the output without wrapping them.
zh_HANS-CN: 如果宽度为`0`（零），则缩进输出的行数而不包裹它们。

note: type: Plain text
en: Consider only commits that are enough to explain how the files that match the specified paths came to be.
zh_HANS-CN: 只考虑那些足以解释符合指定路径的文件是如何产生的提交。

note: type: Plain text
en: Note that if `git shortlog` is run outside of a repository (to process log contents on standard input), it will look for a `.mailmap` file in the current directory.
zh_HANS-CN: 注意，如果`git shortlog`在版本库外运行（处理标准输入的日志内容），它将在当前目录下寻找一个`.mailmap`文件。

note: type: Plain text
en: git-show-branch - Show branches and their commits
zh_HANS-CN: git-show-branch - 显示分支及其提交情况

note: type: Plain text
en: Shows the commit ancestry graph starting from the commits named with <rev>s or <glob>s (or all refs under refs/heads and/or refs/tags) semi-visually.
zh_HANS-CN: 以半直观的方式显示从以 <rev>s 或 <通配符>s 命名的提交（或 refs/heads 和/或 refs/tags 下的所有引用）开始的提交祖先图。

note: type: Plain text
en: It cannot show more than 29 branches and commits at a time.
zh_HANS-CN: 它不能同时显示超过 29 个分支和提交。

note: type: Plain text
en: It uses `showbranch.default` multi-valued configuration items if no <rev> or <glob> is given on the command line.
zh_HANS-CN: 如果命令行中没有给出 <rev> 或 <通配符>，它会使用 `showbranch.default` 多值配置项。

note: type: Plain text
en: Arbitrary extended SHA-1 expression (see linkgit:gitrevisions[7])  that typically names a branch head or a tag.
zh_HANS-CN: 任意扩展的 SHA-1 表达式（参见 linkgit:gitrevisions[7]），通常用于命名分支头或标签。

note: type: Labeled list
en: <glob>
zh_HANS-CN: <通配符>

note: type: Plain text
en: A glob pattern that matches branch or tag names under refs/.  For example, if you have many topic branches under refs/heads/topic, giving `topic/*` would show all of them.
zh_HANS-CN: 匹配 refs/ 下分支或标记名称的通配模式。 例如，如果在 refs/heads/topic 下有许多主题分支，那么输入 `topic/*` 就会显示所有分支。

note: type: Plain text
en: Show the remote-tracking branches.
zh_HANS-CN: 显示远程跟踪分支。

note: type: Plain text
en: Show both remote-tracking branches and local branches.
zh_HANS-CN: 同时显示远程跟踪分支和本地分支。

note: type: Plain text
en: With this option, the command includes the current branch to the list of revs to be shown when it is not given on the command line.
zh_HANS-CN: 使用该选项后，当命令行中没有给出当前分支的版本号时，命令会将该分支包含在要显示的版本号列表中。

note: type: Plain text
en: By default, the branches and their commits are shown in reverse chronological order.  This option makes them appear in topological order (i.e., descendant commits are shown before their parents).
zh_HANS-CN: 默认情况下，分支及其提交按时间倒序显示。 此选项可使它们按拓扑顺序显示（即子分支提交显示在父分支之前）。

note: type: Plain text
en: This option is similar to `--topo-order` in the sense that no parent comes before all of its children, but otherwise commits are ordered according to their commit date.
zh_HANS-CN: 该选项类似于 `-topo-order`，即父提交不会排在所有子提交之前，但也会根据提交日期对提交进行排序。

note: type: Plain text
en: By default, the output omits merges that are reachable from only one tip being shown.  This option makes them visible.
zh_HANS-CN: 默认情况下，输出会忽略只显示一个提示的合并。 该选项将使它们可见。

note: type: Plain text
en: Usually the command stops output upon showing the commit that is the common ancestor of all the branches.  This flag tells the command to go <n> more common commits beyond that.  When <n> is negative, display only the <ref>s given, without showing the commit ancestry tree.
zh_HANS-CN: 通常，命令会在显示所有分支的共同祖先提交后停止输出。 此标记会告诉命令在此基础上再显示 <n> 次共同提交。 当 <n> 为负数时，只显示给出的 <引用>，而不显示提交祖先树。

note: type: Plain text
en: Synonym to `--more=-1`
zh_HANS-CN: 同 `--more=-1`

note: type: Plain text
en: Instead of showing the commit list, determine possible merge bases for the specified commits. All merge bases will be contained in all specified commits. This is different from how linkgit:git-merge-base[1] handles the case of three or more commits.
zh_HANS-CN: 不显示提交列表，而是确定指定提交的可能合并库。所有合并库都将包含在所有指定的提交中。这与 linkgit:git-merge-base[1] 处理三个或更多提交的方式不同。

note: type: Plain text
en: Among the <ref>s given, display only the ones that cannot be reached from any other <ref>.
zh_HANS-CN: 在给出的多个 <引用> 中，只显示无法从其他 <引用> 到达的 <引用> 。

note: type: Plain text
en: Do not show naming strings for each commit.
zh_HANS-CN: 不显示每次提交的命名字符串。

note: type: Plain text
en: Instead of naming the commits using the path to reach them from heads (e.g. "master~2" to mean the grandparent of "master"), name them with the unique prefix of their object names.
zh_HANS-CN: 在命名提交时，不要使用从头到尾的路径（例如，"master~2" 表示 "master" 的祖先），而是使用对象名称的唯一前缀。

note: type: Plain text
en: Shows only commits that are NOT on the first branch given.  This helps track topic branches by hiding any commit that is already in the main line of development.  When given "git show-branch --topics master topic1 topic2", this will show the revisions given by "git rev-list {caret}master topic1 topic2"
zh_HANS-CN: 只显示不在第一个分支上的提交。 这有助于跟踪主题分支，隐藏任何已在主线开发中的提交。 当给出 "git show-branch --topics master topic1 topic2" 时，将显示 "git rev-list {caret}master topic1 topic2" 给出的修订版本

note: type: Plain text
en: Shows <n> most recent ref-log entries for the given ref.  If <base> is given, <n> entries going back from that entry.  <base> can be specified as count or date.  When no explicit <ref> parameter is given, it defaults to the current branch (or `HEAD` if it is detached).
zh_HANS-CN: 显示给定引用的 <n> 条最新引用日志记录。 如果给定 <基点>，则显示从该条目开始的 <n> 条目。 <基点> 可以指定为计数或日期。 如果没有给出明确的 <引用> 参数，则默认为当前分支（如果是分离分支，则为 `HEAD`）。

note: type: Plain text
en: Color the status sign (one of these: `*` `!` `+` `-`) of each commit corresponding to the branch it's in.  The value must be always (the default), never, or auto.
zh_HANS-CN: 为每个提交的状态符号（其中之一：`*``！```+```-`）着色，与它所在的分支相对应。 值必须是 always（总是）（默认值）、never（从不）或 auto（自动）。

note: type: Plain text
en: Turn off colored output, even when the configuration file gives the default to color output.  Same as `--color=never`.
zh_HANS-CN: 关闭彩色输出，即使配置文件默认为彩色输出。 与 `-color=never` 相同。

note: type: Plain text
en: Note that --more, --list, --independent and --merge-base options are mutually exclusive.
zh_HANS-CN: 请注意，--more、--list、--independent 和 --merge-base 选项是互斥的。

note: type: Plain text
en: Given N <ref>s, the first N lines are the one-line description from their commit message. The branch head that is pointed at by $GIT_DIR/HEAD is prefixed with an asterisk `*` character while other heads are prefixed with a `!` character.
zh_HANS-CN: 给定 N 个 <引用>，前 N 行是其提交信息中的单行描述。$GIT_DIR/HEAD 所指向的分支头前缀为星号 `*` 字符，而其他分支头前缀为 `!` 字符。

note: type: Plain text
en: Following these N lines, one-line log for each commit is displayed, indented N places.  If a commit is on the I-th branch, the I-th indentation character shows a `+` sign; otherwise it shows a space.  Merge commits are denoted by a `-` sign.  Each commit shows a short name that can be used as an extended SHA-1 to name that commit.
zh_HANS-CN: 在这 N 行之后，会显示每个提交的单行日志，缩进 N 位。 如果提交在第 I 个分支上，则第 I 个缩进字符显示为 `+` 号，否则显示为空格。 合并提交用 `-` 符号表示。 每个提交都会显示一个简短的名称，可以作为扩展 SHA-1 来命名该提交。

note: type: Plain text
en: The following example shows three branches, "master", "fixes" and "mhf":
zh_HANS-CN: 下面的示例显示了三个分支："master"、"fixes "和 "mhf"：

note: type: delimited block -
en:   + [mhf] Allow "+remote:local" refspec to cause --force when fetching.
      + [mhf~1] Use git-octopus when pulling more than one heads.
     +  [fixes] Introduce "reset type" flag to "git reset"
      + [mhf~2] "git fetch --force".
      + [mhf~3] Use .git/remote/origin, not .git/branches/origin.
      + [mhf~4] Make "git pull" and "git fetch" default to origin
      + [mhf~5] Infamous 'octopus merge'
      + [mhf~6] Retire git-parse-remote.
      + [mhf~7] Multi-head fetch.
      + [mhf~8] Start adding the $GIT_DIR/remotes/ support.
    *++ [master] Add 'git show-branch'.
zh_HANS-CN:   + [mhf] 允许 "+remote:local" 引用规范在获取时导致 --force。
      + [mhf~1] 拉取多个头时使用 git-octopus。
     + [fixes] 在 "git reset" 中引入 "reset type" 标志
      + [mhf~2] "git fetch --force".
      + [mhf~3] 使用 .git/remote/origin，而不是 .git/branches/origin。
      + [mhf~4] 将 "git pull" 和 "git fetch" 默认为 origin
      + [mhf~5] 臭名昭著的 ‘章鱼（多路）合并’
      + [mhf~6] 重试 git-parse-remote。
      + [mhf~7] 获取多个头
      + [mhf~8] 开始添加 $GIT_DIR/remotes/ 支持。
    *++ [master] 添加 'git show-branch'。

note: type: Plain text
en: These three branches all forked from a common commit, [master], whose commit message is "Add \'git show-branch'".  The "fixes" branch adds one commit "Introduce "reset type" flag to "git reset"". The "mhf" branch adds many other commits.  The current branch is "master".
zh_HANS-CN: 这三个分支都分叉自一个共同的提交 [master]，其提交信息是 “添加 \'git show-branch'”。 "fixes" 分支增加了一个提交 "在 "git reset "中引入 "reset type" 标志"。"mhf" 分支增加了许多其他提交。 当前分支是 "master"。

note: type: Plain text
en: If you keep your primary branches immediately under `refs/heads`, and topic branches in subdirectories of it, having the following in the configuration file may help:
zh_HANS-CN: 如果你将主分支放在 `refs/heads` 下，而主题分支放在其子目录中，那么在配置文件中加入以下内容可能会有所帮助：

note: type: Plain text
en: With this, `git show-branch` without extra parameters would show only the primary branches.  In addition, if you happen to be on your topic branch, it is shown as well.
zh_HANS-CN: 这样，不带额外参数的 `git show-branch` 就只能显示主分支。 此外，如果您恰好在您的主题分支上，它也会显示出来。

note: type: Plain text
en: shows 10 reflog entries going back from the tip as of 1 hour ago.  Without `--list`, the output also shows how these tips are topologically related with each other.
zh_HANS-CN: 显示了 10 条从 1 小时前的提示开始的引用日志条目。 如果不使用 `--list`，输出结果还会显示这些提示之间的拓扑关系。

note: type: Plain text
en: git-show-index - Show packed archive index
zh_HANS-CN: git-show-index - 显示打包的档案索引

note: type: Plain text
en: Read the `.idx` file for a Git packfile (created with linkgit:git-pack-objects[1] or linkgit:git-index-pack[1]) from the standard input, and dump its contents. The output consists of one object per line, with each line containing two or three space-separated columns:
zh_HANS-CN: 从标准输入读取 Git packfile 的 `.idx` 文件（使用 linkgit:git-pack-objects[1] 或 linkgit:git-index-pack[1] 创建），并转储其内容。输出包括每行一个对象，每行包含两到三个空格分隔的列：

note: type: Plain text
en: the first column is the offset in bytes of the object within the corresponding packfile
zh_HANS-CN: 第一列是对象在相应打包文件中的偏移量（以字节为单位）

note: type: Plain text
en: the second column is the object id of the object
zh_HANS-CN: 第二列是对象的对象 ID

note: type: Plain text
en: if the index version is 2 or higher, the third column contains the CRC32 of the object data
zh_HANS-CN: 如果索引版本为 2 或更高，第三列包含对象数据的 CRC32

note: type: Plain text
en: The objects are output in the order in which they are found in the index file, which should be (in a correctly constructed file) sorted by object id.
zh_HANS-CN: 对象将按照在索引文件中找到的顺序输出，索引文件应（在正确构建的文件中）按照对象 ID 排序。

note: type: Plain text
en: Note that you can get more information on a packfile by calling linkgit:git-verify-pack[1]. However, as this command considers only the index file itself, it's both faster and more flexible.
zh_HANS-CN: 请注意，您可以通过调用 linkgit:git-verify-pack[1] 获取更多关于打包文件的信息。不过，由于该命令只考虑索引文件本身，因此速度更快，也更灵活。

note: type: Plain text
en: Show the HEAD reference, even if it would normally be filtered out.
zh_HANS-CN: 显示 HEAD 参考，即使它通常会被过滤掉。

note: type: Plain text
en: Shows one or more objects (blobs, trees, tags and commits).
zh_HANS-CN: 显示一个或多个对象（Blobs、树、标签和提交）。

note: type: Plain text
en: For tags, it shows the tag message and the referenced objects.
zh_HANS-CN: 对于标签，它显示标签信息和引用的对象。

note: type: Plain text
en: For trees, it shows the names (equivalent to 'git ls-tree' with --name-only).
zh_HANS-CN: 对于目录树，它显示名字（相当于'git ls-tree'添加了--name-only选项）。

note: type: Plain text
en: For plain blobs, it shows the plain contents.
zh_HANS-CN: 对于普通二进制对象，它显示普通内容。

note: type: Plain text
en: The command takes options applicable to the 'git diff-tree' command to control how the changes the commit introduces are shown.
zh_HANS-CN: 该命令采用适用于'git diff-tree'命令的选项来控制提交所带来的变化的显示方式。

note: type: Plain text
en: This manual page describes only the most frequently used options.
zh_HANS-CN: 本手册页只描述了最常用的选项。

note: type: Labeled list
en: <object>...
zh_HANS-CN: <对象>...

note: type: Plain text
en: The names of objects to show (defaults to 'HEAD').  For a more complete list of ways to spell object names, see "SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].
zh_HANS-CN: 要显示的对象的名称（默认为'HEAD'）。  更完整的对象名称拼写方式列表，请参见 linkgit:gitrevisions[7] 中的 "特别修订" 部分。

note: type: Plain text
en: The options below can be used to change the way `git show` generates diff output.
zh_HANS-CN: 下面的选项可以用来改变`git show`生成差异输出的方式。

note: type: Plain text
en: Shows the tag `v1.0.0`, along with the object the tags points at.
zh_HANS-CN: 显示标签`v1.0.0`，以及标签指向的对象。

note: type: Plain text
en: Shows the tree pointed to by the tag `v1.0.0`.
zh_HANS-CN: 显示标签`v1.0.0`所指向的树。

note: type: Plain text
en: Shows the subject of the commit pointed to by the tag `v1.0.0`.
zh_HANS-CN: 显示由标签`v1.0.0`指向的提交的主题。

note: type: Plain text
en: Shows the contents of the file `Documentation/README` as they were current in the 10th last commit of the branch `next`.
zh_HANS-CN: 显示`Documentation/README`文件的内容，因为它们在分支`next`的最后10次提交中是当前的。

note: type: Plain text
en: Concatenates the contents of said Makefiles in the head of the branch `master`.
zh_HANS-CN: 将上述Makefiles的内容串联在分支`master`的头部。

note: type: Plain text
en: Before sourcing it, your script should set up a few variables; `USAGE` (and `LONG_USAGE`, if any) is used to define message given by `usage()` shell function.  `SUBDIRECTORY_OK` can be set if the script can run from a subdirectory of the working tree (some commands do not).
zh_HANS-CN: 在源码化之前，脚本应该设置一些变量；`USAGE`（和 `LONG_USAGE`，如果有的话）用于定义 shell 函数 `usage()` 给出的信息。 如果脚本可以从工作树的子目录运行，则可以设置 `SUBDIRECTORY_OK`（某些命令不能从子目录运行）。

note: type: Plain text
en: The scriptlet sets `GIT_DIR` and `GIT_OBJECT_DIRECTORY` shell variables, but does *not* export them to the environment.
zh_HANS-CN: 脚本小程序会设置 `GIT_DIR` 和 `GIT_OBJECT_DIRECTORY` shell 变量，但*不会*导出它们到环境中。

note: type: Plain text
en: exit after emitting the supplied error message to the standard error stream.
zh_HANS-CN: 将提供的错误信息发送到标准错误流后退出。

note: type: Plain text
en: die with the usage message.
zh_HANS-CN: 结束，并显示使用信息。

note: type: Plain text
en: Set `GIT_REFLOG_ACTION` environment to a given string (typically the name of the program) unless it is already set.  Whenever the script runs a `git` command that updates refs, a reflog entry is created using the value of this string to leave the record of what command updated the ref.
zh_HANS-CN: 将 `GIT_REFLOG_ACTION` 环境设置为给定的字符串（通常是程序名称），除非它已经被设置。 每当脚本运行更新引用的 `git` 命令时，就会使用该字符串的值创建一个引用日志条目，以记录更新引用的命令。

note: type: Plain text
en: runs an editor of user's choice (GIT_EDITOR, core.editor, VISUAL or EDITOR) on a given file, but error out if no editor is specified and the terminal is dumb.
zh_HANS-CN: 在给定文件上运行用户选择的编辑器（GIT_EDITOR、core.editor、VISUAL 或 EDITOR），但如果未指定编辑器且终端为哑终端，则会出错。

note: type: Plain text
en: outputs `true` or `false` to the standard output stream to indicate if the repository is a bare repository (i.e. without an associated working tree).
zh_HANS-CN: 会向标准输出流输出 `true` 或 `false`，以指示版本库是否为裸仓库（即没有任何关联的工作区）。

note: type: Plain text
en: runs chdir to the toplevel of the working tree.
zh_HANS-CN: 运行 chdir 到工作树的顶层。

note: type: Plain text
en: checks if the current directory is within the working tree of the repository, and otherwise dies.
zh_HANS-CN: 会检查当前目录是否在仓库的工作区中，否则就挂起。

note: type: Plain text
en: checks if the working tree associated with the repository exists, and otherwise dies.  Often done before calling cd_to_toplevel, which is impossible to do if there is no working tree.
zh_HANS-CN: 检查与仓库相关联的工作区是否存在，否则挂掉。 通常在调用 cd_to_toplevel 之前进行，如果没有工作区，就不可能调用 cd_to_toplevel。

note: type: Labeled list
en: require_clean_work_tree <action> [<hint>]
zh_HANS-CN: require_clean_work_tree <行为> [<提示>]

note: type: Plain text
en: checks that the working tree and index associated with the repository have no uncommitted changes to tracked files.  Otherwise it emits an error message of the form `Cannot <action>: <reason>. <hint>`, and dies.  Example:
zh_HANS-CN: 会检查与仓库关联的工作区和索引中是否有未提交的跟踪文件变更。 否则，它将发出 "无法执行 <行为>:<原因>. <提示>"，然后挂掉。例如：

note: type: delimited block -
en: require_clean_work_tree rebase "Please commit or stash them."
zh_HANS-CN: require_clean_work_tree rebase "请提交或者贮藏他们。"

note: type: Plain text
en: outputs code for use with eval to set the GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL and GIT_AUTHOR_DATE variables for a given commit.
zh_HANS-CN: 输出与 eval 配合使用的代码，以设置指定提交的 GIT_AUTHOR_NAME、GIT_AUTHOR_EMAIL 和 GIT_AUTHOR_DATE 变量。

note: type: Plain text
en: modifies the first file so only lines in common with the second file remain. If there is insufficient common material, then the first file is left empty. The result is suitable as a virtual base input for a 3-way merge.
zh_HANS-CN: 修改第一个文件，只保留与第二个文件相同的行。如果共同内容不足，则第一个文件留空。结果适合作为三向合并的虚拟基础输入。

note: type: Plain text
en: git-stage - Add file contents to the staging area
zh_HANS-CN: git-stage - 将文件内容添加到暂存区

note: type: Plain text
en: This is a synonym for linkgit:git-add[1].  Please refer to the documentation of that command.
zh_HANS-CN: 这是 linkgit:git-add[1] 的同义词。 请参阅该命令的文档。

note: type: Plain text
en: git-stash - Stash the changes in a dirty working directory away
zh_HANS-CN: git-stash - 将变化藏在一个脏工作区中

note: type: Plain text
en: Use `git stash` when you want to record the current state of the working directory and the index, but want to go back to a clean working directory.  The command saves your local modifications away and reverts the working directory to match the `HEAD` commit.
zh_HANS-CN: 当你想记录工作目录和索引的当前状态，但又想回到一个干净的工作目录时，请使用`git stash`。  该命令将你的本地修改保存起来，并将工作目录还原为与`HEAD`提交相匹配。

note: type: Plain text
en: The modifications stashed away by this command can be listed with `git stash list`, inspected with `git stash show`, and restored (potentially on top of a different commit) with `git stash apply`.  Calling `git stash` without any arguments is equivalent to `git stash push`.  A stash is by default listed as "WIP on 'branchname' ...", but you can give a more descriptive message on the command line when you create one.
zh_HANS-CN: 这个命令所存储的修改可以用`git stash list`列出，用`git stash show`检查，用`git stash apply`恢复（可能是在不同的提交之上）。  在没有任何参数的情况下调用`git stash`等同于`git stash push`。  默认情况下，储藏库被列为 "WIP on 'branchname' ..."，但你可以在创建储藏库时在命令行中给出更多描述性信息。

note: type: Plain text
en: The latest stash you created is stored in `refs/stash`; older stashes are found in the reflog of this reference and can be named using the usual reflog syntax (e.g. `stash@{0}` is the most recently created stash, `stash@{1}` is the one before it, `stash@{2.hours.ago}` is also possible). Stashes may also be referenced by specifying just the stash index (e.g. the integer `n` is equivalent to `stash@{n}`).
zh_HANS-CN: 你最近创建的储藏库被保存在`refs/stash`中；旧的储藏库可以在这个引用的引用日志中找到，并且可以使用通常的引用日志语法来命名（例如，`stash@{0}`是最近创建的储藏库，`stash@{1}`是它之前的储藏库，`stash@{2.hours.ago}`也是可以的）。也可以通过指定储藏库的索引来引用储藏库（例如，整数`n`等同于`stash@{n}`）。

note: type: Plain text
en: Save your local modifications to a new 'stash entry' and roll them back to HEAD (in the working tree and in the index).  The <message> part is optional and gives the description along with the stashed state.
zh_HANS-CN: 将你的本地修改保存到一个新的 "存储条目 "中，并将它们回滚到 HEAD（在工作区和索引中）。  <信息>部分是可选的，它给出了描述和储藏的状态。

note: type: Plain text
en: For quickly making a snapshot, you can omit "push".  In this mode, non-option arguments are not allowed to prevent a misspelled subcommand from making an unwanted stash entry.  The two exceptions to this are `stash -p` which acts as alias for `stash push -p` and pathspec elements, which are allowed after a double hyphen `--` for disambiguation.
zh_HANS-CN: 为了快速制作快照，你可以省略 "push"。  在这种模式下，非选项参数是不允许的，以防止拼写错误的子命令产生不需要的储藏条目。  这方面的两个例外是`stash -p`，它作为`stash push -p`的别名，以及为消除歧义允许在双连字符`--`之后的路径规范元素。

note: type: Labeled list
en: save [-p|--patch] [-S|--staged] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [<message>]
zh_HANS-CN: save [-p|--patch] [-S|--staged] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [<信息>]

note: type: Plain text
en: This option is deprecated in favour of 'git stash push'.  It differs from "stash push" in that it cannot take pathspec.  Instead, all non-option arguments are concatenated to form the stash message.
zh_HANS-CN: 该选项已被弃用，改为 "git stash push"。  它与 "stash push "的不同之处在于，它不能接受路径规范。  取而代之的是，所有非选项的参数都被串联起来，形成储藏消息。

note: type: Labeled list
en: list [<log-options>]
zh_HANS-CN: list [<日志选项>]

note: type: Plain text
en: List the stash entries that you currently have.  Each 'stash entry' is listed with its name (e.g. `stash@{0}` is the latest entry, `stash@{1}` is the one before, etc.), the name of the branch that was current when the entry was made, and a short description of the commit the entry was based on.
zh_HANS-CN: 列出你目前拥有的储藏目录。  每个 "储藏目录 "都列出了它的名字（例如，`stash@{0}`是最新的条目，`stash@{1}`是之前的条目，等等），条目产生时的分支名称，以及该条目所基于的提交的简短描述。

note: type: Plain text
en: The command takes options applicable to the 'git log' command to control what is shown and how. See linkgit:git-log[1].
zh_HANS-CN: 该命令采用适用于 'git log' 命令的选项来控制显示的内容和方式。参见 linkgit:git-log[1]。

note: type: Labeled list
en: show [-u|--include-untracked|--only-untracked] [<diff-options>] [<stash>]
zh_HANS-CN: show [-u|--include-untracked|--only-untracked] [<diff选项>] [<储藏目录>]

note: type: Plain text
en: Show the changes recorded in the stash entry as a diff between the stashed contents and the commit back when the stash entry was first created.  By default, the command shows the diffstat, but it will accept any format known to 'git diff' (e.g., `git stash show -p stash@{1}` to view the second most recent entry in patch form).  If no `<diff-option>` is provided, the default behavior will be given by the `stash.showStat`, and `stash.showPatch` config variables. You can also use `stash.showIncludeUntracked` to set whether `--include-untracked` is enabled by default.
zh_HANS-CN: 显示贮藏中记录的修改，作为贮藏内容与贮藏库条目首次创建时的提交之间的差异。  默认情况下，该命令显示diff统计，但它会接受 "git diff "已知的任何格式（例如，`git stash show -p stash@{1}`以补丁形式查看第二条最新条目）。  如果没有提供`<diff选项>`，默认行为将由`stash.showStat`和`stash.showPatch`配置变量给出。你也可以使用`stash.showIncludeUntracked`来设置是否默认启用`--include-untracked`。

note: type: Plain text
en: Remove a single stashed state from the stash list and apply it on top of the current working tree state, i.e., do the inverse operation of `git stash push`. The working directory must match the index.
zh_HANS-CN: 从贮藏库列表中移除一个单一的贮藏状态，并将其应用于当前工作区状态之上，也就是做`git stash push`的逆向操作。工作目录必须与索引匹配。

note: type: Plain text
en: Applying the state can fail with conflicts; in this case, it is not removed from the stash list. You need to resolve the conflicts by hand and call `git stash drop` manually afterwards.
zh_HANS-CN: 应用状态可能会因为冲突而失败；在这种情况下，它不会被从贮藏库列表中删除。你需要手动解决冲突，并在之后调用 `git stash drop`。

note: type: Plain text
en: Like `pop`, but do not remove the state from the stash list. Unlike `pop`, `<stash>` may be any commit that looks like a commit created by `stash push` or `stash create`.
zh_HANS-CN: 和 `pop` 一样，但不从贮藏库列表中删除该状态。与`pop`不同，`<贮藏项>`可以是任何看起来像由`stash push`或`stash create`创建的提交。

note: type: Labeled list
en: branch <branchname> [<stash>]
zh_HANS-CN: branch <分支名> [<贮藏项>]

note: type: Plain text
en: Creates and checks out a new branch named `<branchname>` starting from the commit at which the `<stash>` was originally created, applies the changes recorded in `<stash>` to the new working tree and index.  If that succeeds, and `<stash>` is a reference of the form `stash@{<revision>}`, it then drops the `<stash>`.
zh_HANS-CN: 创建并检查一个名为 `<分支名>` 的新分支，从最初创建 `<贮藏项>` 的提交开始，将 `<贮藏项>` 中记录的修改应用到新的工作树和索引。  如果成功了，并且`<贮藏项>`是`stash@{<版本>}`形式的引用，那么它将删除`<贮藏项>`。

note: type: Plain text
en: This is useful if the branch on which you ran `git stash push` has changed enough that `git stash apply` fails due to conflicts. Since the stash entry is applied on top of the commit that was HEAD at the time `git stash` was run, it restores the originally stashed state with no conflicts.
zh_HANS-CN: 如果你运行 `git stash push` 的分支发生了足够的变化，以至于 `git stash apply` 因冲突而失败，那么这就很有用。由于贮藏条目是在运行 `git stash` 时的当前分支提交之上应用的，它没有冲突地恢复了最初的贮藏状态。

note: type: Plain text
en: Remove all the stash entries. Note that those entries will then be subject to pruning, and may be impossible to recover (see 'Examples' below for a possible strategy).
zh_HANS-CN: 删除所有的贮藏条目。直接切断任何联系，而且可能无法恢复（可能的策略见下面的 "例子"）。

note: type: Labeled list
en: drop [-q|--quiet] [<stash>]
zh_HANS-CN: Drop [-q|--quite] [<贮藏项>]

note: type: Plain text
en: Remove a single stash entry from the list of stash entries.
zh_HANS-CN: 从贮藏条目列表中删除一个单一的贮藏条目。

note: type: Plain text
en: Create a stash entry (which is a regular commit object) and return its object name, without storing it anywhere in the ref namespace.  This is intended to be useful for scripts.  It is probably not the command you want to use; see "push" above.
zh_HANS-CN: 创建一个贮藏条目（这是一个普通的提交对象），并返回其对象名称，而不将其存储在引用命名空间的任何地方。  这是为了对脚本有用。  你可能不想用这个命令；可以看看前面的 "push"。

note: type: Plain text
en: Store a given stash created via 'git stash create' (which is a dangling merge commit) in the stash ref, updating the stash reflog.  This is intended to be useful for scripts.  It is probably not the command you want to use; see "push" above.
zh_HANS-CN: 将通过'git stash create'（这是一个悬空的合并提交）创建的特定贮藏库存储在贮藏库引用中，更新贮藏库参考文件。  这是为了对脚本有用。  这条命令可能不是你想要的；见上文"push"。

note: type: Plain text
en: This option is only valid for `push` and `save` commands.
zh_HANS-CN: 这个选项只对`push`和`save`命令有效。

note: type: Plain text
en: All ignored and untracked files are also stashed and then cleaned up with `git clean`.
zh_HANS-CN: 所有被忽略的和未被追踪的文件也被贮藏起来，然后用`git clean`来清理。

note: type: Plain text
en: When used with the `push` and `save` commands, all untracked files are also stashed and then cleaned up with `git clean`.
zh_HANS-CN: 当与`push`和`save`命令一起使用时，所有未被追踪的文件也被贮藏起来，然后用`git clean`来清理。

note: type: Plain text
en: When used with the `show` command, show the untracked files in the stash entry as part of the diff.
zh_HANS-CN: 当与`show`命令一起使用时，显示贮藏库条目中未被追踪的文件作为差异的一部分。

note: type: Plain text
en: This option is only valid for the `show` command.
zh_HANS-CN: 这个选项只对`show`命令有效。

note: type: Plain text
en: Show only the untracked files in the stash entry as part of the diff.
zh_HANS-CN: 只显示贮藏库条目中未被追踪的文件作为差异的一部分。

note: type: Plain text
en: This option is only valid for `pop` and `apply` commands.
zh_HANS-CN: 这个选项只对`pop`和`apply`命令有效。

note: type: Plain text
en: Tries to reinstate not only the working tree's changes, but also the index's ones. However, this can fail, when you have conflicts (which are stored in the index, where you therefore can no longer apply the changes as they were originally).
zh_HANS-CN: 不仅试图恢复工作区的变化，而且恢复索引的变化。然而，这可能会在出现冲突时失败（这些冲突被存储在索引中，因此你不能再按原来的方式应用这些变化）。

note: type: Plain text
en: All changes already added to the index are left intact.
zh_HANS-CN: 所有已经添加到索引中的变化都保持原样。

note: type: Plain text
en: Interactively select hunks from the diff between HEAD and the working tree to be stashed.  The stash entry is constructed such that its index state is the same as the index state of your repository, and its worktree contains only the changes you selected interactively.  The selected changes are then rolled back from your worktree. See the ``Interactive Mode'' section of linkgit:git-add[1] to learn how to operate the `--patch` mode.
zh_HANS-CN: 交互式地从当前分支和工作区之间的差异中选择要存储的内容。  藏匿条目的构造是这样的：它的索引状态与你仓库的索引状态相同，它的工作区只包含你交互选择的变化。  被选中的修改会从你的工作区中回滚。参见 linkgit:git-add[1] 中的 ``互动模式''一节，了解如何操作`--patch`模式。

note: type: Plain text
en: The `--patch` option implies `--keep-index`.  You can use `--no-keep-index` to override this.
zh_HANS-CN: 选项`---patch`意味着`---keep-index`。  你可以使用`--no-keep-index`来覆盖它。

note: type: Plain text
en: Stash only the changes that are currently staged. This is similar to basic `git commit` except the state is committed to the stash instead of current branch.
zh_HANS-CN: 只存放当前分阶段的修改。这类似于基本的`git commit`，只不过是将状态提交到贮藏室而不是当前分支。

note: type: Plain text
en: The `--patch` option has priority over this one.
zh_HANS-CN: `--patch`选项要优先于这个选项。

note: type: Plain text
en: This option is only valid for `push` command.
zh_HANS-CN: 这个选项只对`push`命令有效。

note: type: Plain text
en: This option is only valid for `apply`, `drop`, `pop`, `push`, `save`, `store` commands.
zh_HANS-CN: 这个选项只对`apply`、`drop`、`pop`、`push`、`save`、`store`命令有效。

note: type: Plain text
en: Separates pathspec from options for disambiguation purposes.
zh_HANS-CN: 为了消除歧义，将路径规范与选项分开。

note: type: Plain text
en: The new stash entry records the modified states only for the files that match the pathspec.  The index entries and working tree files are then rolled back to the state in HEAD only for these files, too, leaving files that do not match the pathspec intact.
zh_HANS-CN: 新的贮藏条目只记录了符合路径规范文件的修改状态。  然后索引条目和工作区文件也被回滚到当前分支中的状态，只留下不符合路径规范的文件。

note: type: Plain text
en: This option is only valid for `apply`, `branch`, `drop`, `pop`, `show` commands.
zh_HANS-CN: 这个选项只对`apply`、`branch`、`drop`、`pop`、`show`命令有效。

note: type: Plain text
en: A reference of the form `stash@{<revision>}`. When no `<stash>` is given, the latest stash is assumed (that is, `stash@{0}`).
zh_HANS-CN: 一个形式为`stash@{<版本>}`的引用。如果没有给出`<贮藏项>`，则假定是最新的储藏库（即`stash@{0}`）。

note: type: Plain text
en: A stash entry is represented as a commit whose tree records the state of the working directory, and its first parent is the commit at `HEAD` when the entry was created.  The tree of the second parent records the state of the index when the entry is made, and it is made a child of the `HEAD` commit.  The ancestry graph looks like this:
zh_HANS-CN: 一个贮藏库条目被表示为一个提交，它的目录树记录了工作目录的状态，它的第一个父节点是创建该条目时在`HEAD`的提交。  第二个父节点的树记录了条目生成时索引的状态，它是`HEAD`提交的一个子节点。  祖先图看起来像这样：

note: type: Plain text
en: where `H` is the `HEAD` commit, `I` is a commit that records the state of the index, and `W` is a commit that records the state of the working tree.
zh_HANS-CN: 其中`H`是`HEAD`提交，`I`是记录索引状态的提交，`W`是记录工作区状态的提交。

note: type: Labeled list
en: Pulling into a dirty tree
zh_HANS-CN: 拉进一个脏目录树

note: type: Plain text
en: When you are in the middle of something, you learn that there are upstream changes that are possibly relevant to what you are doing.  When your local changes do not conflict with the changes in the upstream, a simple `git pull` will let you move forward.
zh_HANS-CN: 当你在做某件事的时候，你得知上游有一些变化可能与你正在做的事情有关。  当你的本地修改与上游的修改不冲突时，一个简单的`git pull'就可以让你继续前进。

note: type: Plain text
en: However, there are cases in which your local changes do conflict with the upstream changes, and `git pull` refuses to overwrite your changes.  In such a case, you can stash your changes away, perform a pull, and then unstash, like this:
zh_HANS-CN: 然而，在有些情况下，你的本地修改确实与上游修改有冲突，而`git pull`拒绝覆盖你的修改。  在这种情况下，你可以把你的进度保存起来，执行一次拉取，然后再解开，像这样：

note: type: Plain text
en: When you are in the middle of something, your boss comes in and demands that you fix something immediately.  Traditionally, you would make a commit to a temporary branch to store your changes away, and return to your original branch to make the emergency fix, like this:
zh_HANS-CN: 当你正在做某件事的时候，你的老板来了，要求你立即修复某件事。  传统上，你会向一个临时分支提交，以储存你的修改，然后返回到你的原始分支进行紧急修复，就像这样：

note: type: delimited block -
en: # ... hack hack hack ...
    $ git switch -c my_wip
    $ git commit -a -m "WIP"
    $ git switch master
    $ edit emergency fix
    $ git commit -a -m "Fix in a hurry"
    $ git switch my_wip
    $ git reset --soft HEAD^
    # ... continue hacking ...
zh_HANS-CN: # ... 嗨骇害 ...
    $ git switch -c my_wip
    $ git commit -a -m "我待会还得写点东西"
    $ git switch master
    $ edit emergency fix
    $ git commit -a -m "速速修复BUG"
    $ git switch my_wip
    $ git reset --soft HEAD^
    # ... 继续骇入 ...

note: type: Plain text
en: You can use 'git stash' to simplify the above, like this:
zh_HANS-CN: 你可以用'git stash'来简化上述工作，像这样：

note: type: delimited block -
en: # ... hack hack hack ...
    $ git stash
    $ edit emergency fix
    $ git commit -a -m "Fix in a hurry"
    $ git stash pop
    # ... continue hacking ...
zh_HANS-CN: # ... 嗨骇害 ...
    $ git stash
    $ edit emergency fix
    $ git commit -a -m "紧急修复"
    $ git stash pop
    # ... 继续骇入 ...

note: type: Plain text
en: You can use `git stash push --keep-index` when you want to make two or more commits out of the changes in the work tree, and you want to test each change before committing:
zh_HANS-CN: 当你想把工作区上的改动做两个或更多的提交，并且想在提交前测试每个改动时，你可以使用`git stash push --keep-index`：

note: type: delimited block -
en: # ... hack hack hack ...
    $ git add --patch foo            # add just first part to the index
    $ git stash push --keep-index    # save all other changes to the stash
    $ edit/build/test first part
    $ git commit -m 'First part'     # commit fully tested change
    $ git stash pop                  # prepare to work on all other changes
    # ... repeat above five steps until one commit remains ...
    $ edit/build/test remaining parts
    $ git commit foo -m 'Remaining parts'
zh_HANS-CN: # ... 嗨骇害 ...
    $ git add --patch foo # 仅将第一部分添加到索引中
    $ git stash push --keep-index # 将所有其他改动保存到储藏室中
    $ edit/build/test first part
    $ git commit -m '第一个部分' # 提交完全测试过的改动
    $ git stash pop # 准备处理所有其他改动
    # ... 重复以上五个步骤，直到剩下一个提交...
    $ 编辑/构建/测试剩余部分
    $ git commit foo -m '剩余部分'。

note: type: Labeled list
en: Saving unrelated changes for future use
zh_HANS-CN: 保存不相关的变化供将来使用

note: type: Plain text
en: When you are in the middle of massive changes and you find some unrelated issue that you don't want to forget to fix, you can do the change(s), stage them, and use `git stash push --staged` to stash them out for future use. This is similar to committing the staged changes, only the commit ends-up being in the stash and not on the current branch.
zh_HANS-CN: 当你在进行大规模修改时，发现一些不相关的问题，你不想忘记修复，你可以进行修改，将其分阶段，然后使用 `git stash push --staged` 将其存放起来，以便将来使用。这类似于提交阶段性修改，只是提交的结果是在贮藏库而不是在当前分支。

note: type: Labeled list
en: Recovering stash entries that were cleared/dropped erroneously
zh_HANS-CN: 恢复被错误地清除/丢弃的贮藏库条目

note: type: Plain text
en: If you mistakenly drop or clear stash entries, they cannot be recovered through the normal safety mechanisms.  However, you can try the following incantation to get a list of stash entries that are still in your repository, but not reachable any more:
zh_HANS-CN: 如果你错误地丢弃或清除了贮藏库条目，它们无法通过正常的安全机制恢复。  然而，你可以试试下面的咒语，以获得仍在你的版本库中，但无法到达的贮藏库条目列表：

note: type: delimited block -
en: git fsck --unreachable |
    grep commit | cut -d\  -f3 |
    xargs git log --merges --no-walk --grep=WIP
zh_HANS-CN: git fsck --unreachable |
    grep commit | cut -d -f3 |
    xargs git log --merges --no-walk --grep=WIP

note: type: Plain text
en: git-status - Show the working tree status
zh_HANS-CN: git-status - 显示工作树状态

note: type: Plain text
en: Displays paths that have differences between the index file and the current HEAD commit, paths that have differences between the working tree and the index file, and paths in the working tree that are not tracked by Git (and are not ignored by linkgit:gitignore[5]). The first are what you _would_ commit by running `git commit`; the second and third are what you _could_ commit by running 'git add' before running `git commit`.
zh_HANS-CN: 显示索引文件和当前HEAD提交有差异的路径，工作树和索引文件有差异的路径，以及工作树中不被Git追踪的路径（也不被linkgit:gitignore[5]忽略）。前者是你通过运行 "git commit "会提交的东西；第二和第三者是你在运行 "git commit "之前通过运行 "git add "可以提交的东西。

note: type: Plain text
en: Give the output in the short-format.
zh_HANS-CN: 以简短的形式给出输出。

note: type: Plain text
en: Show the number of entries currently stashed away.
zh_HANS-CN: 显示目前藏匿的条目数量。

note: type: Plain text
en: Give the output in an easy-to-parse format for scripts.  This is similar to the short output, but will remain stable across Git versions and regardless of user configuration. See below for details.
zh_HANS-CN: 以易于解析的格式给出脚本的输出。  这类似于简短的输出，但在不同的Git版本中，无论用户配置如何，都会保持稳定。详见下文。

note: type: Plain text
en: The version parameter is used to specify the format version.  This is optional and defaults to the original version 'v1' format.
zh_HANS-CN: 版本参数用于指定格式版本。  这是可选的，默认为原始版本的 "v1 "格式。

note: type: Plain text
en: Give the output in the long-format. This is the default.
zh_HANS-CN: 给出长格式的输出。这是默认的。

note: type: Plain text
en: In addition to the names of files that have been changed, also show the textual changes that are staged to be committed (i.e., like the output of `git diff --cached`). If `-v` is specified twice, then also show the changes in the working tree that have not yet been staged (i.e., like the output of `git diff`).
zh_HANS-CN: 除了显示被修改的文件名外，还显示被分阶段提交的文本修改（即，像`git diff --cached`的输出）。如果`-v`被指定了两次，那么也会显示工作树中尚未分阶段的变化（即，像`git diff`的输出）。

note: type: Plain text
en: The mode parameter is used to specify the handling of untracked files.  It is optional: it defaults to 'all', and if specified, it must be stuck to the option (e.g. `-uno`, but not `-u no`).
zh_HANS-CN: 模式参数用于指定对未跟踪文件的处理。  它是可选的：默认为 "所有"，如果指定，必须与选项卡在一起（例如，`-uno`，但不是`-u no`）。

note: type: Plain text
en: 'no'     - Show no untracked files.
zh_HANS-CN: 'no' - 不显示未跟踪的文件。

note: type: Plain text
en: 'normal' - Shows untracked files and directories.
zh_HANS-CN: 'normal' - 显示未被追踪的文件和目录。

note: type: Plain text
en: When `-u` option is not used, untracked files and directories are shown (i.e. the same as specifying `normal`), to help you avoid forgetting to add newly created files.  Because it takes extra work to find untracked files in the filesystem, this mode may take some time in a large working tree.  Consider enabling untracked cache and split index if supported (see `git update-index --untracked-cache` and `git update-index --split-index`), Otherwise you can use `no` to have `git status` return more quickly without showing untracked files.
zh_HANS-CN: 当不使用`-u`选项时，将显示未跟踪的文件和目录（即与指定`normal`相同），以帮助你避免忘记添加新创建的文件。  因为在文件系统中寻找未跟踪的文件需要额外的工作，在一个大的工作树中，这种模式可能需要一些时间。  如果支持的话，考虑启用无痕缓存和分割索引（见`git upd-index --untracked-cache`和`git upd-index --split-index`），否则你可以使用`no`来让`git status`更快地返回而不显示无痕文件。

note: type: Plain text
en: Ignore changes to submodules when looking for changes. <when> can be either "none", "untracked", "dirty" or "all", which is the default.  Using "none" will consider the submodule modified when it either contains untracked or modified files or its HEAD differs from the commit recorded in the superproject and can be used to override any settings of the 'ignore' option in linkgit:git-config[1] or linkgit:gitmodules[5]. When "untracked" is used submodules are not considered dirty when they only contain untracked content (but they are still scanned for modified content). Using "dirty" ignores all changes to the work tree of submodules, only changes to the commits stored in the superproject are shown (this was the behavior before 1.7.0). Using "all" hides all changes to submodules (and suppresses the output of submodule summaries when the config option `status.submoduleSummary` is set).
zh_HANS-CN: 在寻找变化时忽略子模块的变化。<when>可以是 "none"、"untracked"、"dirty "或 "all"，这是默认的。  使用 "none"，當子模塊包含未被追蹤或修訂的檔案，或者它的頭部與超級工程中記錄的提交不同時，就會認為子模塊被修改了，可以用來覆蓋 linkgit:git-config[1] 或 linkgit:gitmodules[5] 中 "忽略 "選項的任何設定。当使用 "untracked "时，当子模块只包含未跟踪的内容时，不被认为是脏的（但它们仍然被扫描为修改的内容）。使用 "dirty "会忽略所有对子模块工作树的修改，只显示存储在超级项目中的提交的修改（这是1.7.0之前的行为）。使用 "all "会隐藏子模块的所有变化（当配置选项`status.submoduleSummary`被设置时，会抑制子模块摘要的输出）。

note: type: Labeled list
en: --ignored[=<mode>]
zh_HANS-CN: --ignored[=<模式>]

note: type: Plain text
en: Show ignored files as well.
zh_HANS-CN: 也显示忽略的文件。

note: type: Plain text
en: The mode parameter is used to specify the handling of ignored files.  It is optional: it defaults to 'traditional'.
zh_HANS-CN: 模式参数用于指定对被忽略文件的处理。  它是可选的：默认为 "传统"。

note: type: Plain text
en: 'traditional' - Shows ignored files and directories, unless
zh_HANS-CN: '传统' - 显示被忽略的文件和目录，除非

note: type: Plain text
en: 'no'	        - Show no ignored files.
zh_HANS-CN: 'no' - 不显示被忽略的文件。

note: type: Plain text
en: 'matching'    - Shows ignored files and directories matching an
zh_HANS-CN: 'matching' - 显示忽略的文件和目录，这些文件和目录符合

note: type: Plain text
en: ignore pattern.
zh_HANS-CN: 无视模式。

note: type: Plain text
en: When 'matching' mode is specified, paths that explicitly match an ignored pattern are shown. If a directory matches an ignore pattern, then it is shown, but not paths contained in the ignored directory. If a directory does not match an ignore pattern, but all contents are ignored, then the directory is not shown, but all contents are shown.
zh_HANS-CN: 当指定 "匹配 "模式时，明确匹配忽略模式的路径会被显示。如果一个目录与忽略模式相匹配，那么它就会被显示，但不显示被忽略目录中包含的路径。如果一个目录不匹配忽略模式，但所有内容都被忽略，那么该目录不被显示，但所有内容被显示。

note: type: Plain text
en: Terminate entries with NUL, instead of LF.  This implies the `--porcelain=v1` output format if no other format is given.
zh_HANS-CN: 用NUL而不是LF来终止条目。  如果没有给出其他格式，这就意味着`--porcelain=v1`的输出格式。

note: type: Plain text
en: Display untracked files in columns. See configuration variable `column.status` for option syntax. `--column` and `--no-column` without options are equivalent to 'always' and 'never' respectively.
zh_HANS-CN: 在列中显示未跟踪的文件。选项语法见配置变量`column.status`。`--column`和`--no-column`没有选项，分别相当于'always'和'never'。

note: type: Plain text
en: Display or do not display detailed ahead/behind counts for the branch relative to its upstream branch.  Defaults to true.
zh_HANS-CN: 显示或不显示该分支相对于其上游分支的详细超前/滞后计数。  默认为true。

note: type: Plain text
en: Turn on/off rename detection regardless of user configuration.  See also linkgit:git-diff[1] `--no-renames`.
zh_HANS-CN: 开启/关闭重名检测，不受用户配置影响。  参见linkgit:git-diff[1] `--no-renames`。

note: type: Plain text
en: Turn on rename detection, optionally setting the similarity threshold.  See also linkgit:git-diff[1] `--find-renames`.
zh_HANS-CN: 开启重名检测，可选择设置相似度阈值。  参见 linkgit:git-diff[1] `--find-renames`。

note: type: Plain text
en: See the 'pathspec' entry in linkgit:gitglossary[7].
zh_HANS-CN: 参见 linkgit:gitglossary[7] 中的'pathspec'条目。

note: type: Plain text
en: The output from this command is designed to be used as a commit template comment.  The default, long format, is designed to be human readable, verbose and descriptive.  Its contents and format are subject to change at any time.
zh_HANS-CN: 这个命令的输出是用来作为提交模板注释的。  默认的长篇格式是为了让人可读性强、言简意赅和描述性好。  其内容和格式可以随时更改。

note: type: Plain text
en: The paths mentioned in the output, unlike many other Git commands, are made relative to the current directory if you are working in a subdirectory (this is on purpose, to help cutting and pasting). See the status.relativePaths config option below.
zh_HANS-CN: 与许多其他 Git 命令不同，如果你在子目录中工作，输出中提到的路径是相对于当前目录的（这是故意的，以帮助剪切和粘贴）。参见下面的 status.relativePaths 配置选项。

note: type: Title ~
en: Short Format
zh_HANS-CN: 简短格式

note: type: Plain text
en: In the short-format, the status of each path is shown as one of these forms
zh_HANS-CN: 在简短的格式中，每个路径的状态显示为以下形式之一

note: type: Plain text
en: where `ORIG_PATH` is where the renamed/copied contents came from. `ORIG_PATH` is only shown when the entry is renamed or copied. The `XY` is a two-letter status code.
zh_HANS-CN: 其中`ORIG_PATH`是重命名/复制的内容的来源。`ORIG_PATH`只有在条目被重命名或复制时才会显示。`XY`是一个双字母的状态代码。

note: type: Plain text
en: The fields (including the `->`) are separated from each other by a single space. If a filename contains whitespace or other nonprintable characters, that field will be quoted in the manner of a C string literal: surrounded by ASCII double quote (34) characters, and with interior special characters backslash-escaped.
zh_HANS-CN: 各个字段（包括`->`）之间用一个空格隔开。如果一个文件名包含空白或其他不可打印的字符，该字段将以C语言字符串字面的方式被引用：由ASCII双引号（34）字符包围，内部的特殊字符被反斜线省略。

note: type: Plain text
en: There are three different types of states that are shown using this format, and each one uses the `XY` syntax differently:
zh_HANS-CN: 有三种不同类型的状态是使用这种格式显示的，每一种都以不同的方式使用`XY`语法。

note: type: Plain text
en: When a merge is occurring and the merge was successful, or outside of a merge
zh_HANS-CN: 当一个合并正在发生并且合并成功时，或者在合并之外

note: type: Plain text
en: situation, `X` shows the status of the index and `Y` shows the status of the working tree.
zh_HANS-CN: 情况，`X`显示索引的状态，`Y`显示工作树的状态。

note: type: Plain text
en: When a merge conflict has occurred and has not yet been resolved, `X` and `Y`
zh_HANS-CN: 当发生合并冲突且尚未解决时，"X "和 "Y "就会出现。

note: type: Plain text
en: show the state introduced by each head of the merge, relative to the common ancestor. These paths are said to be _unmerged_.
zh_HANS-CN: 显示了相对于共同祖先而言，合并的每个头所引入的状态。这些路径被称为_未合并_。

note: type: Plain text
en: When a path is untracked, `X` and `Y` are always the same, since they are
zh_HANS-CN: 当一个路径没有被追踪时，`X`和`Y`总是相同的，因为它们是

note: type: Plain text
en: unknown to the index. `??` is used for untracked paths. Ignored files are not listed unless `--ignored` is used; if it is, ignored files are indicated by `!!`.
zh_HANS-CN: 未知的索引。`??`用于未跟踪的路径。除非使用了`--ignored`，否则不列出被忽略的文件；如果使用了，则用`！！`表示被忽略的文件。

note: type: Plain text
en: Note that the term _merge_ here also includes rebases using the default `--merge` strategy, cherry-picks, and anything else using the merge machinery.
zh_HANS-CN: 请注意，这里的_merge_也包括使用默认的`--merge`策略的rebases，cherry-pick，以及其他任何使用merge机制的东西。

note: type: Plain text
en: In the following table, these three classes are shown in separate sections, and these characters are used for `X` and `Y` fields for the first two sections that show tracked paths:
zh_HANS-CN: 在下面的表格中，这三个类别分别显示在不同的部分，这些字符用于显示跟踪路径的前两个部分的`X`和`Y`字段。

note: type: Plain text
en: ' ' = unmodified
zh_HANS-CN: '' = 未修改的

note: type: Plain text
en: 'M' = modified
zh_HANS-CN: 'M' = 修改过的

note: type: Plain text
en: 'A' = added
zh_HANS-CN: 'A'=添加

note: type: Plain text
en: 'D' = deleted
zh_HANS-CN: 'D' = 删除

note: type: Plain text
en: 'R' = renamed
zh_HANS-CN: 'R' = 重命名

note: type: Plain text
en: 'U' = updated but unmerged
zh_HANS-CN: 'U'=更新但未合并

note: type: delimited block .
en: X          Y     Meaning
    -------------------------------------------------
    	 [AMD]   not updated
    M        [ MTD]  updated in index
    T        [ MTD]  type changed in index
    A        [ MTD]  added to index
    D                deleted from index
    R        [ MTD]  renamed in index
    C        [ MTD]  copied in index
    [MTARC]          index and work tree matches
    [ MTARC]    M    work tree changed since index
    [ MTARC]    T    type changed in work tree since index
    [ MTARC]    D    deleted in work tree
    	    R    renamed in work tree
    	    C    copied in work tree
    -------------------------------------------------
    D           D    unmerged, both deleted
    A           U    unmerged, added by us
    U           D    unmerged, deleted by them
    U           A    unmerged, added by them
    D           U    unmerged, deleted by us
    A           A    unmerged, both added
    U           U    unmerged, both modified
    -------------------------------------------------
    ?           ?    untracked
    !           !    ignored
    -------------------------------------------------
zh_HANS-CN: X Y的含义
    -------------------------------------------------
    	 [AMD]未更新
    M [MTD] 在索引中更新
    T [MTD] 类型在索引中有所改变
    A [MTD] 添加到索引中
    D 从索引中删除
    R [MTD] 在索引中重新命名
    C [MTD] 在索引中被复制
    [MTARC] 索引和工作树匹配
    [MTARC] 自索引以来，M工作树发生了变化
    [MTARC] 工作树中的T类型自索引以来发生了变化
    [MTARC] D在工作树中被删除
    	    R在工作树中重新命名
    	    C在工作树中被复制
    -------------------------------------------------
    D D未合并，均已删除
    A U 未合并，由我们添加
    U D未合并，被他人删除
    U A 未合并，由他人添加
    D U未合并，被我们删除
    A A未合并，都被添加
    U U未合并，都被修改
    -------------------------------------------------
    ?           未被追踪的
    !           忽略不计
    -------------------------------------------------

note: type: Plain text
en: Submodules have more state and instead report
    		M    the submodule has a different HEAD than
    		     recorded in the index
    		m    the submodule has modified content
    		?    the submodule has untracked files
    since modified content or untracked files in a submodule cannot be added
    via `git add` in the superproject to prepare a commit.
zh_HANS-CN: 子模块有更多的状态，而是报告
    		M的子模块有一个不同的HEAD比
    		     记录在索引中
    		m 该子模块有修改的内容
    		该子模块有未跟踪的文件
    因为子模块中的修改内容或未跟踪的文件不能被添加到
    通过超级项目中的`git add`来准备提交。

note: type: Plain text
en: 'm' and '?' are applied recursively. For example if a nested submodule in a submodule contains an untracked file, this is reported as '?' as well.
zh_HANS-CN: 'm'和'?'是递归应用的。例如，如果一个子模块中的嵌套子模块包含一个未跟踪的文件，这也会报告为'?'

note: type: Plain text
en: If -b is used the short-format status is preceded by a line
zh_HANS-CN: 如果使用了-b，短格式的状态前面会有一行

note: type: Title ~
en: Porcelain Format Version 1
zh_HANS-CN: 瓷器格式版本1

note: type: Plain text
en: Version 1 porcelain format is similar to the short format, but is guaranteed not to change in a backwards-incompatible way between Git versions or based on user configuration. This makes it ideal for parsing by scripts.  The description of the short format above also describes the porcelain format, with a few exceptions:
zh_HANS-CN: 第1版的瓷器格式与短格式类似，但保证不会在Git版本之间以向后兼容的方式或基于用户配置而改变。这使得它成为脚本解析的理想选择。  上面对短格式的描述也是对瓷器格式的描述，但有一些例外。

note: type: Plain text
en: The user's color.status configuration is not respected; color will always be off.
zh_HANS-CN: 用户的color.status配置不被尊重，颜色将永远是关闭的。

note: type: Plain text
en: The user's status.relativePaths configuration is not respected; paths shown will always be relative to the repository root.
zh_HANS-CN: 用户的 status.relativePaths 配置不被尊重；显示的路径将总是相对于版本库根目录。

note: type: Plain text
en: There is also an alternate -z format recommended for machine parsing. In that format, the status field is the same, but some other things change.  First, the '\->' is omitted from rename entries and the field order is reversed (e.g 'from \-> to' becomes 'to from'). Second, a NUL (ASCII 0) follows each filename, replacing space as a field separator and the terminating newline (but a space still separates the status field from the first filename).  Third, filenames containing special characters are not specially formatted; no quoting or backslash-escaping is performed.
zh_HANS-CN: 还有一种替代的-z格式，建议用于机器解析。在这种格式中，状态字段是相同的，但其他一些事情发生了变化。  首先，重命名条目中的"\->"被省略，字段顺序被颠倒（例如 "from\-> to "变成 "to from"）。第二，每个文件名后面都有一个NUL（ASCII 0），取代空格作为字段分隔符和终止换行符（但空格仍然将状态字段与第一个文件名分开）。  第三，包含特殊字符的文件名不被特别格式化；不进行引号或反斜线escaping。

note: type: Plain text
en: Any submodule changes are reported as modified `M` instead of `m` or single `?`.
zh_HANS-CN: 任何子模块的变化都被报告为修改的`M'，而不是`m'或单一的`?'。

note: type: Title ~
en: Porcelain Format Version 2
zh_HANS-CN: 瓷器格式版本2

note: type: Plain text
en: Version 2 format adds more detailed information about the state of the worktree and changed items.  Version 2 also defines an extensible set of easy to parse optional headers.
zh_HANS-CN: 第二版格式增加了关于工作树的状态和变化的项目的更多详细信息。  第2版还定义了一套可扩展的、易于解析的可选头文件。

note: type: Plain text
en: Header lines start with "#" and are added in response to specific command line arguments.  Parsers should ignore headers they don't recognize.
zh_HANS-CN: 标头行以 "#"开头，是为响应特定的命令行参数而添加的。  解析器应该忽略他们不认识的标题。

note: type: Title ^
en: Branch Headers
zh_HANS-CN: 分支机构负责人

note: type: Plain text
en: If `--branch` is given, a series of header lines are printed with information about the current branch.
zh_HANS-CN: 如果给了`--branch`，就会打印出一系列标题行，其中有关于当前分支的信息。

note: type: delimited block .
en: Line                                     Notes
    ------------------------------------------------------------
    # branch.oid <commit> | (initial)        Current commit.
    # branch.head <branch> | (detached)      Current branch.
    # branch.upstream <upstream_branch>      If upstream is set.
    # branch.ab +<ahead> -<behind>           If upstream is set and
    					 the commit is present.
    ------------------------------------------------------------
zh_HANS-CN: 线路说明
    ------------------------------------------------------------
    # branch.oid <commit> | (初始) 当前的提交。
    # branch.head <branch> | (detached) 当前分支。
    # branch.upstream <upstream_branch> 如果upstream被设置。
    # branch.ab +<ahead> -<behind> 如果上游被设置且
    					 的提交是存在的。
    ------------------------------------------------------------

note: type: Title ^
en: Changed Tracked Entries
zh_HANS-CN: 变更后的跟踪条目

note: type: Plain text
en: Following the headers, a series of lines are printed for tracked entries.  One of three different line formats may be used to describe an entry depending on the type of change.  Tracked entries are printed in an undefined order; parsers should allow for a mixture of the 3 line types in any order.
zh_HANS-CN: 在页眉之后，一系列的行被打印出来，用于追踪条目。  根据变化的类型，三种不同的行格式之一可用于描述一个条目。  追踪条目是以未定义的顺序打印的；解析器应允许以任何顺序混合使用这三种行类型。

note: type: Plain text
en: Ordinary changed entries have the following format:
zh_HANS-CN: 普通更改的条目有以下格式。

note: type: Plain text
en: Renamed or copied entries have the following format:
zh_HANS-CN: 重命名或复制的条目有以下格式。

note: type: delimited block .
en: Field       Meaning
    --------------------------------------------------------
    <XY>        A 2 character field containing the staged and
    	    unstaged XY values described in the short format,
    	    with unchanged indicated by a "." rather than
    	    a space.
    <sub>       A 4 character field describing the submodule state.
    	    "N..." when the entry is not a submodule.
    	    "S<c><m><u>" when the entry is a submodule.
    	    <c> is "C" if the commit changed; otherwise ".".
    	    <m> is "M" if it has tracked changes; otherwise ".".
    	    <u> is "U" if there are untracked changes; otherwise ".".
    <mH>        The octal file mode in HEAD.
    <mI>        The octal file mode in the index.
    <mW>        The octal file mode in the worktree.
    <hH>        The object name in HEAD.
    <hI>        The object name in the index.
    <X><score>  The rename or copy score (denoting the percentage
    	    of similarity between the source and target of the
    	    move or copy). For example "R100" or "C75".
    <path>      The pathname.  In a renamed/copied entry, this
    	    is the target path.
    <sep>       When the `-z` option is used, the 2 pathnames are separated
    	    with a NUL (ASCII 0x00) byte; otherwise, a tab (ASCII 0x09)
    	    byte separates them.
    <origPath>  The pathname in the commit at HEAD or in the index.
    	    This is only present in a renamed/copied entry, and
    	    tells where the renamed/copied contents came from.
    --------------------------------------------------------
zh_HANS-CN: 领域含义
    --------------------------------------------------------
    <XY> 一个2个字符的字段，包含短格式中描述的阶段性和非阶段性XY值。
    	    阶段性和非阶段性的XY值。
    	    不变的用". "表示，而不是用空格。
    	    而不是空格。
    <sub> 一个4个字符的字段，描述子模块的状态。
    	    "N... "当条目不是一个子模块时。
    	    "S<c><m><u>" 当条目是一个子模块。
    	    <c>是 "C"，如果提交改变了；否则是"."。
    	    <m> 如果它有跟踪的变化，则为 "M"；否则为"."。
    	    <u> 如果有未追踪的修改，则为 "U"；否则为"."。
    <mH> HEAD中的八进制文件模式。
    <mI> 索引中的八进制文件模式。
    <mW> 工作树中的八进制文件模式。
    <hH> HEAD中的对象名称。
    <hI> 索引中的对象名称。
    <X><score> 重命名或复制分数（表示源文件和目标文件之间的相似百分比）。
    	    源和目标之间的相似度）。
    	    移动或复制的目标之间的相似度）。)例如，"R100 "或 "C75"。
    <path> 路径名。  在一个重命名/复制的条目中，这
    	    是目标路径。
    <sep> 当使用`-z`选项时，两个路径名用NUL(ASCII 0x00)分隔。
    	    用一个NUL(ASCII 0x00)字节分开；否则，用一个TAB(ASCII 0x09)
    	    字节来分隔它们。
    <origPath> 在HEAD或索引中提交的路径名。
    	    这只存在于重命名/复制的条目中，并且
    	    告诉你重命名/复制的内容来自哪里。
    --------------------------------------------------------

note: type: Plain text
en: Unmerged entries have the following format; the first character is a "u" to distinguish from ordinary changed entries.
zh_HANS-CN: 未合并的条目有以下格式；第一个字符是 "u"，以区别于普通的变更条目。

note: type: delimited block .
en: Field       Meaning
    --------------------------------------------------------
    <XY>        A 2 character field describing the conflict type
    	    as described in the short format.
    <sub>       A 4 character field describing the submodule state
    	    as described above.
    <m1>        The octal file mode in stage 1.
    <m2>        The octal file mode in stage 2.
    <m3>        The octal file mode in stage 3.
    <mW>        The octal file mode in the worktree.
    <h1>        The object name in stage 1.
    <h2>        The object name in stage 2.
    <h3>        The object name in stage 3.
    <path>      The pathname.
    --------------------------------------------------------
zh_HANS-CN: 领域含义
    --------------------------------------------------------
    <XY> 一个2个字符的字段，描述冲突类型
    	    描述冲突类型。
    <sub> 一个4个字符的字段，描述子模块的状态
    	    如上所述。
    <m1> 阶段1中的八进制文件模式。
    <m2> 阶段2中的八进制文件模式。
    <m3> 阶段3中的八进制文件模式。
    <mW> 工作树中的八进制文件模式。
    <h1> 阶段1中的对象名称。
    <h2> 第二阶段的对象名称。
    <h3> 第三阶段的对象名称。
    <path> 路径名。
    --------------------------------------------------------

note: type: Title ^
en: Other Items
zh_HANS-CN: 其他项目

note: type: Plain text
en: Following the tracked entries (and if requested), a series of lines will be printed for untracked and then ignored items found in the worktree.
zh_HANS-CN: 在跟踪的条目之后（如果要求的话），将打印一系列未跟踪的行，然后是在工作树中发现的忽略的条目。

note: type: Plain text
en: Untracked items have the following format:
zh_HANS-CN: 未跟踪的项目有以下格式。

note: type: Plain text
en:     ? <path>
zh_HANS-CN:     ?<路径>

note: type: Plain text
en: Ignored items have the following format:
zh_HANS-CN: 被忽略的项目有以下格式。

note: type: Plain text
en:     ! <path>
zh_HANS-CN:     !<路径>的情况下

note: type: Title ^
en: Pathname Format Notes and -z
zh_HANS-CN: 路径名格式说明和-z

note: type: Plain text
en: When the `-z` option is given, pathnames are printed as is and without any quoting and lines are terminated with a NUL (ASCII 0x00)  byte.
zh_HANS-CN: 当给定"-z "选项时，路径名将按原样打印，没有任何引号，并且以NUL（ASCII 0x00）字节结束行。

note: type: Plain text
en: Without the `-z` option, pathnames with "unusual" characters are quoted as explained for the configuration variable `core.quotePath` (see linkgit:git-config[1]).
zh_HANS-CN: 如果没有`-z`选项，带有 "不寻常 "字符的路径名将被引用，正如对配置变量`core.quotePath`的解释（见linkgit:git-config[1]）。

note: type: Plain text
en: The command honors `color.status` (or `status.color` -- they mean the same thing and the latter is kept for backward compatibility) and `color.status.<slot>` configuration variables to colorize its output.
zh_HANS-CN: 该命令使用`color.status`（或`status.color`--它们的意思是一样的，为了向后兼容，保留后者）和`color.status.<slot>`配置变量来为其输出着色。

note: type: Plain text
en: If the config variable `status.relativePaths` is set to false, then all paths shown are relative to the repository root, not to the current directory.
zh_HANS-CN: 如果配置变量`status.relativePaths`被设置为false，那么所有显示的路径都是相对于版本库根目录的，而不是当前目录。

note: type: Plain text
en: If `status.submoduleSummary` is set to a non zero number or true (identical to -1 or an unlimited number), the submodule summary will be enabled for the long format and a summary of commits for modified submodules will be shown (see --summary-limit option of linkgit:git-submodule[1]). Please note that the summary output from the status command will be suppressed for all submodules when `diff.ignoreSubmodules` is set to 'all' or only for those submodules where `submodule.<name>.ignore=all`. To also view the summary for ignored submodules you can either use the --ignore-submodules=dirty command line option or the 'git submodule summary' command, which shows a similar output but does not honor these settings.
zh_HANS-CN: 如果`status.submoduleSummary`被设置为一个非零的数字或true（与-1或无限制的数字相同），子模块摘要将启用长格式，并显示修改的子模块的提交摘要（见linkgit:git-submodule[1]的-summary-limit选项）。请注意，当`diff.ignoreSubmodules`被设置为'all'或仅为那些`submodule.<name>.ignore=all'的子模块，状态命令的摘要输出将被抑制。要查看被忽略的子模块的摘要，你可以使用 --ignore-submodules=dirty 命令行选项或 "git submodule summary "命令，它显示类似的输出，但不尊重这些设置。

note: type: Title -
en: BACKGROUND REFRESH
zh_HANS-CN: 背景刷新

note: type: Plain text
en: By default, `git status` will automatically refresh the index, updating the cached stat information from the working tree and writing out the result. Writing out the updated index is an optimization that isn't strictly necessary (`status` computes the values for itself, but writing them out is just to save subsequent programs from repeating our computation). When `status` is run in the background, the lock held during the write may conflict with other simultaneous processes, causing them to fail. Scripts running `status` in the background should consider using `git --no-optional-locks status` (see linkgit:git[1] for details).
zh_HANS-CN: 默认情况下，`git status`会自动刷新索引，更新工作树上缓存的状态信息，并将结果写出来。写出更新的索引是一种优化，严格来说并无必要（`status`为自己计算数值，但写出它们只是为了避免后续程序重复我们的计算）。当`status`在后台运行时，在写入过程中持有的锁可能与其他同时进行的进程发生冲突，导致它们失败。在后台运行`status`的脚本应该考虑使用`git --no-optional-locks status`（详见linkgit:git[1]）。

note: type: Plain text
en: `git status` can be very slow in large worktrees if/when it needs to search for untracked files and directories. There are many configuration options available to speed this up by either avoiding the work or making use of cached results from previous Git commands. There is no single optimum set of settings right for everyone. We'll list a summary of the relevant options to help you, but before going into the list, you may want to run `git status` again, because your configuration may already be caching `git status` results, so it could be faster on subsequent runs.
zh_HANS-CN: `git status`在大型工作树中，如果/当它需要搜索未被追踪的文件和目录时，速度会非常慢。有许多配置选项可以通过避免这种操作或是利用以前的 Git 命令的缓存结果来加快速度。但是没有一套适合所有人的最佳设置。我们将列出相关选项的摘要以帮助你，但在进入列表之前，你可能想再次运行`git status`，因为你的配置可能已经缓存了`git status`的结果，所以在随后的运行中可能会更快。

note: type: Plain text
en: `status.showUntrackedfiles=false` config (see above for both): indicate that `git status` should not report untracked files. This is the fastest option. `git status` will not list the untracked files, so you need to be careful to remember if you create any new files and manually `git add` them.
zh_HANS-CN: 设置`status.showUntrackedfiles=false`：表示`git status`不应该报告未跟踪的文件。这是最快的选项。`git status`不会列出未跟踪的文件，所以你得注意，在创建任何新的文件后，需要手动`git add`它们。

note: type: Plain text
en: `advice.statusUoption=false` (see linkgit:git-config[1]):
zh_HANS-CN: `advice.statusUoption=false`（见linkgit:git-config[1]）：

note: type: Plain text
en: setting this variable to `false` disables the warning message given when enumerating untracked files takes more than 2 seconds.  In a large project, it may take longer and the user may have already accepted the trade off (e.g. using "-uno" may not be an acceptable option for the user), in which case, there is no point issuing the warning message, and in such a case, disabling the warning may be the best.
zh_HANS-CN: 将此变量设置为 "false"，当列举未跟踪的文件需要超过2秒时，将禁用警告信息。  在一个大型项目中，可能需要更长的时间，而且用户可能已经接受了这种设置（例如，使用"-uno"可能不是用户可以接受的选项）。在这种情况下，发出警告信息没有意义，禁用警告可能是最好的。

note: type: Plain text
en: enable the untracked cache feature and only search directories that have been modified since the previous `git status` command.  Git remembers the set of untracked files within each directory and assumes that if a directory has not been modified, then the set of untracked files within has not changed.  This is much faster than enumerating the contents of every directory, but still not without cost, because Git still has to search for the set of modified directories. The untracked cache is stored in the `.git/index` file. The reduced cost of searching for untracked files is offset slightly by the increased size of the index and the cost of keeping it up-to-date. That reduced search time is usually worth the additional size.
zh_HANS-CN: 启用未跟踪缓存功能，只搜索自上一个 `git status` 命令以来修改过的目录。 Git 会记住每个目录中的未跟踪文件集，并假定如果目录未被修改，则其中的未跟踪文件集不会更改。这比枚举每个目录的内容要快得多，但这依然有代价，因为 Git 仍然需要搜索修改目录的集合。未跟踪的缓存存储在 .git/index 文件中。搜索未跟踪文件的成本降低被索引大小的增加和保持最新的成本所抵消。缩短的搜索时间通常值得新增额外的大小。

note: type: Plain text
en: `core.untrackedCache=true` and `core.fsmonitor=true` or
zh_HANS-CN: `core.untrackedCache=true`和`core.fsmonitor=true`或

note: type: Plain text
en: `core.fsmonitor=<hook_command_pathname>` (see linkgit:git-update-index[1]): enable both the untracked cache and FSMonitor features and only search directories that have been modified since the previous `git status` command.  This is faster than using just the untracked cache alone because Git can also avoid searching for modified directories.  Git only has to enumerate the exact set of directories that have changed recently. While the FSMonitor feature can be enabled without the untracked cache, the benefits are greatly reduced in that case.
zh_HANS-CN: `core.fsmonitor=<hook_command_pathname>`（见linkgit:git-update-index[1]）：同时启用无痕缓存和FSMonitor功能，只搜索自上一条`git status'命令以来被修改的目录。  这比单独使用无痕缓存要快，因为Git也可以避免搜索被修改的目录。  Git只需要列举出最近有变化的确切目录集。虽然FSMonitor功能可以在没有无痕缓存的情况下启用，但在这种情况下好处会大大减少。

note: type: Plain text
en: Note that after you turn on the untracked cache and/or FSMonitor features it may take a few `git status` commands for the various caches to warm up before you see improved command times.  This is normal.
zh_HANS-CN: 请注意，在你打开无痕缓存和/或FSMonitor功能后，可能需要几个`git status'命令来让各种缓存活动起来，然后你才能看到命令耗时的改善，这很正常。

note: type: Plain text
en: git-stripspace - Remove unnecessary whitespace
zh_HANS-CN: git-stripspace - 去除不必要的空白

note: type: Plain text
en: Read text, such as commit messages, notes, tags and branch descriptions, from the standard input and clean it in the manner used by Git.
zh_HANS-CN: 从标准输入中读取文本，如提交信息、注释、标签和分支描述，并按照 Git 使用的方式进行清理。

note: type: Plain text
en: With no arguments, this will:
zh_HANS-CN: 如果没有任何参数，就会这样：

note: type: Plain text
en: remove trailing whitespace from all lines
zh_HANS-CN: 删除所有行的尾部空白

note: type: Plain text
en: collapse multiple consecutive empty lines into one empty line
zh_HANS-CN: 将多个连续空行折叠为一个空行

note: type: Plain text
en: remove empty lines from the beginning and end of the input
zh_HANS-CN: 删除输入内容开头和结尾的空行

note: type: Plain text
en: add a missing '\n' to the last line if necessary.
zh_HANS-CN: 如有必要，在最后一行添加一个缺失的 '\n'。

note: type: Plain text
en: In the case where the input consists entirely of whitespace characters, no output will be produced.
zh_HANS-CN: 如果输入完全由空白字符组成，则不会产生任何输出。

note: type: Plain text
en: *NOTE*: This is intended for cleaning metadata, prefer the `--whitespace=fix`
    mode of linkgit:git-apply[1] for correcting whitespace of patches or files in
    the repository.
zh_HANS-CN: *注意*： 这是用来清理元数据的，请优先使用 `--whitespace=fix` 模式来修正补丁或文件中的空白。
    模式来修正补丁或仓库中文件的空白。
    仓库中的补丁或文件

note: type: Plain text
en: Skip and remove all lines starting with comment character (default '#').
zh_HANS-CN: 跳过并删除所有以注释字符（默认为 "#"）开头的行。

note: type: Plain text
en: Prepend comment character and blank to each line. Lines will automatically be terminated with a newline. On empty lines, only the comment character will be prepended.
zh_HANS-CN: 在每行前添加注释字符和空白。行将自动以换行符结束。对于空行，只会预置注释字符。

note: type: Plain text
en: Given the following noisy input with '$' indicating the end of a line:
zh_HANS-CN: 给定以下噪音输入，'$' 表示一行的结束：

note: type: Plain text
en: Use 'git stripspace' with no arguments to obtain:
zh_HANS-CN: 使用不带参数的 'git stripspace' 获取：

note: type: Plain text
en: Use 'git stripspace --strip-comments' to obtain:
zh_HANS-CN: 使用 'git stripspace --strip-comments' 获取：

note: type: Plain text
en: 'git submodule' [--quiet] [--cached]
    'git submodule' [--quiet] add [<options>] [--] <repository> [<path>]
    'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
    'git submodule' [--quiet] init [--] [<path>...]
    'git submodule' [--quiet] deinit [-f|--force] (--all|[--] <path>...)
    'git submodule' [--quiet] update [<options>] [--] [<path>...]
    'git submodule' [--quiet] set-branch [<options>] [--] <path>
    'git submodule' [--quiet] set-url [--] <path> <newurl>
    'git submodule' [--quiet] summary [<options>] [--] [<path>...]
    'git submodule' [--quiet] foreach [--recursive] <command>
    'git submodule' [--quiet] sync [--recursive] [--] [<path>...]
    'git submodule' [--quiet] absorbgitdirs [--] [<path>...]
zh_HANS-CN: 'git submodule' [--quiet] [--cached]
    'git submodule' [--quiet] add [<单/多个选项>] [--] <仓库> [<路径>]
    'git submodule' [--quiet] status [--cached] [--recursive] [--] [<路径>...]
    'git submodule' [--quiet] init [--] [<路径>...]
    'git submodule' [--quiet] deinit [-f|--force] (--all|[--] <路径>...)
    'git submodule' [--quiet] update [<单/多个选项>] [--] [<路径>...]
    'git submodule' [--quiet] set-branch [<单/多个选项>] [--] <路径>
    'git submodule' [--quiet] set-url [--] <路径> <newurl>
    'git submodule' [--quiet] summary [<单/多个选项>] [--] [<路径>...]
    'git submodule' [--quiet] foreach [--recursive] <命令>
    'git submodule' [--quiet] sync [--recursive] [--] [<路径>...]
    'git submodule' [--quiet] absorbgitdirs [--] [<路径>...]

note: type: Plain text
en: Inspects, updates and manages submodules.
zh_HANS-CN: 检查、更新和管理子模块。

note: type: Plain text
en: For more information about submodules, see linkgit:gitsubmodules[7].
zh_HANS-CN: 关于子模块的更多信息，见 linkgit:gitsubmodules[7]。

note: type: Plain text
en: With no arguments, shows the status of existing submodules.  Several subcommands are available to perform operations on the submodules.
zh_HANS-CN: 没有参数，显示现有子模块的状态。 有几个子命令可用于对子模块进行操作。

note: type: Labeled list
en: add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--depth <depth>] [--] <repository> [<path>]
zh_HANS-CN: add [-b <分支>] [-f|--force] [--name <名称>] [--reference <仓库>] [--depth <深度>] [--] <仓库> [<路径>]

note: type: Plain text
en: Add the given repository as a submodule at the given path to the changeset to be committed next to the current project: the current project is termed the "superproject".
zh_HANS-CN: 将给定的版本库作为子模块在给定的路径上添加到当前项目旁边要提交的变更集：当前项目被称为 "父项目"。

note: type: Plain text
en: <repository> is the URL of the new submodule's origin repository.  This may be either an absolute URL, or (if it begins with ./ or ../), the location relative to the superproject's default remote repository (Please note that to specify a repository 'foo.git' which is located right next to a superproject 'bar.git', you'll have to use `../foo.git` instead of `./foo.git` - as one might expect when following the rules for relative URLs - because the evaluation of relative URLs in Git is identical to that of relative directories).
zh_HANS-CN: <仓库> 是新子模块仓库的 URL。 这可以是一个绝对 URL，或者（如果它以 ./ 或 ../ 开头），相对于父项目的默认远程仓库的位置（请注意，要指定一个紧挨着父项目 'bar.git' 的仓库 'foo.git'，你必须使用 `../foo.git` 而不是 `./foo.git` 正如人们在遵循相对 URL 的规则时可能期望的那样，因为 Git 中相对 URLs 的解释与相对目录是一样的）。

note: type: Plain text
en: The default remote is the remote of the remote-tracking branch of the current branch. If no such remote-tracking branch exists or the HEAD is detached, "origin" is assumed to be the default remote.  If the superproject doesn't have a default remote configured the superproject is its own authoritative upstream and the current working directory is used instead.
zh_HANS-CN: 默认的远程是当前分支的远程跟踪分支的远程。如果没有这样的远程跟踪分支，或者 HEAD 被分离了，"origin" 就会被假定为默认远程。 如果父项目没有配置默认的远程，那么父项目就是它自己的权威上游，并使用当前工作目录代替。

note: type: Plain text
en: The optional argument <path> is the relative location for the cloned submodule to exist in the superproject. If <path> is not given, the canonical part of the source repository is used ("repo" for "/path/to/repo.git" and "foo" for "host.xz:foo/.git"). If <path> exists and is already a valid Git repository, then it is staged for commit without cloning. The <path> is also used as the submodule's logical name in its configuration entries unless `--name` is used to specify a logical name.
zh_HANS-CN: 可选参数 <路径> 是克隆的子模块在父项目中存在的相对位置。如果没有给出 <路径>，则使用源仓库的规范部分（"repo" 表示 "/path/to/repo.git"，"foo" 表示 "host.xz:foo/.git"）。如果 <路径> 存在并且已经是一个有效的 Git 仓库，那么它将被暂存提交，而无需克隆。<路径> 也被用作子模块在其配置项中的逻辑名称，除非用 `--name` 来指定一个逻辑名称。

note: type: Plain text
en: The given URL is recorded into `.gitmodules` for use by subsequent users cloning the superproject. If the URL is given relative to the superproject's repository, the presumption is the superproject and submodule repositories will be kept together in the same relative location, and only the superproject's URL needs to be provided.  git-submodule will correctly locate the submodule using the relative URL in `.gitmodules`.
zh_HANS-CN: 给定的 URL 被记录到 `.gitmodules` 中，供后续用户克隆父项目时使用。如果 URL 是相对于父项目的仓库给出的，则假定父项目和子模块仓库将被保存在同一相对位置，只需要提供父项目的URL。git-submodule 将使用 `.gitmodules` 中的相对 URL 正确定位子模块。

note: type: Labeled list
en: status [--cached] [--recursive] [--] [<path>...]
zh_HANS-CN: status [--cached] [--recursive] [--] [<路径>...]

note: type: Plain text
en: Show the status of the submodules. This will print the SHA-1 of the currently checked out commit for each submodule, along with the submodule path and the output of 'git describe' for the SHA-1. Each SHA-1 will possibly be prefixed with `-` if the submodule is not initialized, `+` if the currently checked out submodule commit does not match the SHA-1 found in the index of the containing repository and `U` if the submodule has merge conflicts.
zh_HANS-CN: 显示子模块的状态。这将打印每个子模块当前检出提交的 SHA-1，以及子模块的路径和 SHA-1 的 'git describe' 的输出。如果子模块没有被初始化，每个SHA-1 的前缀可能是 `-`；如果当前签出的子模块提交与包含仓库的索引中发现的 SHA-1 不匹配，则是 `+`；如果子模块有合并冲突，则是 `U`。

note: type: Plain text
en: If `--cached` is specified, this command will instead print the SHA-1 recorded in the superproject for each submodule.
zh_HANS-CN: 如果指定了 `--cached`，这个命令将代替打印每个子模块父项目中记录的 SHA-1。

note: type: Plain text
en: If `--recursive` is specified, this command will recurse into nested submodules, and show their status as well.
zh_HANS-CN: 如果指定了 `--recursive`，该命令将递归到嵌套的子模块，并显示它们的状态。

note: type: Plain text
en: If you are only interested in changes of the currently initialized submodules with respect to the commit recorded in the index or the HEAD, linkgit:git-status[1] and linkgit:git-diff[1] will provide that information too (and can also report changes to a submodule's work tree).
zh_HANS-CN: 如果你只对当前初始化的子模块相对于索引或 HEAD 中记录的提交的变化感兴趣，linkgit:git-status[1] 和 linkgit:git-diff[1] 也会提供这些信息（也可以报告一个子模块工作目录的变化）。

note: type: Labeled list
en: init [--] [<path>...]
zh_HANS-CN: init [--] [<路径>...]

note: type: Plain text
en: Optional <path> arguments limit which submodules will be initialized.  If no path is specified and submodule.active has been configured, submodules configured to be active will be initialized, otherwise all submodules are initialized.
zh_HANS-CN: 可选的 <路径> 参数限制哪些子模块将被初始化。 如果没有指定路径，并且已经配置了 submodule.active，配置为激活的子模块将被初始化，否则所有的子模块都被初始化。

note: type: Plain text
en: It will also copy the value of `submodule.$name.update`, if present in the `.gitmodules` file, to `.git/config`, but (1) this command does not alter existing information in `.git/config`, and (2) `submodule.$name.update` that is set to a custom command is *not* copied for security reasons.
zh_HANS-CN: 如果 `.gitmodules` 文件中存在 `submodule.$name.update`，它也会将其值复制到 `.git/config`，但 (1) 该命令不会更改 `.git/config` 中的现有信息，(2) 出于安全考虑，设置为自定义命令的 `submodule.$name.update` 不会被复制。

note: type: Plain text
en: See the add subcommand for the definition of default remote.
zh_HANS-CN: 关于默认远程的定义，请参见 add 的子命令。

note: type: Labeled list
en: deinit [-f|--force] (--all|[--] <path>...)
zh_HANS-CN: deinit [-f|--force] (--all|[--] <路径>...)

note: type: Plain text
en: Unregister the given submodules, i.e. remove the whole `submodule.$name` section from .git/config together with their work tree. Further calls to `git submodule update`, `git submodule foreach` and `git submodule sync` will skip any unregistered submodules until they are initialized again, so use this command if you don't want to have a local checkout of the submodule in your working tree anymore.
zh_HANS-CN: 取消注册给定的子模块，即从 .git/config 中删除整个 `submodule.$name` 部分以及它们的工作目录。进一步调用 `git submodule update`，`git submodule foreach` 和 `git submodule sync` 将跳过任何未注册的子模块，直到它们再次被初始化，所以如果你不想在你的工作区上有一个本地的子模块检出，请使用这个命令。

note: type: Plain text
en: When the command is run without pathspec, it errors out, instead of deinit-ing everything, to prevent mistakes.
zh_HANS-CN: 当命令在没有路径规范的情况下运行时，它会出错，而不是删除所有内容，以防错误。

note: type: Plain text
en: If `--force` is specified, the submodule's working tree will be removed even if it contains local modifications.
zh_HANS-CN: 如果指定了 `--force`，子模块的工作目录将被删除，即使它包含了本地的修改。

note: type: Plain text
en: If you really want to remove a submodule from the repository and commit that use linkgit:git-rm[1] instead. See linkgit:gitsubmodules[7] for removal options.
zh_HANS-CN: 如果你真的想从仓库中删除一个子模块并提交，请使用 linkgit:git-rm[1] 代替。参见 linkgit:gitsubmodules[7] 的删除选项。

note: type: Labeled list
en: update [--init] [--remote] [-N|--no-fetch] [--[no-]recommend-shallow] [-f|--force] [--checkout|--rebase|--merge] [--reference <repository>] [--depth <depth>] [--recursive] [--jobs <n>] [--[no-]single-branch] [--filter <filter spec>] [--] [<path>...]
zh_HANS-CN: update [--init] [--remote] [-N|--no-fetch] [--[no-]recommend-shallow] [-f|--force] [--checkout|--rebase|--merge] [--reference <仓库>] [--depth <深度>] [--recursive] [--jobs <数量>] [--[no-]single-branch] [--filter <过滤规范>] [--] [<路径>...]

note: type: Plain text
en: the commit recorded in the superproject will be checked out in the submodule on a detached HEAD.
zh_HANS-CN: 在父项目中记录的提交将在分离的 HEAD 上的子模块中检出。

note: type: Plain text
en: If `--force` is specified, the submodule will be checked out (using `git checkout --force`), even if the commit specified in the index of the containing repository already matches the commit checked out in the submodule.
zh_HANS-CN: 如果指定了 `--force` ，子模块将被检出（使用 `git checkout --force`），即使在包含仓库的索引中指定的提交已经与子模块中检出的提交匹配。

note: type: Plain text
en: the current branch of the submodule will be rebased onto the commit recorded in the superproject.
zh_HANS-CN: 子模块的当前分支将被变基到父项目中记录的提交上。

note: type: Plain text
en: the commit recorded in the superproject will be merged into the current branch in the submodule.
zh_HANS-CN: 父项目中记录的提交将被合并到子模块中的当前分支。

note: type: Plain text
en: The following update procedures have additional limitations:
zh_HANS-CN: 以下更新程序有其他限制：

note: type: Labeled list
en: custom command
zh_HANS-CN: 自定义命令

note: type: Plain text
en: mechanism for running arbitrary commands with the commit ID as an argument. Specifically, if the `submodule.<name>.update` configuration variable is set to `!custom command`, the object name of the commit recorded in the superproject for the submodule is appended to the `custom command` string and executed. Note that this mechanism is not supported in the `.gitmodules` file or on the command line.
zh_HANS-CN: 以提交 ID 作为参数运行任意命令的机制。具体来说，如果 `submodule.<name>.update` 配置变量被设置为 `!custom command`，子模块的超级项目中记录的提交对象名称就会被附加到 `custom command` 字符串中并被执行。请注意，`.gitmodules` 文件或命令行均不支持该机制。

note: type: Plain text
en: the submodule is not updated. This update procedure is not allowed on the command line.
zh_HANS-CN: 子模块不会更新。命令行中不允许使用此更新程序。

note: type: Plain text
en: If the submodule is not yet initialized, and you just want to use the setting as stored in `.gitmodules`, you can automatically initialize the submodule with the `--init` option.
zh_HANS-CN: 如果子模块还没有被初始化，而你只是想使用存储在 `.gitmodules` 中的设置，你可以用 `--init` 选项自动初始化子模块。

note: type: Plain text
en: If `--recursive` is specified, this command will recurse into the registered submodules, and update any nested submodules within.
zh_HANS-CN: 如果指定了`--recursive`，该命令将递归到已注册的子模块中，并更新其中的任何嵌套子模块。

note: type: Plain text
en: If `--filter <filter spec>` is specified, the given partial clone filter will be applied to the submodule. See linkgit:git-rev-list[1] for details on filter specifications.
zh_HANS-CN: 如果指定了 `--filter <过滤规范>`，给定的部分克隆过滤器将被应用于子模块。关于过滤器规格细节，见 linkgit:git-rev-list[1]。

note: type: Labeled list
en: set-branch (-b|--branch) <branch> [--] <path>
zh_HANS-CN: set-branch (-b|--branch) <分支> [--] <路径>

note: type: Labeled list
en: set-branch (-d|--default) [--] <path>
zh_HANS-CN: set-branch (-d|--default) [--] <路径>

note: type: Plain text
en: Sets the default remote tracking branch for the submodule. The `--branch` option allows the remote branch to be specified. The `--default` option removes the submodule.<name>.branch configuration key, which causes the tracking branch to default to the remote 'HEAD'.
zh_HANS-CN: 设置子模块的默认远程跟踪分支。`--branch` 选项允许指定远程分支。`--default` 选项删除 submodule.<名称>.branch 配置键，使跟踪分支默认为远程 'HEAD'。

note: type: Labeled list
en: set-url [--] <path> <newurl>
zh_HANS-CN: set-url [--] <路径> <新url>

note: type: Plain text
en: Sets the URL of the specified submodule to <newurl>. Then, it will automatically synchronize the submodule's new remote URL configuration.
zh_HANS-CN: 将指定子模块的 URL 设置为 <新url>。然后，它将自动同步子模块的新远程 URL 配置。

note: type: Labeled list
en: summary [--cached|--files] [(-n|--summary-limit) <n>] [commit] [--] [<path>...]
zh_HANS-CN: summary [--cached|--files] [(-n|--summary-limit) <数量>] [commit] [--] [<路径>...]

note: type: Plain text
en: Show commit summary between the given commit (defaults to HEAD) and working tree/index. For a submodule in question, a series of commits in the submodule between the given super project commit and the index or working tree (switched by `--cached`) are shown. If the option `--files` is given, show the series of commits in the submodule between the index of the super project and the working tree of the submodule (this option doesn't allow to use the `--cached` option or to provide an explicit commit).
zh_HANS-CN: 显示指定的提交（默认为 HEAD）和工作区/索引之间的提交摘要。对于一个相关的子模块，显示该子模块在给定的父项目提交和索引或工作区（由 `--cached` 切换）之间的一系列提交。如果给出选项 `--files`，则显示父项目的索引和子模块的工作区之间的一系列提交（这个选项不允许使用 `--cached` 选项或提供明确的提交）。

note: type: Plain text
en: Using the `--submodule=log` option with linkgit:git-diff[1] will provide that information too.
zh_HANS-CN: 使用 linkgit:git-diff[1] 的 `--submodule=log` 选项也会提供这些信息。

note: type: Labeled list
en: foreach [--recursive] <command>
zh_HANS-CN: foreach [--recursive] <命令>

note: type: Plain text
en: Evaluates an arbitrary shell command in each checked out submodule.  The command has access to the variables $name, $sm_path, $displaypath, $sha1 and $toplevel: $name is the name of the relevant submodule section in `.gitmodules`, $sm_path is the path of the submodule as recorded in the immediate superproject, $displaypath contains the relative path from the current working directory to the submodules root directory, $sha1 is the commit as recorded in the immediate superproject, and $toplevel is the absolute path to the top-level of the immediate superproject.  Note that to avoid conflicts with '$PATH' on Windows, the '$path' variable is now a deprecated synonym of '$sm_path' variable.  Any submodules defined in the superproject but not checked out are ignored by this command. Unless given `--quiet`, foreach prints the name of each submodule before evaluating the command.  If `--recursive` is given, submodules are traversed recursively (i.e.  the given shell command is evaluated in nested submodules as well).  A non-zero return from the command in any submodule causes the processing to terminate. This can be overridden by adding '|| :' to the end of the command.
zh_HANS-CN: 在每个签出的子模块中评估一个任意的 shell 命令。 该命令可以访问变量 $name、$sm_path、$displaypath、$sha1 和 $toplevel：$name 是 `.gitmodules` 中相关子模块部分的名称，$sm_path 是即时父项目中记录的子模块的路径，$displaypath 包含从当前工作目录到子模块根目录的相对路径，$sha1 是即时父项目中记录的提交，而$toplevel 是即时父项目的顶级的绝对路径。 注意，为了避免与 Windows 上的 '$PATH' 冲突，'$path' 变量现在是 '$sm_path' 变量的一个废弃的同义词。 任何在父项目中定义但没有检查出来的子模块都会被这个命令忽略。除非给出 `--quiet`，否则 foreach 在评估命令前会打印出每个子模块的名字。 如果给定 `--recursive`，子模块将被递归遍历（即给定的 shel l命令在嵌套的子模块中也被评估）。 在任何子模块中，命令的非零返回将导致处理的终止。这可以通过在命令的末尾添加 '||:' 来覆盖。

note: type: Plain text
en: As an example, the command below will show the path and currently checked out commit for each submodule:
zh_HANS-CN: 作为一个例子，下面的命令将显示每个子模块的路径和当前检出的提交：

note: type: Labeled list
en: sync [--recursive] [--] [<path>...]
zh_HANS-CN: sync [--recursive] [--] [<路径>...]

note: type: Plain text
en: Synchronizes submodules' remote URL configuration setting to the value specified in `.gitmodules`. It will only affect those submodules which already have a URL entry in .git/config (that is the case when they are initialized or freshly added). This is useful when submodule URLs change upstream and you need to update your local repositories accordingly.
zh_HANS-CN: 将子模块的远程 URL 配置设置同步到 `.gitmodules` 中指定的值。它只会影响那些在 .git/config 中已经有一个 URL 条目的子模块（也就是当它们被初始化或新添加时的情况）。当子模块的 URL 在上游发生变化，你需要相应地更新你的本地仓库时，这很有用。

note: type: Plain text
en: `git submodule sync` synchronizes all submodules while `git submodule sync -- A` synchronizes submodule "A" only.
zh_HANS-CN: `git submodule sync` 同步所有子模块，而 `git submodule sync -- A` 只同步子模块 "A"。

note: type: Plain text
en: If `--recursive` is specified, this command will recurse into the registered submodules, and sync any nested submodules within.
zh_HANS-CN: 如果指定了 `--recursive`，该命令将递归到已注册的子模块中，并同步其中的任何嵌套子模块。

note: type: Labeled list
en: absorbgitdirs
zh_HANS-CN: 吸附 gitdirs

note: type: Plain text
en: If a git directory of a submodule is inside the submodule, move the git directory of the submodule into its superproject's `$GIT_DIR/modules` path and then connect the git directory and its working directory by setting the `core.worktree` and adding a .git file pointing to the git directory embedded in the superprojects git directory.
zh_HANS-CN: 如果一个子模块的 git 目录在子模块内部，将子模块的 git 目录移入其父项目的 `$GIT_DIR/modules` 路径，然后通过设置 `core.worktree` 连接 git 目录和其工作目录，并添加一个指向嵌入父项目 git 目录的 .git 文件。

note: type: Plain text
en: A repository that was cloned independently and later added as a submodule or old setups have the submodules git directory inside the submodule instead of embedded into the superprojects git directory.
zh_HANS-CN: 一个独立克隆的仓库，后来被添加为子模块或旧的设置，其子模块的 git 目录在子模块内，而不是嵌入到父项目的 git 目录。

note: type: Plain text
en: This command is recursive by default.
zh_HANS-CN: 这个命令默认是递归的。

note: type: Plain text
en: Only print error messages.
zh_HANS-CN: 只打印出错误信息。

note: type: Plain text
en: This option is only valid for add and update commands.  Progress status is reported on the standard error stream by default when it is attached to a terminal, unless -q is specified. This flag forces progress status even if the standard error stream is not directed to a terminal.
zh_HANS-CN: 这个选项只对添加和更新命令有效。 当标准错误流连接到终端时，除非指定了 -q，否则默认情况下进度状态会在标准错误流中报告。即使标准错误流没有指向终端，这个标志也会强制显示进度状态。

note: type: Plain text
en: This option is only valid for the deinit command. Unregister all submodules in the working tree.
zh_HANS-CN: 这个选项只对 deinit 命令有效。取消工作区中所有子模块的注册。

note: type: Labeled list
en: -b <branch>
zh_HANS-CN: -b <分支>

note: type: Plain text
en: Branch of repository to add as submodule.  The name of the branch is recorded as `submodule.<name>.branch` in `.gitmodules` for `update --remote`.  A special value of `.` is used to indicate that the name of the branch in the submodule should be the same name as the current branch in the current repository.  If the option is not specified, it defaults to the remote 'HEAD'.
zh_HANS-CN: 仓库的分支，作为子模块添加。 分支的名称在 `.gitmodules` 中记录为 `submodule.<名称>.branch`，用于 `update --remote`。 一个特殊的值 `.` 用来表示子模块中的分支名称应该与当前版本库中的当前分支名称相同。 如果没有指定该选项，则默认为远程 'HEAD'。

note: type: Plain text
en: This option is only valid for add, deinit and update commands.  When running add, allow adding an otherwise ignored submodule path.  When running deinit the submodule working trees will be removed even if they contain local changes.  When running update (only effective with the checkout procedure), throw away local changes in submodules when switching to a different commit; and always run a checkout operation in the submodule, even if the commit listed in the index of the containing repository matches the commit checked out in the submodule.
zh_HANS-CN: 这个选项只对 add、deinit 和 update 命令有效。 当运行 add 时，允许添加一个原本被忽略的子模块路径。 当运行 deinit 时，子模块的工作目录将被删除，即使它们包含本地的变化。 当运行 update（仅对 checkout 程序有效）时，当切换到不同的提交时，丢弃子模块中的本地修改；并且总是在子模块中运行 checkout 操作，即使在包含仓库的索引中列出的提交与子模块中签出的提交相匹配。

note: type: Plain text
en: This option is only valid for status and summary commands.  These commands typically use the commit found in the submodule HEAD, but with this option, the commit stored in the index is used instead.
zh_HANS-CN: 这个选项只对状态和摘要命令有效。 这些命令通常使用在子模块 HEAD 中找到的提交，但有了这个选项，就会使用存储在索引中的提交。

note: type: Plain text
en: This option is only valid for the summary command. This command compares the commit in the index with that in the submodule HEAD when this option is used.
zh_HANS-CN: 这个选项只对 summary 命令有效。当使用这个选项时，该命令将索引中的提交与子模块 HEAD 中的提交进行比较。

note: type: Plain text
en: This option is only valid for the summary command.  Limit the summary size (number of commits shown in total).  Giving 0 will disable the summary; a negative number means unlimited (the default). This limit only applies to modified submodules. The size is always limited to 1 for added/deleted/typechanged submodules.
zh_HANS-CN: 这个选项只对 summary 命令有效。 限制摘要的大小（总共显示的提交数量）。 给予 0 将禁用摘要；负数意味着无限（默认）。这个限制只适用于修改过的子模块。对于新增/删除/类型改变的子模块，其大小总是限制为 1。

note: type: Plain text
en: This option is only valid for the update command.  Instead of using the superproject's recorded SHA-1 to update the submodule, use the status of the submodule's remote-tracking branch.  The remote used is branch's remote (`branch.<name>.remote`), defaulting to `origin`.  The remote branch used defaults to the remote `HEAD`, but the branch name may be overridden by setting the `submodule.<name>.branch` option in either `.gitmodules` or `.git/config` (with `.git/config` taking precedence).
zh_HANS-CN: 这个选项只对更新命令有效。 不使用超级项目记录的 SHA-1 来更新子模块，而使用子模块的远程跟踪分支的状态。 使用的远程是分支的远程（`branch.<名称>.remote`），默认为 `origin`。 使用的远程分支默认为远程的 `HEAD`，但分支的名称可以通过在 `.gitmodules` 或 `.git/config` 中设置 `submodule.<名称>.branch` 选项来覆盖（以`.git/config`为先）。

note: type: Plain text
en: This works for any of the supported update procedures (`--checkout`, `--rebase`, etc.).  The only change is the source of the target SHA-1.  For example, `submodule update --remote --merge` will merge upstream submodule changes into the submodules, while `submodule update --merge` will merge superproject gitlink changes into the submodules.
zh_HANS-CN: 这适用于任何支持的更新程序（`--checkout`，`--rebase`，等等）。  唯一的变化是目标 SHA-1 的来源。  例如，`submodule update --remote --merge` 将把上游子模块的变化合并到子模块中，而 `submodule update --merge` 将把父项目的 gitlink 变化合并到子模块。

note: type: Plain text
en: In order to ensure a current tracking branch state, `update --remote` fetches the submodule's remote repository before calculating the SHA-1.  If you don't want to fetch, you should use `submodule update --remote --no-fetch`.
zh_HANS-CN: 为了确保当前的跟踪分支状态，`update --remote` 在计算 SHA-1 之前会获取子模块的远程仓库。  如果你不想获取，你应该使用`submodule update --remote --no-fetch`。

note: type: Plain text
en: Use this option to integrate changes from the upstream subproject with your submodule's current HEAD.  Alternatively, you can run `git pull` from the submodule, which is equivalent except for the remote branch name: `update --remote` uses the default upstream repository and `submodule.<name>.branch`, while `git pull` uses the submodule's `branch.<name>.merge`.  Prefer `submodule.<name>.branch` if you want to distribute the default upstream branch with the superproject and `branch.<name>.merge` if you want a more native feel while working in the submodule itself.
zh_HANS-CN: 使用这个选项可以将上游子项目的变化与你的子模块的当前 HEAD 集成。 或者，你可以从子模块运行 `git pull`，除了远程分支名称外，其他都是一样的：`update --remote` 使用默认的上游仓库和 `submodule.<名称>.branch`，而 `git pull` 使用子模块的 `branch.<名称>.merge`。 如果你想和父项目一起发布默认的上游分支，那么首选 `submodule.<名称>.branch`，如果你想在子模块本身工作时有更多的本地感觉，那么首选 `branch.<名称>.merge`。

note: type: Plain text
en: This option is only valid for the update command.  Don't fetch new objects from the remote site.
zh_HANS-CN: 这个选项只对 update 命令有效。 不要从远程站点获取新对象。

note: type: Plain text
en: This option is only valid for the update command.  Checkout the commit recorded in the superproject on a detached HEAD in the submodule. This is the default behavior, the main use of this option is to override `submodule.$name.update` when set to a value other than `checkout`.  If the key `submodule.$name.update` is either not explicitly set or set to `checkout`, this option is implicit.
zh_HANS-CN: 这个选项只对 update 命令有效。 检出父项目中记录在子模块中的分离 HEAD 上的提交。这是默认行为，这个选项的主要用途是在设置为 `checkout` 以外的值时覆盖 `submodule.$name.update`。 如果键 `submodule.$name.update` 没有明确设置或设置为 `checkout`，这个选项是隐含的。

note: type: Plain text
en: This option is only valid for the update command.  Merge the commit recorded in the superproject into the current branch of the submodule. If this option is given, the submodule's HEAD will not be detached. If a merge failure prevents this process, you will have to resolve the resulting conflicts within the submodule with the usual conflict resolution tools.  If the key `submodule.$name.update` is set to `merge`, this option is implicit.
zh_HANS-CN: 这个选项只对更新命令有效。 将父项目中记录的提交合并到子模块的当前分支中。如果给出这个选项，子模块的 HEAD 将不会被分离。如果合并失败阻止了这个过程，你将不得不用通常的冲突解决工具来解决子模块内产生的冲突。 如果键 `submodule.$name.update` 被设置为 `merge`，这个选项是隐含的。

note: type: Plain text
en: This option is only valid for the update command.  Rebase the current branch onto the commit recorded in the superproject. If this option is given, the submodule's HEAD will not be detached. If a merge failure prevents this process, you will have to resolve these failures with linkgit:git-rebase[1].  If the key `submodule.$name.update` is set to `rebase`, this option is implicit.
zh_HANS-CN: 这个选项只对 update 命令有效。 将当前分支重新归入超级项目中记录的提交。如果给了这个选项，子模块的 HEAD 将不会被分离。如果合并失败阻止了这个过程，你将不得不用 linkgit:git-rebase[1] 解决这些失败。 如果键 `submodule.$name.update` 被设置为 `rebase`，这个选项是隐含的。

note: type: Plain text
en: This option is only valid for the update command.  Initialize all submodules for which "git submodule init" has not been called so far before updating.
zh_HANS-CN: 这个选项只对 update 命令有效。 在更新前初始化所有到目前为止还没有调用过 "git submodule init " 的子模块。

note: type: Plain text
en: This option is only valid for the add command. It sets the submodule's name to the given string instead of defaulting to its path. The name must be valid as a directory name and may not end with a '/'.
zh_HANS-CN: 这个选项只对 add 命令有效。它将子模块的名称设置为给定的字符串，而不是默认为其路径。这个名字必须是有效的目录名，并且不能以 '/' 结尾。

note: type: Plain text
en: This option is only valid for add and update commands.  These commands sometimes need to clone a remote repository. In this case, this option will be passed to the linkgit:git-clone[1] command.
zh_HANS-CN: 这个选项只对添加和更新命令有效。 这些命令有时需要克隆一个远程版本库。在这种情况下，这个选项将被传递给 linkgit:git-clone[1] 命令。

note: type: Plain text
en: *NOTE*: Do *not* use this option unless you have read the note
    for linkgit:git-clone[1]'s `--reference`, `--shared`, and `--dissociate`
    options carefully.
zh_HANS-CN: *注意*： 请*不要*使用这个选项，除非你已经阅读了
    linkgit:git-clone[1] 的 `--reference`, `--shared`, 和 `--dissociate` 选项前
    谨慎使用这个选项。

note: type: Plain text
en: *NOTE*: see the NOTE for the `--reference` option.
zh_HANS-CN: *注意*：参见 `--reference` 选项的说明。

note: type: Plain text
en: This option is only valid for foreach, update, status and sync commands.  Traverse submodules recursively. The operation is performed not only in the submodules of the current repo, but also in any nested submodules inside those submodules (and so on).
zh_HANS-CN: 这个选项只对 foreach、update、status 和 sync 命令有效。 递归地遍历子模块。该操作不仅在当前仓库的子模块中执行，而且在这些子模块内部的任何嵌套子模块中也执行（以此类推）。

note: type: Plain text
en: This option is valid for add and update commands. Create a 'shallow' clone with a history truncated to the specified number of revisions.  See linkgit:git-clone[1]
zh_HANS-CN: 这个选项对 update 和 add 命令有效。创建一个 'shallow' 克隆，其历史被截断到指定的修订次数。 参见 linkgit:git-clone[1]

note: type: Plain text
en: This option is only valid for the update command.  The initial clone of a submodule will use the recommended `submodule.<name>.shallow` as provided by the `.gitmodules` file by default. To ignore the suggestions use `--no-recommend-shallow`.
zh_HANS-CN: 这个选项只对更新命令有效。 一个子模块的初始克隆将默认使用 `.gitmodules` 文件提供的推荐的 `submodule.<名称>.shallow`。要忽略这些建议，请使用 `--no-recommend-shallow`。

note: type: Plain text
en: This option is only valid for the update command.  Clone new submodules in parallel with as many jobs.  Defaults to the `submodule.fetchJobs` option.
zh_HANS-CN: 这个选项只对更新命令有效。 克隆新的子模块与尽可能多的作业并行。 默认为 `submodule.fetchJobs` 选项。

note: type: Plain text
en: This option is only valid for the update command.  Clone only one branch during update: HEAD or one specified by --branch.
zh_HANS-CN: 这个选项只对 update 命令有效。 在更新过程中只克隆一个分支：HEAD 或由 --branch 指定的一个分支。

note: type: Plain text
en: Paths to submodule(s). When specified this will restrict the command to only operate on the submodules found at the specified paths.  (This argument is required with add).
zh_HANS-CN: 子模块的路径。当指定时，这将限制该命令只对在指定路径上发现的子模块进行操作。 (这个参数在添加时是必需的）。

note: type: Plain text
en: When initializing submodules, a `.gitmodules` file in the top-level directory of the containing repository is used to find the url of each submodule.  This file should be formatted in the same way as `$GIT_DIR/config`. The key to each submodule url is "submodule.$name.url".  See linkgit:gitmodules[5] for details.
zh_HANS-CN: 当初始化子模块时，在包含仓库的顶级目录中的 `.gitmodules` 文件被用来寻找每个子模块的 URL。 这个文件的格式应该与 `$GIT_DIR/config` 相同。每个子模块网址的键是 "submodule.$name.url"。 详情见 linkgit:gitmodules[5]。

note: type: Plain text
en: 'git svn' <command> [<options>] [<arguments>]
zh_HANS-CN: 'git svn' <命令> [<选项>] [<参数>]

note: type: Plain text
en: This allows one to specify a prefix which is prepended to the names of remotes if trunk/branches/tags are specified.  The prefix does not automatically include a trailing slash, so be sure you include one in the argument if that is what you want.  If --branches/-b is specified, the prefix must include a trailing slash.  Setting a prefix (with a trailing slash) is strongly encouraged in any case, as your SVN-tracking refs will then be located at "refs/remotes/$prefix/*", which is compatible with Git's own remote-tracking ref layout (refs/remotes/$remote/*). Setting a prefix is also useful if you wish to track multiple projects that share a common repository.  By default, the prefix is set to 'origin/'.
zh_HANS-CN: 如果指定了 trunk/branches/tags，则可以指定一个前缀，将其添加到远程设备名称的前缀中。 前缀不会自动包含斜线，因此如果需要，请确保在参数中包含斜线。 如果指定了 --branches/-b，前缀必须包含斜线。 在任何情况下，我们都强烈建议设置前缀（带尾部斜线），因为这样你的 SVN 跟踪引用就会位于 "refs/remotes/$prefix/*"，这与 Git 自己的远程跟踪引用布局（refs/remotes/$remote/*）是兼容的。如果想跟踪共享一个仓库的多个项目，设置前缀也很有用。 默认情况下，前缀设置为 "origin/"。

note: type: Plain text
en: Before Git v2.0, the default prefix was "" (no prefix). This meant that SVN-tracking refs were put at "refs/remotes/*", which is incompatible with how Git's own remote-tracking refs are organized.  If you still want the old default, you can get it by passing `--prefix ""` on the command line (`--prefix=""` may not work if your Perl's Getopt::Long is < v2.37).
zh_HANS-CN: 在 Git v2.0 之前，默认前缀是""（无前缀）。这意味着 SVN 跟踪的引用被放在 "refs/remotes/*" 目录下，这与 Git 自身远程跟踪引用的组织方式不兼容。 如果你还想要旧的默认值，可以通过在命令行中传递 `--prefix""` 来实现（如果你的 Perl Getopt::Long 版本小于 2.37，则 `--prefix=""` 可能不起作用）。

note: type: Plain text
en: When passed to 'init' or 'clone' this regular expression will be preserved as a config key.  See 'fetch' for a description of `--ignore-refs`.
zh_HANS-CN: 当传递给 'init' 或 'clone' 时，该正则表达式将作为配置键保留。 有关 `--ignore-refs` 的描述，请参阅 'fetch'。

note: type: Plain text
en: When passed to 'init' or 'clone' this regular expression will be preserved as a config key.  See 'fetch' for a description of `--ignore-paths`.
zh_HANS-CN: 当传递给 'init' 或 'clone' 时，该正则表达式将作为配置键保留。 有关 `--ignore-paths` 的描述，请参阅 'fetch'。

note: type: Labeled list
en: --include-paths=<regex>
zh_HANS-CN: --include-paths=<正则表达式>

note: type: Plain text
en: When passed to 'init' or 'clone' this regular expression will be preserved as a config key.  See 'fetch' for a description of `--include-paths`.
zh_HANS-CN: 当传递给 'init' 或 'clone' 时，该正则表达式将作为配置键保留。 有关 `--include-paths` 的描述，请参阅 'fetch'。

note: type: Plain text
en: When tracking multiple directories (using --stdlayout, --branches, or --tags options), git svn will attempt to connect to the root (or highest allowed level) of the Subversion repository.  This default allows better tracking of history if entire projects are moved within a repository, but may cause issues on repositories where read access restrictions are in place.  Passing `--no-minimize-url` will allow git svn to accept URLs as-is without attempting to connect to a higher level directory.  This option is off by default when only one URL/branch is tracked (it would do little good).
zh_HANS-CN: 当跟踪多个目录时（使用 --stdlayout, --branches 或 --tags 选项），git svn 会尝试连接到 Subversion 仓库的根（或允许的最高级别）。 如果整个项目在仓库中移动，这一默认设置可以更好地跟踪历史，但在有读取权限限制的仓库中可能会引起问题。 如果传递 `--no-minimize-url`，git svn 就会按原样接受 URL，而不会尝试连接到更高级别的目录。 如果只跟踪一个 URL/branch（分支），该选项默认是关闭的（这样做没什么好处）。

note: type: Plain text
en: Fetch unfetched revisions from the Subversion remote we are tracking.  The name of the [svn-remote "..."] section in the $GIT_DIR/config file may be specified as an optional command-line argument.
zh_HANS-CN: 从我们正在跟踪的 Subversion 远程仓库中获取未抓取的版本。 $GIT_DIR/config 文件中 [svn-remote "..."] 部分的名称可作为命令行参数指定。

note: type: Plain text
en: This automatically updates the rev_map if needed (see '$GIT_DIR/svn/\**/.rev_map.*' in the FILES section below for details).
zh_HANS-CN: 如果需要，这将自动更新 rev_map（详情请参见下文 FILES 部分中的 '$GIT_DIR/svn/\**/.rev_map.*'）。

note: type: Plain text
en: Store Git commit times in the local time zone instead of UTC.  This makes 'git log' (even without --date=local) show the same times that `svn log` would in the local time zone.
zh_HANS-CN: 以本地时区而非 UTC 来存储 Git 提交时间。 这样，'git log'（即使没有 --date=local ）显示的时间与 'svn log' 在本地时区显示的时间相同。

note: type: Plain text
en: This doesn't interfere with interoperating with the Subversion repository you cloned from, but if you wish for your local Git repository to be able to interoperate with someone else's local Git repository, either don't use this option or you should both use it in the same local time zone.
zh_HANS-CN: 但如果你希望自己的本地 Git 仓库能与他人的本地 Git 仓库互操作，要么就不要使用该选项，要么就在同一时区同时使用。

note: type: Plain text
en: Fetch only from the SVN parent of the current HEAD.
zh_HANS-CN: 仅从当前 HEAD 的 SVN 父节点获取。

note: type: Plain text
en: Ignore refs for branches or tags matching the Perl regular expression. A "negative look-ahead assertion" like `^refs/remotes/origin/(?!tags/wanted-tag|wanted-branch).*$` can be used to allow only certain refs.
zh_HANS-CN: 忽略与 Perl 正则表达式匹配的分支或标记的引用。^refs/remotes/origin/(?!tags/wanted-tag|wanted-branch).*$`之类的 "否定前瞻断言 " 可用于只允许某些引用。

note: type: Plain text
en: config key: svn-remote.<name>.ignore-refs
zh_HANS-CN: config key: svn-remote.<名称>.ignore-refs

note: type: Plain text
en: If the ignore-refs configuration key is set, and the command-line option is also given, both regular expressions will be used.
zh_HANS-CN: 如果设置了 ignore-refs 配置键，并且还给出了命令行选项，则会同时使用这两种正则表达式。

note: type: Plain text
en: This allows one to specify a Perl regular expression that will cause skipping of all matching paths from checkout from SVN.  The `--ignore-paths` option should match for every 'fetch' (including automatic fetches due to 'clone', 'dcommit', 'rebase', etc) on a given repository.
zh_HANS-CN: 该选项允许指定一个 Perl 正则表达式，从而跳过所有与之匹配的 SVN 签出路径。 忽略路径 "选项应与指定仓库的每次 “获取”（包括 “克隆”、“提交”、“重置” 等导致的自动获取）相匹配。

note: type: Plain text
en: config key: svn-remote.<name>.ignore-paths
zh_HANS-CN: config key: svn-remote.<名称>.ignore-paths

note: type: Plain text
en: If the ignore-paths configuration key is set, and the command-line option is also given, both regular expressions will be used.
zh_HANS-CN: 如果设置了 ignore-paths 配置键，并且还给出了命令行选项，则会同时使用这两种正则表达式。

note: type: Labeled list
en: Skip "doc*" directory for every fetch
zh_HANS-CN: 每次提取都跳过 "doc*" 目录

note: type: Labeled list
en: Skip "branches" and "tags" of first level directories
zh_HANS-CN: 跳过一级目录的 "branches"（分支） 和 "tag"（标签）

note: type: Plain text
en: This allows one to specify a Perl regular expression that will cause the inclusion of only matching paths from checkout from SVN.  The `--include-paths` option should match for every 'fetch' (including automatic fetches due to 'clone', 'dcommit', 'rebase', etc) on a given repository. `--ignore-paths` takes precedence over `--include-paths`.
zh_HANS-CN: 该选项允许指定一个 Perl 正则表达式，使 SVN 在检出时只包含匹配的路径。 `-include-paths` 选项应与指定版本库的每次 “取回”（包括 “克隆”、"dcommit"、“变基” 等引起的自动取回）相匹配。`--ignore-paths` 优先于 `--include-paths`。

note: type: Plain text
en: config key: svn-remote.<name>.include-paths
zh_HANS-CN: config key: svn-remote.<名称>.include-paths

note: type: Plain text
en: Fetch <n> log entries per request when scanning Subversion history.  The default is 100. For very large Subversion repositories, larger values may be needed for 'clone'/'fetch' to complete in reasonable time. But overly large values may lead to higher memory usage and request timeouts.
zh_HANS-CN: 扫描 Subversion 历史记录时，每次请求获取 <n> 个日志条目。 默认值为 100。对于非常大的 Subversion 仓库，可能需要更大的值才能在合理的时间内完成 'clone'/'fetch'。但过大的值可能会导致更高的内存使用率和请求超时。

note: type: Plain text
en: Runs 'init' and 'fetch'.  It will automatically create a directory based on the basename of the URL passed to it; or if a second argument is passed; it will create a directory and work within that.  It accepts all arguments that the 'init' and 'fetch' commands accept; with the exception of `--fetch-all` and `--parent`.  After a repository is cloned, the 'fetch' command will be able to update revisions without affecting the working tree; and the 'rebase' command will be able to update the working tree with the latest changes.
zh_HANS-CN: 运行 'init' 和 'fetch'。 它会根据传递给它的 URL 的基名自动创建一个目录；如果传递了第二个参数，则会创建一个目录并在目录内工作。 它接受所有 'init' 和 'fetch' 命令接受的参数，但 `--fetch-all` 和 `--parent` 除外。 克隆仓库后，'fetch' 命令可以更新修订版本，而不影响工作区；'rebase' 命令可以用最新的修改更新工作区。

note: type: Plain text
en: Create a placeholder file in the local Git repository for each empty directory fetched from Subversion.  This includes directories that become empty by removing all entries in the Subversion repository (but not the directory itself).  The placeholder files are also tracked and removed when no longer necessary.
zh_HANS-CN: 在本地 Git 仓库中为每个从 Subversion 获取的空目录创建一个占位符文件。 这包括通过删除 Subversion 仓库中的所有条目（但不包括目录本身）而变为空的目录。 占位符文件也会被跟踪，并在不再需要时删除。

note: type: Plain text
en: Set the name of placeholder files created by --preserve-empty-dirs.  Default: ".gitignore"
zh_HANS-CN: 设置由 --preserve-empty-dirs 创建的占位符文件的名称。 默认：".gitignore"

note: type: Plain text
en: This fetches revisions from the SVN parent of the current HEAD and rebases the current (uncommitted to SVN) work against it.
zh_HANS-CN: 这将从当前 HEAD 的 SVN 父版本中获取修订版本，并将当前（未提交至 SVN）工作与之相对应。

note: type: Plain text
en: This works similarly to `svn update` or 'git pull' except that it preserves linear history with 'git rebase' instead of 'git merge' for ease of dcommitting with 'git svn'.
zh_HANS-CN: 除了用 'git rebase' 而不是 'git merge' 保留线性历史记录以便于用 'git svn' 提交外，它的工作原理与 `svn update` 或 'git pull' 类似。

note: type: Plain text
en: This accepts all options that 'git svn fetch' and 'git rebase' accept.  However, `--fetch-all` only fetches from the current [svn-remote], and not all [svn-remote] definitions.
zh_HANS-CN: 它接受所有 'git svn fetch' 和 'git rebase' 接受的选项。 不过，`--fetch-all` 只从当前 [svn-remote] 获取，而不是所有 [svn-remote] 定义。

note: type: Plain text
en: Like 'git rebase'; this requires that the working tree be clean and have no uncommitted changes.
zh_HANS-CN: 和 'git rebase' 一样，它要求工作区是干净的，没有未提交的更改。

note: type: Plain text
en: Do not fetch remotely; only run 'git rebase' against the last fetched commit from the upstream SVN.
zh_HANS-CN: 不要远程获取；只针对从上游 SVN 获取的最后一次提交运行 'git rebase'。

note: type: Plain text
en: Commit each diff from the current branch directly to the SVN repository, and then rebase or reset (depending on whether or not there is a diff between SVN and head).  This will create a revision in SVN for each commit in Git.
zh_HANS-CN: 将当前分支的每个差异直接提交到 SVN 仓库，然后重置或重置（取决于 SVN 和 head 之间是否有差异）。 这样，Git 中的每次提交都会在 SVN 中创建一个修订版本。

note: type: Plain text
en: When an optional Git branch name (or a Git commit object name)  is specified as an argument, the subcommand works on the specified branch, not on the current branch.
zh_HANS-CN: 当参数中指定了一个可选的 Git 分支名称（或 Git 提交对象名称）时，该子命令将在指定的分支而非当前分支上运行。

note: type: Plain text
en: Use of 'dcommit' is preferred to 'set-tree' (below).
zh_HANS-CN: 使用 'dcommit' 比使用 'set-tree'（下文）更可取。

note: type: Plain text
en: After committing, do not rebase or reset.
zh_HANS-CN: 提交后，请勿变基或重置。

note: type: Plain text
en: Commit to this SVN URL (the full path).  This is intended to allow existing 'git svn' repositories created with one transport method (e.g. `svn://` or `http://` for anonymous read) to be reused if a user is later given access to an alternate transport method (e.g. `svn+ssh://` or `https://`) for commit.
zh_HANS-CN: 提交到此 SVN URL（完整路径）。 这样做的目的是，如果用户后来获得了使用另一种传输方式（如 `svn+ssh://` 或 `https://`）提交的权限，那么使用一种传输方式（如匿名读取的 `svn://` 或 `http://`）创建的现有 'git svn' 仓库就可以重复使用。

note: type: Plain text
en: config key: svn-remote.<name>.commiturl
    config key: svn.commiturl (overwrites all svn-remote.<name>.commiturl options)
zh_HANS-CN: config key: svn-remote.<名称>.commiturl
    config key: svn.commiturl (覆盖所有的 svn-remote.<名称>.commiturl 选项)

note: type: Plain text
en: Note that the SVN URL of the commiturl config key includes the SVN branch.  If you rather want to set the commit URL for an entire SVN repository use svn-remote.<name>.pushurl instead.
zh_HANS-CN: 请注意，commiturl 配置键的 SVN URL 包括 SVN 分支。 如果你想为整个 SVN 仓库设置提交 URL，请使用 svn-remote.<名称>.pushurl。

note: type: Plain text
en: Using this option for any other purpose (don't ask) is very strongly discouraged.
zh_HANS-CN: 我们强烈反对将此选项用于任何其他目的（不要问）。

note: type: Plain text
en: Add the given merge information during the dcommit (e.g. `--mergeinfo="/branches/foo:1-10"`). All svn server versions can store this information (as a property), and svn clients starting from version 1.5 can make use of it. To specify merge information from multiple branches, use a single space character between the branches (`--mergeinfo="/branches/foo:1-10 /branches/bar:3,5-6,8"`)
zh_HANS-CN: 在 dcommit 时添加给定的合并信息（例如 `--mergeinfo="/branches/foo:1-10"`）。所有版本的 svn 服务器都可以存储此信息（作为属性），而从 1.5 版开始的 svn 客户端也可以使用它。要指定多个分支的合并信息，请在分支之间使用一个空格字符（`--mergeinfo="/branches/foo:1-10 /branches/bar:3,5-6,8"`)

note: type: Plain text
en: This option will cause git-svn to attempt to automatically populate the svn:mergeinfo property in the SVN repository when possible. Currently, this can only be done when dcommitting non-fast-forward merges where all parents but the first have already been pushed into SVN.
zh_HANS-CN: 此选项将使 git-svn 在可能的情况下尝试自动填充 SVN 仓库中的 svn:mergeinfo 属性。目前，只有在提交非快进合并时才能这样做，即除了第一个合并之外的所有父合并都已推送到 SVN。

note: type: Plain text
en: Ask the user to confirm that a patch set should actually be sent to SVN.  For each patch, one may answer "yes" (accept this patch), "no" (discard this patch), "all" (accept all patches), or "quit".
zh_HANS-CN: 要求用户确认是否应将补丁集发送到 SVN。 对于每个补丁，用户可以回答 "yes"（接受此补丁）、"no"（放弃此补丁）、"all"（接受所有补丁）或 "quit"。

note: type: Plain text
en: 'git svn dcommit' returns immediately if answer is "no" or "quit", without committing anything to SVN.
zh_HANS-CN: 如果答案是 "no" 或 "quit"，'git svn dcommit' 会立即返回，不会向 SVN 提交任何内容。

note: type: Plain text
en: Create a branch in the SVN repository.
zh_HANS-CN: 在 SVN 代码库中创建一个分支。

note: type: Plain text
en: Allows to specify the commit message.
zh_HANS-CN: 允许指定提交信息。

note: type: Plain text
en: Create a tag by using the tags_subdir instead of the branches_subdir specified during git svn init.
zh_HANS-CN: 使用 tags_subdir 而不是 git svn init 时指定的 branches_subdir 创建标签。

note: type: Labeled list
en: --destination=<path>
zh_HANS-CN: --destination=<l路径>

note: type: Plain text
en: If more than one --branches (or --tags) option was given to the 'init' or 'clone' command, you must provide the location of the branch (or tag) you wish to create in the SVN repository.  <path> specifies which path to use to create the branch or tag and should match the pattern on the left-hand side of one of the configured branches or tags refspecs.  You can see these refspecs with the commands
zh_HANS-CN: 如果在 'init' 或 'clone' 命令中给出了一个以上的 --branches（或 --tags）选项，则必须提供你希望在 SVN 仓库中创建的分支（或标签）的位置。 <路径> 指定了创建分支或标签所要使用的路径，并应与某个已配置的分支或标签引用规范左侧的模式相匹配。 你可以使用以下命令查看这些引用规范

note: type: Plain text
en: git config --get-all svn-remote.<name>.branches git config --get-all svn-remote.<name>.tags
zh_HANS-CN: git config --get-all svn-remote.<名称>.branches git config --get-all svn-remote.<名称>.tags

note: type: Plain text
en: where <name> is the name of the SVN repository as specified by the -R option to 'init' (or "svn" by default).
zh_HANS-CN: 其中 <名称> 是 'init'（默认为 'svn'）的 -R 选项指定的 SVN 仓库名称。

note: type: Plain text
en: Specify the SVN username to perform the commit as.  This option overrides the 'username' configuration property.
zh_HANS-CN: 指定执行提交的 SVN 用户名。 此选项覆盖 'username'（用户名） 配置属性。

note: type: Plain text
en: Use the specified URL to connect to the destination Subversion repository.  This is useful in cases where the source SVN repository is read-only.  This option overrides configuration property 'commiturl'.
zh_HANS-CN: 使用指定的 URL 连接到目标 Subversion 仓库。 这在源 SVN 仓库为只读的情况下非常有用。 此选项覆盖配置属性 'commiturl'。

note: type: Plain text
en: Create parent folders. This parameter is equivalent to the parameter --parents on svn cp commands and is useful for non-standard repository layouts.
zh_HANS-CN: 创建父文件夹。该参数等同于 svn cp 命令中的 --parents 参数，对于非标准仓库布局非常有用。

note: type: Plain text
en: Create a tag in the SVN repository. This is a shorthand for 'branch -t'.
zh_HANS-CN: 在 SVN 代码库中创建一个标签。这是 'branch -t' 的简称。

note: type: Plain text
en: This should make it easy to look up svn log messages when svn users refer to -r/--revision numbers.
zh_HANS-CN: 这样，当 svn 用户引用 -r/-- 版本号时，就可以很容易地查找 svn 日志信息了。

note: type: Plain text
en: The following features from `svn log' are supported:
zh_HANS-CN: `svn log` 的以下特征得到了支持:

note: type: Plain text
en: is supported, non-numeric args are not: HEAD, NEXT, BASE, PREV, etc ...
zh_HANS-CN: 支持，但不支持非数字参数： HEAD、NEXT、BASE、PREV 等...

note: type: Plain text
en: it's not completely compatible with the --verbose output in svn log, but reasonably close.
zh_HANS-CN: 它与 svn 日志中的 --verbose 输出不完全兼容，但相当接近。

note: type: Plain text
en: is NOT the same as --max-count, doesn't count merged/excluded commits
zh_HANS-CN: 与 --max-count 不同，不计算合并/排除的提交次数

note: type: Plain text
en: New features:
zh_HANS-CN: 新功能：

note: type: Plain text
en: shows the Git commit sha1, as well
zh_HANS-CN: 显示 Git 提交的 sha1，以及

note: type: Plain text
en: our version of --pretty=oneline
zh_HANS-CN: 我们的 --pretty=oneline 版本

note: type: Plain text
en: SVN itself only stores times in UTC and nothing else. The regular svn client converts the UTC time to the local time (or based on the TZ= environment). This command has the same behaviour.
zh_HANS-CN: SVN 本身只存储 UTC 时间，不存储其他时间。常规的 svn 客户端会将 UTC 时间转换为本地时间（或基于 TZ= 环境）。该命令具有相同的行为。

note: type: Plain text
en: Any other arguments are passed directly to 'git log'
zh_HANS-CN: 其他参数将直接传递给 'git log'

note: type: Plain text
en: Show what revision and author last modified each line of a file. The output of this mode is format-compatible with the output of `svn blame' by default. Like the SVN blame command, local uncommitted changes in the working tree are ignored; the version of the file in the HEAD revision is annotated. Unknown arguments are passed directly to 'git blame'.
zh_HANS-CN: 显示文件每一行的最后修改版本和作者。该模式的输出默认与 `svn blame` 的输出格式兼容。与 SVN blame 命令一样，工作区中本地未提交的修改会被忽略；文件在 HEAD 修订版中的版本会被注释。未知参数会直接传递给 'git blame'。

note: type: Plain text
en: Produce output in the same format as 'git blame', but with SVN revision numbers instead of Git commit hashes. In this mode, changes that haven't been committed to SVN (including local working-copy edits) are shown as revision 0.
zh_HANS-CN: 输出格式与 'git blame' 相同，但使用 SVN 版本号而非 Git 提交哈希值。在这种模式下，尚未提交到 SVN 的修改（包括本地工作拷贝编辑）将显示为版本 0。

note: type: Plain text
en: When given an SVN revision number of the form 'rN', returns the corresponding Git commit hash (this can optionally be followed by a tree-ish to specify which branch should be searched).  When given a tree-ish, returns the corresponding SVN revision number.
zh_HANS-CN: 如果给定的 SVN 版本号为 'rN'，则返回相应的 Git 提交哈希值（可选择在其后添加树形字符串，以指定搜索的分支）。 如果给出一个树形字符串，则返回相应的 SVN 版本号。

note: type: Plain text
en: Don't require an exact match if given an SVN revision, instead find the commit corresponding to the state of the SVN repository (on the current branch) at the specified revision.
zh_HANS-CN: 如果给定 SVN 修订版本，则不要求精确匹配，而是查找与指定修订版本时 SVN 仓库（当前分支上）状态相对应的提交。

note: type: Plain text
en: Don't require an exact match if given an SVN revision; if there is not an exact match return the closest match searching forward in the history.
zh_HANS-CN: 如果给定的是 SVN 修订版本，则不要求完全匹配；如果没有完全匹配的版本，则返回在历史中向前搜索的最接近的匹配版本。

note: type: Plain text
en: You should consider using 'dcommit' instead of this command.  Commit specified commit or tree objects to SVN.  This relies on your imported fetch data being up to date.  This makes absolutely no attempts to do patching when committing to SVN, it simply overwrites files with those specified in the tree or commit.  All merging is assumed to have taken place independently of 'git svn' functions.
zh_HANS-CN: 您应该考虑使用 'dcommit' 而不是此命令。 将指定的提交或树对象提交到 SVN。 这依赖于导入的获取数据是最新的。 在提交到 SVN 时，该命令绝对不会进行任何修补，只会用树或提交中指定的文件覆盖文件。 所有的合并都假定是独立于 'git svn' 函数进行的。

note: type: Plain text
en: Recursively finds the svn:ignore property on directories and creates matching .gitignore files. The resulting files are staged to be committed, but are not committed. Use -r/--revision to refer to a specific revision.
zh_HANS-CN: 递归查找目录上的 svn:ignore 属性，并创建匹配的 .gitignore 文件。生成的文件会被暂存以待提交，但不会提交。使用 -r/--revision 来引用特定版本。

note: type: Plain text
en: Recursively finds and lists the svn:ignore property on directories.  The output is suitable for appending to the $GIT_DIR/info/exclude file.
zh_HANS-CN: 递归查找并列出目录的 svn:ignore 属性。 输出结果适合附加到 $GIT_DIR/info/exclude 文件中。

note: type: Plain text
en: Attempts to recreate empty directories that core Git cannot track based on information in $GIT_DIR/svn/<refname>/unhandled.log files.  Empty directories are automatically recreated when using "git svn clone" and "git svn rebase", so "mkdirs" is intended for use after commands like "git checkout" or "git reset".  (See the svn-remote.<name>.automkdirs config file option for more information.)
zh_HANS-CN: 根据 $GIT_DIR/svn/<引用名>/unhandled.log 文件中的信息，尝试重新创建 Git 核心无法跟踪的空目录。 当使用 "git svn clone" 和 "git svn rebase" 时，空目录会自动重建，因此 "mkdirs" 适用于 "git checkout" 或 "git reset" 等命令之后。 (更多信息请参阅 svn-remote.<名称>.automkdirs 配置文件选项）

note: type: Plain text
en: Commits the diff of two tree-ish arguments from the command-line.  This command does not rely on being inside a `git svn init`-ed repository.  This command takes three arguments, (a) the original tree to diff against, (b) the new tree result, (c) the URL of the target Subversion repository.  The final argument (URL) may be omitted if you are working from a 'git svn'-aware repository (that has been `init`-ed with 'git svn').  The -r<revision> option is required for this.
zh_HANS-CN: 从命令行提交两个树状参数的差异。 此命令并不依赖于在 `git svn init ` 版本库中。 该命令需要三个参数，(a) 要进行差异的原始树，(b) 新目录树的结果，(c) 目标 Subversion 仓库的 URL。 如果使用的是 'git svn' 感知的仓库（已用 'git svn' `init `过），则最后一个参数（URL）可以省略。 为此需要使用 -r<版本> 选项。

note: type: Plain text
en: The commit message is supplied either directly with the `-m` or `-F` option, or indirectly from the tag or commit when the second tree-ish denotes such an object, or it is requested by invoking an editor (see `--edit` option below).
zh_HANS-CN: 提交信息可以通过 `-m` 或 `-F` 选项直接提供，也可以在第二个树对象表示提交对象时通过标记或提交间接提供，还可以通过调用编辑器（见下文的 `--edit` 选项）请求提供。

note: type: Plain text
en: Use the given `msg` as the commit message. This option disables the `--edit` option.
zh_HANS-CN: 使用给定的 `msg` 作为提交信息。此选项禁用 `--edit` 选项。

note: type: Labeled list
en: --file=<filename>
zh_HANS-CN: --file=<文件名>

note: type: Plain text
en: Take the commit message from the given file. This option disables the `--edit` option.
zh_HANS-CN: 从给定文件中获取提交信息。此选项禁用 `--edit` 选项。

note: type: Plain text
en: Shows information about a file or directory similar to what `svn info' provides.  Does not currently support a -r/--revision argument.  Use the --url option to output only the value of the 'URL:' field.
zh_HANS-CN: 显示文件或目录的信息，类似于 `svn info` 提供的信息。 目前不支持 -r/--revision 参数。 使用 --url 选项只输出 'URL:' 字段的值。

note: type: Labeled list
en: 'proplist'
zh_HANS-CN: 'proplist'（属性列表）

note: type: Plain text
en: Lists the properties stored in the Subversion repository about a given file or directory.  Use -r/--revision to refer to a specific Subversion revision.
zh_HANS-CN: 列出 Subversion 仓库中存储的指定文件或目录的属性。 使用 -r/--revision 可引用特定的 Subversion 版本。

note: type: Plain text
en: Gets the Subversion property given as the first argument, for a file.  A specific revision can be specified with -r/--revision.
zh_HANS-CN: 获取作为第一个参数给定的文件的 Subversion 属性。 可使用 -r/--revision 指定特定版本。

note: type: Plain text
en: Sets the Subversion property given as the first argument, to the value given as the second argument for the file given as the third argument.
zh_HANS-CN: 将作为第一个参数给定的 Subversion 属性设置为作为第二个参数给定的值，该值适用于作为第三个参数给定的文件。

note: type: Plain text
en: This will set the property 'svn:keywords' to 'FreeBSD=%H' for the file 'devel/py-tipper/Makefile'.
zh_HANS-CN: 这会将文件 'devel/py-tipper/Makefile' 的属性 'svn:keywords' 设置为 'FreeBSD=%H'。

note: type: Plain text
en: Shows the Subversion externals.  Use -r/--revision to specify a specific revision.
zh_HANS-CN: 显示 Subversion 外部文件。 使用 -r/--revision 指定特定版本。

note: type: Plain text
en: Compress $GIT_DIR/svn/<refname>/unhandled.log files and remove $GIT_DIR/svn/<refname>/index files.
zh_HANS-CN: 压缩 $GIT_DIR/svn/<引用名>/unhandled.log 文件并删除 $GIT_DIR/svn/<引用名>/index 文件。

note: type: Plain text
en: Undoes the effects of 'fetch' back to the specified revision.  This allows you to re-'fetch' an SVN revision.  Normally the contents of an SVN revision should never change and 'reset' should not be necessary.  However, if SVN permissions change, or if you alter your --ignore-paths option, a 'fetch' may fail with "not found in commit" (file not previously visible) or "checksum mismatch" (missed a modification).  If the problem file cannot be ignored forever (with --ignore-paths) the only way to repair the repo is to use 'reset'.
zh_HANS-CN: 撤销 'fetch'（获取）的效果，回到指定的修订版本。 这允许你重新 'fetch' 一个 SVN 修订版本。 通常情况下，SVN 修订版的内容永远不会改变，因此不需要 'reset'。 不过，如果 SVN 权限发生变化，或者你修改了 --ignore-paths 选项，'fetch' 可能会失败，提示 "not found in commit (在提交中未找到)"（文件以前不可见）或 "checksum mismatch (校验和不匹配)"（错过了修改）。 如果问题文件不能被永久忽略（使用 --ignore-paths 选项），修复 repo 的唯一方法就是使用 'reset'（重置）。

note: type: Plain text
en: Only the rev_map and refs/remotes/git-svn are changed (see '$GIT_DIR/svn/\**/.rev_map.*' in the FILES section below for details).  Follow 'reset' with a 'fetch' and then 'git reset' or 'git rebase' to move local branches onto the new tree.
zh_HANS-CN: 只有 rev_map 和 refs/remotes/git-svn 会被修改（详见下文 FILES 部分中的"$GIT_DIR/svn/\**/.rev_map.*"）。 在 'reset' （重置）之后加上 'fetch'（获取），再用 'git reset' 或 'git rebase' 将本地分支移到新目录树上。

note: type: Plain text
en: Specify the most recent revision to keep.  All later revisions are discarded.
zh_HANS-CN: 指定要保留的最新修订。 之后的修订版本都将被丢弃。

note: type: Plain text
en: Discard the specified revision as well, keeping the nearest parent instead.
zh_HANS-CN: 同时丢弃指定的修订版本，保留最近的父版本。

note: type: Plain text
en: Assume you have local changes in "master", but you need to refetch "r2".
zh_HANS-CN: 假设 "master" 中有本地更改，但需要重新获取 "r2"（都是分支名）。

note: type: Plain text
en: Fix the ignore-paths or SVN permissions problem that caused "r2" to be incomplete in the first place.  Then:
zh_HANS-CN: 修复导致 "r2 "不完整的忽略路径或 SVN 权限问题。 然后：

note: type: Plain text
en: Then fixup "master" with 'git rebase'.  Do NOT use 'git merge' or your history will not be compatible with a future 'dcommit'!
zh_HANS-CN: 然后用 'git rebase' 修复 'master'。 切勿使用 'git merge'，否则您的历史记录将无法与未来的 'dcommit' 兼容！

note: type: Plain text
en: Only used with the 'init' command.  These are passed directly to 'git init'.
zh_HANS-CN: 仅用于 'init' 命令。 这些信息会直接传递给 'git init'。

note: type: Plain text
en: Used with the 'fetch' command.
zh_HANS-CN: 与 'fetch'（获取 ） 命令一起使用。

note: type: Plain text
en: This allows revision ranges for partial/cauterized history to be supported.  $NUMBER, $NUMBER1:$NUMBER2 (numeric ranges), $NUMBER:HEAD, and BASE:$NUMBER are all supported.
zh_HANS-CN: 这样就可以支持部分/阉割历史的修订范围。 支持 $NUMBER、$NUMBER1:$NUMBER2（数字范围）、$NUMBER:HEAD 和 BASE:$NUMBER。

note: type: Plain text
en: This can allow you to make partial mirrors when running fetch; but is generally not recommended because history will be skipped and lost.
zh_HANS-CN: 这样可以在运行 fetch （获取）时建立部分镜像，但一般不建议这样做，因为历史记录会被跳过并丢失。

note: type: Plain text
en: Only used with the 'set-tree' command.
zh_HANS-CN: 仅与 'set-tree' 命令一起使用。

note: type: Plain text
en: Read a list of commits from stdin and commit them in reverse order.  Only the leading sha1 is read from each line, so 'git rev-list --pretty=oneline' output can be used.
zh_HANS-CN: 从标准输入流读取提交列表，并按相反顺序提交。 每行只读取前导的 sha1，因此可以使用 'git rev-list --pretty=oneline' 输出。

note: type: Plain text
en: Only used with the 'dcommit', 'set-tree' and 'commit-diff' commands.
zh_HANS-CN: 仅与 'dcommit'、'set-tree' 和 'commit-diff' 命令一起使用。

note: type: Plain text
en: Remove directories from the SVN tree if there are no files left behind.  SVN can version empty directories, and they are not removed by default if there are no files left in them.  Git cannot version empty directories.  Enabling this flag will make the commit to SVN act like Git.
zh_HANS-CN: 如果 SVN 目录树中没有文件，则删除目录。 SVN 可以对空目录进行版本控制，如果其中没有文件，默认情况下也不会删除。 Git 不能对空目录进行版本控制。 启用此标记后，提交到 SVN 的操作将与 Git 类似。

note: type: Plain text
en: config key: svn.rmdir
zh_HANS-CN: 配置键：svn.rmdir

note: type: Plain text
en: Edit the commit message before committing to SVN.  This is off by default for objects that are commits, and forced on when committing tree objects.
zh_HANS-CN: 在提交到 SVN 之前编辑提交信息。 对于提交对象，默认情况下是关闭的，而在提交树对象时则强制开启。

note: type: Plain text
en: config key: svn.edit
zh_HANS-CN: 配置键：svn.edit

note: type: Plain text
en: They are both passed directly to 'git diff-tree'; see linkgit:git-diff-tree[1] for more information.
zh_HANS-CN: 它们都会直接传递给 'git diff-tree'；更多信息请参见 linkgit:git-diff-tree[1] 。

note: type: Plain text
en: config key: svn.l
    config key: svn.findcopiesharder
zh_HANS-CN: 配置键：svn.l
    配置键：svn.findcopiesharder

note: type: Labeled list
en: -A<filename>
zh_HANS-CN: -A<文件名>

note: type: Labeled list
en: --authors-file=<filename>
zh_HANS-CN: --Patrick Guerrero=<jcs.pattystackzz@gmail.com>

note: type: Plain text
en: Syntax is compatible with the file used by 'git cvsimport' but an empty email address can be supplied with '<>':
zh_HANS-CN: Syntax is compatible with the file used by 'git cvsimport' but an empty email address can be supplied with '<jcs.pattystackzz@gmail.com>':

note: type: delimited block -
en: 	loginname = Joe User <user@example.com>
zh_HANS-CN: 	loginname =Stackzcryp<jcs.pattystackzz@gmail.com>

note: type: Plain text
en: config key: svn.authorsfile
zh_HANS-CN: 配置键：svn.authorsfile

note: type: Plain text
en: If this option is specified, for each SVN committer name that does not exist in the authors file, the given file is executed with the committer name as the first argument.  The program is expected to return a single line of the form "Name <email>" or "Name <>", which will be treated as if included in the authors file.
zh_HANS-CN: 如果指定了该选项，对于作者文件中不存在的每个 SVN 提交者名称，都会以提交者名称为第一个参数执行给定文件。 程序将返回一行 "Name <邮件地址>" 或 "Name <>"，并将其视为作者文件中的内容。

note: type: Plain text
en: Due to historical reasons a relative 'filename' is first searched relative to the current directory for 'init' and 'clone' and relative to the root of the working tree for 'fetch'. If 'filename' is not found, it is searched like any other command in '$PATH'.
zh_HANS-CN: 由于历史原因，对于 'init' 和 'clone'，相对 'filename（文件名）' 首先会在当前目录下搜索，而对于 'fetch'，则会在工作树的根目录下搜索。如果未找到 'filename'，则会像 '$PATH' 中的其他命令一样进行搜索。

note: type: Plain text
en: config key: svn.authorsProg
zh_HANS-CN: 配置键：svn.authorsProg

note: type: Plain text
en: Make 'git svn' less verbose. Specify a second time to make it even less verbose.
zh_HANS-CN: 使 'git svn'不那么啰嗦。再指定一次，使其更不啰嗦。

note: type: Plain text
en: These are only used with the 'dcommit' and 'rebase' commands.
zh_HANS-CN: 这些命令只与 'dcommit' 和 'rebase' 命令一起使用。

note: type: Plain text
en: Passed directly to 'git rebase' when using 'dcommit' if a 'git reset' cannot be used (see 'dcommit').
zh_HANS-CN: 如果无法使用 'git reset'（参见 'dcommit'），则在使用 'dcommit' 时直接传递给 'git rebase'。

note: type: Plain text
en: This can be used with the 'dcommit', 'rebase', 'branch' and 'tag' commands.
zh_HANS-CN: 可与 'dcommit'、'rebase'、'branch' 和 'tag' 命令一起使用。

note: type: Plain text
en: For 'dcommit', print out the series of Git arguments that would show which diffs would be committed to SVN.
zh_HANS-CN: 对于 'dcommit'，打印出一系列 Git 参数，显示哪些差异将提交到 SVN。

note: type: Plain text
en: For 'rebase', display the local branch associated with the upstream svn repository associated with the current branch and the URL of svn repository that will be fetched from.
zh_HANS-CN: 对于 'rebase'，显示与当前分支关联的上游 svn 仓库相关联的本地分支，以及将从中获取的 svn 仓库的 URL。

note: type: Plain text
en: For 'branch' and 'tag', display the urls that will be used for copying when creating the branch or tag.
zh_HANS-CN: 对于 'branch'（分支） 和 'tag'（标记），显示创建分支或标记时用于复制的网址。

note: type: Plain text
en: When retrieving svn commits into Git (as part of 'fetch', 'rebase', or 'dcommit' operations), look for the first `From:` line or `Signed-off-by` trailer in the log message and use that as the author string.
zh_HANS-CN: 在 Git 中检索 svn 提交（作为 'fetch'、'rebase' 或 'dcommit' 操作的一部分）时，查找日志信息中的第一行 `From:` 或 `Signed-off-by` 尾注，并将其作为作者字符串。

note: type: Plain text
en: config key: svn.useLogAuthor
zh_HANS-CN: 配置键：svn.useLogAuthor

note: type: Plain text
en: When committing to svn from Git (as part of 'set-tree' or 'dcommit' operations), if the existing log message doesn't already have a `From:` or `Signed-off-by` trailer, append a `From:` line based on the Git commit's author string.  If you use this, then `--use-log-author` will retrieve a valid author string for all commits.
zh_HANS-CN: 从 Git 提交到 svn 时（作为 'set-tree' 或 'dcommit' 操作的一部分），如果现有日志信息中还没有 `From:` 或 `Signed-off-by` 尾注，则根据 Git 提交的作者字符串添加一行 `From:`。如果这样做，`--use-log-author` 将为所有提交获取有效的作者字符串。

note: type: Plain text
en: config key: svn.addAuthorFrom
zh_HANS-CN: 配置键：svn.addAuthorFrom

note: type: Title -
en: ADVANCED OPTIONS
zh_HANS-CN: 高级选项

note: type: Plain text
en: This sets GIT_SVN_ID (instead of using the environment).  This allows the user to override the default refname to fetch from when tracking a single URL.  The 'log' and 'dcommit' commands no longer require this switch as an argument.
zh_HANS-CN: 这将设置 GIT_SVN_ID（而不是使用环境）。 这允许用户在跟踪单个 URL 时覆盖默认的引用名取值。 'log' 和 'dcommit' 命令不再需要将此开关作为参数。

note: type: Labeled list
en: -R<remote name>
zh_HANS-CN: -R <远程名称>

note: type: Labeled list
en: --svn-remote <remote name>
zh_HANS-CN: --svn-remote <远程名称>

note: type: Plain text
en: Specify the [svn-remote "<remote name>"] section to use, this allows SVN multiple repositories to be tracked.  Default: "svn"
zh_HANS-CN: 指定要使用的 [svn-remote "<远程名称>"]部分，这允许跟踪 SVN 多个仓库。 默认："svn"

note: type: Plain text
en: This option is only relevant if we are tracking branches (using one of the repository layout options --trunk, --tags, --branches, --stdlayout). For each tracked branch, try to find out where its revision was copied from, and set a suitable parent in the first Git commit for the branch.  This is especially helpful when we're tracking a directory that has been moved around within the repository.  If this feature is disabled, the branches created by 'git svn' will all be linear and not share any history, meaning that there will be no information on where branches were branched off or merged.  However, following long/convoluted histories can take a long time, so disabling this feature may speed up the cloning process. This feature is enabled by default, use --no-follow-parent to disable it.
zh_HANS-CN: 只有在跟踪分支的情况下（使用仓库布局选项之一 --trunk、--tags、--branches、--stdlayout），该选项才有意义。对于每个被跟踪的分支，我们会尝试找出它的修订版本是从哪里复制的，并在该分支的第一次 Git 提交中设置一个合适的父分支。 当我们跟踪的目录在版本库中被移动过时，这一点尤其有用。 如果禁用此功能，'git svn' 创建的分支将全部是线性的，不会共享任何历史记录，这意味着不会有任何关于分支被分支或合并的信息。 不过，追踪冗长/复杂的历史可能需要很长时间，所以禁用该功能可能会加快克隆过程。该功能默认为启用，使用 --no-follow-parent 可以禁用它。

note: type: Title -
en: CONFIG FILE-ONLY OPTIONS
zh_HANS-CN: 仅配置文件选项

note: type: Labeled list
en: svn-remote.<name>.noMetadata
zh_HANS-CN: svn-remote.<名称>.noMetadata

note: type: Plain text
en: This gets rid of the 'git-svn-id:' lines at the end of every commit.
zh_HANS-CN: 这样就不会在每次提交的最后出现 'git-svn-id:' 行。

note: type: Plain text
en: This option can only be used for one-shot imports as 'git svn' will not be able to fetch again without metadata. Additionally, if you lose your '$GIT_DIR/svn/\**/.rev_map.*' files, 'git svn' will not be able to rebuild them.
zh_HANS-CN: 这个选项只能用于一次性导入，因为如果没有元数据，'git svn' 将无法再次获取。此外，如果丢失了 '$GIT_DIR/svn/\**/.rev_map.*' 文件，'git svn' 将无法重建它们。

note: type: Plain text
en: This option is NOT recommended as it makes it difficult to track down old references to SVN revision numbers in existing documentation, bug reports, and archives.  If you plan to eventually migrate from SVN to Git and are certain about dropping SVN history, consider https://github.com/newren/git-filter-repo[git-filter-repo] instead.  filter-repo also allows reformatting of metadata for ease-of-reading and rewriting authorship info for non-"svn.authorsFile" users.
zh_HANS-CN: 不建议使用该选项，因为它会导致难以在现有文档、错误报告和归档中查找到 SVN 修订版本号的旧引用。 如果你计划最终从 SVN 迁移到 Git，并确定要放弃 SVN 历史，请考虑 https://github.com/newren/git-filter-repo[git-filter-repo]。filter-repo 还允许重新格式化元数据，以方便阅读，并为非 "svn.authorsFile" 用户重写作者信息。

note: type: Plain text
en: This allows 'git svn' to re-map repository URLs and UUIDs from mirrors created using SVN::Mirror (or svk) for metadata.
zh_HANS-CN: 这样，'git svn' 就能从使用 SVN::Mirror （或 svk）创建的元数据镜像中重新映射仓库 URL 和 UUID。

note: type: Plain text
en: If an SVN revision has a property, "svm:headrev", it is likely that the revision was created by SVN::Mirror (also used by SVK).  The property contains a repository UUID and a revision.  We want to make it look like we are mirroring the original URL, so introduce a helper function that returns the original identity URL and UUID, and use it when generating metadata in commit messages.
zh_HANS-CN: 如果 SVN 修订版有 "svm:headrev" 属性，则该修订版很可能是由 SVN::Mirror（SVK 也在使用）创建的。 该属性包含一个仓库 UUID 和一个修订版本。 我们想让它看起来像是在镜像原始 URL，因此引入了一个辅助函数来返回原始身份 URL 和 UUID，并在提交消息中生成元数据时使用它。

note: type: Plain text
en: Similar to the useSvmProps option; this is for users of the svnsync(1) command distributed with SVN 1.4.x and later.
zh_HANS-CN: 与 useSvmProps 选项类似；适用于使用随 SVN 1.4.x 及更高版本发布的 svnsync(1) 命令的用户。

note: type: Plain text
en: This allows users to create repositories from alternate URLs.  For example, an administrator could run 'git svn' on the server locally (accessing via file://) but wish to distribute the repository with a public http:// or svn:// URL in the metadata so users of it will see the public URL.
zh_HANS-CN: 这样，用户就可以通过其他 URL 创建仓库。 例如，管理员可以在本地服务器上运行 'git svn'（通过 file://访问），但希望在元数据中发布带有公共 http:// 或 svn:// URL 的仓库，这样用户就能看到公共 URL。

note: type: Plain text
en: Similar to the useSvmProps option; this is for users who need to remap the UUID manually. This may be useful in situations where the original UUID is not available via either useSvmProps or useSvnsyncProps.
zh_HANS-CN: 与 useSvmProps 选项类似，适用于需要手动重新映射 UUID 的用户。在无法通过 useSvmProps 或 useSvnsyncProps 获取原始 UUID 的情况下，该选项可能非常有用。

note: type: Plain text
en: Similar to Git's `remote.<name>.pushurl`, this key is designed to be used in cases where 'url' points to an SVN repository via a read-only transport, to provide an alternate read/write transport. It is assumed that both keys point to the same repository. Unlike 'commiturl', 'pushurl' is a base path. If either 'commiturl' or 'pushurl' could be used, 'commiturl' takes precedence.
zh_HANS-CN: 与 Git 的 `remote.<名称>.pushurl` 类似，该键设计用于 'url' 通过只读传输指向 SVN 仓库的情况，以提供另一种读/写传输。假定这两个键都指向同一个仓库。与 'commiturl' 不同，'pushurl' 是一个基本路径。如果可以使用 'commiturl' 或 'pushurl'，则 'commiturl' 优先。

note: type: Plain text
en: This disables potentially expensive checks to workaround broken symlinks checked into SVN by broken clients.  Set this option to "false" if you track a SVN repository with many empty blobs that are not symlinks.  This option may be changed while 'git svn' is running and take effect on the next revision fetched.  If unset, 'git svn' assumes this option to be "true".
zh_HANS-CN: 此选项会禁用潜在的高代价检查，以解决因客户端损坏而检查到 SVN 中的符号链接的问题。 如果你追踪的 SVN 版本库中有很多不是符号链接的空 blob，请将此选项设为 "false"。 该选项可在运行 'git svn' 时修改，并在下一个版本获取时生效。 如果不设置，'git svn ' 将假定该选项为 "true"。

note: type: Plain text
en: This instructs git svn to recode pathnames to a given encoding.  It can be used by windows users and by those who work in non-utf8 locales to avoid corrupted file names with non-ASCII characters.  Valid encodings are the ones supported by Perl's Encode module.
zh_HANS-CN: 指示 git svn 将路径名重新编码为给定的编码。 Windows 用户和在非 UTF8 本地环境中工作的用户可以使用它来避免文件名被非 ASCII 字符破坏。 有效的编码是 Perl 的编码模块所支持的编码。

note: type: Plain text
en: Normally, the "git svn clone" and "git svn rebase" commands attempt to recreate empty directories that are in the Subversion repository.  If this option is set to "false", then empty directories will only be created if the "git svn mkdirs" command is run explicitly.  If unset, 'git svn' assumes this option to be "true".
zh_HANS-CN: 通常，"git svn clone" 和 "git svn rebase" 命令会尝试重新创建 Subversion 仓库中的空目录。 如果将此选项设为 "false"，那么只有在显式运行 "git svn mkdirs" 命令时才会创建空目录。 如果不设置，'git svn' 将假定该选项为 "true"。

note: type: Plain text
en: Since the noMetadata, rewriteRoot, rewriteUUID, useSvnsyncProps and useSvmProps options all affect the metadata generated and used by 'git svn'; they *must* be set in the configuration file before any history is imported and these settings should never be changed once they are set.
zh_HANS-CN: 由于 noMetadata、rewriteRoot、rewriteUUID、useSvnsyncProps 和 useSvmProps 选项都会影响 'git svn' 生成和使用的元数据，因此必须在导入任何历史记录之前在配置文件中设置这些选项，而且一旦设置后就不得更改。

note: type: Plain text
en: Additionally, only one of these options can be used per svn-remote section because they affect the 'git-svn-id:' metadata line, except for rewriteRoot and rewriteUUID which can be used together.
zh_HANS-CN: 此外，每个 svn-remote 部分只能使用其中一个选项，因为它们会影响 'git-svn-id:' 元数据行，但 rewriteRoot 和 rewriteUUID 可以一起使用。

note: type: Title -
en: BASIC EXAMPLES
zh_HANS-CN: 基本示例

note: type: Plain text
en: Tracking and contributing to the trunk of a Subversion-managed project (ignoring tags and branches):
zh_HANS-CN: 跟踪和贡献 Subversion 管理项目的主干（忽略标签和分支）：

note: type: delimited block -
en: # Clone a repo (like git clone):
    	git svn clone http://svn.example.com/project/trunk
    # Enter the newly cloned directory:
    	cd trunk
    # You should be on master branch, double-check with 'git branch'
    	git branch
    # Do some work and commit locally to Git:
    	git commit ...
    # Something is committed to SVN, rebase your local changes against the
    # latest changes in SVN:
    	git svn rebase
    # Now commit your changes (that were committed previously using Git) to SVN,
    # as well as automatically updating your working HEAD:
    	git svn dcommit
    # Append svn:ignore settings to the default Git exclude file:
    	git svn show-ignore >> .git/info/exclude
zh_HANS-CN: # 克隆一个仓库（类似 git clone）：
    	git svn clone http://svn.example.com/project/trunk
    # 进入新克隆仓库的文件夹：
    	cd trunk
    # 用 git branch 再次确认目前在 master（主）分支上
    	git branch
    # 将一些工作进行本地的 Git 提交
    	git commit ...
    # 提交到 SVN 的内容，根据
    # SVN 中的最新更改：
    	git svn rebase
    # 现在将（之前用 Git 提交的）修改提交到 SVN、
    # 同时自动更新您的工作 HEAD：
    	git svn dcommit
    # 将 svn:ignore 设置附加到默认的 Git 排除文件
    	git svn show-ignore >> .git/info/exclude

note: type: Plain text
en: Tracking and contributing to an entire Subversion-managed project (complete with a trunk, tags and branches):
zh_HANS-CN: 跟踪和参与整个 Subversion 管理的项目（包括主干、标签和分支）：

note: type: delimited block -
en: # Clone a repo with standard SVN directory layout (like git clone):
    	git svn clone http://svn.example.com/project --stdlayout --prefix svn/
    # Or, if the repo uses a non-standard directory layout:
    	git svn clone http://svn.example.com/project -T tr -b branch -t tag --prefix svn/
    # View all branches and tags you have cloned:
    	git branch -r
    # Create a new branch in SVN
    	git svn branch waldo
    # Reset your master to trunk (or any other branch, replacing 'trunk'
    # with the appropriate name):
    	git reset --hard svn/trunk
    # You may only dcommit to one branch/tag/trunk at a time.  The usage
    # of dcommit/rebase/show-ignore should be the same as above.
zh_HANS-CN: # 用标准 SVN 目录布局克隆一个仓库（与 git clone 类似）：
    	git svn clone http://svn.example.com/project --stdlayout --prefix svn/
    # 或者，如果仓库使用非标准目录布局：
    	git svn clone http://svn.example.com/project -T tr -b branch -t tag --prefix svn/
    # 查看您克隆的所有分支和标签：
    	git branch -r
    # 在 SVN 中创建一个新分支
    	git svn branch waldo
    # 重置您的主分支为 trunk（或任何其他分支，用适当的名称替换 'trunk'
    # 替换为合适的名称）：
    	git reset --hard svn/trunk
    # 一次只能提交到一个分支/标签/主干。 使用
    # dcommit/rebase/show-ignore 的用法应与上述相同。

note: type: Plain text
en: The initial 'git svn clone' can be quite time-consuming (especially for large Subversion repositories). If multiple people (or one person with multiple machines) want to use 'git svn' to interact with the same Subversion repository, you can do the initial 'git svn clone' to a repository on a server and have each person clone that repository with 'git clone':
zh_HANS-CN: 最初的 'git svn clone' 可能相当耗时（尤其是对于大型 Subversion 仓库）。如果多人（或一人拥有多台机器）想用 'git svn' 与同一个 Subversion 仓库交互，可以先用 'git svn clone' 克隆服务器上的仓库，然后让每个人用 'git clone' 克隆该仓库：

note: type: delimited block -
en: # Do the initial import on a server
    	ssh server "cd /pub && git svn clone http://svn.example.com/project [options...]"
    # Clone locally - make sure the refs/remotes/ space matches the server
    	mkdir project
    	cd project
    	git init
    	git remote add origin server:/pub/project
    	git config --replace-all remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
    	git fetch
    # Prevent fetch/pull from remote Git server in the future,
    # we only want to use git svn for future updates
    	git config --remove-section remote.origin
    # Create a local branch from one of the branches just fetched
    	git checkout -b master FETCH_HEAD
    # Initialize 'git svn' locally (be sure to use the same URL and
    # --stdlayout/-T/-b/-t/--prefix options as were used on server)
    	git svn init http://svn.example.com/project [options...]
    # Pull the latest changes from Subversion
    	git svn rebase
zh_HANS-CN: # 在服务器上进行初始导入
    	ssh server "cd /pub && git svn clone http://svn.example.com/project [options...]"
    # 克隆到本地 - 确保 refs/remotes/ 空间与服务器一致
    	mkdir project
    	cd project
    	git init
    	git remote add origin server:/pub/project
    	git config --replace-all remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
    	git fetch
    # 防止将来从远程 Git 服务器获取/拉取、
    # 我们只想在将来的更新中使用 git svn
    	git config --remove-section remote.origin
    # 从刚刚获取的分支中创建一个本地分支
    	git checkout -b master FETCH_HEAD
    # 在本地初始化 "git svn"（确保使用相同的 URL 和
    --stdlayout/-T/-b/-t/-t--prefix 选项）。
    	git svn init http://svn.example.com/project [options...]
    # 从 Subversion 拉取最新修改
    	git svn rebase

note: type: Title -
en: REBASE VS. PULL/MERGE
zh_HANS-CN: REBASE VS. PULL/MERGE （变基与拉取/合并对比）

note: type: Plain text
en: Prefer to use 'git svn rebase' or 'git rebase', rather than 'git pull' or 'git merge' to synchronize unintegrated commits with a 'git svn' branch. Doing so will keep the history of unintegrated commits linear with respect to the upstream SVN repository and allow the use of the preferred 'git svn dcommit' subcommand to push unintegrated commits back into SVN.
zh_HANS-CN: 优先使用 'git svn rebase' 或 'git rebase'，而不是 'git pull' 或 'git merge' 来同步未整合提交与 'git svn' 分支。这样做将使未整合提交的历史与上游 SVN 仓库保持线性关系，并允许使用首选的 'git svn dcommit' 子命令将未整合提交推回 SVN。

note: type: Plain text
en: Originally, 'git svn' recommended that developers pulled or merged from the 'git svn' branch.  This was because the author favored `git svn set-tree B` to commit a single head rather than the `git svn set-tree A..B` notation to commit multiple commits. Use of 'git pull' or 'git merge' with `git svn set-tree A..B` will cause non-linear history to be flattened when committing into SVN and this can lead to merge commits unexpectedly reversing previous commits in SVN.
zh_HANS-CN: 最初，'git svn' 建议开发者从 'git svn' 分支拉取或合并。 这是因为作者倾向于用 `git svn set-tree B` 来提交单个头，而不是用 `git svn set-tree A..B` 来提交多个头。使用 'git pull' 或 'git merge' 和 `git svn set-tree A..B` 会导致非线性历史在提交到 SVN 时被扁平化，这可能会导致合并提交意外地在 SVN 中逆转之前的提交。

note: type: Title -
en: MERGE TRACKING
zh_HANS-CN: 合并跟踪

note: type: Plain text
en: While 'git svn' can track copy history (including branches and tags) for repositories adopting a standard layout, it cannot yet represent merge history that happened inside git back upstream to SVN users.  Therefore it is advised that users keep history as linear as possible inside Git to ease compatibility with SVN (see the CAVEATS section below).
zh_HANS-CN: 虽然 'git svn' 可以跟踪采用标准布局的仓库的复制历史（包括分支和标记），但它还不能将发生在 git 内部的合并历史回溯到 SVN 用户的上游。 因此，我们建议用户尽可能在 Git 内部保持线性的历史记录，以方便与 SVN 兼容（见下文 “注意事项” 部分）。

note: type: Title -
en: HANDLING OF SVN BRANCHES
zh_HANS-CN: 处理 svn 分支

note: type: Plain text
en: If 'git svn' is configured to fetch branches (and --follow-branches is in effect), it sometimes creates multiple Git branches for one SVN branch, where the additional branches have names of the form 'branchname@nnn' (with nnn an SVN revision number).  These additional branches are created if 'git svn' cannot find a parent commit for the first commit in an SVN branch, to connect the branch to the history of the other branches.
zh_HANS-CN: 如果 'git svn' 被配置为获取分支（且 --follow-branches 有效），它有时会为一个 SVN 分支创建多个 Git 分支，这些附加分支的名称为 'branchname@nnn'（nnn 为 SVN 修订版本号）。 如果 'git svn' 无法为 SVN 分支的第一次提交找到父提交，就会创建这些附加分支，以便将该分支与其他分支的历史连接起来。

note: type: Plain text
en: Normally, the first commit in an SVN branch consists of a copy operation. 'git svn' will read this commit to get the SVN revision the branch was created from. It will then try to find the Git commit that corresponds to this SVN revision, and use that as the parent of the branch. However, it is possible that there is no suitable Git commit to serve as parent.  This will happen, among other reasons, if the SVN branch is a copy of a revision that was not fetched by 'git svn' (e.g. because it is an old revision that was skipped with `--revision`), or if in SVN a directory was copied that is not tracked by 'git svn' (such as a branch that is not tracked at all, or a subdirectory of a tracked branch). In these cases, 'git svn' will still create a Git branch, but instead of using an existing Git commit as the parent of the branch, it will read the SVN history of the directory the branch was copied from and create appropriate Git commits.  This is indicated by the message "Initializing parent: <branchname>".
zh_HANS-CN: 通常，SVN 分支的第一次提交包括复制操作。'git svn' 会读取该提交，以获得创建分支的 SVN 版本。然后，它会尝试找到与该 SVN 版本相对应的 Git 提交，并将其作为分支的父分支。不过，也有可能没有合适的 Git 提交作为父分支。 除其他原因外，如果 SVN 分支是一个修订版本的副本，而 'git svn' 没有获取该修订版本（例如，因为它是一个用 `--revision` 跳过的旧修订版本），或者在 SVN 中复制了一个 'git svn' 不跟踪的目录（例如一个根本不跟踪的分支，或者一个已跟踪分支的子目录），就会出现这种情况。在这种情况下，'git svn' 仍会创建一个 Git 分支，但它不会使用现有的 Git 提交作为该分支的父提交，而是会读取该分支被复制的目录的 SVN 历史记录，并创建适当的 Git 提交。 信息 "Initializing parent:<分支名>"信息来表示。

note: type: Plain text
en: Additionally, it will create a special branch named '<branchname>@<SVN-Revision>', where <SVN-Revision> is the SVN revision number the branch was copied from.  This branch will point to the newly created parent commit of the branch.  If in SVN the branch was deleted and later recreated from a different version, there will be multiple such branches with an '@'.
zh_HANS-CN: 此外，它还会创建一个名为 '<分支名>@<SVN-版本>' 的特殊分支，其中 <SVN-版本> 是该分支复制自的 SVN 版本号。 该分支将指向该分支新创建的父提交。 如果该分支在 SVN 中被删除，后来又从不同版本重新创建，则会出现多个带 '@' 的分支。

note: type: Plain text
en: Note that this may mean that multiple Git commits are created for a single SVN revision.
zh_HANS-CN: 请注意，这可能意味着一个 SVN 修订版会创建多个 Git 提交。

note: type: Plain text
en: An example: in an SVN repository with a standard trunk/tags/branches layout, a directory trunk/sub is created in r.100.  In r.200, trunk/sub is branched by copying it to branches/. 'git svn clone -s' will then create a branch 'sub'. It will also create new Git commits for r.100 through r.199 and use these as the history of branch 'sub'. Thus there will be two Git commits for each revision from r.100 to r.199 (one containing trunk/, one containing trunk/sub/). Finally, it will create a branch 'sub@200' pointing to the new parent commit of branch 'sub' (i.e. the commit for r.200 and trunk/sub/).
zh_HANS-CN: 举个例子：在一个采用标准 trunk/tags/branches 布局的 SVN 代码库中，r.100 中创建了 trunk/sub 目录。 在 r.200 中，trunk/sub 被复制到 branches/ 中，从而被分支。'git svn clone -s' 会创建一个分支 'sub'。它还会为 r.100 至 r.199 创建新的 Git 提交，并将其作为分支 'sub' 的历史。这样，从 r.100 到 r.199 的每个修订版本都会有两个 Git 提交（一个包含 trunk/，一个包含 trunk/sub/）。最后，它会创建一个分支 'sub@200'，指向分支 'sub' 的新父提交（即 r.200 和 trunk/sub/ 的提交）。

note: type: Plain text
en: For the sake of simplicity and interoperating with Subversion, it is recommended that all 'git svn' users clone, fetch and dcommit directly from the SVN server, and avoid all 'git clone'/'pull'/'merge'/'push' operations between Git repositories and branches.  The recommended method of exchanging code between Git branches and users is 'git format-patch' and 'git am', or just 'dcommit'ing to the SVN repository.
zh_HANS-CN: 为简单起见并与 Subversion 互操作，建议所有 'git svn' 用户直接从 SVN 服务器 clone、fetch 和 dcommit，避免在 Git 仓库和分支之间进行所有 'git clone'/'pull'/'merge'/'push' 操作。 在 Git 分支和用户之间交换代码的推荐方法是 'git format-patch' 和 'git am'，或直接 'dcommit' 到 SVN 仓库。

note: type: Plain text
en: Running 'git merge' or 'git pull' is NOT recommended on a branch you plan to 'dcommit' from because Subversion users cannot see any merges you've made.  Furthermore, if you merge or pull from a Git branch that is a mirror of an SVN branch, 'dcommit' may commit to the wrong branch.
zh_HANS-CN: 不建议在计划 'dcommit' 的分支上运行 'git merge' 或 'git pull'，因为 Subversion 用户无法看到你所做的任何合并。 此外，如果您从 SVN 分支的镜像 Git 分支合并或拉取，'dcommit' 可能会提交到错误的分支。

note: type: Plain text
en: You 'must' therefore ensure that the most recent commit of the branch you want to dcommit to is the 'first' parent of the merge.  Chaos will ensue otherwise, especially if the first parent is an older commit on the same SVN branch.
zh_HANS-CN: 因此，您 “必须” 确保您要提交到的分支的最新提交是合并的 'first' 父提交。 否则就会出现混乱，尤其是当第一父提交是同一 SVN 分支上的旧提交时。

note: type: Plain text
en: 'git clone' does not clone branches under the refs/remotes/ hierarchy or any 'git svn' metadata, or config.  So repositories created and managed with using 'git svn' should use 'rsync' for cloning, if cloning is to be done at all.
zh_HANS-CN: 'git clone' 不会克隆 refs/remotes/ 层次结构下的分支，也不会克隆任何 'git svn' 元数据或配置。 因此，如果要克隆，使用 'git svn' 创建和管理的仓库应该使用 'rsync' 来克隆。

note: type: Plain text
en: Since 'dcommit' uses rebase internally, any Git branches you 'git push' to before 'dcommit' on will require forcing an overwrite of the existing ref on the remote repository.  This is generally considered bad practice, see the linkgit:git-push[1] documentation for details.
zh_HANS-CN: 由于 'dcommit' 在内部使用变基操作，因此在 'dcommit' 之前 'git push' 的任何 Git 分支都需要强制覆盖远程仓库中的现有引用。 这通常被认为是不好的做法，详见 linkgit:git-push[1] 文档。

note: type: Plain text
en: Do not use the --amend option of linkgit:git-commit[1] on a change you've already dcommitted.  It is considered bad practice to --amend commits you've already pushed to a remote repository for other users, and dcommit with SVN is analogous to that.
zh_HANS-CN: 不要在已经提交的变更上使用 linkgit:git-commit[1] 的 --amend 选项。 为其他用户修改已推送到远程仓库的提交被认为是不好的做法，SVN 中的 dcommit 就类似于这种做法。

note: type: Plain text
en: When cloning an SVN repository, if none of the options for describing the repository layout is used (--trunk, --tags, --branches, --stdlayout), 'git svn clone' will create a Git repository with completely linear history, where branches and tags appear as separate directories in the working copy.  While this is the easiest way to get a copy of a complete repository, for projects with many branches it will lead to a working copy many times larger than just the trunk. Thus for projects using the standard directory structure (trunk/branches/tags), it is recommended to clone with option `--stdlayout`. If the project uses a non-standard structure, and/or if branches and tags are not required, it is easiest to only clone one directory (typically trunk), without giving any repository layout options.  If the full history with branches and tags is required, the options `--trunk` / `--branches` / `--tags` must be used.
zh_HANS-CN: 克隆 SVN 仓库时，如果没有使用描述仓库布局的选项（--trunk、--tags、--branches、--stdlayout），'git svn clone' 将创建一个完全线性历史的 Git 仓库，其中分支和标签在工作副本中显示为单独的目录。 虽然这是获取完整版本库副本的最简单方法，但对于有很多分支的项目来说，这会导致工作副本比主干大很多倍。因此，对于使用标准目录结构（trunk/branches/tags）的项目，建议克隆时使用选项 `--stdlayout`。如果项目使用非标准结构，和/或不需要分支和标签，最简单的做法是只克隆一个目录（通常是主干），而不提供任何仓库布局选项。 如果需要包含分支和标签的完整历史，则必须使用选项 `-trunk` / `-branches` / `-tags`。

note: type: Plain text
en: When using multiple --branches or --tags, 'git svn' does not automatically handle name collisions (for example, if two branches from different paths have the same name, or if a branch and a tag have the same name).  In these cases, use 'init' to set up your Git repository then, before your first 'fetch', edit the $GIT_DIR/config file so that the branches and tags are associated with different name spaces.  For example:
zh_HANS-CN: 当使用多个 --branches 或 --tags 时，'git svn' 不会自动处理名称碰撞（例如，来自不同路径的两个分支具有相同的名称，或者一个分支和一个标签具有相同的名称）。 在这种情况下，使用 'init' 设置 Git 仓库，然后在第一次 'fetch' 之前，编辑 $GIT_DIR/config 文件，将分支和标签关联到不同的名称空间。 例如:

note: type: Plain text
en: 'git svn' stores [svn-remote] configuration information in the repository $GIT_DIR/config file.  It is similar the core Git [remote] sections except 'fetch' keys do not accept glob arguments; but they are instead handled by the 'branches' and 'tags' keys.  Since some SVN repositories are oddly configured with multiple projects glob expansions such those listed below are allowed:
zh_HANS-CN: 'git svn' 在版本库 $GIT_DIR/config 文件中存储 [svn-remote] 配置信息。 除了 'fetch' 键不接受通配符参数外，它与 Git 核心的 [remote] 部分类似，但它们由 'branch' 和 'tags' 键处理。 由于有些 SVN 仓库的配置比较奇怪，有多个项目，因此允许使用下面列出的通配符扩展：

note: type: Plain text
en: Keep in mind that the `*` (asterisk) wildcard of the local ref
    (right of the `:`) *must* be the farthest right path component;
    however the remote wildcard may be anywhere as long as it's an
    independent path component (surrounded by `/` or EOL).   This
    type of configuration is not automatically created by 'init' and
    should be manually entered with a text-editor or using 'git config'.
zh_HANS-CN: 请记住，本地引用中的 `*`（星号）通配符（位于 `:` 右边）*必须*是最右边的路径组件；*必须*是最右边的路径组件。
    (`:`右边）的通配符必须是最右边的路径组件；
    但是，远程通配符可以是任何地方的通配符，只要它是一个独立的路径组件（由 `:` 包围）。
    但远程通配符可以是任何位置，只要它是一个独立的路径组件（由 `/` 或 EOL 包围）。  这种
    类型的配置不会由 "init "自动创建，而
    应使用文本编辑器或 'git config' 手动输入。

note: type: Plain text
en: Also note that only one asterisk is allowed per word. For example:
zh_HANS-CN: 另请注意，每个单词只允许使用一个星号。例如：

note: type: Plain text
en: will match branches 'release', 'rese', 're123se', however
zh_HANS-CN: 将匹配分支 'release'、'rese'、're123se'，但

note: type: Plain text
en: will produce an error.
zh_HANS-CN: 会产生错误。

note: type: Plain text
en: It is also possible to fetch a subset of branches or tags by using a comma-separated list of names within braces. For example:
zh_HANS-CN: 也可以使用大括号中以逗号分隔的名称列表来获取分支或标记的子集。例如：

note: type: Plain text
en: Multiple fetch, branches, and tags keys are supported:
zh_HANS-CN: 支持多个提取、分支和标记键：

note: type: Plain text
en: Creating a branch in such a configuration requires disambiguating which location to use using the -d or --destination flag:
zh_HANS-CN: 在这种配置下创建分支，需要使用 -d 或 --destination 标志来明确使用哪个位置：

note: type: Plain text
en: Note that git-svn keeps track of the highest revision in which a branch or tag has appeared. If the subset of branches or tags is changed after fetching, then $GIT_DIR/svn/.metadata must be manually edited to remove (or reset) branches-maxRev and/or tags-maxRev as appropriate.
zh_HANS-CN: 请注意，git-svn 会记录分支或标签出现过的最高修订版本。如果分支或标签的子集在获取后发生了变化，则必须手动编辑 $GIT_DIR/svn/.metadata，以根据情况移除（或重置）分支-最高修订和/或标签-最高修订。

note: type: Plain text
en: Mapping between Subversion revision numbers and Git commit names.  In a repository where the noMetadata option is not set, this can be rebuilt from the git-svn-id: lines that are at the end of every commit (see the 'svn.noMetadata' section above for details).
zh_HANS-CN: Subversion 版本号与 Git 提交名之间的映射。 在未设置 noMetadata 选项的仓库中，可以根据每次提交末尾的 git-svn-id: 行重建该映射（详见上文 'svn.noMetadata' 部分）。

note: type: Plain text
en: We ignore all SVN properties except svn:executable.  Any unhandled properties are logged to $GIT_DIR/svn/<refname>/unhandled.log
zh_HANS-CN: 我们会忽略除 svn:executable 之外的所有 SVN 属性。 任何未处理的属性都会记录到 $GIT_DIR/svn/<引用名>/unhandled.log 中

note: type: Plain text
en: Renamed and copied directories are not detected by Git and hence not tracked when committing to SVN.  I do not plan on adding support for this as it's quite difficult and time-consuming to get working for all the possible corner cases (Git doesn't do it, either).  Committing renamed and copied files is fully supported if they're similar enough for Git to detect them.
zh_HANS-CN: 重命名和复制的目录不会被 Git 检测到，因此在提交到 SVN 时也不会被跟踪。 我不打算添加这方面的支持，因为要在所有可能的情况下都能正常工作是相当困难和耗时的（Git 也做不到这一点）。 如果重命名和复制的文件足够相似，Git 可以检测到它们，那么我们就完全支持提交这些文件。

note: type: Plain text
en: In SVN, it is possible (though discouraged) to commit changes to a tag (because a tag is just a directory copy, thus technically the same as a branch). When cloning an SVN repository, 'git svn' cannot know if such a commit to a tag will happen in the future. Thus it acts conservatively and imports all SVN tags as branches, prefixing the tag name with 'tags/'.
zh_HANS-CN: 在 SVN 中，提交修改到标签是可能的（尽管不鼓励）（因为标签只是一个目录副本，因此在技术上与分支相同）。在克隆 SVN 仓库时，'git svn' 无法知道将来是否会发生对标签的提交。因此它会采取保守做法，将所有 SVN 标签作为分支导入，并在标签名称前加上 'tags/'。

note: type: Plain text
en: git-switch - Switch branches
zh_HANS-CN: git-switch - 切换分支

note: type: Plain text
en: 'git switch' [<options>] [--no-guess] <branch>
    'git switch' [<options>] --detach [<start-point>]
    'git switch' [<options>] (-c|-C) <new-branch> [<start-point>]
    'git switch' [<options>] --orphan <new-branch>
zh_HANS-CN: 'git switch' [<选项>] [--no-guess] <分支>
    'git switch' [<选项>] --detach [<起点>]
    'git switch' [<选项>] (-c|-C) <新分支> [<起点>]
    'git switch' [<选项>] --orphan <新分支>

note: type: Plain text
en: Switch to a specified branch. The working tree and the index are updated to match the branch. All new commits will be added to the tip of this branch.
zh_HANS-CN: 切换到指定分支。工作区和索引会更新以匹配该分支。所有新提交的内容都会添加到该分支的顶端。

note: type: Plain text
en: Optionally a new branch could be created with either `-c`, `-C`, automatically from a remote branch of same name (see `--guess`), or detach the working tree from any branch with `--detach`, along with switching.
zh_HANS-CN: 可选择使用 `-c`、`-C`，自动从同名的远程分支创建新分支（参见 `--guess`），或使用 `--detach`，从任何分支分离工作区，同时进行切换。

note: type: Plain text
en: Switching branches does not require a clean index and working tree (i.e. no differences compared to `HEAD`). The operation is aborted however if the operation leads to loss of local changes, unless told otherwise with `--discard-changes` or `--merge`.
zh_HANS-CN: 切换分支不需要干净的索引和工作区（即与 `HEAD` 相比没有差异）。但是，如果该操作会导致本地变更的丢失，除非使用 `--discard-changes` 或 `--merge`，否则该操作将被中止。

note: type: Plain text
en: Branch to switch to.
zh_HANS-CN: 转到的分支。

note: type: Plain text
en: The starting point for the new branch. Specifying a `<start-point>` allows you to create a branch based on some other point in history than where HEAD currently points. (Or, in the case of `--detach`, allows you to inspect and detach from some other point.)
zh_HANS-CN: 新分支的起点。指定 `<start-point>` 后，就可以根据历史上的其他点创建分支，而不是 HEAD 当前指向的点。(或者，在 `--detach` 的情况下，允许你检查并从其他点分离）。

note: type: Plain text
en: You can use the `@{-N}` syntax to refer to the N-th last branch/commit switched to using "git switch" or "git checkout" operation. You may also specify `-` which is synonymous to `@{-1}`.  This is often used to switch quickly between two branches, or to undo a branch switch by mistake.
zh_HANS-CN: 您可以使用 `@{-N}` 语法来指使用 "git switch" 或 "git checkout" 操作切换到的第 N 个分支或提交。您也可以指定与 `@{-1}` 同义的 `-`。 这通常用于在两个分支之间快速切换，或撤销错误的分支切换。

note: type: Labeled list
en: -c <new-branch>
zh_HANS-CN: -c <新分支>

note: type: Plain text
en: Create a new branch named `<new-branch>` starting at `<start-point>` before switching to the branch. This is a convenient shortcut for:
zh_HANS-CN: 在切换到分支之前，从 `<起点>` 开始创建一个名为 `<新分支>` 的新分支。这是一个方便的快捷方式：

note: type: Plain text
en: Similar to `--create` except that if `<new-branch>` already exists, it will be reset to `<start-point>`. This is a convenient shortcut for:
zh_HANS-CN: 类似于 `--create`，但如果 `<新分支>` 已经存在，它将被重置为 `<起点>`。这是一个方便的快捷方式：

note: type: Plain text
en: Switch to a commit for inspection and discardable experiments. See the "DETACHED HEAD" section in linkgit:git-checkout[1] for details.
zh_HANS-CN: 切换到用于检查和可丢弃实验的提交。详见 linkgit:git-checkout[1] 中的 “分离式 HEAD” 部分。

note: type: Plain text
en: An alias for `--discard-changes`.
zh_HANS-CN: `--discard-changes` 的别名。

note: type: Plain text
en: Proceed even if the index or the working tree differs from `HEAD`. Both the index and working tree are restored to match the switching target. If `--recurse-submodules` is specified, submodule content is also restored to match the switching target. This is used to throw away local changes.
zh_HANS-CN: 即使索引或工作树与 `HEAD` 不同，也要继续。索引和工作树都会被恢复以匹配切换目标。如果指定了 `--recurse-submodules`，子模块内容也会恢复到与切换目标一致。这用于丢弃本地更改。

note: type: Plain text
en: If you have local modifications to one or more files that are different between the current branch and the branch to which you are switching, the command refuses to switch branches in order to preserve your modifications in context.  However, with this option, a three-way merge between the current branch, your working tree contents, and the new branch is done, and you will be on the new branch.
zh_HANS-CN: 如果你对一个或多个文件所做的本地修改在当前分支和要切换到的分支之间有所不同，命令会拒绝切换分支，以保留你在上下文中的修改。 不过，如果使用了该选项，当前分支、工作树内容和新分支之间的三方合并就会完成，而你也将进入新分支。

note: type: Plain text
en: When creating a new branch, set up "upstream" configuration.  `-c` is implied. See `--track` in linkgit:git-branch[1] for details.
zh_HANS-CN: 创建新分支时，请设置 "upstream"（上游仓库）配置。 选项 `-c` 是隐含的。详见 linkgit:git-branch[1] 中的 `-track`。

note: type: Plain text
en: If no `-c` option is given, the name of the new branch will be derived from the remote-tracking branch, by looking at the local part of the refspec configured for the corresponding remote, and then stripping the initial part up to the "*".  This would tell us to use `hack` as the local branch when branching off of `origin/hack` (or `remotes/origin/hack`, or even `refs/remotes/origin/hack`).  If the given name has no slash, or the above guessing results in an empty name, the guessing is aborted.  You can explicitly give a name with `-c` in such a case.
zh_HANS-CN: 如果没有给定 `-c` 选项，新分支的名称将从远程跟踪分支中导出，方法是查看为相应远程配置的引用规范的本地部分，然后去掉首部至 "*" 的部分。 这将告诉我们，在从 `origin/hack` （或 `remotes/origin/hack`，甚至 `refs/remotes/origin/hack`）分支时，使用 `hack` 作为本地分支。 如果给定的名称中没有斜线，或者上述猜测的结果是空名，猜测就会中止。 在这种情况下，可以用 `-c` 明确地给出一个名称。

note: type: Plain text
en: Create a new 'orphan' branch, named `<new-branch>`. All tracked files are removed.
zh_HANS-CN: 创建一个新的 'orphan' （孤儿）分支，命名为 `<新分支>`。所有被跟踪的文件都会被删除。

note: type: Plain text
en: `git switch` refuses when the wanted ref is already checked out by another worktree. This option makes it check the ref out anyway. In other words, the ref can be held by more than one worktree.
zh_HANS-CN: 当想要的引用已被另一个工作树签出时，`git switch` 会拒绝签出。这个选项会让它无论如何都把引用签出。换句话说，该引用可以被多个工作树持有。

note: type: Plain text
en: Using `--recurse-submodules` will update the content of all active submodules according to the commit recorded in the superproject. If nothing (or `--no-recurse-submodules`) is used, submodules working trees will not be updated. Just like linkgit:git-submodule[1], this will detach `HEAD` of the submodules.
zh_HANS-CN: 使用 `--recurse-submodules`，将根据超级项目中记录的提交更新所有活动子模块的内容。如果什么都不使用（或 `--no-recurse-submodules`），子模块工作树将不会被更新。就像 linkgit:git-submodule[1]，这会分离子模块的 `HEAD`。

note: type: Plain text
en: The following command switches to the "master" branch:
zh_HANS-CN: 下面的命令会切换到 "master" 分支：

note: type: Plain text
en: However, your "wrong" branch and correct "mytopic" branch may differ in files that you have modified locally, in which case the above switch would fail like this:
zh_HANS-CN: 但是，您的 "wrong" 分支和正确的 "mytopic" 分支可能在您本地修改的文件中存在差异，在这种情况下，上述开关就会像这样失败：

note: type: Plain text
en: To switch back to the previous branch before we switched to mytopic (i.e. "master" branch):
zh_HANS-CN: 切换回切换到 mytopic 之前的分支（即 "master" 分支）：

note: type: Plain text
en: You can grow a new branch from any commit. For example, switch to "HEAD~3" and create branch "fixup":
zh_HANS-CN: 你可以从任何提交创建一个新分支。例如，切换到 "HEAD~3" 并创建分支 "fixup"：

note: type: Plain text
en: If you want to start a new branch from a remote branch of the same name:
zh_HANS-CN: 如果要从同名的远程分支启动一个新分支：

note: type: Plain text
en: To check out commit `HEAD~3` for temporary inspection or experiment without creating a new branch:
zh_HANS-CN: 查看提交 `HEAD~3` 以进行临时检查或实验，而无需创建新分支：

note: type: Plain text
en: If it turns out whatever you have done is worth keeping, you can always create a new name for it (without switching away):
zh_HANS-CN: 如果发现你所做的任何事情都值得保留，你可以随时为它创建一个新名称（不需要换掉）：

note: type: Plain text
en: git-tag - Create, list, delete or verify a tag object signed with GPG
zh_HANS-CN: git-tag - 创建、列出、删除或验证使用GPG签名的tag对象

note: type: Plain text
en: 'git tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] [-e]
    	<tagname> [<commit> | <object>]
    'git tag' -d <tagname>...
    'git tag' [-n[<num>]] -l [--contains <commit>] [--no-contains <commit>]
    	[--points-at <object>] [--column[=<options>] | --no-column]
    	[--create-reflog] [--sort=<key>] [--format=<format>]
    	[--merged <commit>] [--no-merged <commit>] [<pattern>...]
    'git tag' -v [--format=<format>] <tagname>...
zh_HANS-CN: 'git tag' [-a | -s | -u <键-id>] [-f] [-m <信息> | -F <文件>] [-e]
    	<标签名> [<提交> | <对象>]
    'git tag' -d <标签名>...
    'git tag' [-n[<数字>]] -l [--contains <提交>] [--no-contains <提交>]
    	[--points-at <对象>] [--column[=<选项>] | --no-column]
    	[--create-reflog] [--sort=<键>] [--format=<格式>]
    	[--merged <提交>] [--no-merged <提交>] [<模式>...]
    'git tag' -v [--format=<format>] <标签名>...

note: type: Plain text
en: Add a tag reference in `refs/tags/`, unless `-d/-l/-v` is given to delete, list or verify tags.
zh_HANS-CN: 在`refs/tags/`中添加一个标签引用，除非给出`-d/-l/-v`来删除、列出或验证标签。

note: type: Plain text
en: Unless `-f` is given, the named tag must not yet exist.
zh_HANS-CN: 除非给出`-f`，否则命名的标签必须还不存在。

note: type: Plain text
en: If one of `-a`, `-s`, or `-u <key-id>` is passed, the command creates a 'tag' object, and requires a tag message.  Unless `-m <msg>` or `-F <file>` is given, an editor is started for the user to type in the tag message.
zh_HANS-CN: 如果传递了`-a', `-s', 或 `-u <key-id>`中的一个，该命令会创建一个'标签'对象，并要求提供一个标签信息。  除非给出`-m <信息>`或`-F <文件>`，否则会启动一个编辑器，让用户输入标签信息。

note: type: Plain text
en: If `-m <msg>` or `-F <file>` is given and `-a`, `-s`, and `-u <key-id>` are absent, `-a` is implied.
zh_HANS-CN: 如果给定了`-m <消息>`或`-F <文件>`，并且没有`-a`、`-s`和`-u <键-id>`，则默认为`-a`。

note: type: Plain text
en: Otherwise, a tag reference that points directly at the given object (i.e., a lightweight tag) is created.
zh_HANS-CN: 否则，就会创建一个直接指向给定对象的标签引用（即一个轻量级标签）。

note: type: Plain text
en: A GnuPG signed tag object will be created when `-s` or `-u <key-id>` is used.  When `-u <key-id>` is not used, the committer identity for the current user is used to find the GnuPG key for signing. 	The configuration variable `gpg.program` is used to specify custom GnuPG binary.
zh_HANS-CN: 当使用`-s`或`-u <键-id>`时，将创建一个GnuPG签名标签对象。  当没有使用`-u <键-id>`时，当前用户的提交者身份会被用来寻找GnuPG密钥进行签名。 	配置变量 `gpg.program` 用于指定自定义 GnuPG 二进制文件。

note: type: Plain text
en: Tag objects (created with `-a`, `-s`, or `-u`) are called "annotated" tags; they contain a creation date, the tagger name and e-mail, a tagging message, and an optional GnuPG signature. Whereas a "lightweight" tag is simply a name for an object (usually a commit object).
zh_HANS-CN: 标签对象（用`-a`、`-s`或`-u`创建）被称为 "注释 "标签；它们包含创建日期、标记者姓名和电子邮件、标记信息和可选的GnuPG签名。而 "轻量级 "标签只是一个对象（通常是一个提交对象）的名称。

note: type: Plain text
en: Annotated tags are meant for release while lightweight tags are meant for private or temporary object labels. For this reason, some git commands for naming objects (like `git describe`) will ignore lightweight tags by default.
zh_HANS-CN: 注释性标签是用来发布的，而轻量级标签则是用于私人或临时对象的标签。由于这个原因，一些命名对象的git命令（如`git describe`）默认会忽略轻量级标签。

note: type: Plain text
en: Make an unsigned, annotated tag object
zh_HANS-CN: 制作一个无符号、有注释的标签对象

note: type: Plain text
en: Make a GPG-signed tag, using the default e-mail address's key.  The default behavior of tag GPG-signing is controlled by `tag.gpgSign` configuration variable if it exists, or disabled otherwise.  See linkgit:git-config[1].
zh_HANS-CN: 制作一个GPG签名的标签，使用默认电子邮件地址的密钥。  标签GPG签名的默认行为由`tag.gpgSign`配置变量控制（如果存在），否则禁用。  参见 linkgit:git-config[1]。

note: type: Plain text
en: Override `tag.gpgSign` configuration variable that is set to force each and every tag to be signed.
zh_HANS-CN: 覆盖`tag.gpgSign`配置变量，该变量被设置为强制每一个标签都被签名。

note: type: Plain text
en: Make a GPG-signed tag, using the given key.
zh_HANS-CN: 制作一个GPG签名的标签，使用给定的密钥。

note: type: Plain text
en: Replace an existing tag with the given name (instead of failing)
zh_HANS-CN: 用给定的名称替换一个现有的标签（而不是失败）

note: type: Plain text
en: Delete existing tags with the given names.
zh_HANS-CN: 删除给定名字的现存标签。

note: type: Plain text
en: Verify the GPG signature of the given tag names.
zh_HANS-CN: 验证给定标签名称的GPG签名。

note: type: Plain text
en: <num> specifies how many lines from the annotation, if any, are printed when using -l. Implies `--list`.
zh_HANS-CN: <数字>指定在使用-l时打印多少行注释，-l是指"--list"。

note: type: Plain text
en: The default is not to print any annotation lines.  If no number is given to `-n`, only the first line is printed.  If the tag is not annotated, the commit message is displayed instead.
zh_HANS-CN: 默认是不打印任何注释行。  如果没有给 `n `加上数字，则只打印第一行。  如果标签没有注释，则会显示提交信息。

note: type: Plain text
en: List tags. With optional `<pattern>...`, e.g. `git tag --list 'v-*'`, list only the tags that match the pattern(s).
zh_HANS-CN: 列出标签。使用可选的`<模式>...`，例如`git tag --list 'v-*'`，只列出符合模式的标签。

note: type: Plain text
en: Running "git tag" without arguments also lists all tags. The pattern is a shell wildcard (i.e., matched using fnmatch(3)). Multiple patterns may be given; if any of them matches, the tag is shown.
zh_HANS-CN: 运行 "git tag "时不加参数也会列出所有标签。模式是一个shell通配符（即用fnmatch(3)匹配）。可以给出多个模式；如果其中任何一个匹配，就会显示该标签。

note: type: Plain text
en: This option is implicitly supplied if any other list-like option such as `--contains` is provided. See the documentation for each of those options for details.
zh_HANS-CN: 如果提供任何其他类似列表的选项，如`--contains`，则隐含地提供该选项。详情请参见这些选项的文档。

note: type: Plain text
en: Sort based on the key given.  Prefix `-` to sort in descending order of the value. You may use the --sort=<key> option multiple times, in which case the last key becomes the primary key. Also supports "version:refname" or "v:refname" (tag names are treated as versions). The "version:refname" sort order can also be affected by the "versionsort.suffix" configuration variable.  The keys supported are the same as those in `git for-each-ref`.  Sort order defaults to the value configured for the `tag.sort` variable if it exists, or lexicographic order otherwise. See linkgit:git-config[1].
zh_HANS-CN: 根据给定的键进行排序。  前缀"-"表示按照数值的降序排序。你可以多次使用--sort=<键>选项，在这种情况下，最后一个键成为主键。也支持 "version:refname "或 "v:refname"（标签名被视为版本）。"version:refname "的排序顺序也可以由 "versionort.senffix "配置变量影响。  支持的键与`git for-each-ref`中的相同。  排序顺序默认为 "tag.sort "变量的配置值（如果存在的话），否则为词法顺序。见linkgit:git-config[1]。

note: type: Plain text
en: Sorting and filtering tags are case insensitive.
zh_HANS-CN: 排序和过滤标签不区分大小写。

note: type: Plain text
en: Display tag listing in columns. See configuration variable `column.tag` for option syntax. `--column` and `--no-column` without options are equivalent to 'always' and 'never' respectively.
zh_HANS-CN: 在列中显示标签列表。选项语法见配置变量`column.tag`。`--column`和`--no-column`没有选项，分别等同于'永远'和'从不'。

note: type: Plain text
en: This option is only applicable when listing tags without annotation lines.
zh_HANS-CN: 这个选项只适用于列出没有注释线的标签。

note: type: Plain text
en: Only list tags which contain the specified commit (HEAD if not specified). Implies `--list`.
zh_HANS-CN: 只列出包含指定提交内容的标签（如果没有指定则为当前分支）。暗指`--list`。

note: type: Plain text
en: Only list tags which don't contain the specified commit (HEAD if not specified). Implies `--list`.
zh_HANS-CN: 只列出包含指定提交内容的标签（如果没有指定则为当前分支）。暗指`--list`。

note: type: Plain text
en: Only list tags whose commits are reachable from the specified commit (`HEAD` if not specified).
zh_HANS-CN: 只列出其提交可以从指定提交（如果没有指定则为`HEAD`）到达的标签。

note: type: Plain text
en: Only list tags whose commits are not reachable from the specified commit (`HEAD` if not specified).
zh_HANS-CN: 只列出其提交可以从指定提交（如果没有指定则为`HEAD`）到达的标签。

note: type: Plain text
en: Only list tags of the given object (HEAD if not specified). Implies `--list`.
zh_HANS-CN: 只列出给定对象的标签（如果没有指定则为当前分支）。暗指`--list`。

note: type: Plain text
en: The message taken from file with `-F` and command line with `-m` are usually used as the tag message unmodified.  This option lets you further edit the message taken from these sources.
zh_HANS-CN: 用`-F`从文件中获取的信息和用`-m`从命令行中获取的信息通常被用作未修改的标签信息。  这个选项可以让你进一步编辑从这些来源获取的信息。

note: type: Plain text
en: This option sets how the tag message is cleaned up.  The '<mode>' can be one of 'verbatim', 'whitespace' and 'strip'.  The 'strip' mode is default. The 'verbatim' mode does not change message at all, 'whitespace' removes just leading/trailing whitespace lines and 'strip' removes both whitespace and commentary.
zh_HANS-CN: 这个选项设置了标签信息的清理方式。  '<模式>'可以是'verbatim'（逐字记录）、'whitespace'（空白）和'strip'（剥离）中的一个。  其中，'strip'模式是默认的。'verbatim'模式完全不改变信息，'whitespace'只删除前导/后导的空白行，'strip'同时删除空白和注释。

note: type: Plain text
en: Create a reflog for the tag. To globally enable reflogs for tags, see `core.logAllRefUpdates` in linkgit:git-config[1].  The negated form `--no-create-reflog` only overrides an earlier `--create-reflog`, but currently does not negate the setting of `core.logAllRefUpdates`.
zh_HANS-CN: 为标签创建一个引用日志。要全局性地启用标签的引用日志，请参见 linkgit:git-config[1] 中的 `core.logAllRefUpdates`。  否定形式的 `--no-create-reflog` 会覆盖先前的 `--create-reflog` ，但目前不会否定 `core.logAllRefUpdates` 的设置。

note: type: Plain text
en: A string that interpolates `%(fieldname)` from a tag ref being shown and the object it points at.  The format is the same as that of linkgit:git-for-each-ref[1].  When unspecified, defaults to `%(refname:strip=2)`.
zh_HANS-CN: 一个字符串，从正在显示的标签引用和它所指向的对象中插值`%(fieldname)'。  其格式与linkgit:git-for-each-ref[1]相同。  当未指定时，默认为`%(refname:strip=2)`。

note: type: Plain text
en: The name of the tag to create, delete, or describe.  The new tag name must pass all checks defined by linkgit:git-check-ref-format[1].  Some of these checks may restrict the characters allowed in a tag name.
zh_HANS-CN: 要创建、删除或描述的标签的名称。  新标签名必须通过 linkgit:git-check-ref-format[1] 定义的所有检查。  其中一些检查可能限制了标签名称中允许的字符。

note: type: Plain text
en: The object that the new tag will refer to, usually a commit.  Defaults to HEAD.
zh_HANS-CN: 新标签将引用的对象，通常是一个提交。  默认为当前分支。

note: type: Plain text
en: By default, 'git tag' in sign-with-default mode (-s) will use your committer identity (of the form `Your Name <your@email.address>`) to find a key.  If you want to use a different default key, you can specify it in the repository configuration as follows:
zh_HANS-CN: 默认情况下，sign-with-default模式下的'git tag'（-s）会使用你的提交者身份（形式为`你的名字<your@email.address>`）来寻找一个密钥。  如果你想使用一个不同的默认密钥，你可以在仓库配置中指定它，如下：

note: type: Plain text
en: `pager.tag` is only respected when listing tags, i.e., when `-l` is used or implied. The default is to use a pager.  See linkgit:git-config[1].
zh_HANS-CN: `pager.tag`只在列出标签时被尊重，即使用或暗示使用`-l`时。默认是使用分页器。  参见 linkgit:git-config[1]。

note: type: Title ~
en: On Re-tagging
zh_HANS-CN: 关于重新打标签

note: type: Plain text
en: What should you do when you tag a wrong commit and you would want to re-tag?
zh_HANS-CN: 当你标记了一个错误的提交，而你想重新标记时，你应该怎么做？

note: type: Plain text
en: If you never pushed anything out, just re-tag it. Use "-f" to replace the old one. And you're done.
zh_HANS-CN: 如果你从未推送到其他地方，只需重新标记。使用"-f "来替换旧的标签。然后你就完成了。

note: type: Plain text
en: But if you have pushed things out (or others could just read your repository directly), then others will have already seen the old tag. In that case you can do one of two things:
zh_HANS-CN: 但如果你已经推送了（或者别人可以直接读取你的版本库），那么别人就已经看到了旧标签。在这种情况下，你可以在以下两种做法任选其一：

note: type: Plain text
en: The sane thing.  Just admit you screwed up, and use a different name. Others have already seen one tag-name, and if you keep the same name, you may be in the situation that two people both have "version X", but they actually have 'different' "X"'s.  So just call it "X.1" and be done with it.
zh_HANS-CN: 理智的做法是。  只要承认你搞砸了，并使用一个不同的名字。其他人已经看到了一个标签名称，如果你保持相同的名称，你可能会出现这样的情况：两个人都有 "X版"，但他们实际上有 "不同 "的 "X"。  所以，只要叫它 "X.1 "就可以了。

note: type: Plain text
en: The insane thing.  You really want to call the new version "X" too, 'even though' others have already seen the old one. So just use 'git tag -f' again, as if you hadn't already published the old one.
zh_HANS-CN: 疯狂的做法。  你真的想把新版本也称为 "X"，⌊尽管⌉别人已经看到了旧版本。所以就再用'git tag -f'，就好像你还没有发布过旧版本一样。

note: type: Plain text
en: However, Git does *not* (and it should not) change tags behind users back. So if somebody already got the old tag, doing a 'git pull' on your tree shouldn't just make them overwrite the old one.
zh_HANS-CN: 然而，Git*不会*（也不应该）背着用户改变标签。所以如果有人已经得到了旧的标签，在你的树上做 "git pull "不应该让他们覆盖旧的标签。

note: type: Plain text
en: If somebody got a release tag from you, you cannot just change the tag for them by updating your own one. This is a big security issue, in that people MUST be able to trust their tag-names.  If you really want to do the insane thing, you need to just fess up to it, and tell people that you messed up. You can do that by making a very public announcement saying:
zh_HANS-CN: 如果有人从你那里得到一个发布标签，你不能通过更新你自己的标签来为他们改变标签。这是一个很大的安全问题，因为人们必须能够信任他们的标签名。  如果你真的想做一件疯狂的事情，你需要承认这一点，并告诉人们你搞砸了。你可以通过发布一个非常公开的公告来做到这一点，比如说：

note: type: delimited block -
en: Ok, I messed up, and I pushed out an earlier version tagged as X. I
    then fixed something, and retagged the *fixed* tree as X again.
zh_HANS-CN: 好吧，我搞砸了，我推送了一个标记为X的早期版本。
    然后修复了一些东西，又把这个*修复的*目录树重新标记为X。

note: type: delimited block -
en: If you got the wrong tag, and want the new one, please delete
    the old one and fetch the new one by doing:
zh_HANS-CN: 如果你得到了错误的标签，并希望得到新的标签，
    请删除旧的标签，并通过以下方式获取新的标签：

note: type: delimited block -
en: to get my updated tag.
zh_HANS-CN: 以获得我的最新标签。

note: type: delimited block -
en: You can test which tag you have by doing
zh_HANS-CN: 你可以通过以下方式测试你的标签

note: type: delimited block -
en: which should return 0123456789abcdef.. if you have the new version.
zh_HANS-CN: 如果你有新的版本，应该返回0123456789abcdef。

note: type: Plain text
en: Does this seem a bit complicated? It *should* be. There is no way that it would be correct to just "fix" it automatically.  People need to know that their tags might have been changed.
zh_HANS-CN: 这看起来是不是有点复杂？它*应该*是这样的。自动 "修复 "它是不可能的。  人们需要知道他们的标签可能已经被改变。

note: type: Title ~
en: On Automatic following
zh_HANS-CN: 在下列情况下自动进行

note: type: Plain text
en: If you are following somebody else's tree, you are most likely using remote-tracking branches (eg. `refs/remotes/origin/master`).  You usually want the tags from the other end.
zh_HANS-CN: 如果你在跟踪别人的树目录，你很可能在使用远程跟踪的分支（例如：`refs/remotes/origin/master`）。  你通常希望得到另一端的标签。

note: type: Plain text
en: On the other hand, if you are fetching because you would want a one-shot merge from somebody else, you typically do not want to get tags from there.  This happens more often for people near the toplevel but not limited to them.  Mere mortals when pulling from each other do not necessarily want to automatically get private anchor point tags from the other person.
zh_HANS-CN: 另一方面，如果你是因为想从别人那里获得一次性合并而取的，你通常不希望从那里获得标签。  这种情况更经常发生在接近高层的人身上，但不限于他们。  普通人从对方那里取东西时，不一定想从对方那里自动获得私人锚点标签。

note: type: Plain text
en: Often, "please pull" messages on the mailing list just provide two pieces of information: a repo URL and a branch name; this is designed to be easily cut&pasted at the end of a 'git fetch' command line:
zh_HANS-CN: 通常，邮件列表上的 "请拉"信息只提供了两条信息：一个 仓库URL 和一个分支名称；这被设计成可以轻松地剪切和粘贴在 "git fetch "命令行的末尾：

note: type: delimited block -
en: Linus, please pull from
zh_HANS-CN: Linus，请从这里拉取

note: type: delimited block -
en: to get the following updates...
zh_HANS-CN: 以获得以下更新...

note: type: Plain text
en: becomes:
zh_HANS-CN: 成为：

note: type: Plain text
en: In such a case, you do not want to automatically follow the other person's tags.
zh_HANS-CN: 在这种情况下，你不希望自动跟随对方的标签。

note: type: Plain text
en: One important aspect of Git is its distributed nature, which largely means there is no inherent "upstream" or "downstream" in the system.  On the face of it, the above example might seem to indicate that the tag namespace is owned by the upper echelon of people and that tags only flow downwards, but that is not the case.  It only shows that the usage pattern determines who are interested in whose tags.
zh_HANS-CN: Git 的一个重要方面是它的分布式性质，这很大程度上意味着系统中没有固有的 "上游 "或 "下游"。  从表面上看，上面的例子似乎表明标签命名空间是由上层人士拥有的，而标签只能向下流动，但事实并非如此。  它只是表明，使用模式决定了谁对谁的标签感兴趣。

note: type: Plain text
en: A one-shot pull is a sign that a commit history is now crossing the boundary between one circle of people (e.g. "people who are primarily interested in the networking part of the kernel") who may have their own set of tags (e.g. "this is the third release candidate from the networking group to be proposed for general consumption with 2.6.21 release") to another circle of people (e.g. "people who integrate various subsystem improvements").  The latter are usually not interested in the detailed tags used internally in the former group (that is what "internal" means).  That is why it is desirable not to follow tags automatically in this case.
zh_HANS-CN: 一次性拉取是一个标志，表明一个提交历史正在跨越一个圈子（例如 "主要对内核的网络部分感兴趣的人"）和另一个圈子（例如 "整合各种子系统改进的人"）之间的界限，后者可能有自己的一套标签（例如 "这是网络组的第三个候选版本，将在2.6.21版本中被建议用于一般消费"）。  后者通常对前一组内部使用的详细标签不感兴趣（这就是 "内部 "的意思）。  这就是为什么在这种情况下最好不要自动跟随标签。

note: type: Plain text
en: It may well be that among networking people, they may want to exchange the tags internal to their group, but in that workflow they are most likely tracking each other's progress by having remote-tracking branches.  Again, the heuristic to automatically follow such tags is a good thing.
zh_HANS-CN: 在这个网络知州，他们可能想交换他们小组内部的标签，但在那个工作流程中，他们很可能是通过有远程跟踪的分支来跟踪对方的进展。  同样，自动跟踪这种标签的启发式方法也是一个好东西。

note: type: Plain text
en: If you have imported some changes from another VCS and would like to add tags for major releases of your work, it is useful to be able to specify the date to embed inside of the tag object; such data in the tag object affects, for example, the ordering of tags in the gitweb interface.
zh_HANS-CN: 如果你从另一个VCS导入了一些修改，并想为你工作的主要版本添加标签，能够指定嵌入标签对象内部的日期是很有用的；标签对象中的这种数据会产生影响，例如，gitweb界面中标签的排序。

note: type: Plain text
en: To set the date used in future tag objects, set the environment variable GIT_COMMITTER_DATE (see the later discussion of possible values; the most common form is "YYYY-MM-DD HH:MM").
zh_HANS-CN: 要设置未来标签对象中使用的日期，请设置环境变量GIT_COMMITTER_DATE（见后面关于可能数值的讨论；最常见的形式是 "YYY-MM-DD HH:MM"）。

note: type: Plain text
en: git - the stupid content tracker
zh_HANS-CN: git - 傻瓜式内容追踪器

note: type: Plain text
en: Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals.
zh_HANS-CN: Git是一个快速、可扩展的分布式版本控制系统，它拥有异常丰富的命令集，可以提供高级操作和对内部的完全访问。

note: type: Plain text
en: See linkgit:gittutorial[7] to get started, then see linkgit:giteveryday[7] for a useful minimum set of commands.  The link:user-manual.html[Git User's Manual] has a more in-depth introduction.
zh_HANS-CN: 请参阅 linkgit:gittutorial[7] 来开始,然后参阅 linkgit:giteveryday[7] 获取有用的最小命令集。  link:user-manual.html[Git用户手册] 中拥有更为深入的介绍。

note: type: Plain text
en: After you mastered the basic concepts, you can come back to this page to learn what commands Git offers.  You can learn more about individual Git commands with "git help command".  linkgit:gitcli[7] manual page gives you an overview of the command-line command syntax.
zh_HANS-CN: 在掌握了基本概念之后，你可以回到本页了解Git提供的命令。  你可以通过“git help”命令了解更多关于单个Git命令的信息。  linkgit:gitcli[7] 手册页面为您提供了命令行命令语法的概述。

note: type: Plain text
en: A formatted and hyperlinked copy of the latest Git documentation can be viewed at https://git.github.io/htmldocs/git.html or https://git-scm.com/docs.
zh_HANS-CN: 最新Git文档的格式化和超链接副本可以在 https://git.github.io/htmldocs/git.html 或 https://git-scm.com/docs上查看。

note: type: Plain text
en: Prints the Git suite version that the 'git' program came from.
zh_HANS-CN: 打印‘git’程序的Git套件版本。

note: type: Plain text
en: This option is internally converted to `git version ...` and accepts the same options as the linkgit:git-version[1] command. If `--help` is also given, it takes precedence over `--version`.
zh_HANS-CN: 此选项在内部转换为 `git version ...` 并接受与linkgit:git-version[1] 命令相同的选项。如果`--version`后接`--help` 选项，则会优先展示`--version`选项的帮助信息。

note: type: Plain text
en: Prints the synopsis and a list of the most commonly used commands. If the option `--all` or `-a` is given then all available commands are printed. If a Git command is named this option will bring up the manual page for that command.
zh_HANS-CN: 打印概要和最常用的命令列表。如果给出选项`--all`或`--a`，则打印所有可用的命令。如果给出命令，该选项将调出该命令的手册页面。

note: type: Plain text
en: Other options are available to control how the manual page is displayed. See linkgit:git-help[1] for more information, because `git --help ...` is converted internally into `git help ...`.
zh_HANS-CN: 还有其他选项可以控制手册页面的显示方式。参阅linkgit:git-help[1]获取更多信息，因为 `git --help ...` 会在内部转换为 `git help ...`。

note: type: Plain text
en: Run as if git was started in '<path>' instead of the current working directory.  When multiple `-C` options are given, each subsequent non-absolute `-C <path>` is interpreted relative to the preceding `-C <path>`.  If '<path>' is present but empty, e.g. `-C ""`, then the current working directory is left unchanged.
zh_HANS-CN: 运行时就像git在'<path>'而不是在当前工作目录下启动一样。  当给出多个`-C`选项时，每个后续的非绝对的`-C <path>`都是相对于前一个`-C <path>`解释的。  如果'<path>'存在但为空，例如`-C ""`，那么就在当前工作目录启动。

note: type: Plain text
en: This option affects options that expect path name like `--git-dir` and `--work-tree` in that their interpretations of the path names would be made relative to the working directory caused by the `-C` option. For example the following invocations are equivalent:
zh_HANS-CN: 这个选项会影响到像`--git-dir`和`--work-tree`这样的需要路径名的选项，因为它们会用`-C`选项设置的工作目录进行相对路径的解释。例如，下面的调用是等价的：

note: type: Plain text
en: Pass a configuration parameter to the command. The value given will override values from configuration files.  The <name> is expected in the same format as listed by 'git config' (subkeys separated by dots).
zh_HANS-CN: 向命令传递一个配置参数。给出的值将覆盖配置文件的值。  <name>的格式应与'git config'列出的格式相同（子键由`.`分隔）。

note: type: Plain text
en: Like `-c <name>=<value>`, give configuration variable '<name>' a value, where <envvar> is the name of an environment variable from which to retrieve the value. Unlike `-c` there is no shortcut for directly setting the value to an empty string, instead the environment variable itself must be set to the empty string.  It is an error if the `<envvar>` does not exist in the environment. `<envvar>` may not contain an equals sign to avoid ambiguity with `<name>` containing one.
zh_HANS-CN: 像`-c <name>=<value>`一样，给配置变量'<name>'一个值，其中<envvar>是一个环境变量的名字，可以从中获取该环境变量的值。与`-c`不同的是，没有直接将值设置为空字符串的快捷方式，除非环境变量本身就设置为空字符串。  如果`<envvar>`在环境变量中不存在，则会报错。`<envvar>`可能不包含等号，以避免与包含等号的`<name>`产生歧义。

note: type: Plain text
en: This is useful for cases where you want to pass transitory configuration options to git, but are doing so on OS's where other processes might be able to read your cmdline (e.g. `/proc/self/cmdline`), but not your environ (e.g. `/proc/self/environ`). That behavior is the default on Linux, but may not be on your system.
zh_HANS-CN: 这对于你想向git传递临时配置选项，在其他进程可能能够读取你的cmdline（如`/proc/self/cmdline`），但不能读取你的environ（如`/proc/self/environ`）的操作系统上这样做很有用。这种行为在Linux上是默认的，但在你的系统上可能不是这样。

note: type: Plain text
en: Note that this might add security for variables such as `http.extraHeader` where the sensitive information is part of the value, but not e.g. `url.<base>.insteadOf` where the sensitive information can be part of the key.
zh_HANS-CN: 请注意，这可能会增加变量的安全性，例如`http.extraHeader`，因为他的敏感信息包含在值中，但并不会增加例如`url.<base>.insteadOf`这种变量的安全性，因为其敏感信息可能会包含在部分键中。

note: type: Plain text
en: Path to wherever your core Git programs are installed.  This can also be controlled by setting the GIT_EXEC_PATH environment variable. If no path is given, 'git' will print the current setting and then exit.
zh_HANS-CN: 安装Git核心程序的路径。  这也可以通过设置 GIT_EXEC_PATH 环境变量来控制。如果没有给出路径，'git'会打印当前的设置，然后退出。

note: type: Plain text
en: Print the path, without trailing slash, where Git's HTML documentation is installed and exit.
zh_HANS-CN: 打印Git的HTML文档的安装路径（尾部不带斜杠）然后退出。

note: type: Plain text
en: Print the manpath (see `man(1)`) for the man pages for this version of Git and exit.
zh_HANS-CN: 打印该版本Git man page的manpath（参阅`man(1)`），然后退出。

note: type: Plain text
en: Print the path where the Info files documenting this version of Git are installed and exit.
zh_HANS-CN: 打印记录该版本Git信息文件的安装路径并退出。

note: type: Plain text
en: Pipe all output into 'less' (or if set, $PAGER) if standard output is a terminal.  This overrides the `pager.<cmd>` configuration options (see the "Configuration Mechanism" section below).
zh_HANS-CN: 如果标准输出是一个终端，则将所有的输出输出到'less（git默认的分页器）'（如果设置，则为$PAGER）中。  这会覆盖`pager.<cmd>`配置选项（参阅下面的 "配置机制 "部分）。

note: type: Plain text
en: Do not pipe Git output into a pager.
zh_HANS-CN: 不使用分页器进行Git的输出。

note: type: Labeled list
en: --git-dir=<path>
zh_HANS-CN: --git-dir=<path（文件路径）>

note: type: Plain text
en: Set the path to the repository (".git" directory). This can also be controlled by setting the `GIT_DIR` environment variable. It can be an absolute path or relative path to current working directory.
zh_HANS-CN: 设置存储库的路径（".git "目录）。这也可以通过设置`GIT_DIR`环境变量来控制。<path>可以是绝对路径或是当前工作目录的相对路径。

note: type: Plain text
en: Specifying the location of the ".git" directory using this option (or `GIT_DIR` environment variable) turns off the repository discovery that tries to find a directory with ".git" subdirectory (which is how the repository and the top-level of the working tree are discovered), and tells Git that you are at the top level of the working tree.  If you are not at the top-level directory of the working tree, you should tell Git where the top-level of the working tree is, with the `--work-tree=<path>` option (or `GIT_WORK_TREE` environment variable)
zh_HANS-CN: 使用该选项（或`GIT_DIR`环境变量）指定".git "目录的位置，这会关闭对带有".git "子目录仓库的扫描（这是找到仓库和顶级工作区的方式），并告诉 Git 当前在顶级工作区。  如果当前并不在工作区的顶级目录，你应该用`--work-tree=<path>`选项（或`GIT_WORK_TREE`环境变量）告诉Git顶级工作区在哪里。

note: type: Plain text
en: If you just want to run git as if it was started in `<path>` then use `git -C <path>`.
zh_HANS-CN: 如果你只是想在`<path>`中运行Git，可以使用`git -C <path>`。

note: type: Labeled list
en: --work-tree=<path>
zh_HANS-CN: --work-tree=<path（文件路径）>

note: type: Plain text
en: Set the path to the working tree. It can be an absolute path or a path relative to the current working directory.  This can also be controlled by setting the GIT_WORK_TREE environment variable and the core.worktree configuration variable (see core.worktree in linkgit:git-config[1] for a more detailed discussion).
zh_HANS-CN: 设置工作树的路径。<path>可以是一个绝对路径或与当前工作目录相对的路径。  这也可以通过设置 GIT_WORK_TREE 环境变量和 core.worktree 配置变量来控制（参阅linkgit:git-config[1] 中的 core.worktree获取更为详细的论述）。

note: type: Plain text
en: Set the Git namespace.  See linkgit:gitnamespaces[7] for more details.  Equivalent to setting the `GIT_NAMESPACE` environment variable.
zh_HANS-CN: 设置 Git 命名空间。  参阅 linkgit:gitnamespaces[7] 以了解更多细节。  这相当于设置 `GIT_NAMESPACE` 环境变量。

note: type: Plain text
en: Treat the repository as a bare repository.  If GIT_DIR environment is not set, it is set to the current working directory.
zh_HANS-CN: 将该仓库视为裸仓库。  如果没有设置GIT_DIR环境变量，它将在当前工作目录生成仓库。

note: type: Plain text
en: Do not use replacement refs to replace Git objects. See linkgit:git-replace[1] for more information.
zh_HANS-CN: 不使用候补引用来替换 Git 对象。更多信息参阅 linkgit:git-replace[1]。

note: type: Plain text
en: Treat pathspecs literally (i.e. no globbing, no pathspec magic).  This is equivalent to setting the `GIT_LITERAL_PATHSPECS` environment variable to `1`.
zh_HANS-CN: 按字面意思处理路径规格（即不使用通配符，不使用路径规范功能）。  这相当于将`GIT_LITERAL_PATHSPECS`环境变量设置为`1`。

note: type: Plain text
en: Add "glob" magic to all pathspec. This is equivalent to setting the `GIT_GLOB_PATHSPECS` environment variable to `1`. Disabling globbing on individual pathspecs can be done using pathspec magic ":(literal)"
zh_HANS-CN: 在所有的路径规范中添加 "glob"功能。这相当于将`GIT_GLOB_PATHSPECS`环境变量设置为`1`。在单个路径规格上禁用通配符可以用路径规范功能":(literal) "来完成。

note: type: Plain text
en: Add "literal" magic to all pathspec. This is equivalent to setting the `GIT_NOGLOB_PATHSPECS` environment variable to `1`. Enabling globbing on individual pathspecs can be done using pathspec magic ":(glob)"
zh_HANS-CN: 在所有路径规范中添加 "literal"功能。这相当于将`GIT_NOGLOB_PATHSPECS`环境变量设为`1`。在单个路径规范上启用通配符功能，可以使用路径规范功能":(glob) "来完成。

note: type: Plain text
en: Add "icase" magic to all pathspec. This is equivalent to setting the `GIT_ICASE_PATHSPECS` environment variable to `1`.
zh_HANS-CN: 在所有的路径规范中添加 "icase "功能。这相当于将`GIT_ICASE_PATHSPECS`环境变量设置为`1`。

note: type: Plain text
en: Do not perform optional operations that require locks. This is equivalent to setting the `GIT_OPTIONAL_LOCKS` to `0`.
zh_HANS-CN: 禁止执行需要锁的可选操作。这相当于将`GIT_OPTIONAL_LOCKS`设置为`0'。

note: type: Plain text
en: List commands by group. This is an internal/experimental option and may change or be removed in the future. Supported groups are: builtins, parseopt (builtin commands that use parse-options), main (all commands in libexec directory), others (all other commands in `$PATH` that have git- prefix), list-<category> (see categories in command-list.txt), nohelpers (exclude helper commands), alias and config (retrieve command list from config variable completion.commands)
zh_HANS-CN: 按组列出命令。这是一个内部/实验性的选项，将来可能会改变或删除。支持的组有：buildins、parseopt（使用parse-options的内置命令）、main（libexec目录下的所有命令）、others（`$PATH`中其他带有git-前缀的命令）、list-<category>（参阅command-list.txt中的目录【原文是这么说的，但是下面那个Git命令章节已经列出了所有命令列表】）、nohelpers（排除辅助命令）、alias和config（在配置completion.commands中检索命令列表）

note: type: Title -
en: GIT COMMANDS
zh_HANS-CN: Git命令

note: type: Plain text
en: We divide Git into high level ("porcelain") commands and low level ("plumbing") commands.
zh_HANS-CN: 我们把Git分为上层封装命令（“瓷件”）和底层核心命令（“管件”）。

note: type: Title -
en: High-level commands (porcelain)
zh_HANS-CN: 上层封装命令（瓷件）

note: type: Plain text
en: We separate the porcelain commands into the main commands and some ancillary user utilities.
zh_HANS-CN: 我们将瓷件命令分为主要命令和一些辅助性的用户工具。

note: type: Title ~
en: Main porcelain commands
zh_HANS-CN: 主要瓷件命令

note: type: Title ~
en: Ancillary Commands
zh_HANS-CN: 辅助命令

note: type: Plain text
en: Manipulators:
zh_HANS-CN: 控制相关：

note: type: Plain text
en: Interrogators:
zh_HANS-CN: 审阅相关：

note: type: Title ~
en: Interacting with Others
zh_HANS-CN: 与其他应用交互

note: type: Plain text
en: These commands are to interact with foreign SCM and with other people via patch over e-mail.
zh_HANS-CN: 这些命令是为了与外部SCM（源代码管理工具）以及通过电子邮件与其他人进行交互。

note: type: Title ~
en: Reset, restore and revert
zh_HANS-CN: 重置、恢复和还原

note: type: Plain text
en: There are three commands with similar names: `git reset`, `git restore` and `git revert`.
zh_HANS-CN: 包括了三个名称相似的命令：`git reset`、`git restore`和`git revert`。

note: type: Plain text
en: linkgit:git-revert[1] is about making a new commit that reverts the changes made by other commits.
zh_HANS-CN: linkgit:git-revert[1] 是关于进行新的提交，以还原其他提交所做的更改。

note: type: Plain text
en: linkgit:git-restore[1] is about restoring files in the working tree from either the index or another commit. This command does not update your branch. The command can also be used to restore files in the index from another commit.
zh_HANS-CN: linkgit:git-restore[1] 是有关从索引或其他提交中恢复工作区中文件的命令。这个命令不会更新你的分支。该命令也可以用来从另一个提交中恢复索引中的文件。

note: type: Plain text
en: linkgit:git-reset[1] is about updating your branch, moving the tip in order to add or remove commits from the branch. This operation changes the commit history.
zh_HANS-CN: linkgit:git-reset[1] 是有关更新分支、移动提示的命令，以便从分支中添加或删除提交。这个操作会修改提交历史。

note: type: Plain text
en: `git reset` can also be used to restore the index, overlapping with `git restore`.
zh_HANS-CN: `git reset`也可以用来恢复索引，这个功能`git restore`的功能有些重合。

note: type: Title -
en: Low-level commands (plumbing)
zh_HANS-CN: 底层核心命令（管件）

note: type: Plain text
en: Although Git includes its own porcelain layer, its low-level commands are sufficient to support development of alternative porcelains.  Developers of such porcelains might start by reading about linkgit:git-update-index[1] and linkgit:git-read-tree[1].
zh_HANS-CN: 尽管 Git 包含了它自己的瓷件层，但它的底层核心命令足以支持替代瓷件的开发。  此类瓷件开发者可以从阅读 linkgit:git-update-index[1] 和 linkgit:git-read-tree[1] 开始。

note: type: Plain text
en: The interface (input, output, set of options and the semantics)  to these low-level commands are meant to be a lot more stable than Porcelain level commands, because these commands are primarily for scripted use.  The interface to Porcelain commands on the other hand are subject to change in order to improve the end user experience.
zh_HANS-CN: 这些底层命令的界面（输入、输出、选项集和语义）要比上层封装命令稳定得多，因为这些命令主要是用于脚本的使用。  另一方面，为了改善终端用户的体验，上层封装命令接口是可以改变的。

note: type: Plain text
en: The following description divides the low-level commands into commands that manipulate objects (in the repository, index, and working tree), commands that interrogate and compare objects, and commands that move objects and references between repositories.
zh_HANS-CN: 下面的描述将底层核心命令分为操作对象（在存储库、索引和工作树中）的命令、审阅和比较对象的命令，以及在存储库之间移动对象和引用的命令。

note: type: Title ~
en: Manipulation commands
zh_HANS-CN: 控制命令

note: type: Title ~
en: Interrogation commands
zh_HANS-CN: 审阅命令

note: type: Plain text
en: In general, the interrogate commands do not touch the files in the working tree.
zh_HANS-CN: 一般来说，审阅命令不接触工作区中的文件。

note: type: Title ~
en: Syncing repositories
zh_HANS-CN: 同步仓库

note: type: Plain text
en: The following are helper commands used by the above; end users typically do not use them directly.
zh_HANS-CN: 以下是上面使用的辅助命令，终端用户一般不会直接使用这些命令。

note: type: Title ~
en: Internal helper commands
zh_HANS-CN: 内部辅助命令

note: type: Plain text
en: These are internal helper commands used by other commands; end users typically do not use them directly.
zh_HANS-CN: 这些是其他命令使用的内部辅助命令；终端用户一般不会直接使用这些命令。

note: type: Title -
en: Guides
zh_HANS-CN: 指南

note: type: Plain text
en: The following documentation pages are guides about Git concepts.
zh_HANS-CN: 以下文档页是关于Git概念的指南。

note: type: Title -
en: Repository, command and file interfaces
zh_HANS-CN: 仓库、命令和文件接口

note: type: Plain text
en: This documentation discusses repository and command interfaces which users are expected to interact with directly. See `--user-formats` in linkgit:git-help[1] for more details on the criteria.
zh_HANS-CN: 本文档讨论了用户希望直接与之交互的仓库和命令接口。有关标准的更多细节，请参阅linkgit:git-help[1]中的`--user-formats`。

note: type: Title -
en: File formats, protocols and other developer interfaces
zh_HANS-CN: 文件格式、协议和其他开发者接口

note: type: Plain text
en: This documentation discusses file formats, over-the-wire protocols and other git developer interfaces. See `--developer-interfaces` in linkgit:git-help[1].
zh_HANS-CN: 本文档讨论了文件格式、线上协议和其他git开发者接口。参阅 linkgit:git-help[1] 中的`--developer-interfaces`。

note: type: Title -
en: Configuration Mechanism
zh_HANS-CN: 配置机制

note: type: Plain text
en: Git uses a simple text format to store customizations that are per repository and are per user.  Such a configuration file may look like this:
zh_HANS-CN: Git 使用一种简单的文本格式来存储每个仓库和每个用户的定制内容。  这样的配置文件可能是像这样：

note: type: delimited block -
en: #
    # A '#' or ';' character indicates a comment.
    #
zh_HANS-CN: #
    # 符号 '#' 或是 ';' 表示本行是注释信息
    #

note: type: delimited block -
en: ; user identity
    [user]
    	name = "Junio C Hamano"
    	email = "gitster@pobox.com"
zh_HANS-CN: ; 用户身份信息
    [user]
    	name = "Junio C Hamano"
    	email = "gitster@pobox.com"

note: type: Plain text
en: Various commands read from the configuration file and adjust their operation accordingly.  See linkgit:git-config[1] for a list and more details about the configuration mechanism.
zh_HANS-CN: 各种命令从配置文件中读取并相应地调整其操作。有关配置机制的列表和更多细节，请参阅 linkgit:git-config[1]。

note: type: Title -
en: Identifier Terminology
zh_HANS-CN: 标识符术语

note: type: Plain text
en: Indicates the object name for any type of object.
zh_HANS-CN: 表示任何类型的对象的名称。

note: type: Plain text
en: Indicates a blob object name.
zh_HANS-CN: 表示一个数据对象的名称。

note: type: Plain text
en: Indicates a tree object name.
zh_HANS-CN: 表示一个树对象名称。

note: type: Plain text
en: Indicates a commit object name.
zh_HANS-CN: 表示一个提交对象名称。

note: type: Plain text
en: Indicates a tree, commit or tag object name.  A command that takes a <tree-ish> argument ultimately wants to operate on a <tree> object but automatically dereferences <commit> and <tag> objects that point at a <tree>.
zh_HANS-CN: 表示一个树、提交或标签对象的名称。  一个需要<tree-ish>参数的命令最终会对<tree>对象进行操作，但会自动解除对指向<tree>对象的<commit>和<tag>对象的引用。

note: type: Plain text
en: Indicates a commit or tag object name.  A command that takes a <commit-ish> argument ultimately wants to operate on a <commit> object but automatically dereferences <tag> objects that point at a <commit>.
zh_HANS-CN: 表示一个提交或标记对象的名称。  一个需要<commit-ish>参数的命令最终要对<commit>对象进行操作，但会自动解除对指向<commit>的<tag>对象的引用。

note: type: Plain text
en: Indicates that an object type is required.  Currently one of: `blob`, `tree`, `commit`, or `tag`.
zh_HANS-CN: 表示需要一个对象类型。  目前是其中之一：`blob`、`tree`、`commit`或`tag`。

note: type: Plain text
en: Indicates a filename - almost always relative to the root of the tree structure `GIT_INDEX_FILE` describes.
zh_HANS-CN: 表示一个文件名——几乎总是相对于`GIT_INDEX_FILE`描述的树状结构的根部文件。

note: type: Title -
en: Symbolic Identifiers
zh_HANS-CN: 符号标识符

note: type: Plain text
en: Any Git command accepting any <object> can also use the following symbolic notation:
zh_HANS-CN: 任何接受任意<object>的Git命令也可以使用下面的符号表示法：

note: type: Plain text
en: indicates the head of the current branch.
zh_HANS-CN: 表示当前分支。

note: type: Plain text
en: a valid tag 'name' (i.e. a `refs/tags/<tag>` reference).
zh_HANS-CN: 一个有效的标签 "名称"（即一个`refs/tags/<tag>`引用）。

note: type: Plain text
en: a valid head 'name' (i.e. a `refs/heads/<head>` reference).
zh_HANS-CN: 一个有效的分支 "名称"（即一个`refs/heads/<head>`引用）。

note: type: Plain text
en: For a more complete list of ways to spell object names, see "SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].
zh_HANS-CN: 更完整的对象名称列表，请参阅 linkgit:gitrevisions[7] 中的 "校正说明 "部分。

note: type: Title -
en: File/Directory Structure
zh_HANS-CN: 文件/目录结构

note: type: Plain text
en: Please see the linkgit:gitrepository-layout[5] document.
zh_HANS-CN: 请参阅 linkgit:gitrepository-layout[5] 文档。

note: type: Plain text
en: Read linkgit:githooks[5] for more details about each hook.
zh_HANS-CN: 阅读 linkgit:githooks[5] 了解关于每个钩子的更多细节。

note: type: Plain text
en: Higher level SCMs may provide and manage additional information in the `$GIT_DIR`.
zh_HANS-CN: 更高级别的源代码管理工具(SCM)可以在"$GIT_DIR "中提供和管理额外的信息。

note: type: Title -
en: Terminology
zh_HANS-CN: 术语

note: type: Plain text
en: Please see linkgit:gitglossary[7].
zh_HANS-CN: 请参阅linkgit:gitglossary[7]。

note: type: Plain text
en: Various Git commands pay attention to environment variables and change their behavior.  The environment variables marked as "Boolean" take their values the same way as Boolean valued configuration variables, e.g.  "true", "yes", "on" and positive numbers are taken as "yes".
zh_HANS-CN: 各种 Git 命令都会关注环境变量并改变它们的行为。  以"布尔 值"为标记的环境变量，其取值方式与布尔值配置变量相同，例如，"true"、"yes"、"on "和正数被视为 "yes"。

note: type: Plain text
en: Here are the variables:
zh_HANS-CN: 常规变量：

note: type: Title ~
en: The Git Repository
zh_HANS-CN: Git仓库

note: type: Plain text
en: These environment variables apply to 'all' core Git commands. Nb: it is worth noting that they may be used/overridden by SCMS sitting above Git so take care if using a foreign front-end.
zh_HANS-CN: 这些环境变量适用于 "所有 "核心的 Git 命令。注：值得注意的是，它们可能被位于Git之上的SCMS使用/覆盖，所以如果之前使用过其他的源代码管理工具。

note: type: Plain text
en: This environment variable specifies an alternate index file. If not specified, the default of `$GIT_DIR/index` is used.
zh_HANS-CN: 这个环境变量指定了一个备用的索引文件。如果没有指定，则默认使用`$GIT_DIR/index`。

note: type: Plain text
en: This environment variable specifies what index version is used when writing the index file out.  It won't affect existing index files.  By default index file version 2 or 3 is used. See linkgit:git-update-index[1] for more information.
zh_HANS-CN: 这个环境变量指定在写出索引文件时使用什么版本。  它不会影响现有的索引文件。  默认情况下，索引文件的版本为 2 或 3。参见 linkgit:git-update-index[1] 获取更多信息。

note: type: Plain text
en: If the object storage directory is specified via this environment variable then the sha1 directories are created underneath - otherwise the default `$GIT_DIR/objects` directory is used.
zh_HANS-CN: 如果对象存储目录是通过这个环境变量指定的，那么sha1目录将在该目录下创建 - 否则将使用默认的`$GIT_DIR/objects`目录。

note: type: Plain text
en: Due to the immutable nature of Git objects, old objects can be archived into shared, read-only directories. This variable specifies a ":" separated (on Windows ";" separated) list of Git object directories which can be used to search for Git objects. New objects will not be written to these directories.
zh_HANS-CN: 由于Git对象的不可改变性，旧的对象可以被归档到共享的只读目录中。这个变量指定了一个由": "分隔（在Windows下为"; "分隔）的Git对象目录列表，可以用来搜索Git对象。新的对象将不会写入这些目录中。

note: type: Plain text
en: Entries that begin with `"` (double-quote) will be interpreted as C-style quoted paths, removing leading and trailing double-quotes and respecting backslash escapes. E.g., the value `"path-with-\"-and-:-in-it":vanilla-path` has two paths: `path-with-"-and-:-in-it` and `vanilla-path`.
zh_HANS-CN: 以`"`（双引号）开头的条目将被解释为C语言风格字符串路径，去掉前导和后导的双引号，并支持反斜杠转义。例如，`"path-with-\"-and-:-in-it":vanilla-path`有两个路径：`path-with-"-and-:-in-it`和`vanilla-path`。

note: type: Plain text
en: If the `GIT_DIR` environment variable is set then it specifies a path to use instead of the default `.git` for the base of the repository.  The `--git-dir` command-line option also sets this value.
zh_HANS-CN: 如果设置了`GIT_DIR`环境变量，那么它指定了一个路径来代替默认的`.git`作为仓库库的基础。  `--git-dir`命令行选项也能够设置这个值。

note: type: Plain text
en: Set the path to the root of the working tree.  This can also be controlled by the `--work-tree` command-line option and the core.worktree configuration variable.
zh_HANS-CN: 设置到工作区的根部路径。  这也可以由`--work-tree`命令行选项和core.worktree配置变量设置。

note: type: Plain text
en: Set the Git namespace; see linkgit:gitnamespaces[7] for details.  The `--namespace` command-line option also sets this value.
zh_HANS-CN: 设置 Git 命名空间；详见 linkgit:gitnamespaces[7]。  `--namespace`命令行选项也可以设置这个值。

note: type: Plain text
en: This should be a colon-separated list of absolute paths.  If set, it is a list of directories that Git should not chdir up into while looking for a repository directory (useful for excluding slow-loading network directories).  It will not exclude the current working directory or a GIT_DIR set on the command line or in the environment.  Normally, Git has to read the entries in this list and resolve any symlink that might be present in order to compare them with the current directory.  However, if even this access is slow, you can add an empty entry to the list to tell Git that the subsequent entries are not symlinks and needn't be resolved; e.g., `GIT_CEILING_DIRECTORIES=/maybe/symlink::/very/slow/non/symlink`.
zh_HANS-CN: 这应该是一个用冒号分隔的绝对路径列表。  如果设置了，它是一个目录列表，在寻找仓库目录时，Git不应该向上改变目录(chidir)（对于排除缓慢加载的网络目录很有用）。  它不会排除当前工作目录或在命令行或环境中设置的GIT_DIR。  通常情况下，Git 需要读取这个列表中的条目，并解析任何可能存在的符号链接，以便将它们与当前目录进行比较。  然而，如果连这个访问都很慢，你可以在列表中添加一个空条目，告诉Git后面的条目不是符号链接，不需要解析；例如，`GIT_CEILING_DIRECTORIES=/maybe/symlink::/very/slow/non/symlink`。

note: type: Plain text
en: When run in a directory that does not have ".git" repository directory, Git tries to find such a directory in the parent directories to find the top of the working tree, but by default it does not cross filesystem boundaries.  This Boolean environment variable can be set to true to tell Git not to stop at filesystem boundaries.  Like `GIT_CEILING_DIRECTORIES`, this will not affect an explicit repository directory set via `GIT_DIR` or on the command line.
zh_HANS-CN: 当在一个没有".git "仓库目录的目录下运行时，Git 会尝试在父目录中找到这样的目录来寻找工作区的顶端，但默认情况下它不会跨越文件系统的边界。  这个布尔环境变量可以被设置为 "true"，以告诉Git不要在文件系统边界处停止。  和`GIT_CEILING_DIRECTORIES`一样，这不会影响通过`GIT_DIR`或在命令行中设置的明确的仓库目录。

note: type: Plain text
en: If this variable is set to a path, non-worktree files that are normally in $GIT_DIR will be taken from this path instead. Worktree-specific files such as HEAD or index are taken from $GIT_DIR. See linkgit:gitrepository-layout[5] and linkgit:git-worktree[1] for details. This variable has lower precedence than other path variables such as GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY...
zh_HANS-CN: 如果这个变量被设置为一个路径，通常在$GIT_DIR中的非工作树文件将被从这个路径中取出。工作树中特定的文件，如 HEAD 或 index，则从 $GIT_DIR 取出。详情见 linkgit:gitrepository-layout[5] 和 linkgit:git-worktree[1]。这个变量的优先级低于其他路径变量，如 GIT_INDEX_FILE、GIT_OBJECT_DIRECTORY...

note: type: Title ~
en: Git Commits
zh_HANS-CN: Git提交

note: type: Plain text
en: The human-readable name used in the author identity when creating commit or tag objects, or when writing reflogs. Overrides the `user.name` and `author.name` configuration settings.
zh_HANS-CN: 在创建提交、标签对象或在编写日志时，作者身份中使用的可读名称。这会覆盖`user.name`和`author.name`配置的值。

note: type: Plain text
en: The email address used in the author identity when creating commit or tag objects, or when writing reflogs. Overrides the `user.email` and `author.email` configuration settings.
zh_HANS-CN: 在创建提交、标签对象或在编写引用日志时，用以表明作者身份所使用的电子邮件地址。这会覆盖`user.email`和`author.email`的配置值。

note: type: Plain text
en: The date used for the author identity when creating commit or tag objects, or when writing reflogs. See linkgit:git-commit[1] for valid formats.
zh_HANS-CN: 在创建提交、标签对象或在编写引用日志时，用于标注作者修改的日期。有效格式见 linkgit:git-commit[1]。

note: type: Plain text
en: The human-readable name used in the committer identity when creating commit or tag objects, or when writing reflogs. Overrides the `user.name` and `committer.name` configuration settings.
zh_HANS-CN: 在创建提交、标签对象或在编写引用日志时，提交者身份中使用的可读名称。这会覆盖`user.name`和`committer.name`的配置值。

note: type: Plain text
en: The email address used in the author identity when creating commit or tag objects, or when writing reflogs. Overrides the `user.email` and `committer.email` configuration settings.
zh_HANS-CN: 在创建提交、标签对象或在编写引用日志时，用以表明提交者所使用的电子邮件地址。这会覆盖`user.email`和`author.email`的配置值。

note: type: Plain text
en: The date used for the committer identity when creating commit or tag objects, or when writing reflogs. See linkgit:git-commit[1] for valid formats.
zh_HANS-CN: 在创建提交、标签对象或在编写 reflogs 时，用于标注提交者所作修改的日期。有效格式见 linkgit:git-commit[1]。

note: type: Plain text
en: The email address used in the author and committer identities if no other relevant environment variable or configuration setting has been set.
zh_HANS-CN: 如果没有设置其他相关的环境变量或配置设置，作者和提交者的电子邮件地址会参考该值。

note: type: Title ~
en: Git Diffs
zh_HANS-CN: Git差异比较(Diffs)

note: type: Plain text
en: Only valid setting is "--unified=??" or "-u??" to set the number of context lines shown when a unified diff is created.  This takes precedence over any "-U" or "--unified" option value passed on the Git diff command line.
zh_HANS-CN: 唯一有效的设置是"--unified=?? "或"-u??"，用于设置创建统一的差异时显示的文本行数。  这优先于 Git diff 命令行中传递的任何 "-U" 或 "--unified" 选项值。

note: type: Plain text
en: When the environment variable `GIT_EXTERNAL_DIFF` is set, the program named by it is called to generate diffs, and Git does not use its builtin diff machinery.  For a path that is added, removed, or modified, `GIT_EXTERNAL_DIFF` is called with 7 parameters:
zh_HANS-CN: 当环境变量`GIT_EXTERNAL_DIFF`被设置时，由它命名的程序被调用来生成差异化文本，而不使用Git内置的diff工具。  对于一个被添加、删除或修改的操作，`GIT_EXTERNAL_DIFF`会被调用，一共接收7个参数：

note: type: Plain text
en: where:
zh_HANS-CN: 使用：

note: type: Plain text
en: are files GIT_EXTERNAL_DIFF can use to read the contents of <old|new>,
zh_HANS-CN: 是GIT_EXTERNAL_DIFF用来读取<old|new>内容的文件，

note: type: Plain text
en: are the 40-hexdigit SHA-1 hashes,
zh_HANS-CN: 是40个十六进制的SHA-1哈希值，

note: type: Plain text
en: are the octal representation of the file modes.
zh_HANS-CN: 是文件模式的八进制表示法。

note: type: Plain text
en: For a path that is unmerged, `GIT_EXTERNAL_DIFF` is called with 1 parameter, <path>.
zh_HANS-CN: `GIT_EXTERNAL_DIFF`被调用时，对于未合并的路径可通过<path>进行设置。

note: type: Plain text
en: For each path `GIT_EXTERNAL_DIFF` is called, two environment variables, `GIT_DIFF_PATH_COUNTER` and `GIT_DIFF_PATH_TOTAL` are set.
zh_HANS-CN: 在调用每个路径 `GIT_EXTERNAL_DIFF` 时，都会设置两个环境变量 `GIT_DIFF_PATH_COUNTER` 和 `GIT_DIFF_PATH_TOTAL`。

note: type: Plain text
en: A 1-based counter incremented by one for every path.
zh_HANS-CN: 以 1 为单位的计数器，每条路径递增 1。

note: type: Plain text
en: The total number of paths.
zh_HANS-CN: 路径总数。

note: type: Plain text
en: A number controlling the amount of output shown by the recursive merge strategy.  Overrides merge.verbosity.  See linkgit:git-merge[1]
zh_HANS-CN: 一个数字，用于控制递归合并策略的输出量。 覆盖 merge.verbosity。 参见 linkgit:git-merge[1]

note: type: Plain text
en: This environment variable overrides `$PAGER`. If it is set to an empty string or to the value "cat", Git will not launch a pager.  See also the `core.pager` option in linkgit:git-config[1].
zh_HANS-CN: 该环境变量优先于 `$PAGER`。如果设置为空字符串或 "cat"，Git 将不会启动分页器。 参见 linkgit:git-config[1] 中的 `core.pager` 选项。

note: type: Plain text
en: A number controlling how many seconds to delay before showing optional progress indicators. Defaults to 2.
zh_HANS-CN: 一个数字，用于控制延迟多少秒后才显示可选的进度指示器。默认为 2。

note: type: Plain text
en: This environment variable overrides `$EDITOR` and `$VISUAL`.  It is used by several Git commands when, on interactive mode, an editor is to be launched. See also linkgit:git-var[1] and the `core.editor` option in linkgit:git-config[1].
zh_HANS-CN: 该环境变量覆盖 `$EDITOR` 和 `$VISUAL`。 有几条 Git 命令在交互模式下启动编辑器时会用到它。参见 linkgit:git-var[1] 和 linkgit:git-config[1] 中的 `core.editor` 选项。

note: type: Plain text
en: This environment variable overrides the configured Git editor when editing the todo list of an interactive rebase. See also linkgit:git-rebase[1] and the `sequence.editor` option in linkgit:git-config[1].
zh_HANS-CN: 在编辑交互式变基的待办事项列表时，该环境变量会覆盖配置的 Git 编辑器。参见 linkgit:git-rebase[1] 和 linkgit:git-config[1] 中的 `sequence.editor` 选项。

note: type: Plain text
en: If either of these environment variables is set then 'git fetch' and 'git push' will use the specified command instead of 'ssh' when they need to connect to a remote system.  The command-line parameters passed to the configured command are determined by the ssh variant.  See `ssh.variant` option in linkgit:git-config[1] for details.
zh_HANS-CN: 如果设置了这两个环境变量中的任何一个，'git fetch' 和 'git push' 在连接远程系统时就会使用指定的命令而不是 'ssh'。 传递给配置命令的命令行参数由 ssh 变量决定。 详见 linkgit:git-config[1] 中的 `ssh.variant` 选项。

note: type: Plain text
en: `$GIT_SSH_COMMAND` takes precedence over `$GIT_SSH`, and is interpreted by the shell, which allows additional arguments to be included.  `$GIT_SSH` on the other hand must be just the path to a program (which can be a wrapper shell script, if additional arguments are needed).
zh_HANS-CN: `$GIT_SSH_COMMAND` 优先于 `$GIT_SSH`，由 shell 解释，允许包含额外参数。 另一方面，`$GIT_SSH` 必须是一个程序的路径（如果需要额外参数，可以是一个包装 shell 脚本）。

note: type: Plain text
en: Usually it is easier to configure any desired options through your personal `.ssh/config` file.  Please consult your ssh documentation for further details.
zh_HANS-CN: 通常，通过个人的 `.ssh/config` 文件配置任何所需的选项会更容易。 详情请查阅 ssh 文档。

note: type: Plain text
en: If this environment variable is set, it overrides Git's autodetection whether `GIT_SSH`/`GIT_SSH_COMMAND`/`core.sshCommand` refer to OpenSSH, plink or tortoiseplink. This variable overrides the config setting `ssh.variant` that serves the same purpose.
zh_HANS-CN: 如果设置了这个环境变量，Git 会自动检测 `GIT_SSH`/`GIT_SSH_COMMAND`/`core.sshCommand`是否指向 OpenSSH、plink 或 tortoiseplink。该变量覆盖了具有相同作用的配置设置 `ssh.variant`。

note: type: Plain text
en: Setting and exporting this environment variable to any value tells Git not to verify the SSL certificate when fetching or pushing over HTTPS.
zh_HANS-CN: 将此环境变量设置并导出为任意值，Git 就不会在通过 HTTPS 获取或推送数据时验证 SSL 证书。

note: type: Plain text
en: Sets the treeish that gitattributes will be read from.
zh_HANS-CN: 设置读取 gitattributes 的书对象。

note: type: Plain text
en: If this environment variable is set, then Git commands which need to acquire passwords or passphrases (e.g. for HTTP or IMAP authentication)  will call this program with a suitable prompt as command-line argument and read the password from its STDOUT. See also the `core.askPass` option in linkgit:git-config[1].
zh_HANS-CN: 如果设置了这个环境变量，那么需要获取密码或口令的 Git 命令（例如用于 HTTP 或 IMAP 身份验证）就会调用这个程序，并将合适的提示符作为命令行参数，然后从其 STDOUT 中读取密码。参见 linkgit:git-config[1] 中的 `core.askPass` 选项。

note: type: Plain text
en: If this Boolean environment variable is set to false, git will not prompt on the terminal (e.g., when asking for HTTP authentication).
zh_HANS-CN: 如果将此布尔环境变量设为 false，git 将不会在终端上提示（例如，要求 HTTP 认证时）。

note: type: Plain text
en: Take the configuration from the given files instead from global or system-level configuration files. If `GIT_CONFIG_SYSTEM` is set, the system config file defined at build time (usually `/etc/gitconfig`)  will not be read. Likewise, if `GIT_CONFIG_GLOBAL` is set, neither `$HOME/.gitconfig` nor `$XDG_CONFIG_HOME/git/config` will be read. Can be set to `/dev/null` to skip reading configuration files of the respective level.
zh_HANS-CN: 从给定文件中获取配置，而不是从全局或系统级配置文件中获取。如果设置了 `GIT_CONFIG_SYSTEM`，则不会读取构建时定义的系统配置文件（通常是 `/etc/gitconfig`）。同样，如果设置了 `GIT_CONFIG_GLOBAL`，则既不会读取 `$HOME/.gitconfig` 也不会读取 `$XDG_CONFIG_HOME/git/config`。可以设置为 `/dev/null`，以跳过读取相应级别的配置文件。

note: type: Plain text
en: Whether to skip reading settings from the system-wide `$(prefix)/etc/gitconfig` file.  This Boolean environment variable can be used along with `$HOME` and `$XDG_CONFIG_HOME` to create a predictable environment for a picky script, or you can set it to true to temporarily avoid using a buggy `/etc/gitconfig` file while waiting for someone with sufficient permissions to fix it.
zh_HANS-CN: 是否跳过从系统范围内的 `$(prefix)/etc/gitconfig` 文件读取设置。 这个布尔环境变量可以与 `$HOME` 和 `$XDG_CONFIG_HOME` 一起使用，为挑剔的脚本创建一个可预测的环境，也可以设为 true 以暂时避免使用有错误的 `/etc/gitconfig` 文件，等待有足够权限的人来修复它。

note: NEEDSWORK: make it into a usual Boolean environment variable type: Plain text
en: If this environment variable is set to "1", then commands such
    as 'git blame' (in incremental mode), 'git rev-list', 'git log',
    'git check-attr' and 'git check-ignore' will
    force a flush of the output stream after each record have been
    flushed. If this
    variable is set to "0", the output of these commands will be done
    using completely buffered I/O.   If this environment variable is
    not set, Git will choose buffered or record-oriented flushing
    based on whether stdout appears to be redirected to a file or not.
zh_HANS-CN: 如果该环境变量设置为 "1"，那么诸如
    'git blame'（增量模式）、'git rev-list'、'git log'
    'git check-attr' 和 'git check-ignore' 等命令将
    会在每条记录被刷新后强制刷新输出流。
    强制刷新输出流。如果该
    变量设置为 "0"，这些命令的输出将使用完全缓冲的 I/O 方式进行
    使用完全缓冲的 I/O 输出。  如果不设置这个环境变量
    不设置，Git 将根据标准输出流是否重定向到文件，选择缓冲或面向记录的刷新方式
    根据标准输出流是否被重定向到文件。

note: type: Plain text
en: Enables general trace messages, e.g. alias expansion, built-in command execution and external command execution.
zh_HANS-CN: 启用一般跟踪信息，如别名扩展、内置命令执行和外部命令执行。

note: type: Plain text
en: If this variable is set to "1", "2" or "true" (comparison is case insensitive), trace messages will be printed to stderr.
zh_HANS-CN: 如果该变量设置为 "1"、"2" 或 "true"（比较不区分大小写），跟踪信息将被打印到标准错误流。

note: type: Plain text
en: If the variable is set to an integer value greater than 2 and lower than 10 (strictly) then Git will interpret this value as an open file descriptor and will try to write the trace messages into this file descriptor.
zh_HANS-CN: 如果变量设置为大于 2 小于 10（严格意义上）的整数值，那么 Git 会将该值解释为一个打开的文件描述符，并尝试将跟踪信息写入该文件描述符。

note: type: Plain text
en: Alternatively, if the variable is set to an absolute path (starting with a '/' character), Git will interpret this as a file path and will try to append the trace messages to it.
zh_HANS-CN: 另外，如果变量设置为绝对路径（以 '/' 字符开头），Git 会将其理解为文件路径，并尝试将跟踪信息附加到该路径上。

note: type: Plain text
en: Unsetting the variable, or setting it to empty, "0" or "false" (case insensitive) disables trace messages.
zh_HANS-CN: 取消对变量的设置，或将其设置为空、"0" 或 "false"（不区分大小写），将禁用跟踪信息。

note: type: Plain text
en: Enables trace messages for the filesystem monitor extension.  See `GIT_TRACE` for available trace output options.
zh_HANS-CN: 启用文件系统监视器扩展的跟踪信息。 有关可用的跟踪输出选项，请参阅 `GIT_TRACE`。

note: type: Plain text
en: Enables trace messages for all accesses to any packs. For each access, the pack file name and an offset in the pack is recorded. This may be helpful for troubleshooting some pack-related performance problems.  See `GIT_TRACE` for available trace output options.
zh_HANS-CN: 启用对所有数据包访问的跟踪信息。每次访问都会记录包文件名和包中的偏移量。这可能有助于排除一些与包相关的性能问题。 有关可用的跟踪输出选项，请参阅 `GIT_TRACE`。

note: type: Plain text
en: Enables trace messages for all packets coming in or out of a given program. This can help with debugging object negotiation or other protocol issues. Tracing is turned off at a packet starting with "PACK" (but see `GIT_TRACE_PACKFILE` below).  See `GIT_TRACE` for available trace output options.
zh_HANS-CN: 启用对进出指定程序的所有数据包的跟踪信息。这有助于调试对象协商或其他协议问题。以 "PACK" 开头的数据包会关闭跟踪（但请参阅下文的 `GIT_TRACE_PACKFILE`）。 有关可用的跟踪输出选项，请参见 `GIT_TRACE`。

note: type: Plain text
en: Enables tracing of packfiles sent or received by a given program. Unlike other trace output, this trace is verbatim: no headers, and no quoting of binary data. You almost certainly want to direct into a file (e.g., `GIT_TRACE_PACKFILE=/tmp/my.pack`) rather than displaying it on the terminal or mixing it with other trace output.
zh_HANS-CN: 可跟踪指定程序发送或接收的打包文件。与其他跟踪输出不同，这种跟踪是逐字的：没有标题，也不引用二进制数据。你几乎肯定希望将其直接存入一个文件（例如 `GIT_TRACE_PACKFILE=/tmp/my.pack`），而不是显示在终端上或与其他跟踪输出混在一起。

note: type: Plain text
en: Note that this is currently only implemented for the client side of clones and fetches.
zh_HANS-CN: 请注意，目前仅在克隆和获取的客户端实施了这一功能。

note: type: Plain text
en: Enables performance related trace messages, e.g. total execution time of each Git command.  See `GIT_TRACE` for available trace output options.
zh_HANS-CN: 启用与性能相关的跟踪信息，例如每条 Git 命令的总执行时间。 有关可用的跟踪输出选项，请参见 `GIT_TRACE`。

note: type: Plain text
en: Enables trace messages for operations on the ref database.  See `GIT_TRACE` for available trace output options.
zh_HANS-CN: 启用引用数据库操作的跟踪信息。 有关可用的跟踪输出选项，请参见 `GIT_TRACE`。

note: type: Plain text
en: Enables trace messages printing the .git, working tree and current working directory after Git has completed its setup phase.  See `GIT_TRACE` for available trace output options.
zh_HANS-CN: 在 Git 完成设置阶段后，启用打印 .git、工作树和当前工作目录的跟踪信息。 有关可用的跟踪输出选项，请参见 `GIT_TRACE`。

note: type: Plain text
en: Enables trace messages that can help debugging fetching / cloning of shallow repositories.  See `GIT_TRACE` for available trace output options.
zh_HANS-CN: 启用可帮助调试获取/克隆浅仓库的跟踪信息。 有关可用的跟踪输出选项，请参见 `GIT_TRACE`。

note: type: Plain text
en: Enables a curl full trace dump of all incoming and outgoing data, including descriptive information, of the git transport protocol.  This is similar to doing curl `--trace-ascii` on the command line.  See `GIT_TRACE` for available trace output options.
zh_HANS-CN: 启用对 git 传输协议所有传入和传出数据（包括描述性信息）的 curl 完整跟踪转储。 这类似于在命令行上执行 curl `--trace-ascii`。 有关可用的跟踪输出选项，请参阅 `GIT_TRACE`。

note: type: Plain text
en: When a curl trace is enabled (see `GIT_TRACE_CURL` above), do not dump data (that is, only dump info lines and headers).
zh_HANS-CN: 启用 curl 跟踪时（见上文 `GIT_TRACE_CURL`），不要转储数据（即只转储信息行和头文件）。

note: type: Plain text
en: Enables more detailed trace messages from the "trace2" library.  Output from `GIT_TRACE2` is a simple text-based format for human readability.
zh_HANS-CN: 启用来自 "trace2" 库的更详细的跟踪信息。 `GIT_TRACE2` 的输出是一种简单的文本格式，便于人类阅读。

note: type: Plain text
en: Alternatively, if the variable is set to an absolute path (starting with a '/' character), Git will interpret this as a file path and will try to append the trace messages to it.  If the path already exists and is a directory, the trace messages will be written to files (one per process)  in that directory, named according to the last component of the SID and an optional counter (to avoid filename collisions).
zh_HANS-CN: 另外，如果变量设置为绝对路径（以 '/' 字符开头），Git 会将其理解为文件路径，并尝试将跟踪信息附加到该路径上。 如果路径已经存在且是一个目录，跟踪信息将被写入该目录下的文件（每个进程一个），文件名根据 SID 的最后一个分量和一个可选的计数器命名（以避免文件名冲突）。

note: type: Plain text
en: In addition, if the variable is set to `af_unix:[<socket_type>:]<absolute-pathname>`, Git will try to open the path as a Unix Domain Socket.  The socket type can be either `stream` or `dgram`.
zh_HANS-CN: 此外，如果变量设置为 `af_unix:[<套接字类型>:]<绝对文件路径>`，Git 将尝试以 Unix 域套接字的方式打开路径。 套接字类型可以是 `stream` 或 `dgram`。

note: type: Plain text
en: See link:technical/api-trace2.html[Trace2 documentation] for full details.
zh_HANS-CN: 详见 link:technical/api-trace2.html[Trace2 文档]。

note: type: Plain text
en: This setting writes a JSON-based format that is suited for machine interpretation.  See `GIT_TRACE2` for available trace output options and link:technical/api-trace2.html[Trace2 documentation] for full details.
zh_HANS-CN: 此设置会写入适合机器解释的基于 JSON 的格式。 有关可用的跟踪输出选项，请参阅 `GIT_TRACE2`，以及 link:technical/api-trace2.html[Trace2 文档] 了解更多详情。

note: type: Plain text
en: In addition to the text-based messages available in `GIT_TRACE2`, this setting writes a column-based format for understanding nesting regions.  See `GIT_TRACE2` for available trace output options and link:technical/api-trace2.html[Trace2 documentation] for full details.
zh_HANS-CN: 除了 `GIT_TRACE2` 中可用的基于文本的信息外，此设置还可写入基于列的格式，以了解嵌套区域。 有关可用的跟踪输出选项，请参阅 `GIT_TRACE2`，以及 link:technical/api-trace2.html[Trace2 文档] 了解更多详情。

note: type: Plain text
en: By default, when tracing is activated, Git redacts the values of cookies, the "Authorization:" header, the "Proxy-Authorization:" header and packfile URIs. Set this Boolean environment variable to false to prevent this redaction.
zh_HANS-CN: 默认情况下，启动跟踪后，Git 会编辑 cookie、"Authorization:"（授权：）标头、"Proxy-Authorization:"（代理授权：）标头和 packfile URI 的值。将此布尔环境变量设为 false，可阻止这种编辑。

note: type: Plain text
en: Setting this Boolean environment variable to true will cause Git to treat all pathspecs literally, rather than as glob patterns. For example, running `GIT_LITERAL_PATHSPECS=1 git log -- '*.c'` will search for commits that touch the path `*.c`, not any paths that the glob `*.c` matches. You might want this if you are feeding literal paths to Git (e.g., paths previously given to you by `git ls-tree`, `--raw` diff output, etc).
zh_HANS-CN: 将这个布尔环境变量设为 true 会导致 Git 按字面意思而非通配符模式来处理所有路径规范。例如，运行 `GIT_LITERAL_PATHSPECS=1 git log -- '*.c'` 将搜索涉及路径 `*.c` 的提交，而不是任何与 glob `*.c` 匹配的路径。如果你正在向 Git 输入字面路径（例如，之前由 `git ls-tree`、`--raw` 差异输出等提供的路径），你可能需要这样做。

note: type: Plain text
en: Setting this Boolean environment variable to true will cause Git to treat all pathspecs as glob patterns (aka "glob" magic).
zh_HANS-CN: 将这个布尔环境变量设置为 true 会导致 Git 将所有路径规范视为通配符模式（又称 "glob" 魔法）。

note: type: Plain text
en: Setting this Boolean environment variable to true will cause Git to treat all pathspecs as literal (aka "literal" magic).
zh_HANS-CN: 将这个布尔环境变量设置为 true，Git 就会将所有路径规范都视为字面意思（又称 "literal"（字面）魔法）。

note: type: Plain text
en: Setting this Boolean environment variable to true will cause Git to treat all pathspecs as case-insensitive.
zh_HANS-CN: 将此布尔环境变量设置为 true 会导致 Git 将所有路径规范视为不区分大小写。

note: type: Plain text
en: When a ref is updated, reflog entries are created to keep track of the reason why the ref was updated (which is typically the name of the high-level command that updated the ref), in addition to the old and new values of the ref.  A scripted Porcelain command can use set_reflog_action helper function in `git-sh-setup` to set its name to this variable when it is invoked as the top level command by the end user, to be recorded in the body of the reflog.
zh_HANS-CN: 更新引用时，会创建引用日志条目来记录更新引用的原因（通常是更新引用的高级命令的名称），以及引用的新旧值。 脚本化的上层命令可以使用 `git-sh-setup` 中的 set_reflog_action 辅助函数，在被最终用户作为顶级命令调用时将其名称设置为该变量，并记录在引用日志的正文中。

note: type: Plain text
en: If this Boolean environment variable is set to false, ignore broken or badly named refs when iterating over lists of refs. Normally Git will try to include any such refs, which may cause some operations to fail. This is usually preferable, as potentially destructive operations (e.g., linkgit:git-prune[1]) are better off aborting rather than ignoring broken refs (and thus considering the history they point to as not worth saving). The default value is `1` (i.e., be paranoid about detecting and aborting all operations). You should not normally need to set this to `0`, but it may be useful when trying to salvage data from a corrupted repository.
zh_HANS-CN: 如果将此布尔环境变量设置为 false，则在遍历引用列表时会忽略已损坏或命名不正确的引用。通常情况下，Git 会尝试包含任何此类引用，这可能会导致某些操作失败。这通常是可取的，因为潜在的破坏性操作（例如 linkgit:git-prune[1]）最好是中止，而不是忽略破损的 refs（从而认为它们指向的历史不值得保存）。默认值是 `1`（即偏执地检测并终止所有操作）。通常不需要将其设置为 `0`，但在试图从损坏的版本库中挽救数据时可能会有用。

note: type: Plain text
en: If set to a colon-separated list of protocols, behave as if `protocol.allow` is set to `never`, and each of the listed protocols has `protocol.<name>.allow` set to `always` (overriding any existing configuration). See the description of `protocol.allow` in linkgit:git-config[1] for more details.
zh_HANS-CN: 如果设置为以冒号分隔的协议列表，其行为就好像 `protocol.allow` 被设置为 `never` 而每个列出的协议都被 `protocol.<名称>.allow` 设置为 `always`（覆盖任何现有配置）。详见 linkgit:git-config[1] 中关于 `protocol.allow` 的描述。

note: type: Plain text
en: Set this Boolean environment variable to false to prevent protocols used by fetch/push/clone which are configured to the `user` state.  This is useful to restrict recursive submodule initialization from an untrusted repository or for programs which feed potentially-untrusted URLS to git commands.  See linkgit:git-config[1] for more details.
zh_HANS-CN: 将此布尔环境变量设为 false，以防止 fetch/push/clone 使用配置为 `user` 状态的协议。 这对于限制从不可信任的仓库或向 git 命令提供可能不可信任的 URLS 的程序递归初始化子模块非常有用。 详见 linkgit:git-config[1]。

note: type: Plain text
en: For internal use only.  Used in handshaking the wire protocol.  Contains a colon ':' separated list of keys with optional values 'key[=value]'.  Presence of unknown keys and values must be ignored.
zh_HANS-CN: 仅供内部使用。 用于有线协议握手。 包含一个用冒号 ': ' 分隔的键列表，可选值为 'key[=value]'。 必须忽略未知键和值的存在。

note: type: Plain text
en: Note that servers may need to be configured to allow this variable to pass over some transports. It will be propagated automatically when accessing local repositories (i.e., `file://` or a filesystem path), as well as over the `git://` protocol. For git-over-http, it should work automatically in most configurations, but see the discussion in linkgit:git-http-backend[1]. For git-over-ssh, the ssh server may need to be configured to allow clients to pass this variable (e.g., by using `AcceptEnv GIT_PROTOCOL` with OpenSSH).
zh_HANS-CN: 请注意，可能需要对服务器进行配置，以允许该变量通过某些传输方式传递。在访问本地仓库（即 `file://` 或文件系统路径）以及通过 `git://` 协议时，它会自动传播。对于 git-over-http，它在大多数配置中都会自动工作，但请参阅 linkgit:git-http-backend[1] 中的讨论。对于 git-over-ssh，可能需要配置 ssh 服务器以允许客户端传递此变量（例如，在 OpenSSH 中使用 `AcceptEnv GIT_PROTOCOL`）。

note: type: Plain text
en: This configuration is optional. If the variable is not propagated, then clients will fall back to the original "v0" protocol (but may miss out on some performance improvements or features). This variable currently only affects clones and fetches; it is not yet used for pushes (but may be in the future).
zh_HANS-CN: 此配置为可选配置。如果不传播该变量，客户端将退回到原始的 "v0" 协议（但可能会错过某些性能改进或功能）。该变量目前只影响克隆和获取，尚未用于推送（但将来可能会）。

note: type: Plain text
en: If this Boolean environment variable is set to false, Git will complete any requested operation without performing any optional sub-operations that require taking a lock.  For example, this will prevent `git status` from refreshing the index as a side effect. This is useful for processes running in the background which do not want to cause lock contention with other operations on the repository.  Defaults to `1`.
zh_HANS-CN: 如果把这个布尔环境变量设置为 false，Git 将在不执行任何需要加锁的可选子操作的情况下完成任何请求的操作。 例如，这将防止 `git status` 刷新索引的副作用。这对后台运行的进程非常有用，因为它们不希望与版本库中的其他操作造成锁争用。 默认值为 `1`。

note: type: Plain text
en: Windows-only: allow redirecting the standard input/output/error handles to paths specified by the environment variables. This is particularly useful in multi-threaded applications where the canonical way to pass standard handles via `CreateProcess()` is not an option because it would require the handles to be marked inheritable (and consequently *every* spawned process would inherit them, possibly blocking regular Git operations). The primary intended use case is to use named pipes for communication (e.g. `\\.\pipe\my-git-stdin-123`).
zh_HANS-CN: 仅限 Windows：允许将标准输入/输出/错误句柄重定向到环境变量指定的路径。这在多线程应用程序中特别有用，因为通过 `CreateProcess()` 传递标准句柄的标准方式并不可行，因为这需要将句柄标记为可继承（因此 *每个* 生成的进程都会继承它们，可能会阻塞常规的 Git 操作）。主要的预期用例是使用命名管道进行通信（例如 `\\.\pipe\my-git-stdin-123`）。

note: type: Plain text
en: Two special values are supported: `off` will simply close the corresponding standard handle, and if `GIT_REDIRECT_STDERR` is `2>&1`, standard error will be redirected to the same handle as standard output.
zh_HANS-CN: 支持两个特殊值： 如果 `GIT_REDIRECT_STDERR` 是 `2>&1` ，标准错误将重定向到与标准输出相同的句柄。

note: type: Labeled list
en: `GIT_PRINT_SHA1_ELLIPSIS` (deprecated)
zh_HANS-CN: GIT_PRINT_SHA1_ELLIPSIS（已弃用）

note: type: Plain text
en: If set to `yes`, print an ellipsis following an (abbreviated) SHA-1 value.  This affects indications of detached HEADs (linkgit:git-checkout[1]) and the raw diff output (linkgit:git-diff[1]).  Printing an ellipsis in the cases mentioned is no longer considered adequate and support for it is likely to be removed in the foreseeable future (along with the variable).
zh_HANS-CN: 如果设置为 `yes`，会在 SHA-1 值（缩写）后打印省略号。 这会影响分离 HEAD 的指示（linkgit:git-checkout[1]）和原始差异输出（linkgit:git-diff[1]）。 在上述情况下打印省略号不再被认为是适当的，在可预见的将来，对它的支持可能会被移除（连同变量）。

note: type: Plain text
en: More detail on the following is available from the link:user-manual.html#git-concepts[Git concepts chapter of the user-manual] and linkgit:gitcore-tutorial[7].
zh_HANS-CN: 有关以下内容的更多详情，请参阅 link:user-manual.html#git-concepts[用户手册中的 Git 概念章节] 和 linkgit:gitcore-tutorial[7]。

note: type: Plain text
en: A Git project normally consists of a working directory with a ".git" subdirectory at the top level.  The .git directory contains, among other things, a compressed object database representing the complete history of the project, an "index" file which links that history to the current contents of the working tree, and named pointers into that history such as tags and branch heads.
zh_HANS-CN: Git 项目通常由一个工作目录和一个位于顶层的 ".git " 子目录组成。 除其他内容外，.git 目录还包含一个压缩对象数据库，代表项目的完整历史；一个 "index" 文件，将历史记录与当前工作区的内容相链接；以及指向历史记录的命名指针，如标签和分支头。

note: type: Plain text
en: The object database contains objects of three main types: blobs, which hold file data; trees, which point to blobs and other trees to build up directory hierarchies; and commits, which each reference a single tree and some number of parent commits.
zh_HANS-CN: 对象数据库包含三种主要类型的对象：blobs，用于保存文件数据；tree，用于指向 blobs 和其他树，以建立目录层次结构；commits，用于引用单个树和一定数量的父提交。

note: type: Plain text
en: The commit, equivalent to what other systems call a "changeset" or "version", represents a step in the project's history, and each parent represents an immediately preceding step.  Commits with more than one parent represent merges of independent lines of development.
zh_HANS-CN: 提交相当于其他系统所说的 "changeset" 或 "version"，代表项目历史中的一个步骤，每个父提交代表紧接着的前一个步骤。 有多个父提交的提交代表独立开发线的合并。

note: type: Plain text
en: All objects are named by the SHA-1 hash of their contents, normally written as a string of 40 hex digits.  Such names are globally unique.  The entire history leading up to a commit can be vouched for by signing just that commit.  A fourth object type, the tag, is provided for this purpose.
zh_HANS-CN: 所有对象都以其内容的 SHA-1 哈希值命名，通常写成由 40 个十六进制数字组成的字符串。 这些名称具有全局唯一性。 只需对某个提交进行签名，就能证明该提交之前的整个历史。 为此，我们提供了第四种对象类型——tag（标签）。

note: type: Plain text
en: When first created, objects are stored in individual files, but for efficiency may later be compressed together into "pack files".
zh_HANS-CN: 首次创建时，对象存储在单个文件中，但为了提高效率，以后可能会压缩成 "pack files"。

note: type: Plain text
en: Named pointers called refs mark interesting points in history.  A ref may contain the SHA-1 name of an object or the name of another ref.  Refs with names beginning `ref/head/` contain the SHA-1 name of the most recent commit (or "head") of a branch under development.  SHA-1 names of tags of interest are stored under `ref/tags/`.  A special ref named `HEAD` contains the name of the currently checked-out branch.
zh_HANS-CN: 被称为引用的命名指针标记着历史上有趣的点。 一个引用可以包含一个对象的 SHA-1 名称或另一个引用的名称。 名称以 `ref/head/` 开头的引用包含开发中分支的最新提交（或 "head"）的 SHA-1 名称。 相关标记的 SHA-1 名称存储在 `ref/tags/` 下。 名为 `HEAD` 的特殊引用包含当前已签出分支的名称。

note: type: Plain text
en: The index file is initialized with a list of all paths and, for each path, a blob object and a set of attributes.  The blob object represents the contents of the file as of the head of the current branch.  The attributes (last modified time, size, etc.) are taken from the corresponding file in the working tree.  Subsequent changes to the working tree can be found by comparing these attributes.  The index may be updated with new content, and new commits may be created from the content stored in the index.
zh_HANS-CN: 索引文件初始化时包含一个所有路径的列表，以及每个路径的一个二进制对象和一组属性。 二进制对象代表当前分支头部的文件内容。 属性（最后修改时间、大小等）取自工作树中的相应文件。 通过比较这些属性，可以发现工作区的后续更改。 索引可根据新内容进行更新，也可根据索引中存储的内容创建新提交。

note: type: Plain text
en: The index is also capable of storing multiple entries (called "stages")  for a given pathname.  These stages are used to hold the various unmerged version of a file when a merge is in progress.
zh_HANS-CN: 索引还能为给定路径名存储多个条目（称为 "stages"（阶段））。 在合并过程中，这些阶段用于保存文件的各种未合并版本。

note: type: Title -
en: FURTHER DOCUMENTATION
zh_HANS-CN: 更多文件

note: type: Plain text
en: See the references in the "description" section to get started using Git.  The following is probably more detail than necessary for a first-time user.
zh_HANS-CN: 请参阅 “说明” 部分的参考资料，开始使用 Git。 对于初次使用 Git 的用户来说，以下内容可能过于详细。

note: type: Plain text
en: The link:user-manual.html#git-concepts[Git concepts chapter of the user-manual] and linkgit:gitcore-tutorial[7] both provide introductions to the underlying Git architecture.
zh_HANS-CN: link:user-manual.html#git-concepts[用户手册中的 Git 概念章节] 和 linkgit:gitcore-tutorial[7] 都介绍了 Git 的底层架构。

note: type: Plain text
en: See linkgit:gitworkflows[7] for an overview of recommended workflows.
zh_HANS-CN: 请参阅 linkgit:gitworkflows[7] 了解推荐的工作流程。

note: type: Plain text
en: See also the link:howto-index.html[howto] documents for some useful examples.
zh_HANS-CN: 另请参阅 link:howto-index.html[howto] 文档，了解一些有用的示例。

note: type: Plain text
en: The internals are documented in the link:technical/api-index.html[Git API documentation].
zh_HANS-CN: 链接:technical/api-index.html[Git API 文档]中介绍了内部结构。

note: type: Plain text
en: Users migrating from CVS may also want to read linkgit:gitcvs-migration[7].
zh_HANS-CN: 从 CVS 迁移的用户可能还需要阅读 linkgit:gitcvs-migration[7]。

note: type: Plain text
en: Git was started by Linus Torvalds, and is currently maintained by Junio C Hamano. Numerous contributions have come from the Git mailing list <git@vger.kernel.org>.  http://www.openhub.net/p/git/contributors/summary gives you a more complete list of contributors.
zh_HANS-CN: Git 由 Linus Torvalds 发起，目前由 Junio C Hamano 维护。许多贡献来自 Git 邮件列表 <git@vger.kernel.org>。http://www.openhub.net/p/git/contributors/summary 提供了更完整的贡献者名单。

note: type: Plain text
en: If you have a clone of git.git itself, the output of linkgit:git-shortlog[1] and linkgit:git-blame[1] can show you the authors for specific parts of the project.
zh_HANS-CN: 如果克隆了 git.git，linkgit:git-shortlog[1] 和 linkgit:git-blame[1] 的输出结果可以显示项目特定部分的作者。

note: type: Plain text
en: Report bugs to the Git mailing list <git@vger.kernel.org> where the development and maintenance is primarily done.  You do not have to be subscribed to the list to send a message there.  See the list archive at https://lore.kernel.org/git for previous bug reports and other discussions.
zh_HANS-CN: 向 Git 邮件列表 <git@vger.kernel.org> 报告错误，开发和维护工作主要在此进行。 您无需订阅该列表即可在此发送信息。 有关以前的错误报告和其他讨论，请参阅 https://lore.kernel.org/git 的列表档案。

note: type: Plain text
en: Issues which are security relevant should be disclosed privately to the Git Security mailing list <git-security@googlegroups.com>.
zh_HANS-CN: 与安全相关的问题应在 Git 安全邮件列表 <git-security@googlegroups.com> 中私下披露。

note: type: Plain text
en: linkgit:gittutorial[7], linkgit:gittutorial-2[7], linkgit:giteveryday[7], linkgit:gitcvs-migration[7], linkgit:gitglossary[7], linkgit:gitcore-tutorial[7], linkgit:gitcli[7], link:user-manual.html[The Git User's Manual], linkgit:gitworkflows[7]
zh_HANS-CN: linkgit:gittutorial[7], linkgit:gittutorial-2[7], linkgit:giteveryday[7], linkgit:gitcvs-migration[7], linkgit:gitglossary[7], linkgit:gitcore-tutorial[7], linkgit:gitcli[7], link:user-manual.html[Git 用户手册], linkgit:gitworkflows[7]

note: type: Plain text
en: Invoked by 'git archive --remote' and sends a generated archive to the other end over the Git protocol.
zh_HANS-CN: 由 'git archive--remote' 调用，通过 Git 协议向另一端发送生成的归档文件。

note: type: Plain text
en: This command is usually not invoked directly by the end user.  The UI for the protocol is on the 'git archive' side, and the program pair is meant to be used to get an archive from a remote repository.
zh_HANS-CN: 终端用户通常不会直接调用该命令。 该协议的用户界面在 'git archive'（存档）端，程序对用于从远程仓库获取存档。

note: type: Plain text
en: In order to protect the privacy of objects that have been removed from history but may not yet have been pruned, `git-upload-archive` avoids serving archives for commits and trees that are not reachable from the repository's refs.  However, because calculating object reachability is computationally expensive, `git-upload-archive` implements a stricter but easier-to-check set of rules:
zh_HANS-CN: 为了保护已从历史中删除但可能尚未被剪枝的对象的隐私，`git-upload-archive` 避免为从版本库的 refs 无法访问的提交和树提供存档。 不过，由于计算对象可达性的计算成本很高，`git-upload-archive` 实现了一套更严格但更容易检查的规则：

note: type: Plain text
en: Clients may request a commit or tree that is pointed to directly by a ref. E.g., `git archive --remote=origin v1.0`.
zh_HANS-CN: 客户端可以请求由 ref 直接指向的提交或树。例如，`git archive --remote=origin v1.0`。

note: type: Plain text
en: Clients may request a sub-tree within a commit or tree using the `ref:path` syntax. E.g., `git archive --remote=origin v1.0:Documentation`.
zh_HANS-CN: 客户端可以使用 `ref:path` 语法请求提交或树中的子树。例如，`git archive --remote=origin v1.0:Documentation`。

note: type: Plain text
en: Clients may _not_ use other sha1 expressions, even if the end result is reachable. E.g., neither a relative commit like `master^` nor a literal sha1 like `abcd1234` is allowed, even if the result is reachable from the refs.
zh_HANS-CN: 客户端不得_使用其他 sha1 表达式，即使最终结果是可达的。例如，既不允许使用像 `master^` 这样的相对提交，也不允许使用像 `abcd1234` 这样的字面 sha1 表达式，即便结果能够从引用中找到。

note: type: Plain text
en: Note that rule 3 disallows many cases that do not have any privacy implications. These rules are subject to change in future versions of git, and the server accessed by `git archive --remote` may or may not follow these exact rules.
zh_HANS-CN: 请注意，规则 3 不允许许多不涉及隐私的情况。这些规则可能会在未来的 git 版本中修改，而通过 `git archive --remote` 访问的服务器可能会也可能不会完全遵循这些规则。

note: type: Plain text
en: If the config option `uploadArchive.allowUnreachable` is true, these rules are ignored, and clients may use arbitrary sha1 expressions.  This is useful if you do not care about the privacy of unreachable objects, or if your object database is already publicly available for access via non-smart-http.
zh_HANS-CN: 如果配置选项 `uploadArchive.allowUnreachable` 为 true，这些规则将被忽略，客户端可以使用任意的 sha1 表达式。 如果你不关心无法访问对象的隐私，或者如果你的对象数据库已经公开，可以通过非智能 HTTP 访问，那么这将非常有用。

note: type: Plain text
en: The repository to get a tar archive from.
zh_HANS-CN: 要获取 tar 压缩包的仓库。

note: type: Plain text
en: 'git-upload-pack' [--[no-]strict] [--timeout=<n>] [--stateless-rpc]
    		  [--advertise-refs] <directory>
zh_HANS-CN: 'git-upload-pack' [--[no-]strict] [--timeout=<n>] [--stateless-rpc]
    		  [--advertise-refs] <目录>

note: type: Plain text
en: Invoked by 'git fetch-pack', learns what objects the other side is missing, and sends them after packing.
zh_HANS-CN: 由 'git fetch-pack' 调用，了解对方缺少哪些对象，并在打包后发送。

note: type: Plain text
en: This command is usually not invoked directly by the end user.  The UI for the protocol is on the 'git fetch-pack' side, and the program pair is meant to be used to pull updates from a remote repository.  For push operations, see 'git send-pack'.
zh_HANS-CN: 终端用户通常不会直接调用该命令。 该协议的用户界面在 'git fetch-pack' 端，程序对用于从远程仓库拉取更新。 关于推送操作，请参阅 'git send-pack'。

note: type: Plain text
en: Do not try <directory>/.git/ if <directory> is no Git directory.
zh_HANS-CN: 如果<directory>不是git目录，请不要尝试<directory>/.git/。

note: type: Plain text
en: Interrupt transfer after <n> seconds of inactivity.
zh_HANS-CN: <n> 秒不活动后中断传输。

note: type: Plain text
en: Perform only a single read-write cycle with stdin and stdout.  This fits with the HTTP POST request processing model where a program may read the request, write a response, and must exit.
zh_HANS-CN: 只对标准输入和标准输出执行一次读写循环。 这符合 HTTP POST 请求处理模式，即程序可以读取请求、写入响应，然后必须退出。

note: type: Plain text
en: Used by linkgit:git-http-backend[1] to serve up `$GIT_URL/info/refs?service=git-upload-pack` requests. See "Smart Clients" in linkgit:gitprotocol-http[5] and "HTTP Transport" in the linkgit:gitprotocol-v2[5] documentation. Also understood by linkgit:git-receive-pack[1].
zh_HANS-CN: 由 linkgit:git-http-backend[1] 使用，用于提供 `$GIT_URL/info/refs?service=git-upload-pack` 请求。参见 linkgit:gitprotocol-http[5] 中的 “智能客户端” 和 linkgit:gitprotocol-v2[5] 文档中的 “HTTP 传输”。也可理解为 linkgit:git-receive-pack[1]。

note: type: Plain text
en: The repository to sync from.
zh_HANS-CN: 要同步的仓库。

note: type: Plain text
en: Internal variable used for handshaking the wire protocol. Server admins may need to configure some transports to allow this variable to be passed. See the discussion in linkgit:git[1].
zh_HANS-CN: 用于与传输协议握手的内部变量。服务器管理员可能需要配置某些传输协议，以允许传递此变量。请参阅 linkgit:git[1] 中的讨论。

note: type: Plain text
en: git-var - Show a Git logical variable
zh_HANS-CN: git-var - 显示 Git 逻辑变量

note: type: Plain text
en: Prints a Git logical variable. Exits with code 1 if the variable has no value.
zh_HANS-CN: 打印 Git 逻辑变量。如果变量没有值，则以代码 1 退出。

note: type: Plain text
en: Cause the logical variables to be listed. In addition, all the variables of the Git configuration file .git/config are listed as well. (However, the configuration variables listing functionality is deprecated in favor of `git config -l`.)
zh_HANS-CN: 会导致逻辑变量被列出。此外，Git 配置文件 .git/config 中的所有变量也会被列出。(不过，列出配置变量的功能已被弃用，改用 `git config -l`。）

note: type: Title -
en: VARIABLES
zh_HANS-CN: 变量

note: type: Plain text
en: The author of a piece of code.
zh_HANS-CN: 一段代码的作者。

note: type: Plain text
en: The person who put a piece of code into Git.
zh_HANS-CN: 将代码放入 Git 的人。

note: type: Plain text
en: Text editor for use by Git commands.  The value is meant to be interpreted by the shell when it is used.  Examples: `~/bin/vi`, `$SOME_ENVIRONMENT_VARIABLE`, `"C:\Program Files\Vim\gvim.exe" --nofork`.  The order of preference is the `$GIT_EDITOR` environment variable, then `core.editor` configuration, then `$VISUAL`, then `$EDITOR`, and then the default chosen at compile time, which is usually 'vi'.
zh_HANS-CN: 供 Git 命令使用的文本编辑器。  该值在使用时由 shell 解释。  例如~/bin/vi`、`$SOME_ENVIRONMENT_VARIABLE`、`"C:\Program Files\Vim\gvim.exe" --nofork`。  首选顺序是 `$GIT_EDITOR` 环境变量，然后是 `core.editor` 配置，然后是 `$VISUAL`，然后是 `$EDITOR`，然后是编译时选择的默认值，通常是 'vi'。

note: type: Plain text
en:     The build you are using chose '{git-default-editor}' as the default.
zh_HANS-CN:     您正在使用的版本选择了 '{git-default-editor}' 作为默认编辑器。

note: type: Plain text
en: Text editor used to edit the 'todo' file while running `git rebase -i`. Like `GIT_EDITOR`, the value is meant to be interpreted by the shell when it is used. The order of preference is the `$GIT_SEQUENCE_EDITOR` environment variable, then `sequence.editor` configuration, and then the value of `git var GIT_EDITOR`.
zh_HANS-CN: 用于在运行 `git rebase -i` 时编辑 'todo' 文件的文本编辑器。与 `GIT_EDITOR`一样，该值在使用时由 shell 解释。首选顺序是 `$GIT_SEQUENCE_EDITOR` 环境变量，然后是 `sequence.editor` 配置，最后是 `git var GIT_EDITOR` 的值。

note: type: Plain text
en: Text viewer for use by Git commands (e.g., 'less').  The value is meant to be interpreted by the shell.  The order of preference is the `$GIT_PAGER` environment variable, then `core.pager` configuration, then `$PAGER`, and then the default chosen at compile time (usually 'less').
zh_HANS-CN: 供 Git 命令（如 'less'）使用的文本查看器。  该值由 shell 解释。  首选顺序是 `$GIT_PAGER` 环境变量，然后是 `core.pager` 配置，然后是 `$PAGER`，然后是编译时选择的默认值（通常是 'less'）。

note: type: Plain text
en:     The build you are using chose '{git-default-pager}' as the default.
zh_HANS-CN:     您正在使用的构建选择了 '{git-default-pager}' 作为默认设置。

note: type: Plain text
en: The name of the first branch created in newly initialized repositories.
zh_HANS-CN: 在新初始化的仓库中创建的第一个分支的名称。

note: type: Plain text
en: The path of the binary providing the POSIX shell for commands which use the shell.
zh_HANS-CN: 为使用 shell 的命令提供 POSIX shell 的二进制文件路径。

note: type: Plain text
en: The path to the system linkgit:gitattributes[5] file, if one is enabled.
zh_HANS-CN: 系统 linkgit:gitattributes[5] 文件的路径（如果已启用）。

note: type: Plain text
en: The path to the global (per-user) linkgit:gitattributes[5] file.
zh_HANS-CN: 全局（每个用户）linkgit:gitattributes[5] 文件的路径。

note: type: Plain text
en: The path to the system configuration file, if one is enabled.
zh_HANS-CN: 系统配置文件的路径（如果已启用）。

note: type: Plain text
en: The path to the global (per-user) configuration files, if any.
zh_HANS-CN: 全局（按用户）配置文件的路径（如果有）。

note: type: Plain text
en: Most path values contain only one value. However, some can contain multiple values, which are separated by newlines, and are listed in order from highest to lowest priority.  Callers should be prepared for any such path value to contain multiple items.
zh_HANS-CN: 大多数路径值只包含一个值。不过，有些路径值可能包含多个值，这些值之间用换行分隔，并按优先级从高到低排列。  调用者应做好任何此类路径值包含多个项目的准备。

note: type: Plain text
en: Note that paths are printed even if they do not exist, but not if they are disabled by other environment variables.
zh_HANS-CN: 请注意，即使路径不存在，也会打印出来，但如果路径被其他环境变量禁用，则不会打印出来。

note: type: Plain text
en: git-verify-commit - Check the GPG signature of commits
zh_HANS-CN: git-verify-commit - 检查提交的 GPG 签名

note: type: Plain text
en: Validates the GPG signature created by 'git commit -S'.
zh_HANS-CN: 验证 'git commit -S' 创建的 GPG 签名。

note: type: Plain text
en: Print the raw gpg status output to standard error instead of the normal human-readable output.
zh_HANS-CN: 将原始 gpg 状态输出打印到标准错误，而不是正常的人类可读输出。

note: type: Plain text
en: Print the contents of the commit object before validating it.
zh_HANS-CN: 在验证之前打印提交对象的内容。

note: type: Plain text
en: SHA-1 identifiers of Git commit objects.
zh_HANS-CN: Git 提交对象的 SHA-1 标识符。

note: type: Plain text
en: git-verify-tag - Check the GPG signature of tags
zh_HANS-CN: git-verify-tag - 检查标签的 GPG 签名

note: type: Plain text
en: Validates the gpg signature created by 'git tag'.
zh_HANS-CN: 验证由 'git tag' 创建的 gpg 签名。

note: type: Plain text
en: Print the contents of the tag object before validating it.
zh_HANS-CN: 在验证之前打印标记对象的内容。

note: type: Labeled list
en: <tag>...
zh_HANS-CN: <标签>...

note: type: Plain text
en: SHA-1 identifiers of Git tag objects.
zh_HANS-CN: Git 标签对象的 SHA-1 标识符。

note: type: Plain text
en: This script tries, as much as possible, to display the URLs and FILEs that are passed as arguments, as HTML pages in new tabs on an already opened web browser.
zh_HANS-CN: 该脚本尽可能将作为参数传递的 URL 和 FILE 作为 HTML 页面显示在已打开的网页浏览器的新标签页中。

note: type: Plain text
en: The following browsers (or commands) are currently supported:
zh_HANS-CN: 目前支持以下浏览器（或命令）：

note: type: Plain text
en: firefox (this is the default under X Window when not using KDE)
zh_HANS-CN: firefox（不使用 KDE 时，这是 X Window 下的默认设置）

note: type: Plain text
en: chromium (also supported as chromium-browser)
zh_HANS-CN: chromium (也支持其他 chromium 内核浏览器)

note: type: Plain text
en: google-chrome (also supported as chrome)
zh_HANS-CN: 谷歌浏览器（也支持chrome浏览器）

note: type: Plain text
en: konqueror (this is the default under KDE, see 'Note about konqueror' below)
zh_HANS-CN: konqueror（这是 KDE 下的默认设置，参见下文 ‘关于 konqueror 的说明’）

note: type: Plain text
en: open (this is the default under Mac OS X GUI)
zh_HANS-CN: open（这是 Mac OS X 图形用户界面下的默认设置）

note: type: Plain text
en: start (this is the default under MinGW)
zh_HANS-CN: start（这是 MinGW 下的默认设置）

note: type: Plain text
en: cygstart (this is the default under Cygwin)
zh_HANS-CN: cygstart（这是 Cygwin 下的默认设置）

note: type: Plain text
en: Custom commands may also be specified.
zh_HANS-CN: 也可指定自定义命令。

note: type: Plain text
en: Use the specified browser. It must be in the list of supported browsers.
zh_HANS-CN: 使用指定的浏览器。它必须在支持的浏览器列表中。

note: type: Plain text
en: CONF.VAR is looked up in the Git config files. If it's set, then its value specifies the browser that should be used.
zh_HANS-CN: CONF.VAR 会在 Git 配置文件中查找。如果设置了 CONF.VAR，则其值将指定应使用的浏览器。

note: type: Title ~
en: CONF.VAR (from -c option) and web.browser
zh_HANS-CN: CONF.VAR（来自 -c 选项）和 web.browser

note: type: Plain text
en: The web browser can be specified using a configuration variable passed with the -c (or --config) command-line option, or the `web.browser` configuration variable if the former is not used.
zh_HANS-CN: 网络浏览器可以通过与 -c（或 --config）命令行选项一起传递的配置变量来指定，如果不使用前者，则使用 `web.browser` 配置变量。

note: type: Title ~
en: browser.<tool>.path
zh_HANS-CN: browser.<工具>.path

note: type: Plain text
en: You can explicitly provide a full path to your preferred browser by setting the configuration variable `browser.<tool>.path`. For example, you can configure the absolute path to firefox by setting 'browser.firefox.path'. Otherwise, 'git web{litdd}browse' assumes the tool is available in PATH.
zh_HANS-CN: 您可以通过设置配置变量 `browser.<工具>.path`，明确提供首选浏览器的完整路径。例如，可以通过设置 'browser.firefox.path' 来配置 firefox 的绝对路径。否则，'git web{litdd}browse' 会假定该工具在 PATH 中可用。

note: type: Title ~
en: browser.<tool>.cmd
zh_HANS-CN: browser.<工具>.cmd

note: type: Plain text
en: When the browser, specified by options or configuration variables, is not among the supported ones, then the corresponding `browser.<tool>.cmd` configuration variable will be looked up. If this variable exists then 'git web{litdd}browse' will treat the specified tool as a custom command and will use a shell eval to run the command with the URLs passed as arguments.
zh_HANS-CN: 如果选项或配置变量指定的浏览器不在支持之列，则会查找相应的 `browser.<工具>.cmd` 配置变量。如果该变量存在，'git web{litdd}browse' 就会将指定的工具视为自定义命令，并使用 shell eval 以传递的 URL 作为参数运行该命令。

note: type: Title -
en: NOTE ABOUT KONQUEROR
zh_HANS-CN: 关于 Konqueror 的说明

note: type: Plain text
en: When 'konqueror' is specified by a command-line option or a configuration variable, we launch 'kfmclient' to try to open the HTML man page on an already opened konqueror in a new tab if possible.
zh_HANS-CN: 当命令行选项或配置变量指定了 'konqueror' 时，我们会启动 'kfmclient'，尽可能在已打开的 konqueror 上以新标签页打开 HTML man 页面。

note: type: Plain text
en: For consistency, we also try such a trick if 'browser.konqueror.path' is set to something like `A_PATH_TO/konqueror`. That means we will try to launch `A_PATH_TO/kfmclient` instead.
zh_HANS-CN: 为了保持一致性，如果 'browser.konqueror.path ' 被设置为 `A_PATH_TO/konqueror`，我们也会尝试这样做。这意味着我们将尝试启动 `A_PATH_TO/kfmclient`，而不是 `A_PATH_TO/kfmclient`。

note: type: Title ~
en: Note about git-config --global
zh_HANS-CN: 关于 git-config --global 的注意事项

note: type: Plain text
en: Note that these configuration variables should probably be set using the `--global` flag, for example like this:
zh_HANS-CN: 请注意，这些配置变量可能应该使用 `--global` 标志来设置，例如像这样：

note: type: Plain text
en: git-whatchanged - Show logs with difference each commit introduces
zh_HANS-CN: git-whatchanged - 显示每次提交引入的差异日志

note: type: Plain text
en: 'git whatchanged' <option>...
zh_HANS-CN: 'git whatchanged' <选项>...

note: type: Plain text
en: Shows commit logs and diff output each commit introduces.
zh_HANS-CN: 显示每次提交引入的提交日志和差异输出。

note: type: Plain text
en: New users are encouraged to use linkgit:git-log[1] instead.  The `whatchanged` command is essentially the same as linkgit:git-log[1] but defaults to show the raw format diff output and to skip merges.
zh_HANS-CN: 建议新用户使用 linkgit:git-log[1] 代替。 `whatchanged` 命令与 linkgit:git-log[1] 基本相同，但默认显示原始格式的差异输出并跳过合并。

note: type: Plain text
en: The command is kept primarily for historical reasons; fingers of many people who learned Git long before `git log` was invented by reading Linux kernel mailing list are trained to type it.
zh_HANS-CN: 保留该命令主要是出于历史原因；早在 `git log` 被发明之前，许多人就通过阅读 Linux 内核邮件列表学会了输入该命令。

note: type: Plain text
en: Show as patches the commits since version 'v2.6.12' that changed any file in the include/scsi or drivers/scsi subdirectories
zh_HANS-CN: 以补丁形式显示自版本 'v2.6.12' 以来修改了 include/scsi 或 drivers/scsi 子目录中任何文件的提交内容

note: type: Plain text
en: Show the changes during the last two weeks to the file 'gitk'.  The "--" is necessary to avoid confusion with the *branch* named 'gitk'
zh_HANS-CN: 显示过去两周内 'gitk' 文件的改动。  为了避免与名为 'gitk' 的*分支*混淆，"--" 是必要的

note: type: Plain text
en: git-worktree - Manage multiple working trees
zh_HANS-CN: git-worktree - 管理多个工作区

note: type: Plain text
en: Manage multiple working trees attached to the same repository.
zh_HANS-CN: 管理附属于同一仓库的多个工作区。

note: type: Plain text
en: A git repository can support multiple working trees, allowing you to check out more than one branch at a time.  With `git worktree add` a new working tree is associated with the repository, along with additional metadata that differentiates that working tree from others in the same repository.  The working tree, along with this metadata, is called a "worktree".
zh_HANS-CN: 一个 git 仓库可以支持多个工作区，允许你一次签出多个分支。  通过`git worktree add`，一个新的工作区与仓库相关联，同时还有额外的元数据，以区分该工作区与同一仓库中的其他工作区。  工作区目录树，连同这些元数据，被称为 "工作区"。

note: type: Plain text
en: This new worktree is called a "linked worktree" as opposed to the "main worktree" prepared by linkgit:git-init[1] or linkgit:git-clone[1].  A repository has one main worktree (if it's not a bare repository) and zero or more linked worktrees. When you are done with a linked worktree, remove it with `git worktree remove`.
zh_HANS-CN: 这个新的工作区被称为 "链接工作区"，与 linkgit:git-init[1] 或 linkgit:git-clone[1] 所准备的 "主工作区 "相对应。  一个仓库有一个主工作区（如果它不是一个裸仓库）和零个或多个链接工作区。当你用完一个链接工作区后，用 `git worktree remove` 删除它。

note: type: Plain text
en: In its simplest form, `git worktree add <path>` automatically creates a new branch whose name is the final component of `<path>`, which is convenient if you plan to work on a new topic. For instance, `git worktree add ../hotfix` creates new branch `hotfix` and checks it out at path `../hotfix`. To instead work on an existing branch in a new worktree, use `git worktree add <path> <branch>`. On the other hand, if you just plan to make some experimental changes or do testing without disturbing existing development, it is often convenient to create a 'throwaway' worktree not associated with any branch. For instance, `git worktree add -d <path>` creates a new worktree with a detached `HEAD` at the same commit as the current branch.
zh_HANS-CN: 在其最简单的形式中，`git worktree add <路径>`自动创建一个新的分支，其名称是`<路径>`的最后一个组成部分，如果你计划在一个新的主题上工作，这很方便。例如，`git worktree add .../hotfix`创建了新的分支`hotfix`，并在路径`.../hotfix`处签出它。如果要在一个新的工作区中处理现有的分支，可以使用`git worktree add <路径> <分支>`。另一方面，如果你只是打算做一些实验性的修改，或者在不影响现有开发的情况下进行测试，创建一个不与任何分支相关联的 "抛弃式 "工作区通常是很方便的。例如，`git worktree add -d <路径>`在与当前分支相同的提交中，创建一个带有分离`HEAD`的新工作区。

note: type: Plain text
en: If a working tree is deleted without using `git worktree remove`, then its associated administrative files, which reside in the repository (see "DETAILS" below), will eventually be removed automatically (see `gc.worktreePruneExpire` in linkgit:git-config[1]), or you can run `git worktree prune` in the main or any linked worktree to clean up any stale administrative files.
zh_HANS-CN: 如果没有使用 `git worktree remove` 就删除了工作区，那么它的相关管理文件，即驻扎在仓库中的文件（见下面的 "详细说明"），最终会被自动删除（见 linkgit:git-config[1] 中的 `gc.worktreePruneExpire`），或者你可以在主工作区或任何链接工作区中运行`git worktree prune` 来清理任何过时的管理文件。

note: type: Plain text
en: If the working tree for a linked worktree is stored on a portable device or network share which is not always mounted, you can prevent its administrative files from being pruned by issuing the `git worktree lock` command, optionally specifying `--reason` to explain why the worktree is locked.
zh_HANS-CN: 如果一个链接的工作区存储在便携设备或网络共享上，而这些设备并不总是被挂载，你可以通过发布`git worktree lock`命令来防止其管理文件被修剪，可以使用选项`--reason`来解释为什么工作树被锁定。

note: type: Labeled list
en: add <path> [<commit-ish>]
zh_HANS-CN: add <路径> [<提交号>]

note: type: Plain text
en: Create a worktree at `<path>` and checkout `<commit-ish>` into it. The new worktree is linked to the current repository, sharing everything except per-worktree files such as `HEAD`, `index`, etc. As a convenience, `<commit-ish>` may be a bare "`-`", which is synonymous with `@{-1}`.
zh_HANS-CN: 在`<路径>`创建一个工作树，并将`<提交号>`签入其中。新的工作区被链接到当前仓库，共享除每个工作区文件（如`HEAD`、`index`等）之外的一切。为了方便起见，`<提交号>`可以是一个光秃秃的"`-`"，它与`@{-1}`同义。

note: type: Plain text
en: If `<commit-ish>` is a branch name (call it `<branch>`) and is not found, and neither `-b` nor `-B` nor `--detach` are used, but there does exist a tracking branch in exactly one remote (call it `<remote>`)  with a matching name, treat as equivalent to:
zh_HANS-CN: 如果`<提交号>`是一个分支名称（称其为`<分支>`），并且没有找到，也没有使用`-b`或`-B`或`-detach`，但确实在正好一个远程仓库（称其为`<远程仓库>`）中存在一个名称匹配的跟踪分支，则视为等同于：

note: type: Plain text
en: If the branch exists in multiple remotes and one of them is named by the `checkout.defaultRemote` configuration variable, we'll use that one for the purposes of disambiguation, even if the `<branch>` isn't unique across all remotes. Set it to e.g. `checkout.defaultRemote=origin` to always checkout remote branches from there if `<branch>` is ambiguous but exists on the `origin` remote. See also `checkout.defaultRemote` in linkgit:git-config[1].
zh_HANS-CN: 如果该分支存在于多个远程仓库，并且其中一个是由`checkout.defaultRemote`配置变量命名的，为了消除歧义，我们将使用该变量，即使`<分支>`在所有远程中并不唯一。将其设置为例如 `checkout.defaultRemote=origin`，以便在`<分支>`不明确但存在于'origin'远程时，总是从那里签出远程分支。参见 linkgit:git-config[1] 中的 `checkout.defaultRemote`。

note: type: Plain text
en: If `<commit-ish>` is omitted and neither `-b` nor `-B` nor `--detach` used, then, as a convenience, the new worktree is associated with a branch (call it `<branch>`) named after `$(basename <path>)`.  If `<branch>` doesn't exist, a new branch based on `HEAD` is automatically created as if `-b <branch>` was given.  If `<branch>` does exist, it will be checked out in the new worktree, if it's not checked out anywhere else, otherwise the command will refuse to create the worktree (unless `--force` is used).
zh_HANS-CN: 如果省略了`<提交号>`，也没有使用`-b`或`-B`或`-detach`，那么作为一种方便，新的工作树将与一个以`$(basename <路径>)`命名的分支（称为`<分支>`）相关联。  如果`<分支>`不存在，一个基于`HEAD`的新分支将被自动创建，就像给出`-b <分支>`一样。  如果`<分支>`确实存在，它将在新的工作树中被签出，如果它没有在其他地方被签出，否则命令将拒绝创建工作区（除非使用`--force`）。

note: type: Plain text
en: If `<commit-ish>` is omitted, neither `--detach`, or `--orphan` is used, and there are no valid local branches (or remote branches if `--guess-remote` is specified) then, as a convenience, the new worktree is associated with a new orphan branch named `<branch>` (after `$(basename <path>)` if neither `-b` or `-B` is used) as if `--orphan` was passed to the command. In the event the repository has a remote and `--guess-remote` is used, but no remote or local branches exist, then the command fails with a warning reminding the user to fetch from their remote first (or override by using `-f/--force`).
zh_HANS-CN: 如果省略了 `<commit-ish>`，既没有使用 `--detach`，也没有使用 `--orphan`，并且没有有效的本地分支（或远程分支，如果指定了 `--guess-remote`），那么为了方便起见，新的工作树会与一个名为 `<branch>` 的新孤儿分支关联（如果没有使用 `-b` 或 `-B`，则在 `$(basename <path>)`之后），就像向命令传递了 `--orphan`一样。如果仓库有远程分支，并且使用了 `--guess-remote`，但不存在远程或本地分支，则命令会失败，并发出警告，提醒用户先从远程获取（或使用 `-f/-force` 覆盖）。

note: type: Plain text
en: List details of each worktree.  The main worktree is listed first, followed by each of the linked worktrees.  The output details include whether the worktree is bare, the revision currently checked out, the branch currently checked out (or "detached HEAD" if none), "locked" if the worktree is locked, "prunable" if the worktree can be pruned by the `prune` command.
zh_HANS-CN: 列出每个工作区的细节。  主工作区被首先列出，接着是每个链接工作区。  输出的细节包括该工作区是否为裸树，当前签出的修订版，当前检出的分支（如果没有则为 "分离的HEAD"），如果工作树被锁定则为 "锁定"，如果工作树可以被`prune`命令修剪则为 "可修剪"。

note: type: Plain text
en: If a worktree is on a portable device or network share which is not always mounted, lock it to prevent its administrative files from being pruned automatically. This also prevents it from being moved or deleted.  Optionally, specify a reason for the lock with `--reason`.
zh_HANS-CN: 如果一个工作区在便携式设备或网络共享上，而这个设备或网络共享并不总是被挂载，请锁定它以防止其管理文件被自动修剪。这也可以防止它被移动或删除。  可以选择用`--reason`选项来指定锁定的原因。

note: type: Plain text
en: Move a worktree to a new location. Note that the main worktree or linked worktrees containing submodules cannot be moved with this command. (The `git worktree repair` command, however, can reestablish the connection with linked worktrees if you move the main worktree manually.)
zh_HANS-CN: 将一个工作区移动到一个新的位置。注意，主工作区或包含子模块的链接工作区不能用此命令移动。(然而，如果你手动移动主工作区，`git worktree repair`命令可以重新建立与链接工作区的连接。）

note: type: Plain text
en: Prune worktree information in `$GIT_DIR/worktrees`.
zh_HANS-CN: 修剪`$GIT_DIR/worktrees`中的工作区信息。

note: type: Plain text
en: Remove a worktree. Only clean worktrees (no untracked files and no modification in tracked files) can be removed. Unclean worktrees or ones with submodules can be removed with `--force`. The main worktree cannot be removed.
zh_HANS-CN: 移除一个工作区。只有干净的工作区（没有未跟踪的文件和未修改的跟踪文件）可以被删除。脏工作区或有子模块的工作区可以用 `--force` 删除。主工作区不能被删除。

note: type: Labeled list
en: repair [<path>...]
zh_HANS-CN: repair [<路径>...]

note: type: Plain text
en: Repair worktree administrative files, if possible, if they have become corrupted or outdated due to external factors.
zh_HANS-CN: 如果可能的话，修复工作区的管理文件，如果它们由于外部因素而变得损坏或过时。

note: type: Plain text
en: For instance, if the main worktree (or bare repository) is moved, linked worktrees will be unable to locate it. Running `repair` in the main worktree will reestablish the connection from linked worktrees back to the main worktree.
zh_HANS-CN: 例如，如果主工作区（或裸仓库）被移动，链接工作区将无法找到它。在主工作区中运行 `repair` 将重新建立从链接工作区到主工作区的连接。

note: type: Plain text
en: Similarly, if the working tree for a linked worktree is moved without using `git worktree move`, the main worktree (or bare repository) will be unable to locate it. Running `repair` within the recently-moved worktree will reestablish the connection. If multiple linked worktrees are moved, running `repair` from any worktree with each tree's new `<path>` as an argument, will reestablish the connection to all the specified paths.
zh_HANS-CN: 同样地，如果没有使用 `git worktree move` 就移动了链接工作区，主工作区（或裸仓库）将无法定位它。在最近移动的工作区中运行`repair`将重新建立连接。如果多个链接工作区被移动，在任何工作区中运行`repair`，以每个树的新`<路径>`作为参数，将重新建立与所有指定路径的连接。

note: type: Plain text
en: If both the main worktree and linked worktrees have been moved manually, then running `repair` in the main worktree and specifying the new `<path>` of each linked worktree will reestablish all connections in both directions.
zh_HANS-CN: 如果主工作区和链接工作区都被手动移动，那么在主工作区中运行`repair`并指定每个链接工作树的新`<路径>`将重新建立两个方向的所有连接。

note: type: Plain text
en: Unlock a worktree, allowing it to be pruned, moved or deleted.
zh_HANS-CN: 解锁一个工作区，允许它被修剪、移动或删除。

note: type: Plain text
en: By default, `add` refuses to create a new worktree when `<commit-ish>` is a branch name and is already checked out by another worktree, or if `<path>` is already assigned to some worktree but is missing (for instance, if `<path>` was deleted manually). This option overrides these safeguards. To add a missing but locked worktree path, specify `--force` twice.
zh_HANS-CN: 默认情况下，当`<提交号>`是一个分支名称，并且已经被另一个工作树签出，或者`<路径>`已经被分配给某个工作树，但丢失了（例如，如果`<路径>`被手动删除），`add`拒绝创建一个新的工作树。这个选项覆盖了这些保护措施。要添加一个缺失但锁定的工作区路径，请指定`--force`两次。

note: type: Plain text
en: `move` refuses to move a locked worktree unless `--force` is specified twice. If the destination is already assigned to some other worktree but is missing (for instance, if `<new-path>` was deleted manually), then `--force` allows the move to proceed; use `--force` twice if the destination is locked.
zh_HANS-CN: `move`拒绝移动一个被锁定的工作区，除非`--force`被指定两次。如果目的地已经被分配给其他工作区，但没有找到（例如，如果`<新路径>`被手动删除），那么`--force`允许移动；如果目的地被锁定，则使用`--force`两次。

note: type: Plain text
en: `remove` refuses to remove an unclean worktree unless `--force` is used.  To remove a locked worktree, specify `--force` twice.
zh_HANS-CN: `remove`拒绝删除一个脏工作区，除非使用`--force`。  要删除一个锁定的工作区，需要指定`--force`两次。

note: type: Plain text
en: With `add`, create a new branch named `<new-branch>` starting at `<commit-ish>`, and check out `<new-branch>` into the new worktree.  If `<commit-ish>` is omitted, it defaults to `HEAD`.  By default, `-b` refuses to create a new branch if it already exists. `-B` overrides this safeguard, resetting `<new-branch>` to `<commit-ish>`.
zh_HANS-CN: 通过`add`，创建一个名为`<新分支>`的新分支，从`<提交号>`开始，并将`<新分支>`检出到新的工作树。  如果省略了`<提交号>`，则默认为`HEAD`。  默认情况下，如果一个新的分支已经存在，`-b`会拒绝创建它。`-B`则不会拒绝创建，将`<新分支>`重置为`<提交号>`。

note: type: Plain text
en: By default, `add` checks out `<commit-ish>`, however, `--no-checkout` can be used to suppress checkout in order to make customizations, such as configuring sparse-checkout. See "Sparse checkout" in linkgit:git-read-tree[1].
zh_HANS-CN: 默认情况下，`add`会检出`<提交号>`，然而，`--no-checkout`可以用来抑制检出，以便进行定制，比如配置稀疏检出。参见 linkgit:git-read-tree[1] 中的 "稀疏检出"。

note: type: Plain text
en: With `worktree add <path>`, without `<commit-ish>`, instead of creating a new branch from `HEAD`, if there exists a tracking branch in exactly one remote matching the basename of `<path>`, base the new branch on the remote-tracking branch, and mark the remote-tracking branch as "upstream" from the new branch.
zh_HANS-CN: 在`worktree add <路径>`下，如果没有`<提交号>`，则不从`HEAD`创建新的分支，而是在正好有一个与`<路径>`的基名相匹配的远程跟踪分支的情况下，将新的分支建立在远程跟踪分支上，并将远程跟踪分支标记为新分支的 "上游"。

note: type: Plain text
en: This can also be set up as the default behaviour by using the `worktree.guessRemote` config option.
zh_HANS-CN: 这也可以通过使用`worktree.guessRemote`配置选项设置为默认行为。

note: type: Plain text
en: When creating a new branch, if `<commit-ish>` is a branch, mark it as "upstream" from the new branch.  This is the default if `<commit-ish>` is a remote-tracking branch.  See `--track` in linkgit:git-branch[1] for details.
zh_HANS-CN: 当创建一个新的分支时，如果 `<提交号>` 是一个分支，则将其标记为新分支的 "上游"。  默认认为 `<提交号>` 是一个远程跟踪分支。  详情见 linkgit:git-branch[1] 中的 `--track`。

note: type: Plain text
en: Keep the worktree locked after creation. This is the equivalent of `git worktree lock` after `git worktree add`, but without a race condition.
zh_HANS-CN: 在创建后保持工作区的锁定。这相当于在`git worktree add`之后执行`git worktree lock`，但没有资源竞争。

note: type: Plain text
en: With `prune`, do not remove anything; just report what it would remove.
zh_HANS-CN: 在使用`prune`时，不会删除任何文件；只会报告它要删除的东西。

note: type: Plain text
en: With `add`, make the new worktree and index empty, associating the worktree with a new orphan/unborn branch named `<new-branch>`.
zh_HANS-CN: 使用 `add` 使新的工作区和索引为空，并将工作树与名为 `<new-branch>` 的新孤儿/未出生分支关联起来。

note: type: Plain text
en: Terminate each line with a NUL rather than a newline when `--porcelain` is specified with `list`. This makes it possible to parse the output when a worktree path contains a newline character.
zh_HANS-CN: 当`--porcelain`与`list`一起指定时，用NUL而不是换行来结束每一行。这使得在工作区路径包含换行符时，可以解析输出。

note: type: Plain text
en: With `add`, suppress feedback messages.
zh_HANS-CN: 用`add`，抑制反馈信息。

note: type: Plain text
en: With `prune`, report all removals.
zh_HANS-CN: 使用`prune`，报告所有的移除情况。

note: type: Plain text
en: With `list`, output additional information about worktrees (see below).
zh_HANS-CN: 用`list`，输出关于工作区的额外信息（见下文）。

note: type: Plain text
en: With `prune`, only expire unused worktrees older than `<time>`.
zh_HANS-CN: 使用 `prune`，只对超过`<时间>`未使用的工作区进行淘汰。

note: type: Plain text
en: With `list`, annotate missing worktrees as prunable if they are older than `<time>`.
zh_HANS-CN: 使用`list`，如果丢失的工作区比`<时间>`早，则将其注释为可修剪。

note: type: Plain text
en: With `lock` or with `add --lock`, an explanation why the worktree is locked.
zh_HANS-CN: 用`lock`或用`add --lock`，解释为什么工作区被锁定。

note: type: Plain text
en: Worktrees can be identified by path, either relative or absolute.
zh_HANS-CN: 工作区可以通过相对或绝对路径来识别。

note: type: Plain text
en: If the last path components in the worktree's path is unique among worktrees, it can be used to identify a worktree. For example if you only have two worktrees, at `/abc/def/ghi` and `/abc/def/ggg`, then `ghi` or `def/ghi` is enough to point to the former worktree.
zh_HANS-CN: 如果工作区路径中的后几个层次在工作树中是唯一的，则它可以用来识别一个工作树。例如，如果你只有两个工作区，在`/abc/def/ghi`和`/abc/def/ggg`，那么使用`ghi`或`def/ghi`就足以指向前一个工作区。

note: type: Plain text
en: When using multiple worktrees, some refs are shared between all worktrees, but others are specific to an individual worktree. One example is `HEAD`, which is different for each worktree. This section is about the sharing rules and how to access refs of one worktree from another.
zh_HANS-CN: 当使用多个工作区时，一些引用在所有工作区之间共享，但其他引用是特定于单个工作区的。比如：`HEAD`，它对每个工作树都是不同的。本节是关于共享规则，以及如何从另一个工作区访问一个工作区的引用。

note: type: Plain text
en: In general, all pseudo refs are per-worktree and all refs starting with `refs/` are shared. Pseudo refs are ones like `HEAD` which are directly under `$GIT_DIR` instead of inside `$GIT_DIR/refs`. There are exceptions, however: refs inside `refs/bisect` and `refs/worktree` are not shared.
zh_HANS-CN: 一般来说，所有的伪引用都是工作区特有的，所有以`refs/`开头的引用都是共享的。伪引用是像`HEAD`那样直接在`$GIT_DIR`下，而不是在`$GIT_DIR/refs`内的引用。但也有例外：`refs/bisect`和`refs/worktree`内的引用不被共享。

note: type: Plain text
en: Refs that are per-worktree can still be accessed from another worktree via two special paths, `main-worktree` and `worktrees`. The former gives access to per-worktree refs of the main worktree, while the latter to all linked worktrees.
zh_HANS-CN: 每个工作区的引用仍然可以通过两个特殊的路径，即 `主工作区`和 `从工作区`，从另一个工作区访问。前者可以访问主工作区的每个工作区的引用，而后者可以访问所有链接的工作区。

note: type: Plain text
en: For example, `main-worktree/HEAD` or `main-worktree/refs/bisect/good` resolve to the same value as the main worktree's `HEAD` and `refs/bisect/good` respectively. Similarly, `worktrees/foo/HEAD` or `worktrees/bar/refs/bisect/bad` are the same as `$GIT_COMMON_DIR/worktrees/foo/HEAD` and `$GIT_COMMON_DIR/worktrees/bar/refs/bisect/bad`.
zh_HANS-CN: 例如，`main-worktree/HEAD`或`main-worktree/refs/bisect/good`分别解析到与主工作区的`HEAD`和`refs/bisect/good`相同的值。类似地，`worktrees/foo/HEAD`或`worktrees/bar/refs/bisect/bad`与`$GIT_COMMON_DIR/worktrees/foo/HEAD`和`$GIT_COMMON_DIR/worktrees/bar/refs/bisect/bad`相同。

note: type: Plain text
en: To access refs, it's best not to look inside `$GIT_DIR` directly. Instead use commands such as linkgit:git-rev-parse[1] or linkgit:git-update-ref[1] which will handle refs correctly.
zh_HANS-CN: 要访问引用，最好不要直接在 `$GIT_DIR` 中查找。相反，使用 linkgit:git-rev-parse[1] 或 linkgit:git-update-ref[1] 这样的命令可以正确处理引用。

note: type: Plain text
en: By default, the repository `config` file is shared across all worktrees.  If the config variables `core.bare` or `core.worktree` are present in the common config file and `extensions.worktreeConfig` is disabled, then they will be applied to the main worktree only.
zh_HANS-CN: 默认情况下，资源库的`config`文件在所有工作区上共享。  如果配置变量`core.bare`或`core.worktree`存在于公共配置文件中，并且`extensions.worktreeConfig`被禁用，那么它们将只应用于主工作区。

note: type: Plain text
en: In order to have worktree-specific configuration, you can turn on the `worktreeConfig` extension, e.g.:
zh_HANS-CN: 为了对工作区进行特定配置，你可以打开`worktreeConfig`扩展，例如：

note: type: Plain text
en: In this mode, specific configuration stays in the path pointed by `git rev-parse --git-path config.worktree`. You can add or update configuration in this file with `git config --worktree`. Older Git versions will refuse to access repositories with this extension.
zh_HANS-CN: 在这种模式下，特定的配置保持在`git rev-parse --git-path config.worktree`所指向的路径中。你可以用`git config --worktree`添加或更新该文件中的配置。旧版本的Git会拒绝访问带有这个扩展的仓库。

note: type: Plain text
en: Note that in this file, the exception for `core.bare` and `core.worktree` is gone. If they exist in `$GIT_DIR/config`, you must move them to the `config.worktree` of the main worktree. You may also take this opportunity to review and move other configuration that you do not want to share to all worktrees:
zh_HANS-CN: 注意，在这个文件中，`core.bare`和`core.worktree`的例外情况已经消失。如果它们存在于`$GIT_DIR/config`中，你必须把它们移到主工作区的`config.worktree`中。你也可以借此机会审查和移动其他你不想共享到所有工作区的配置：

note: type: Plain text
en: `core.worktree` should never be shared.
zh_HANS-CN: `core.worktree`不应该被共享。

note: type: Plain text
en: `core.bare` should not be shared if the value is `core.bare=true`.
zh_HANS-CN: 如果`core.bare`的值为`core.bare=true`，则不应共享。

note: type: Plain text
en: `core.sparseCheckout` should not be shared, unless you are sure you always use sparse checkout for all worktrees.
zh_HANS-CN: `core.sparseCheckout`不应该被共享，除非你确信你总是对所有工作区使用稀疏检出。

note: type: Plain text
en: See the documentation of `extensions.worktreeConfig` in linkgit:git-config[1] for more details.
zh_HANS-CN: 更多细节请参见 linkgit:git-config[1] 中的 `extensions.worktreeConfig` 文档。

note: type: Plain text
en: Each linked worktree has a private sub-directory in the repository's `$GIT_DIR/worktrees` directory.  The private sub-directory's name is usually the base name of the linked worktree's path, possibly appended with a number to make it unique.  For example, when `$GIT_DIR=/path/main/.git` the command `git worktree add /path/other/test-next next` creates the linked worktree in `/path/other/test-next` and also creates a `$GIT_DIR/worktrees/test-next` directory (or `$GIT_DIR/worktrees/test-next1` if `test-next` is already taken).
zh_HANS-CN: 每个链接工作区在仓库的`$GIT_DIR/worktrees`目录下都有一个私有子目录。  私有子目录的名称通常是被链接的工作树路径的基本名称，但可能加上一个数字以使成为唯一目录。  例如，当`$GIT_DIR=/path/main/.git`时，命令`git worktree add /path/other/test-next next`会在`/path/other/test-next`中创建链接工作区，同时创建一个`$GIT_DIR/worktrees/test-next`目录（如果`test-next`已经被占用，则创建`$GIT_DIR/worktrees/test-next1`）。

note: type: Plain text
en: Within a linked worktree, `$GIT_DIR` is set to point to this private directory (e.g. `/path/main/.git/worktrees/test-next` in the example) and `$GIT_COMMON_DIR` is set to point back to the main worktree's `$GIT_DIR` (e.g. `/path/main/.git`). These settings are made in a `.git` file located at the top directory of the linked worktree.
zh_HANS-CN: 在一个链接工作区中，`$GIT_DIR`设置为指向这个私有目录（例如，例子中的`/path/main/.git/worktrees/test-next`），`$GIT_COMMON_DIR`会被设置为指向主工作区的`$GIT_DIR`（例如，`/path/main/.git`）。这些设置是在位于链接工作区顶级目录的`.git`文件中进行的。

note: type: Plain text
en: Path resolution via `git rev-parse --git-path` uses either `$GIT_DIR` or `$GIT_COMMON_DIR` depending on the path. For example, in the linked worktree `git rev-parse --git-path HEAD` returns `/path/main/.git/worktrees/test-next/HEAD` (not `/path/other/test-next/.git/HEAD` or `/path/main/.git/HEAD`) while `git rev-parse --git-path refs/heads/master` uses `$GIT_COMMON_DIR` and returns `/path/main/.git/refs/heads/master`, since refs are shared across all worktrees, except `refs/bisect` and `refs/worktree`.
zh_HANS-CN: 通过`git rev-parse --git-path`进行的路径解析使用`$GIT_DIR`或`$GIT_COMMON_DIR`，取决于路径。例如，在链接工作区中，`git rev-parse --git-path HEAD`命令返回`/path/main/.git/worktrees/test-next/HEAD`（而不是`/path/other/test-next/.git/HEAD`或者`/path/main/.git/HEAD`），而`git rev-parse --git-path refs/heads/master`则使用`$GIT_COMMON_DIR`并返回`/path/main/.git/refs/heads/master`，因为除了`refs/bisect`和`refs/worktree`，所有工作区都共享引用。

note: type: Plain text
en: See linkgit:gitrepository-layout[5] for more information. The rule of thumb is do not make any assumption about whether a path belongs to `$GIT_DIR` or `$GIT_COMMON_DIR` when you need to directly access something inside `$GIT_DIR`. Use `git rev-parse --git-path` to get the final path.
zh_HANS-CN: 更多信息见 linkgit:gitrepository-layout[5]。经验法则是，当你需要直接访问`$GIT_DIR`或`$GIT_COMMON_DIR`内的东西时，不要对路径是否属于`$GIT_DIR`做出任何假设。使用`git rev-parse --git-path`来获得最终路径。

note: type: Plain text
en: If you manually move a linked worktree, you need to update the `gitdir` file in the entry's directory. For example, if a linked worktree is moved to `/newpath/test-next` and its `.git` file points to `/path/main/.git/worktrees/test-next`, then update `/path/main/.git/worktrees/test-next/gitdir` to reference `/newpath/test-next` instead. Better yet, run `git worktree repair` to reestablish the connection automatically.
zh_HANS-CN: 如果你手动移动一个链接工作区，你需要更新该条目目录下的`gitdir`文件。例如，如果一个链接工作区被移到`/newpath/test-next`，而它的`.git`文件指向`/path/main/.git/worktrees/test-next`，那么更新`/path/main/.git/worktrees/test-next/gitdir`以引用`/newpath/test-next`。除此之外，更好的选择是，运行`git worktree repair`来自动重新建立连接。

note: type: Plain text
en: To prevent a `$GIT_DIR/worktrees` entry from being pruned (which can be useful in some situations, such as when the entry's worktree is stored on a portable device), use the `git worktree lock` command, which adds a file named `locked` to the entry's directory. The file contains the reason in plain text. For example, if a linked worktree's `.git` file points to `/path/main/.git/worktrees/test-next` then a file named `/path/main/.git/worktrees/test-next/locked` will prevent the `test-next` entry from being pruned.  See linkgit:gitrepository-layout[5] for details.
zh_HANS-CN: 为了防止`$GIT_DIR/worktrees`条目被修剪（这在某些情况下很有用，比如该条目的工作区存储在便携设备上），使用`git worktree lock`命令，它会在条目的目录中添加一个名为`locked`的文件。该文件包含纯文本的原因。例如，如果一个链接工作区的`.git`文件指向`/path/main/.git/worktrees/test-next`，那么一个名为`/path/main/.git/worktrees/test-next/locked`的文件将阻止`test-next`条目被剪除。  详情见linkgit:gitrepository-layout[5]。

note: type: Plain text
en: When `extensions.worktreeConfig` is enabled, the config file `.git/worktrees/<id>/config.worktree` is read after `.git/config` is.
zh_HANS-CN: 当`extensions.worktreeConfig`被启用时，在`.git/config`之后会读取`.git/worktrees/<id>/config.worktree`的配置文件。

note: type: Title -
en: LIST OUTPUT FORMAT
zh_HANS-CN: 列表输出格式

note: type: Plain text
en: The `worktree list` command has two output formats. The default format shows the details on a single line with columns.  For example:
zh_HANS-CN: `worktree list` 命令有两种输出格式。默认的格式是在单行上显示细节，并带有列。  例如：

note: type: Plain text
en: The command also shows annotations for each worktree, according to its state.  These annotations are:
zh_HANS-CN: 该命令还根据每个工作区的状态，显示其注释。  这些注释是：

note: type: Plain text
en: `locked`, if the worktree is locked.
zh_HANS-CN: `locked`，如果工作区被锁定。

note: type: Plain text
en: `prunable`, if the worktree can be pruned via `git worktree prune`.
zh_HANS-CN: `prunable`，如果工作区可以通过`git worktree prune`进行修剪。

note: type: delimited block -
en: $ git worktree list --verbose
    /path/to/linked-worktree              abcd1234 [master]
    /path/to/locked-worktree-no-reason    abcd5678 (detached HEAD) locked
    /path/to/locked-worktree-with-reason  1234abcd (brancha)
    	locked: worktree path is mounted on a portable device
    /path/to/prunable-worktree            5678abc1 (detached HEAD)
    	prunable: gitdir file points to non-existent location
zh_HANS-CN: $ git worktree list --verbose
    /path/to/linked-worktree                           abcd1234 [master]
    /path/to/locked-worktree-no-reason    abcd5678 (分离的 HEAD) locked
    /path/to/locked-worktree-with-reason  1234abcd (brancha)
    	锁定：工作区路径被安装在一个可移动设备上
    /path/to/prunable-worktree            5678abc1 (分离的 HEAD)
    	可修剪：gitdir 文件指向不存在的位置

note: type: Plain text
en: Note that the annotation is moved to the next line if the additional information is available, otherwise it stays on the same line as the worktree itself.
zh_HANS-CN: 注意，如果有额外的信息，注释将被移到下一行，否则它将与工作区本身保持在同一行。

note: type: Title ~
en: Porcelain Format
zh_HANS-CN: 上层命令格式

note: type: Plain text
en: The porcelain format has a line per attribute.  If `-z` is given then the lines are terminated with NUL rather than a newline.  Attributes are listed with a label and value separated by a single space.  Boolean attributes (like `bare` and `detached`) are listed as a label only, and are present only if the value is true.  Some attributes (like `locked`) can be listed as a label only or with a value depending upon whether a reason is available.  The first attribute of a worktree is always `worktree`, an empty line indicates the end of the record.  For example:
zh_HANS-CN: 上层命令的每个属性有一行。  如果给了`-z`，那么这几行将以NUL（空字符）而不是换行来结束。  属性以标签和值的形式列出，用一个空格隔开。  布尔属性（如`bare`和`detached`）仅作为标签列出，并且仅在值为真时出现。  一些属性（如`locked'）可以只作为标签列出，也可以根据是否有理由列出一个值。  工作区的第一个属性总是`工作树'，一个空行表示记录的结束。  比如说：

note: type: delimited block -
en: worktree /path/to/linked-worktree-prunable
    HEAD 1233def1234def1234def1234def1234def1234b
    detached
    prunable gitdir file points to non-existent location
zh_HANS-CN: worktree /path/to/linked-worktree-prunable
    HEAD 1233def1234def1234def1234def1234def1234b
    detached
    修剪的gitdir文件指向不存在的位置

note: type: Plain text
en: Unless `-z` is used any "unusual" characters in the lock reason such as newlines are escaped and the entire reason is quoted as explained for the configuration variable `core.quotePath` (see linkgit:git-config[1]).  For Example:
zh_HANS-CN: 除非使用`-z`，否则锁定的原因中任何 "不寻常"的字符，如换行，都会被转义，并且整个原因被引用为配置变量`core.quotePath`（见linkgit:git-config[1]）。  举例来说：

note: type: delimited block -
en: $ git worktree list --porcelain
    ...
    locked "reason\nwhy is locked"
    ...
zh_HANS-CN: $ git worktree list --porcelain
    …
    locked "reason\nwhy is locked"
    …

note: type: Plain text
en: You are in the middle of a refactoring session and your boss comes in and demands that you fix something immediately. You might typically use linkgit:git-stash[1] to store your changes away temporarily, however, your working tree is in such a state of disarray (with new, moved, and removed files, and other bits and pieces strewn around) that you don't want to risk disturbing any of it. Instead, you create a temporary linked worktree to make the emergency fix, remove it when done, and then resume your earlier refactoring session.
zh_HANS-CN: 你正在进行重构工作，你的老板进来了，要求你立即修复一些东西。你通常会使用linkgit:git-stash[1]来暂时存储你的修改，然而你的工作树处于如此混乱的状态（有新的、被移动的、被删除的文件，以及其他散落的碎片），你不想冒险去打扰它。相反，你创建了一个临时的链接工作树来进行紧急修复，完成后将其删除，然后继续你先前的重构会话。

note: type: delimited block -
en: $ git worktree add -b emergency-fix ../temp master
    $ pushd ../temp
    # ... hack hack hack ...
    $ git commit -a -m 'emergency fix for boss'
    $ popd
    $ git worktree remove ../temp
zh_HANS-CN: $ git worktree add -b emergency-fix ../temp master
    $ pushd ../temp
    # ... 嗨骇害 ...
    $ git commit -a -m '老板让我赶紧修复的问题'
    $ popd
    $ git worktree remove ../temp

note: type: Plain text
en: Multiple checkout in general is still experimental, and the support for submodules is incomplete. It is NOT recommended to make multiple checkouts of a superproject.
zh_HANS-CN: 多重检出总体上仍处于试验阶段，对子模块的支持也不完整。我们 ⌈不⌋ 建议对一个父项目进行多重检出。

note: type: Plain text
en: gitglossary - A Git Glossary
zh_HANS-CN: gitglossary - Git术语表

note: type: Plain text
en: linkgit:gittutorial[7], linkgit:gittutorial-2[7], linkgit:gitcvs-migration[7], linkgit:giteveryday[7], link:user-manual.html[The Git User's Manual]
zh_HANS-CN: linkgit:gittutorial[7], linkgit:gittutorial-2[7], linkgit:gitcvs-migration[7], linkgit:giteveryday[7], link:user-manual.html [Git 用户手册]

note: type: Labeled list
en: [[def_alternate_object_database]]alternate object database
zh_HANS-CN: [[def_alternate_object_database]] 轮替对象库(alternate object database)

note: type: Plain text
en: Via the alternates mechanism, a <<def_repository,repository>> can inherit part of its <<def_object_database,object database>> from another object database, which is called an "alternate".
zh_HANS-CN: 通过替代机制, 一个 <<def_repository,repository>> 能够从另一个对象库中继承 <<def_object_database,object database>> 的一部分对象, 这被称作“轮替”。

note: type: Labeled list
en: [[def_bare_repository]]bare repository
zh_HANS-CN: [[def_bare_repository]]裸仓库(bare repository)

note: type: Plain text
en: A bare repository is normally an appropriately named <<def_directory,directory>> with a `.git` suffix that does not have a locally checked-out copy of any of the files under revision control. That is, all of the Git administrative and control files that would normally be present in the hidden `.git` sub-directory are directly present in the `repository.git` directory instead, and no other files are present and checked out. Usually publishers of public repositories make bare repositories available.
zh_HANS-CN: 一个裸仓库通常是一个有适当命名的<<def_directory,directory>>，后缀为`.git`，它没有任何版本控制下的文件的本地检出副本。也就是说，所有通常存在于隐藏的`.git`子目录中的Git管理和控制文件都直接存在于`repository.git`目录中，而没有其他文件存在并被检出。通常，公共仓库的发布者会提供裸仓库。

note: type: Labeled list
en: [[def_blob_object]]blob object
zh_HANS-CN: [[def_blob_object]] 数据对象 (blob object)

note: type: Plain text
en: Untyped <<def_object,object>>, e.g. the contents of a file.
zh_HANS-CN: 无类型的<<def_object,对象>>，比如一个文件的内容。

note: type: Labeled list
en: [[def_branch]]branch
zh_HANS-CN: [[def_branch]] 分支 (branch)

note: type: Plain text
en: A "branch" is a line of development.  The most recent <<def_commit,commit>> on a branch is referred to as the tip of that branch.  The tip of the branch is <<def_ref,referenced>> by a branch <<def_head,head>>, which moves forward as additional development is done on the branch.  A single Git <<def_repository,repository>> can track an arbitrary number of branches, but your <<def_working_tree,working tree>> is associated with just one of them (the "current" or "checked out" branch), and <<def_HEAD,HEAD>> points to that branch.
zh_HANS-CN: 一个 "分支 "就是一条开发线。  一个分支上最近的<<def_commit,commit>>被称为该分支的顶端。  分支的顶端被<<def_ref,引用>>分支<<def_head,head>>引用，当分支上有更多的开发工作时，它就会向前移动。  一个Git<<def_repository,仓库>>可以跟踪任意数量的分支，但你的<<def_working_tree,工作区>>只与其中一个分支（"当前(current) "或 "检出(checked out)"分支）相关联，而<<def_HEAD,头指针>>指向该分支。

note: type: Labeled list
en: [[def_cache]]cache
zh_HANS-CN: [[def_cache]] 缓存 (cache)

note: type: Plain text
en: Obsolete for: <<def_index,index>>.
zh_HANS-CN: 已过时：<<def_index，索引>>。

note: type: Labeled list
en: [[def_chain]]chain
zh_HANS-CN: [[def_chain]]（提交）链(chain)

note: type: Plain text
en: A list of objects, where each <<def_object,object>> in the list contains a reference to its successor (for example, the successor of a <<def_commit,commit>> could be one of its <<def_parent,parents>>).
zh_HANS-CN: 一个对象的列表，列表中的每个<<def_object,对象>>都包含对其继承者的引用（例如，一个<<def_commit,提交（commit）>>的继承者可以是其<<def_parent,父对象>>之一）。

note: type: Labeled list
en: [[def_changeset]]changeset
zh_HANS-CN: [[def_changeset]] 变更集 (changeset)

note: type: Plain text
en: BitKeeper/cvsps speak for "<<def_commit,commit>>". Since Git does not store changes, but states, it really does not make sense to use the term "changesets" with Git.
zh_HANS-CN: BitKeeper/cvsps是指"<<def_commit,提交>>"。由于Git并不存储变化，而是存储状态，所以在Git中使用"变化集（changesets）"这个词真的没有意义。

note: type: Labeled list
en: [[def_checkout]]checkout
zh_HANS-CN: [[def_checkout]] 检出 (checkout)

note: type: Plain text
en: The action of updating all or part of the <<def_working_tree,working tree>> with a <<def_tree_object,tree object>> or <<def_blob_object,blob>> from the <<def_object_database,object database>>, and updating the <<def_index,index>> and <<def_HEAD,HEAD>> if the whole working tree has been pointed at a new <<def_branch,branch>>.
zh_HANS-CN: 用<<def_object_database,对象库>>中的<<def_tree_object,树对象>>或<<def_blob_object,blob>>更新全部或部分<<def_working_tree,工作区>>，如果整个工作树已经指向一个新<<def_branch,分支>>，就更新<<def_index,暂存区>>和<<def_HEAD,头指针>>。

note: type: Labeled list
en: [[def_cherry-picking]]cherry-picking
zh_HANS-CN: [[def_cherry-picking]]拣选（cherry-picking）

note: type: Plain text
en: In <<def_SCM,SCM>> jargon, "cherry pick" means to choose a subset of changes out of a series of changes (typically commits) and record them as a new series of changes on top of a different codebase. In Git, this is performed by the "git cherry-pick" command to extract the change introduced by an existing <<def_commit,commit>> and to record it based on the tip of the current <<def_branch,branch>> as a new commit.
zh_HANS-CN: 在<<def_SCM,SCM>>中，"cherry pick"意味着从一系列的修改（通常是提交）中选择一个子集，并将其记录为不同代码库之上的一系列新修改。在Git中，这是由"git cherry-pick"命令执行的，提取现有<<def_commit,提交>>引入的修改，并根据当前<<def_branch,分支>>的提示，将其记录为新提交。

note: type: Labeled list
en: [[def_clean]]clean
zh_HANS-CN: [[def_clean]]干净（的工作区）

note: type: Plain text
en: A <<def_working_tree,working tree>> is clean, if it corresponds to the <<def_revision,revision>> referenced by the current <<def_head,head>>. Also see "<<def_dirty,dirty>>".
zh_HANS-CN: 如果一个<<def_working_tree,工作区>>对应于当前<<def_revision,版本>>所引用的<<def_head,头、分支>>，它就是干净的（clean）。另请参见"<<def_dirty,脏（的工作区）>>"。

note: type: Labeled list
en: [[def_commit]]commit
zh_HANS-CN: [[def_commit]]提交

note: type: Plain text
en: As a noun: A single point in the Git history; the entire history of a project is represented as a set of interrelated commits.  The word "commit" is often used by Git in the same places other revision control systems use the words "revision" or "version".  Also used as a short hand for <<def_commit_object,commit object>>.
zh_HANS-CN: 作为名词时，意为：Git 历史中的一个点；一个项目的整个历史被表示为一组相互关联的提交。  Git经常使用"提交(commit)"这个词，就像其他版本控制系统使用"revision"或"version"一样。  也被用作<<def_commit_object,提交对象>>的简称。

note: type: Plain text
en: As a verb: The action of storing a new snapshot of the project's state in the Git history, by creating a new commit representing the current state of the <<def_index,index>> and advancing <<def_HEAD,HEAD>> to point at the new commit.
zh_HANS-CN: 作为动词时，意为：在 Git 历史中存储一个该项目状态的新快照，通过创建一个代表当前<<def_index,暂存区>>状态的提交，并移动<<def_HEAD,头指针>>指向此新提交。

note: type: Labeled list
en: [[def_commit_graph_general]]commit graph concept, representations and usage
zh_HANS-CN: [[def_commit_graph_general]]提交图示(commit graph)的概念、结构表示和用途

note: type: Plain text
en: A synonym for the <<def_DAG,DAG>> structure formed by the commits in the object database, <<def_ref,referenced>> by branch tips, using their <<def_chain,chain>> of linked commits.  This structure is the definitive commit graph. The graph can be represented in other ways, e.g. the <<def_commit_graph_file,"commit-graph" file>>.
zh_HANS-CN: 由对象数据库中的提交形成的<<def_DAG,有向无环图(DAG)>>，由被<<def_ref,引用>>的分支提示，使用其<<def_chain,对象链(chain)>>的链接提交。  这个结构就是明确的提交图。该图还有其他展示形式，例如<<def_commit_graph_file, "提交图示"文件>>。

note: type: Labeled list
en: [[def_commit_graph_file]]commit-graph file
zh_HANS-CN: [[def_commit_graph_file]]提交图示(commit-graph)文件

note: type: Plain text
en: The "commit-graph" (normally hyphenated) file is a supplemental representation of the <<def_commit_graph_general,commit graph>> which accelerates commit graph walks. The "commit-graph" file is stored either in the .git/objects/info directory or in the info directory of an alternate object database.
zh_HANS-CN: “提交图示(ommit-graph)”（通常是连字符）文件是<<def_commit_graph_general,提交图(commit graph)>>的补充表示，可以加速提交图的生成。“提交图示”文件存储在.git/objects/info目录下，或者存储在另一个对象数据库的info目录下。

note: type: Labeled list
en: [[def_commit_object]]commit object
zh_HANS-CN: [[def_commit_object]]提交对象(commit object)

note: type: Plain text
en: An <<def_object,object>> which contains the information about a particular <<def_revision,revision>>, such as <<def_parent,parents>>, committer, author, date and the <<def_tree_object,tree object>> which corresponds to the top <<def_directory,directory>> of the stored revision.
zh_HANS-CN: 一个<<def_object,对象 >>包含了关于某个特定<<def_revision,版本>>的信息，例如<<def_parent,父提交>>、提交者、作者、日期和<<def_tree_object, 树对象>>（对应于保存的版本顶部<<def_directory,目录>>）。

note: type: Labeled list
en: [[def_commit-ish]]commit-ish (also committish)
zh_HANS-CN: [[def_commit-ish]]提交号[commit-ish (also committish)]

note: type: Plain text
en: A <<def_commit_object,commit object>> or an <<def_object,object>> that can be recursively dereferenced to a commit object.  The following are all commit-ishes: a commit object, a <<def_tag_object,tag object>> that points to a commit object, a tag object that points to a tag object that points to a commit object, etc.
zh_HANS-CN: 一个<<def_commit_object,提交对象>>或一个<<def_object,对象>>可以递归反向引用到一个提交对象。这些都与提交号(commit-ish)有关：提交对象、指向提交对象的<<def_tag_object,标签对象>>、指向，指向提交对象的标签对象，的标签对象，等等。

note: type: Labeled list
en: [[def_core_git]]core Git
zh_HANS-CN: [[def_core_git]]Git核心(core Git)

note: type: Plain text
en: Fundamental data structures and utilities of Git. Exposes only limited source code management tools.
zh_HANS-CN: Git 的基本数据结构和实用工具。只暴露了有限的源代码管理工具。

note: type: Labeled list
en: [[def_DAG]]DAG
zh_HANS-CN: [[def_DAG]]有向无环图(DAG)

note: type: Plain text
en: Directed acyclic graph. The <<def_commit_object,commit objects>> form a directed acyclic graph, because they have parents (directed), and the graph of commit objects is acyclic (there is no <<def_chain,chain>> which begins and ends with the same <<def_object,object>>).
zh_HANS-CN: 有向无环图。<<def_commit_object,提交对象>>形成了一个有向无环图，因为它们有父提交（有向），而且提交对象的图是无环的（没有<<def_chain,对象链>>以同一个<<def_object,对象>>开始和结束）。

note: type: Labeled list
en: [[def_dangling_object]]dangling object
zh_HANS-CN: [[def_dangling_object]]悬空对象

note: type: Plain text
en: An <<def_unreachable_object,unreachable object>> which is not <<def_reachable,reachable>> even from other unreachable objects; a dangling object has no references to it from any reference or <<def_object,object>> in the <<def_repository,repository>>.
zh_HANS-CN: 一个<<def_unreachable_object,不可达对象>>，即使从其他无法可达对象也无法<<def_reachable,可达>>；一个悬空对象在<<def_repository,仓库>>中没有任何引用或<<def_object,对象>>。

note: type: Labeled list
en: [[def_detached_HEAD]]detached HEAD
zh_HANS-CN: [[def_detached_HEAD]分离的头指针(detached HEAD)

note: type: Plain text
en: Normally the <<def_HEAD,HEAD>> stores the name of a <<def_branch,branch>>, and commands that operate on the history HEAD represents operate on the history leading to the tip of the branch the HEAD points at.  However, Git also allows you to <<def_checkout,check out>> an arbitrary <<def_commit,commit>> that isn't necessarily the tip of any particular branch.  The HEAD in such a state is called "detached".
zh_HANS-CN: 通常，<<def_HEAD,HEAD>>存储的是一个<<def_branch,分支>>的名称，对 HEAD 所代表的历史进行操作的命令会对HEAD所指向的分支的顶端的历史进行操作。然而，Git 也允许你<<def_checkout,签出>>到一个任意的<<def_commit,提交>>，不一定是任何特定分支的顶端。处于这种状态的 HEAD 被称为“分离”。

note: type: Plain text
en: Note that commands that operate on the history of the current branch (e.g. `git commit` to build a new history on top of it) still work while the HEAD is detached. They update the HEAD to point at the tip of the updated history without affecting any branch.  Commands that update or inquire information _about_ the current branch (e.g. `git branch --set-upstream-to` that sets what remote-tracking branch the current branch integrates with) obviously do not work, as there is no (real) current branch to ask about in this state.
zh_HANS-CN: 请注意，当 HEAD 分离时，对当前分支的历史进行操作的命令（例如，`git commit`在其上建立一个新的历史）仍然有效。它们会更新 HEAD，使其指向更新的历史记录的顶端，而不影响任何分支。更新或查询关于当前分支的信息的命令（例如，`git branch --set-upstream-to`，设置当前分支与哪个远程跟踪分支集成）显然不起作用，因为在这种状态下没有（真正的）当前分支可以查询。

note: type: Labeled list
en: [[def_directory]]directory
zh_HANS-CN: [[def_directory]]目录

note: type: Plain text
en: The list you get with "ls" :-)
zh_HANS-CN: 你用 "ls" 命令得到的列表(─‿‿─)

note: type: Labeled list
en: [[def_dirty]]dirty
zh_HANS-CN: [[def_dirty]]脏（的工作区）(dirty)

note: type: Plain text
en: A <<def_working_tree,working tree>> is said to be "dirty" if it contains modifications which have not been <<def_commit,committed>> to the current <<def_branch,branch>>.
zh_HANS-CN: 如果<<def_working_tree,工作区>>包含的修改没有被<<def_commit,提交>>到当前的<<def_branch,分支>>，就被认为是 "dirty" 的。

note: type: Labeled list
en: [[def_evil_merge]]evil merge
zh_HANS-CN: [[def_evil_merge]]坏合并（合并引入了父提交没有的修改）(evil merge)

note: type: Plain text
en: An evil merge is a <<def_merge,merge>> that introduces changes that do not appear in any <<def_parent,parent>>.
zh_HANS-CN: 一个坏合并，指引入了没有出现在任何<<def_parent,父提交>>中修改的<<def_merge,合并>>。

note: type: Labeled list
en: [[def_fast_forward]]fast-forward
zh_HANS-CN: [[def_fast_forward]]快速合并

note: type: Plain text
en: A fast-forward is a special type of <<def_merge,merge>> where you have a <<def_revision,revision>> and you are "merging" another <<def_branch,branch>>'s changes that happen to be a descendant of what you have. In such a case, you do not make a new <<def_merge,merge>> <<def_commit,commit>> but instead just update your branch to point at the same revision as the branch you are merging. This will happen frequently on a <<def_remote_tracking_branch,remote-tracking branch>> of a remote <<def_repository,repository>>.
zh_HANS-CN: 快速合并是<<def_merge,合并>>的一种特殊类型，即你有一个<<def_revision,版本>>而你正在“合并”另一个<<def_branch,分支>>的修改，这些修改恰好是你的后续提交。在这种情况下，你不需要添加一个新的<<def_merge,合并>> <<def_commit,提交>>而只是更新你的分支，使其指向与你要合并的分支相同的版本。这种情况会经常发生在一个远程<<def_remote_tracking_branch,远程跟踪分支>>的<<def_repository,仓库>>。

note: type: Labeled list
en: [[def_fetch]]fetch
zh_HANS-CN: [[def_fetch]]获取(fetch)

note: type: Plain text
en: Fetching a <<def_branch,branch>> means to get the branch's <<def_head_ref,head ref>> from a remote <<def_repository,repository>>, to find out which objects are missing from the local <<def_object_database,object database>>, and to get them, too.  See also linkgit:git-fetch[1].
zh_HANS-CN: 获取一个<<def_branch,分支>>意味着从远程<<def_repository,仓库>>获取该分支的<<def_head_ref,头引用>>，找出本地<<def_object_database,对象库>>中缺失的对象，并获取这些对象。另见 linkgit:git-fetch[1]。

note: type: Labeled list
en: [[def_file_system]]file system
zh_HANS-CN: [[def_file_system]]文件系统

note: type: Plain text
en: Linus Torvalds originally designed Git to be a user space file system, i.e. the infrastructure to hold files and directories. That ensured the efficiency and speed of Git.
zh_HANS-CN: Linus Torvalds （林纳斯·本纳第克特·托瓦兹；Git的作者、Linux之父）最初将 Git 设计为用户空间文件系统，即用于保存文件和目录的基础结构。这确保了 Git 的效率和速度。

note: type: Labeled list
en: [[def_git_archive]]Git archive
zh_HANS-CN: [[def_git_archive]]仓库（对于arch用户）(Git archive)

note: type: Plain text
en: Synonym for <<def_repository,repository>> (for arch people).
zh_HANS-CN: 与<<def_repository,仓库>> 同义(对于arch用户)。

note: type: Labeled list
en: [[def_gitfile]]gitfile
zh_HANS-CN: [[def_gitfile]]gitfile（仓库链接文件）

note: type: Plain text
en: A plain file `.git` at the root of a working tree that points at the directory that is the real repository.
zh_HANS-CN: 在工作区根部的普通文件 `.git`，指向真正的版本库目录。

note: type: Labeled list
en: [[def_grafts]]grafts
zh_HANS-CN: [[def_grafts]]（提交）移植(grafts)

note: type: Plain text
en: Grafts enables two otherwise different lines of development to be joined together by recording fake ancestry information for commits. This way you can make Git pretend the set of <<def_parent,parents>> a <<def_commit,commit>> has is different from what was recorded when the commit was created. Configured via the `.git/info/grafts` file.
zh_HANS-CN: 移植（Grafts）通过记录提交的虚假祖先信息，使两条原本不同的开发线连接在一起。这样你就可以让 Git 假装<<def_commit,提交>>的一组<<def_parent,父提交>>与创建提交(commit)时的记录不同。通过 `.git/info/grafts` 文件进行配置。

note: type: Plain text
en: Note that the grafts mechanism is outdated and can lead to problems transferring objects between repositories; see linkgit:git-replace[1] for a more flexible and robust system to do the same thing.
zh_HANS-CN: 请注意，移植（Grafts）机制已经过时了，可能会导致在仓库之间转移对象的问题；参见 linkgit:git-replace[1] ，这是一个更灵活更强大的系统，可以做同样的事情。

note: type: Labeled list
en: [[def_hash]]hash
zh_HANS-CN: [[def_hash]]哈希（hash）

note: type: Plain text
en: In Git's context, synonym for <<def_object_name,object name>>.
zh_HANS-CN: 在 Git 的上下文中，是<<def_object_name,对象名称>>的同义词。

note: type: Labeled list
en: [[def_head]]head
zh_HANS-CN: [[def_head]]头/分支(head)

note: type: Plain text
en: A <<def_ref,named reference>> to the <<def_commit,commit>> at the tip of a <<def_branch,branch>>.  Heads are stored in a file in `$GIT_DIR/refs/heads/` directory, except when using packed refs. (See linkgit:git-pack-refs[1].)
zh_HANS-CN: 一个<<def_ref,命名引用>>到<<def_commit,提交>>在<<def_branch,分支>>的顶端。头部存储在 `$GIT_DIR/refs/heads/` 目录下的一个文件中，除非使用打包的 refs（参见 linkgit:git-pack-refs[1]）。

note: type: Labeled list
en: [[def_HEAD]]HEAD
zh_HANS-CN: [[def_HEAD]]HEAD（头指针，亦即当前分支）

note: type: Plain text
en: The current <<def_branch,branch>>.  In more detail: Your <<def_working_tree, working tree>> is normally derived from the state of the tree referred to by HEAD.  HEAD is a reference to one of the <<def_head,heads>> in your repository, except when using a <<def_detached_HEAD,detached HEAD>>, in which case it directly references an arbitrary commit.
zh_HANS-CN: 当前<<def_branch,分支>>。详细地讲，你的<<def_working_tree,工作区>>通常是由 HEAD 所指的树的状态衍生出来的。HEAD 是对你的版本库中的一个<<def_head,头>>的引用，除非使用<<def_detached_HEAD,分离的 HEAD>>，这种情况下它直接引用一个任意的提交。

note: type: Labeled list
en: [[def_head_ref]]head ref
zh_HANS-CN: [[def_head_ref]]头引用

note: type: Plain text
en: A synonym for <<def_head,head>>.
zh_HANS-CN: <<def_head,头>>的同义词。

note: type: Labeled list
en: [[def_hook]]hook
zh_HANS-CN: [[def_hook]钩子

note: type: Plain text
en: During the normal execution of several Git commands, call-outs are made to optional scripts that allow a developer to add functionality or checking. Typically, the hooks allow for a command to be pre-verified and potentially aborted, and allow for a post-notification after the operation is done. The hook scripts are found in the `$GIT_DIR/hooks/` directory, and are enabled by simply removing the `.sample` suffix from the filename. In earlier versions of Git you had to make them executable.
zh_HANS-CN: 在几个 Git 命令的正常执行过程中，会对可选的脚本进行调用，允许开发者添加功能或检查。通常情况下，钩子允许一个命令被预先验证并可能中止执行，并允许在操作完成后发出通知。钩子脚本可以在 `$GIT_DIR/hooks/` 目录下找到，只需将文件名中的 `.sample` 后缀去掉即可启用。在早期版本的 Git 中，你必须将它们设置为可执行。

note: type: Labeled list
en: [[def_index]]index
zh_HANS-CN: [[def_index]]索引

note: type: Plain text
en: A collection of files with stat information, whose contents are stored as objects. The index is a stored version of your <<def_working_tree,working tree>>. Truth be told, it can also contain a second, and even a third version of a working tree, which are used when <<def_merge,merging>>.
zh_HANS-CN: 一个带有统计信息的文件集合，其内容以对象形式存储。索引是你的<<def_working_tree,工作区>>的一个存储版本。事实上它也可以包含第二个，甚至第三个版本的工作区，这些在<<def_merge,合并>>时使用。

note: type: Labeled list
en: [[def_index_entry]]index entry
zh_HANS-CN: [[def_index_entry]]索引项

note: type: Plain text
en: The information regarding a particular file, stored in the <<def_index,index>>. An index entry can be unmerged, if a <<def_merge,merge>> was started, but not yet finished (i.e. if the index contains multiple versions of that file).
zh_HANS-CN: 关于某个特定文件的信息，存储在<<def_index,索引/暂存区>>。如果<<def_merge,合并>>已经开始，但尚未完成（即如果索引包含该文件的多个版本），则索引条目可以取消合并。

note: type: Labeled list
en: [[def_master]]master
zh_HANS-CN: [[def_master]]master（默认分支名）

note: type: Plain text
en: The default development <<def_branch,branch>>. Whenever you create a Git <<def_repository,repository>>, a branch named "master" is created, and becomes the active branch. In most cases, this contains the local development, though that is purely by convention and is not required.
zh_HANS-CN: 默认的开发<<def_branch,分支 >>。每当你创建一个 Git <<def_repository,仓库>>，就会创建一个名为 "master" 的分支，并成为活动分支。在大多数情况下，它包含了本地的开发内容，但这纯粹是惯例，并不是必须的。

note: type: Labeled list
en: [[def_merge]]merge
zh_HANS-CN: [[def_merge]合并

note: type: Plain text
en: As a verb: To bring the contents of another <<def_branch,branch>> (possibly from an external <<def_repository,repository>>) into the current branch.  In the case where the merged-in branch is from a different repository, this is done by first <<def_fetch,fetching>> the remote branch and then merging the result into the current branch.  This combination of fetch and merge operations is called a <<def_pull,pull>>.  Merging is performed by an automatic process that identifies changes made since the branches diverged, and then applies all those changes together.  In cases where changes conflict, manual intervention may be required to complete the merge.
zh_HANS-CN: 作为动词。将另一个<<def_branch,分支>>（可能来自外部<<def_repository,仓库>>）的内容引入当前分支。在被合并的分支来自不同的仓库的情况下，这是通过首先<<def_fetch,抓取>>远程分支，然后将结果合并到当前分支来实现的。这种获取和合并操作的组合被称为<<def_pull,拉取>>。合并是由一个自动过程进行的，该过程会识别自分支分歧以来的变化，然后将所有这些变化应用在一起。在变化发生冲突的情况下，可能需要人工干预来完成合并。

note: type: Plain text
en: As a noun: unless it is a <<def_fast_forward,fast-forward>>, a successful merge results in the creation of a new <<def_commit,commit>> representing the result of the merge, and having as <<def_parent,parents>> the tips of the merged <<def_branch,branches>>.  This commit is referred to as a "merge commit", or sometimes just a "merge".
zh_HANS-CN: 作为名词，除非是<<def_fast_forward,快速合并>>，否则一个成功的合并会产生一个新的<<def_commit,提交>>，代表合并的结果，并且有<<def_parent,父提交>>与<<def_branch,分支>> 合并的提示。这种提交被称为"合并提交"，或者有时只是"合并"。

note: type: Labeled list
en: [[def_object]]object
zh_HANS-CN: [[def_object]]对象

note: type: Plain text
en: The unit of storage in Git. It is uniquely identified by the <<def_SHA1,SHA-1>> of its contents. Consequently, an object cannot be changed.
zh_HANS-CN: Git中的存储单位。它由其内容的<<def_SHA1,SHA-1>>作为唯一的标识。因此，一个对象不能被改变。

note: type: Labeled list
en: [[def_object_database]]object database
zh_HANS-CN: [[def_object_database]对象库

note: type: Plain text
en: Stores a set of "objects", and an individual <<def_object,object>> is identified by its <<def_object_name,object name>>. The objects usually live in `$GIT_DIR/objects/`.
zh_HANS-CN: 存储一组"对象"，一个单独的<<def_object,对象>>由其<<def_object_name,对象名称>>标识。这些对象通常存在于`$GIT_DIR/objects/`中。

note: type: Labeled list
en: [[def_object_identifier]]object identifier (oid)
zh_HANS-CN: [[def_object_identifier]]对象标识符[object identifier (oid)]

note: type: Plain text
en: Synonym for <<def_object_name,object name>>.
zh_HANS-CN: <<def_object_name,对象名称>>的同义词。

note: type: Labeled list
en: [[def_object_name]]object name
zh_HANS-CN: [[def_object_name]]对象名称

note: type: Plain text
en: The unique identifier of an <<def_object,object>>.  The object name is usually represented by a 40 character hexadecimal string.  Also colloquially called <<def_SHA1,SHA-1>>.
zh_HANS-CN: 一个<<def_object,对象>>的唯一标识。对象名称通常由40个字符的十六进制字符串表示。也被称为<<def_SHA1,SHA-1>>。

note: type: Labeled list
en: [[def_object_type]]object type
zh_HANS-CN: [[def_object_type]]对象类型

note: type: Plain text
en: One of the identifiers "<<def_commit_object,commit>>", "<<def_tree_object,tree>>", "<<def_tag_object,tag>>" or "<<def_blob_object,blob>>" describing the type of an <<def_object,object>>.
zh_HANS-CN: 其中一个标识符"<<def_commit_object,提交>>", "<<def_tree_object,树>>", "<<def_tag_object,标签>>"或"<<def_blob_object,blob>>"描述一个<<def_object,对象>的类型。

note: type: Labeled list
en: [[def_octopus]]octopus
zh_HANS-CN: [[def_octopus]]章鱼式合并（两分支以上的合并）(octopus)

note: type: Plain text
en: To <<def_merge,merge>> more than two <<def_branch,branches>>.
zh_HANS-CN: <<def_merge,合并>>两个以上的<<def_branch,分支>>。

note: type: Labeled list
en: [[def_origin]]origin
zh_HANS-CN: [[def_origin]]origin（默认的远程名称）

note: type: Plain text
en: The default upstream <<def_repository,repository>>. Most projects have at least one upstream project which they track. By default 'origin' is used for that purpose. New upstream updates will be fetched into <<def_remote_tracking_branch,remote-tracking branches>> named origin/name-of-upstream-branch, which you can see using `git branch -r`.
zh_HANS-CN: 默认的上游<<def_repository,仓库>>。大多数项目至少有一个上游项目，它们会对其进行跟踪。默认情况下，'origin'被用于此目的。新的上游更新会被拉取到<<def_remote_tracking_branch,远程跟踪分支>>，名为origin/name-of-upstream-branch，你可以用`git branch -r`看到。

note: type: Labeled list
en: [[def_overlay]]overlay
zh_HANS-CN: [[def_overlay]]覆盖(overlay)

note: type: Plain text
en: Only update and add files to the working directory, but don't delete them, similar to how 'cp -R' would update the contents in the destination directory.  This is the default mode in a <<def_checkout,checkout>> when checking out files from the <<def_index,index>> or a <<def_tree-ish,tree-ish>>.  In contrast, no-overlay mode also deletes tracked files not present in the source, similar to 'rsync --delete'.
zh_HANS-CN: 只更新和添加文件到工作目录，但不删除它们，类似于'cp -R'会更新目标目录中的内容。这是<<def_checkout,检出>>中的默认模式，当从<<def_index,暂存区>>或<<def_tree-ish,树对象(tree-ish)>>中检出文件时。相反，非覆盖模式也会删除源文件中不存在的跟踪文件，类似于'rsync --delete'。

note: type: Labeled list
en: [[def_pack]]pack
zh_HANS-CN: [[def_pack]包(pack)

note: type: Plain text
en: A set of objects which have been compressed into one file (to save space or to transmit them efficiently).
zh_HANS-CN: 一组被压缩成一个文件的对象（以节省空间或有效传输）。

note: type: Labeled list
en: [[def_pack_index]]pack index
zh_HANS-CN: [[def_pack_index]]包索引(pack index)

note: type: Plain text
en: The list of identifiers, and other information, of the objects in a <<def_pack,pack>>, to assist in efficiently accessing the contents of a pack.
zh_HANS-CN: <<def_pack,包>>中的对象的标识符和其他信息的列表，以协助有效地访问一个包的内容。

note: type: Labeled list
en: [[def_pathspec]]pathspec
zh_HANS-CN: [[def_pathspec]]路径规范(pathspec)

note: type: Plain text
en: Pattern used to limit paths in Git commands.
zh_HANS-CN: 用来限制Git命令中的路径的模式。

note: type: Plain text
en: Pathspecs are used on the command line of "git ls-files", "git ls-tree", "git add", "git grep", "git diff", "git checkout", and many other commands to limit the scope of operations to some subset of the tree or working tree.  See the documentation of each command for whether paths are relative to the current directory or toplevel.  The pathspec syntax is as follows:
zh_HANS-CN: 在 "git ls-files"、"git ls-tree"、"git add"、"git grep"、"git diff"、"git checkout "和许多其他命令的命令行中，路径规格被用来将操作范围限制在树或工作区的某个子集。  关于路径是相对于当前目录还是顶层，请参阅每个命令的文档。  pathspec的语法如下：

note: type: Plain text
en: any path matches itself
zh_HANS-CN: 任何路径都与自己匹配

note: type: Plain text
en: the pathspec up to the last slash represents a directory prefix.  The scope of that pathspec is limited to that subtree.
zh_HANS-CN: 到最后一个斜线的路径规范代表一个目录前缀。  该路径规范的范围只限于该子树。

note: type: Plain text
en: the rest of the pathspec is a pattern for the remainder of the pathname.  Paths relative to the directory prefix will be matched against that pattern using fnmatch(3); in particular, '*' and '?' _can_ match directory separators.
zh_HANS-CN: 路径规范的其余部分是路径名其余部分的模式。  相对于目录前缀的路径将使用fnmatch(3)（匹配函数）与该模式进行匹配；特别是，‘*’和‘?’_可以_匹配目录分隔符。

note: type: Plain text
en: For example, Documentation/*.jpg will match all .jpg files in the Documentation subtree, including Documentation/chapter_1/figure_1.jpg.
zh_HANS-CN: 例如，Documentation/*.jpg将匹配Documentation子树中的所有.jpg文件，包括Documentation/chapter_1/figure_1.jpg。

note: type: Plain text
en: A pathspec that begins with a colon `:` has special meaning.  In the short form, the leading colon `:` is followed by zero or more "magic signature" letters (which optionally is terminated by another colon `:`), and the remainder is the pattern to match against the path.  The "magic signature" consists of ASCII symbols that are neither alphanumeric, glob, regex special characters nor colon.  The optional colon that terminates the "magic signature" can be omitted if the pattern begins with a character that does not belong to "magic signature" symbol set and is not a colon.
zh_HANS-CN: 以冒号`:`开头的路径规范有特殊含义。  在简短的形式中，前面的冒号`:`后面是0个或更多的 “魔术签名(magic signature)”（可以选择以另一个冒号`:`结束），剩下的部分是与路径匹配的模式。  “魔术签名”由ASCII符号组成，这些符号既不是字母数字、glob、regex特殊字符也不是冒号。  如果模式以不属于“魔术签名”符号集的字符开始，并且不是冒号，那么结束“魔术签名”的可选冒号就可以省略。

note: type: Plain text
en: In the long form, the leading colon `:` is followed by an open parenthesis `(`, a comma-separated list of zero or more "magic words", and a close parentheses `)`, and the remainder is the pattern to match against the path.
zh_HANS-CN: 在较长规范中，前面的冒号`:`后面是一个开放的小括号`(`，一个用逗号分隔的0个或多个 “魔术单词”列表，以及一个封闭的小括号`)`，其余部分是要与路径匹配的模式。

note: type: Plain text
en: A pathspec with only a colon means "there is no pathspec". This form should not be combined with other pathspec.
zh_HANS-CN: 一个只有冒号的路径规范意味着 “不使用路径规范”。这种形式不应该与其他路径规范结合。

note: type: Labeled list
en: top
zh_HANS-CN: 顶部(top)

note: type: Plain text
en: The magic word `top` (magic signature: `/`) makes the pattern match from the root of the working tree, even when you are running the command from inside a subdirectory.
zh_HANS-CN: 魔术词`top`（魔术签名：`/`）使模式从工作区的根目录开始匹配，即使你从子目录内运行命令。

note: type: Labeled list
en: literal
zh_HANS-CN: 字面量(literal)

note: type: Plain text
en: Wildcards in the pattern such as `*` or `?` are treated as literal characters.
zh_HANS-CN: 模式中的通配符，如`*`或`?`被视为字面量字符。

note: type: Labeled list
en: icase
zh_HANS-CN: 不敏感匹配(icase)

note: type: Plain text
en: Case insensitive match.
zh_HANS-CN: 不区分大小写的匹配。

note: type: Labeled list
en: glob
zh_HANS-CN: 通配符

note: type: Plain text
en: Git treats the pattern as a shell glob suitable for consumption by fnmatch(3) with the FNM_PATHNAME flag: wildcards in the pattern will not match a / in the pathname.  For example, "Documentation/{asterisk}.html" matches "Documentation/git.html" but not "Documentation/ppc/ppc.html" or "tools/perf/Documentation/perf.html".
zh_HANS-CN: Git将模式视为适合fnmatch(3)（匹配函数）使用shell的glob模式（shell 所使用的简化了的正则表达式），带有FNM_PATHNAME标志:模式中的通配符将不匹配路径名中的/（即不对子目录或上级目录进行匹配）。例如，"Documentation/{asterisk}.html"匹配"Documentation/git.html"，而不是"Documentation/ppc/ppc.html"或"tools/perf/Documentation/perff.html"。

note: type: Plain text
en: Two consecutive asterisks ("`**`") in patterns matched against full pathname may have special meaning:
zh_HANS-CN: 在与全路径名匹配的模式中，两个连续的星号（"`**`"）可能有特殊含义：

note: type: Plain text
en: A leading "`**`" followed by a slash means match in all directories. For example, "`**/foo`" matches file or directory "`foo`" anywhere, the same as pattern "`foo`". "`**/foo/bar`" matches file or directory "`bar`" anywhere that is directly under directory "`foo`".
zh_HANS-CN: "`**`"在带斜杠目录之前，表示在所有目录中匹配。例如，"`**/foo`"匹配任何文件或目录的"`foo`"，与模式"`foo`"相同。"`**/foo/bar`"匹配任何文件或目录中直接位于目录"`foo`"之下的"`bar`"。

note: type: Plain text
en: A trailing "`/**`" matches everything inside. For example, "`abc/**`" matches all files inside directory "abc", relative to the location of the `.gitignore` file, with infinite depth.
zh_HANS-CN: 路径后跟有"`/**`"表示匹配这个目录里面的所有文件。例如，"`abc/**`"匹配相对于`.gitignore`文件的位置中目录 "abc "内的所有文件，深度无限。

note: type: Plain text
en: A slash followed by two consecutive asterisks then a slash matches zero or more directories. For example, "`a/**/b`" matches "`a/b`", "`a/x/b`", "`a/x/y/b`" and so on.
zh_HANS-CN: 一个斜杠后面是两个连续的星号再接上一个斜杠，匹配零个或多个目录。例如，"`a/**/b`" 匹配 "`a/b`"、"`a/x/b`"、"`a/x/y/b`"，等等，依此类推。

note: type: Plain text
en: Other consecutive asterisks are considered invalid.
zh_HANS-CN: 其他连续的星号是无效的。

note: type: Plain text
en: Glob magic is incompatible with literal magic.
zh_HANS-CN: 通配符魔术词(glob)与字面量魔术词(literal)是不相容的。

note: type: Labeled list
en: attr
zh_HANS-CN: 属性匹配

note: type: Plain text
en: After `attr:` comes a space separated list of "attribute requirements", all of which must be met in order for the path to be considered a match; this is in addition to the usual non-magic pathspec pattern matching.  See linkgit:gitattributes[5].
zh_HANS-CN: 在`attr:` 之后是一个空格分隔的“属性要求”列表，所有这些都必须满足才能被认为是匹配的路径;这是在通常的非魔法路径规范模式匹配之外的。参见linkgit:gitattributes[5]。

note: type: Plain text
en: Each of the attribute requirements for the path takes one of these forms:
zh_HANS-CN: 以下包含了路径的每个属性要求：

note: type: Plain text
en: "`ATTR`" requires that the attribute `ATTR` be set.
zh_HANS-CN: "`ATTR`"表示要求设置`ATTR`属性。

note: type: Plain text
en: "`-ATTR`" requires that the attribute `ATTR` be unset.
zh_HANS-CN: "`-ATTR`"要求属性`ATTR`没有设置。

note: type: Plain text
en: "`ATTR=VALUE`" requires that the attribute `ATTR` be set to the string `VALUE`.
zh_HANS-CN: "`ATTR=VALUE`"要求将属性`ATTR`设置为字符串`VALUE`。

note: type: Plain text
en: "`!ATTR`" requires that the attribute `ATTR` be unspecified.
zh_HANS-CN: "`!ATTR`"要求属性`ATTR`是未指定的。

note: type: Plain text
en: Note that when matching against a tree object, attributes are still obtained from working tree, not from the given tree object.
zh_HANS-CN: 注意，当与树对象进行匹配时，属性仍然是从工作区中获得的，而不是从给定的树对象中获得。

note: type: Labeled list
en: exclude
zh_HANS-CN: 排除匹配(exclude)

note: type: Plain text
en: After a path matches any non-exclude pathspec, it will be run through all exclude pathspecs (magic signature: `!` or its synonym `^`). If it matches, the path is ignored.  When there is no non-exclude pathspec, the exclusion is applied to the result set as if invoked without any pathspec.
zh_HANS-CN: 当一个路径匹配了任何规则之外的(non-exclude)路径规范后，它将遍历所有的排除性路径规范（魔术签名：`！`或其同义词`^`）。如果匹配，该路径将被忽略。  当没有规则之外路径规范时，排除法将应用于结果集，就像在没有任何路径规范的情况下调用。

note: type: Labeled list
en: [[def_parent]]parent
zh_HANS-CN: [[def_parent]]父提交(parent)

note: type: Plain text
en: A <<def_commit_object,commit object>> contains a (possibly empty) list of the logical predecessor(s) in the line of development, i.e. its parents.
zh_HANS-CN: 一个<<def_commit_object,提交对象>>包含一个开发中的逻辑前驱列表（可能是空的），即其父提交。

note: type: Labeled list
en: [[def_pickaxe]]pickaxe
zh_HANS-CN: [[def_pickaxe]]挖掘(pickaxe)

note: type: Plain text
en: The term <<def_pickaxe,pickaxe>> refers to an option to the diffcore routines that help select changes that add or delete a given text string. With the `--pickaxe-all` option, it can be used to view the full <<def_changeset,changeset>> that introduced or removed, say, a particular line of text. See linkgit:git-diff[1].
zh_HANS-CN: 术语<<def_pickaxe,挖掘>>指的是diff核心例程(diffcore)的一个选项，辅助选择增加或删除特定文本字符串的变化。通过`--pickaxe-all`选项，它可以用来查看引入或删除的全部<<def_changeset,变更集>>，例如某一行文字。参见linkgit:git-diff[1]。

note: type: Labeled list
en: [[def_plumbing]]plumbing
zh_HANS-CN: [[def_plumbing]]管件(plumbing)

note: type: Plain text
en: Cute name for <<def_core_git,core Git>>.
zh_HANS-CN: <<def_core_git,Git核心>>的昵称。

note: type: Labeled list
en: [[def_porcelain]]porcelain
zh_HANS-CN: [[def_porcelain]]瓷件(porcelain)

note: type: Plain text
en: Cute name for programs and program suites depending on <<def_core_git,core Git>>, presenting a high level access to core Git. Porcelains expose more of a <<def_SCM,SCM>> interface than the <<def_plumbing,plumbing>>.
zh_HANS-CN: 依靠<<def_core_git,Git核心>>的程序和程序套件的昵称，是对Git核心上层封装。与<<def_plumbing,管件>>相比，瓷件暴露了更多<<def_SCM,SCM>>接口。

note: type: Labeled list
en: [[def_per_worktree_ref]]per-worktree ref
zh_HANS-CN: [[def_per_worktree_ref]]工作区引用(per-worktree ref)

note: type: Plain text
en: Refs that are per-<<def_worktree,worktree>>, rather than global.  This is presently only <<def_HEAD,HEAD>> and any refs that start with `refs/bisect/`, but might later include other unusual refs.
zh_HANS-CN: 相比于全局引用，它是对每个<<def_worktree,工作区>>的引用。  目前只有<<def_HEAD,HEAD>>和任何以`refs/bisect/`开头的引用，但以后可能包括其他不寻常的引用。

note: type: Labeled list
en: [[def_pseudoref]]pseudoref
zh_HANS-CN: [[def_pseudoref]]伪引用(pseudoref)

note: type: Plain text
en: Pseudorefs are a class of files under `$GIT_DIR` which behave like refs for the purposes of rev-parse, but which are treated specially by git.  Pseudorefs both have names that are all-caps, and always start with a line consisting of a <<def_SHA1,SHA-1>> followed by whitespace.  So, HEAD is not a pseudoref, because it is sometimes a symbolic ref.  They might optionally contain some additional data.  `MERGE_HEAD` and `CHERRY_PICK_HEAD` are examples.  Unlike <<def_per_worktree_ref,per-worktree refs>>, these files cannot be symbolic refs, and never have reflogs.  They also cannot be updated through the normal ref update machinery.  Instead, they are updated by directly writing to the files.  However, they can be read as if they were refs, so `git rev-parse MERGE_HEAD` will work.
zh_HANS-CN: 伪引用是`$GIT_DIR`下的一类文件，其行为与修订-剖析(rev-parse)中的引用一样，但被Git区分对待。  伪引用的名字一般是由由一行<<def_SHA1,SHA-1>>开始，然后是空格。  所以，HEAD并不是一个伪引用，因为它有时是一个符号性引用。  它可能选择性地包含一些额外的数据。  比如`MERGE_HEAD`和`CHERRY_PICK_HEAD`。  与<<def_per_worktree_ref,工作区引用>>不同，这些文件不能是符号引用，也没有引用日志。  它们也不能通过正常的引用更新机制进行更新。  相反，它们是通过直接写入文件来更新的。  不过，它们可以被当作引用读取，所以 `git rev-parse MERGE_HEAD` 仍可以运行。

note: type: Labeled list
en: [[def_pull]]pull
zh_HANS-CN: [[def_pull]]拉取(pull)

note: type: Plain text
en: Pulling a <<def_branch,branch>> means to <<def_fetch,fetch>> it and <<def_merge,merge>> it.  See also linkgit:git-pull[1].
zh_HANS-CN: 拉取一个<<def_branch,分支>>意味着<<def_fetch,获取>>一个分支并且<<def_merge,合并>>这个分支。  另见 linkgit:git-pull[1]。

note: type: Labeled list
en: [[def_push]]push
zh_HANS-CN: [[def_push]]推送(push)

note: type: Plain text
en: Pushing a <<def_branch,branch>> means to get the branch's <<def_head_ref,head ref>> from a remote <<def_repository,repository>>, find out if it is an ancestor to the branch's local head ref, and in that case, putting all objects, which are <<def_reachable,reachable>> from the local head ref, and which are missing from the remote repository, into the remote <<def_object_database,object database>>, and updating the remote head ref. If the remote <<def_head,head>> is not an ancestor to the local head, the push fails.
zh_HANS-CN: 推送一个<<def_branch,分支>>意味着从远程的<<def_repository,仓库>>获取该分支的<<def_head_ref,头引用>>，找出它是否是该分支的本地分支引用的一个祖先。在这种情况下，将所有从本地分支引用<<def_reachable,可达>>的对象，以及从远程仓库中丢失的对象，放入远程<<def_object_database,对象库>>，并更新远程分支引用。如果远程<<def_head,头/分支>>不是本地分支的祖先，则推送失败。

note: type: Labeled list
en: [[def_reachable]]reachable
zh_HANS-CN: [[def_reachable]]可达的（reachable）

note: type: Plain text
en: All of the ancestors of a given <<def_commit,commit>> are said to be "reachable" from that commit. More generally, one <<def_object,object>> is reachable from another if we can reach the one from the other by a <<def_chain,chain>> that follows <<def_tag,tags>> to whatever they tag, <<def_commit_object,commits>> to their parents or trees, and <<def_tree_object,trees>> to the trees or <<def_blob_object,blobs>> that they contain.
zh_HANS-CN: 一个给定的<<def_commit,提交>>的所有祖先都被称为可以从该提交 “到达”。更一般地说，如果一个<<def_object,对象>>可以通过<<def_chain,对象链>>从一个<<def_tag,标签>>到达任意一个对象链标记的<<def_tag,标签>>，那么该对象就是可达的，<<def_commit_object,提交>>到它们的父提交或树，以及<<def_tree_object,树>>到它们所包含的树或<<def_blob_object,二进制对象>>。

note: type: Labeled list
en: [[def_reachability_bitmap]]reachability bitmaps
zh_HANS-CN: [[def_reachability_bitmap]]可达性位图

note: type: Plain text
en: Reachability bitmaps store information about the <<def_reachable,reachability>> of a selected set of commits in a packfile, or a multi-pack index (MIDX), to speed up object search.  The bitmaps are stored in a ".bitmap" file. A repository may have at most one bitmap file in use. The bitmap file may belong to either one pack, or the repository's multi-pack index (if it exists).
zh_HANS-CN: 可达性位图存储了包文件或多包索引（MIDX）中选定的一组提交的<<def_reachable,可达性>>的信息，以加快对象搜索。  位图被存储在".bitmap "文件中。一个版本库最多可以有一个位图文件在使用。这个位图文件可以属于一个包，也可以属于版本库的多包索引（如果有的话）。

note: type: Labeled list
en: [[def_rebase]]rebase
zh_HANS-CN: [[def_rebase]]变基(rebase)

note: type: Plain text
en: To reapply a series of changes from a <<def_branch,branch>> to a different base, and reset the <<def_head,head>> of that branch to the result.
zh_HANS-CN: 将<<def_branch,分支>>的一系列修改重新应用于不同的分支上，并将<<def_head,头>>指针重置为该分支。

note: type: Labeled list
en: [[def_ref]]ref
zh_HANS-CN: [[def_ref]]引用(ref)

note: type: Plain text
en: A name that begins with `refs/` (e.g. `refs/heads/master`)  that points to an <<def_object_name,object name>> or another ref (the latter is called a <<def_symref,symbolic ref>>).  For convenience, a ref can sometimes be abbreviated when used as an argument to a Git command; see linkgit:gitrevisions[7] for details.  Refs are stored in the <<def_repository,repository>>.
zh_HANS-CN: 一个以`refs/`开头的名字（例如`refs/heads/master`），它指向一个<<def_object_name,对象名称>>或另一个引用（后者被称为<<def_symref,符号引用>>）。  为方便起见，当作为 Git 命令的参数时，引用可以使用缩写；参见 linkgit:gitrevisions[7] 。  引用保存在<<def_repository,仓库>>中。

note: type: Plain text
en: The ref namespace is hierarchical.  Different subhierarchies are used for different purposes (e.g. the `refs/heads/` hierarchy is used to represent local branches).
zh_HANS-CN: 引用的命名空间是分层次的。  不同的子层次表示不同的情况（例如，`refs/heads/`层次用于代表本地分支）。

note: type: Plain text
en: There are a few special-purpose refs that do not begin with `refs/`.  The most notable example is `HEAD`.
zh_HANS-CN: 有一些特殊意义的引用不以`refs/`开头。  最经典的例子就是`HEAD`。

note: type: Labeled list
en: [[def_reflog]]reflog
zh_HANS-CN: [[def_reflog]]引用日志(reflog)

note: type: Plain text
en: A reflog shows the local "history" of a ref.  In other words, it can tell you what the 3rd last revision in _this_ repository was, and what was the current state in _this_ repository, yesterday 9:14pm.  See linkgit:git-reflog[1] for details.
zh_HANS-CN: 引用日志显示一个引用的本地 "历史"。  换句话说，它可以告诉你，在昨天下午9:14，_这个_版本库的最后三次修订是什么，以及_这个_版本库的当前状态是什么。  详情见 linkgit:git-reflog[1]。

note: type: Labeled list
en: [[def_refspec]]refspec
zh_HANS-CN: [[def_refspec]]引用规范(refspec)

note: type: Plain text
en: A "refspec" is used by <<def_fetch,fetch>> and <<def_push,push>> to describe the mapping between remote <<def_ref,ref>> and local ref.
zh_HANS-CN: “引用规范”是<<def_fetch,获取>>和<<def_push,推送>>用以描述远程<<def_ref,引用>>和本地引用之间的映射关系。

note: type: Labeled list
en: [[def_remote]]remote repository
zh_HANS-CN: [[def_remote]]远程仓库

note: type: Plain text
en: A <<def_repository,repository>> which is used to track the same project but resides somewhere else. To communicate with remotes, see <<def_fetch,fetch>> or <<def_push,push>>.
zh_HANS-CN: 一个部署在其他地方但用于跟踪同一个项目的<<def_repository,仓库>>。要与远程通信，请参阅<<def_fetch,获取>>或<<def_push,推送>>。

note: type: Labeled list
en: [[def_remote_tracking_branch]]remote-tracking branch
zh_HANS-CN: [[def_remote_tracking_branch]]远程跟踪分支(remote-tracking branch)

note: type: Plain text
en: A <<def_ref,ref>> that is used to follow changes from another <<def_repository,repository>>. It typically looks like 'refs/remotes/foo/bar' (indicating that it tracks a branch named 'bar' in a remote named 'foo'), and matches the right-hand-side of a configured fetch <<def_refspec,refspec>>. A remote-tracking branch should not contain direct modifications or have local commits made to it.
zh_HANS-CN: 一个用来跟踪另一个<<def_repository,仓库>>变化的<<def_ref,引用>>。它通常看起来像'refs/remotes/foo/bar'（表示它跟踪一个名为'foo'的远程中名为'bar'的分支），并对配置好的fetch<<def_refspec,引用规范>>右侧进行匹配。一个远程跟踪分支不应该由直接的修改或是本地的提交构成。

note: type: Labeled list
en: [[def_repository]]repository
zh_HANS-CN: [[def_repository]仓库

note: type: Plain text
en: A collection of <<def_ref,refs>> together with an <<def_object_database,object database>> containing all objects which are <<def_reachable,reachable>> from the refs, possibly accompanied by meta data from one or more <<def_porcelain,porcelains>>. A repository can share an object database with other repositories via <<def_alternate_object_database,alternates mechanism>>.
zh_HANS-CN: 一个<<def_ref,引用>>的集合和一个<<def_object_database,对象库>>的集合，包含了引用中所有的<<def_reachable,可达的>>对象，可能还有一个或多个<<def_porcelain,瓷件>>元数据。一个仓库可以通过<<def_alternate_object_database,轮替对象库>>与其他存储库共享对象数据库。

note: type: Labeled list
en: [[def_resolve]]resolve
zh_HANS-CN: [[def_resolve]]解决

note: type: Plain text
en: The action of fixing up manually what a failed automatic <<def_merge,merge>> left behind.
zh_HANS-CN: 手动修复由自动<<def_merge,合并>>产生的遗留错误。

note: type: Labeled list
en: [[def_revision]]revision
zh_HANS-CN: [[def_revision]]版本

note: type: Plain text
en: Synonym for <<def_commit,commit>> (the noun).
zh_HANS-CN: 与<<def_commit,提交>>（名词形式）同义。

note: type: Labeled list
en: [[def_rewind]]rewind
zh_HANS-CN: [[def_rewind]]回退

note: type: Plain text
en: To throw away part of the development, i.e. to assign the <<def_head,head>> to an earlier <<def_revision,revision>>.
zh_HANS-CN: 删除一部分数据，即把<<def_head,头>>指针指向较早的<<def_revision,版本>>。

note: type: Labeled list
en: [[def_SCM]]SCM
zh_HANS-CN: [[def_SCM]]SCM（源代码管理工具）

note: type: Plain text
en: Source code management (tool).
zh_HANS-CN: 源代码管理（工具）。

note: type: Plain text
en: "Secure Hash Algorithm 1"; a cryptographic hash function.  In the context of Git used as a synonym for <<def_object_name,object name>>.
zh_HANS-CN: "安全哈希算法1"；一个加密哈希函数。  在Git的上下文中是<<def_object_name,对象名>>的同义词。

note: type: Labeled list
en: [[def_shallow_clone]]shallow clone
zh_HANS-CN: [[def_shallow_clone]]浅克隆(shallow clone)

note: type: Plain text
en: Mostly a synonym to <<def_shallow_repository,shallow repository>> but the phrase makes it more explicit that it was created by running `git clone --depth=...` command.
zh_HANS-CN: 大部分是指<<def_shallow_repository,浅仓库>>，但它更明确地表明其是通过运行`git clone --depth=...`命令创建的。

note: type: Labeled list
en: [[def_shallow_repository]]shallow repository
zh_HANS-CN: [[def_shallow_repository]浅仓库(shallow repository)

note: type: Plain text
en: A shallow <<def_repository,repository>> has an incomplete history some of whose <<def_commit,commits>> have <<def_parent,parents>> cauterized away (in other words, Git is told to pretend that these commits do not have the parents, even though they are recorded in the <<def_commit_object,commit object>>). This is sometimes useful when you are interested only in the recent history of a project even though the real history recorded in the upstream is much larger. A shallow repository is created by giving the `--depth` option to linkgit:git-clone[1], and its history can be later deepened with linkgit:git-fetch[1].
zh_HANS-CN: 一个浅<<def_repository,仓库>>不会记录完整的提交历史，其中一些<<def_commit,提交>>的<<def_parent,父>>提交被销毁了（换句话说，Git被告知假装这些提交没有父提交，尽管在<<def_commit_object,提交对象>>中有记录）。当你只对一个项目的近期历史感兴趣时，这是很有用的，尽管上游记录的真实历史要大得多。通过给 linkgit:git-clone[1]提供 `--depth` 选项，可以创建一个浅层的仓库，之后可以用 linkgit:git-fetch[1] 深掘它的历史。

note: type: Labeled list
en: [[def_stash]]stash entry
zh_HANS-CN: [[def_stash]]贮藏项

note: type: Plain text
en: An <<def_object,object>> used to temporarily store the contents of a <<def_dirty,dirty>> working directory and the index for future reuse.
zh_HANS-CN: 一个<<def_object,对象>>，用于临时存储<<def_dirty,脏>>工作目录的内容和索引，以便将来重新使用。

note: type: Labeled list
en: [[def_submodule]]submodule
zh_HANS-CN: [[def_submodule]]子模块(submodule)

note: type: Plain text
en: A <<def_repository,repository>> that holds the history of a separate project inside another repository (the latter of which is called <<def_superproject, superproject>>).
zh_HANS-CN: 一个<<def_repository,仓库>>保存着另一个库内的独立项目的历史（后者被称为<<def_superproject, 父工程>>）。

note: type: Labeled list
en: [[def_superproject]]superproject
zh_HANS-CN: [[def_superproject]]父工程(superproject)

note: type: Plain text
en: A <<def_repository,repository>> that references repositories of other projects in its working tree as <<def_submodule,submodules>>.  The superproject knows about the names of (but does not hold copies of) commit objects of the contained submodules.
zh_HANS-CN: 一个<<def_repository,仓库>>在其工作区中引用其他项目的仓库，作为<<def_submodule,子模块>>。  父工程包含子模块的提交对象的名称（但不持有其副本）。

note: type: Labeled list
en: [[def_symref]]symref
zh_HANS-CN: [[def_symref]]符号引用

note: type: Plain text
en: Symbolic reference: instead of containing the <<def_SHA1,SHA-1>> id itself, it is of the format 'ref: refs/some/thing' and when referenced, it recursively dereferences to this reference.  '<<def_HEAD,HEAD>>' is a prime example of a symref. Symbolic references are manipulated with the linkgit:git-symbolic-ref[1] command.
zh_HANS-CN: 符号引用：它不包含<<def_SHA1,SHA-1>>id，而是采用'ref: refs/some/thing'的格式，当被引用时，它会递归到这个引用。'<<def_HEAD,HEAD>>'是一个符号引用的典型例子。符号引用可通过linkgit:git-symbolic-ref[1]命令对其进行操作。

note: type: Labeled list
en: [[def_tag]]tag
zh_HANS-CN: [[def_tag]]标签(tag)

note: type: Plain text
en: A <<def_ref,ref>> under `refs/tags/` namespace that points to an object of an arbitrary type (typically a tag points to either a <<def_tag_object,tag>> or a <<def_commit_object,commit object>>).  In contrast to a <<def_head,head>>, a tag is not updated by the `commit` command. A Git tag has nothing to do with a Lisp tag (which would be called an <<def_object_type,object type>> in Git's context). A tag is most typically used to mark a particular point in the commit ancestry <<def_chain,chain>>.
zh_HANS-CN: 在`refs/tags/`命名空间下的一个<<def_ref,引用>>，指向一个任意类型的对象（通常一个标签指向一个<<def_tag_object,标签>>对象或者一个<<def_commit_object,提交对象>>）。  与<<def_head,head>>标记相比，标签不会被`commit`命令更新。Git的标签与Lisp的标签（在Git的上下文中称为<<def_object_type,对象类型>>）毫无关系。标签最常用的是标记祖先提交中的一个特定<<def_chain,对象链>>。

note: type: Labeled list
en: [[def_tag_object]]tag object
zh_HANS-CN: [[def_tag_object]]标签对象

note: type: Plain text
en: An <<def_object,object>> containing a <<def_ref,ref>> pointing to another object, which can contain a message just like a <<def_commit_object,commit object>>. It can also contain a (PGP)  signature, in which case it is called a "signed tag object".
zh_HANS-CN: 一个<<def_object,对象>>包含一个指向另一个对象的<<def_ref,引用>>，它可以像<<def_commit_object,提交对象>>那样包含一个消息。它也可以包含一个（PGP）签名，这种情况下PGP被称为： "有签名的标签对象"(signed tag object)。

note: type: Labeled list
en: [[def_topic_branch]]topic branch
zh_HANS-CN: [[def_topic_branch]]主题分支

note: type: Plain text
en: A regular Git <<def_branch,branch>> that is used by a developer to identify a conceptual line of development. Since branches are very easy and inexpensive, it is often desirable to have several small branches that each contain very well defined concepts or small incremental yet related changes.
zh_HANS-CN: 一个常规的 Git <<def_branch,分支>>，被开发者用来确定一个概念性的开发路线。由于新建一个分支通常需要很小的代价，所以通常开发中会包含几个小的分支，每个分支都有着非常明确的概念或小的增量但相关的变化。

note: type: Labeled list
en: [[def_tree]]tree
zh_HANS-CN: [[def_tree]]树/目录树(tree)

note: type: Plain text
en: Either a <<def_working_tree,working tree>>, or a <<def_tree_object,tree object>> together with the dependent <<def_blob_object,blob>> and tree objects (i.e. a stored representation of a working tree).
zh_HANS-CN: 要么是一个<<def_working_tree,工作区>>，要么是一个<<def_tree_object,树对象>>连同附属的<<def_blob_object,二进制文件>>对对象和对象树（即一个工作区的存储表示）。

note: type: Labeled list
en: [[def_tree_object]]tree object
zh_HANS-CN: [[def_tree_object]]树对象

note: type: Plain text
en: An <<def_object,object>> containing a list of file names and modes along with refs to the associated blob and/or tree objects. A <<def_tree,tree>> is equivalent to a <<def_directory,directory>>.
zh_HANS-CN: 一个<<def_object,对象>>包含一个文件名和模式的列表，以及相关的二进制文件和/或对象树的引用。一个<<def_tree,树>>等同于一个<<def_directory,目录>>。

note: type: Labeled list
en: [[def_tree-ish]]tree-ish (also treeish)
zh_HANS-CN: [[def_tree-ish]]树状对象[tree-ish (also treeish)]

note: type: Plain text
en: A <<def_tree_object,tree object>> or an <<def_object,object>> that can be recursively dereferenced to a tree object.  Dereferencing a <<def_commit_object,commit object>> yields the tree object corresponding to the <<def_revision,revision>>'s top <<def_directory,directory>>.  The following are all tree-ishes: a <<def_commit-ish,commit-ish>>, a tree object, a <<def_tag_object,tag object>> that points to a tree object, a tag object that points to a tag object that points to a tree object, etc.
zh_HANS-CN: 一个<<def_tree_object,树对象>>或者一个<<def_object,对象>>可以递归推断出一个树状对象。  递归一个<<def_commit_object,提交对象>>可以得到对应于<<def_revision,版本>>的顶层<<def_directory,目录>>树。  以下都是树状对象：<<def_commit-ish,提交号>>、树对象、指向树对象的<<def_tag_object,标签对象>>、指向树对象标签对象的标签对象，等等。

note: type: Labeled list
en: [[def_unmerged_index]]unmerged index
zh_HANS-CN: [[def_unmerged_index]未合并暂存区

note: type: Plain text
en: An <<def_index,index>> which contains unmerged <<def_index_entry,index entries>>.
zh_HANS-CN: 一个<<def_index,暂存区>>，包含未合并的<<def_index_entry,索引项>>。

note: type: Labeled list
en: [[def_unreachable_object]]unreachable object
zh_HANS-CN: [[def_unreachable_object]]不可达对象(unreachable object)

note: type: Plain text
en: An <<def_object,object>> which is not <<def_reachable,reachable>> from a <<def_branch,branch>>, <<def_tag,tag>>, or any other reference.
zh_HANS-CN: 一个从<<def_branch,分支>>、<<def_tag,标签>>或任何其他引用中都不<<def_reachable,可达的>><<def_object,对象>>。

note: type: Labeled list
en: [[def_upstream_branch]]upstream branch
zh_HANS-CN: [[def_upstream_branch]]上游分支

note: type: Plain text
en: The default <<def_branch,branch>> that is merged into the branch in question (or the branch in question is rebased onto). It is configured via branch.<name>.remote and branch.<name>.merge. If the upstream branch of 'A' is 'origin/B' sometimes we say "'A' is tracking 'origin/B'".
zh_HANS-CN: 默认的 <<def_branch,分支>> 会被合并到相关的分支中（或相关的变基(rebase)分支）。它是通过 `branch.<name>.remote` 和 `branch.<name>.merge` 配置的。如果'A'的上游分支是'origin/B'，这有时会称作“'A'正在跟踪'origin/B'”。

note: type: Labeled list
en: [[def_working_tree]]working tree
zh_HANS-CN: [[def_working_tree]]工作区(working tree)

note: type: Plain text
en: The tree of actual checked out files.  The working tree normally contains the contents of the <<def_HEAD,HEAD>> commit's tree, plus any local changes that you have made but not yet committed.
zh_HANS-CN: 实际检查出来的文件树。  工作区通常包含<<def_HEAD,HEAD>>提交树的内容，和一些你已经做了但还没有提交的本地修改。

note: type: Labeled list
en: [[def_worktree]]worktree
zh_HANS-CN: [[def_worktree]]工作树(worktree)

note: type: Plain text
en: A repository can have zero (i.e. bare repository) or one or more worktrees attached to it. One "worktree" consists of a "working tree" and repository metadata, most of which are shared among other worktrees of a single repository, and some of which are maintained separately per worktree (e.g. the index, HEAD and pseudorefs like MERGE_HEAD, per-worktree refs and per-worktree configuration file).
zh_HANS-CN: 一个仓库可以没有（即裸仓库），也可以有一个或多个工作树附属于它。一个 “工作树 ”由 “工作区”和版本库元数据组成，其中大部分元数据在单个仓库的其他工作树中共享，有些元数据在每个工作树中单独维护（例如：索引、HEAD 和像MERGE_HEAD这样的伪引用 、每个工作树索引件和每个工作树）。

note: type: Plain text
en: Git is to some extent character encoding agnostic.
zh_HANS-CN: Git在某种程度上是与字符编码无关的。

note: type: Plain text
en: The contents of the blob objects are uninterpreted sequences of bytes.  There is no encoding translation at the core level.
zh_HANS-CN: blob对象的内容是未经解释的字节序列。  在核心层没有编码转换。

note: type: Plain text
en: Path names are encoded in UTF-8 normalization form C. This applies to tree objects, the index file, ref names, as well as path names in command line arguments, environment variables and config files (`.git/config` (see linkgit:git-config[1]), linkgit:gitignore[5], linkgit:gitattributes[5] and linkgit:gitmodules[5]).
zh_HANS-CN: 路径名以UTF-8规范化形式C编码，这适用于树对象、索引文件、参考名称，以及命令行参数、环境变量和配置文件（`.git/config`（见linkgit:git-config[1]），linkgit:gitignore[5]，linkgit:gitattributes[5] 和linkgit:gitmodules[5]）中的路径名。

note: type: Plain text
en: Note that Git at the core level treats path names simply as sequences of non-NUL bytes, there are no path name encoding conversions (except on Mac and Windows). Therefore, using non-ASCII path names will mostly work even on platforms and file systems that use legacy extended ASCII encodings. However, repositories created on such systems will not work properly on UTF-8-based systems (e.g. Linux, Mac, Windows) and vice versa.  Additionally, many Git-based tools simply assume path names to be UTF-8 and will fail to display other encodings correctly.
zh_HANS-CN: 请注意，Git 在核心层将路径名简单地视为非 NUL 字节的序列，没有路径名编码的转换（除了 Mac 和 Windows）。因此，即使在使用传统的扩展ASCII编码的平台和文件系统上，使用非ASCII的路径名大多也能工作。然而，在这种系统上创建的仓库在基于UTF-8的系统（如Linux、Mac、Windows）上将无法正常工作，反之亦然。  此外，许多基于Git的工具简单地认为路径名称是UTF-8，而不能正确显示其他编码。

note: type: Plain text
en: Commit log messages are typically encoded in UTF-8, but other extended ASCII encodings are also supported. This includes ISO-8859-x, CP125x and many others, but _not_ UTF-16/32, EBCDIC and CJK multi-byte encodings (GBK, Shift-JIS, Big5, EUC-x, CP9xx etc.).
zh_HANS-CN: 提交日志信息通常以UTF-8编码，但也支持其他扩展ASCII编码。这包括ISO-8859-x、CP125x和其他许多编码，但不包括UTF-16/32、EBCDIC和CJK多字节编码（GBK、Shift-JIS、Big5、EUC-x、CP9xx等）。

note: type: Plain text
en: Although we encourage that the commit log messages are encoded in UTF-8, both the core and Git Porcelain are designed not to force UTF-8 on projects.  If all participants of a particular project find it more convenient to use legacy encodings, Git does not forbid it.  However, there are a few things to keep in mind.
zh_HANS-CN: 尽管我们鼓励提交日志信息使用UTF-8编码，但核心系统和Git Porcelain的设计并不强制要求项目使用UTF-8。  如果某个项目的所有参与者都认为使用传统编码更方便，Git也不会禁止。  然而，有几件事需要注意。

note: type: Plain text
en: 'git commit' and 'git commit-tree' issues a warning if the commit log message given to it does not look like a valid UTF-8 string, unless you explicitly say your project uses a legacy encoding.  The way to say this is to have `i18n.commitEncoding` in `.git/config` file, like this:
zh_HANS-CN: git commit "和 "git commit-tree "如果收到的提交日志信息不像是有效的UTF-8字符串，就会发出警告，除非你明确表示你的项目使用的是传统编码。  说这个的方法是在`.git/config`文件中设置`i18n.commitEncoding`，像这样。

note: type: Plain text
en: Commit objects created with the above setting record the value of `i18n.commitEncoding` in its `encoding` header.  This is to help other people who look at them later.  Lack of this header implies that the commit log message is encoded in UTF-8.
zh_HANS-CN: 用上述设置创建的提交对象在其`encoding`头中记录了`i18n.commitEncoding`的值。  这是为了帮助以后看这些对象的人。  缺少这个头意味着提交日志信息是以UTF-8编码的。

note: type: Plain text
en: If you do not have this configuration variable, the value of `i18n.commitEncoding` is used instead.
zh_HANS-CN: 如果你没有这个配置变量，则使用`i18n.commitEncoding`的值来代替。

note: type: Plain text
en: Note that we deliberately chose not to re-code the commit log message when a commit is made to force UTF-8 at the commit object level, because re-coding to UTF-8 is not necessarily a reversible operation.
zh_HANS-CN: 请注意，我们特意选择在提交对象层面上，不对提交日志信息进行重新编码，因为重新编码为UTF-8不一定是一个可逆的操作。

note: type: Plain text
en: Everything below this line in this section is selectively included from the linkgit:git-config[1] documentation. The content is the same as what's found there:
zh_HANS-CN: 本节中这一行以下的内容都是从 linkgit:git-config[1] 文档中摘录的。其内容与那里的内容相同：

note: type: Plain text
en: Everything above this line in this section isn't included from the linkgit:git-config[1] documentation. The content that follows is the same as what's found there:
zh_HANS-CN: 本节中这一行以上的内容并不包括在 linkgit:git-config[1] 文档中。下面的内容与那里的内容相同：

note: type: Plain text
en: '<start>' and '<end>' can take one of these forms:
zh_HANS-CN: '<开始>'和'<结束>'可以采取这些形式之一。

note: type: Plain text
en: If '<start>' or '<end>' is a number, it specifies an absolute line number (lines count from 1).
zh_HANS-CN: 如果'<开始>'或'<结束>'是一个数字，它指定了一个绝对行数（行数从1开始计算）。

note: type: Plain text
en: This form will use the first line matching the given POSIX regex. If '<start>' is a regex, it will search from the end of the previous `-L` range, if any, otherwise from the start of file.  If '<start>' is `^/regex/`, it will search from the start of file.  If '<end>' is a regex, it will search starting at the line given by '<start>'.
zh_HANS-CN: 这种形式将使用与给定的POSIX regex匹配的第一行。如果'<start>'是一个重词，它将从前一个`-L'范围的末尾开始搜索，如果有的话，则从文件的开始。  如果'<start>'是`^/regex/`，它将从文件的开始搜索。  如果'<end>'是一个regex，它将从'<start>'所给的行开始搜索。

note: type: Plain text
en: +offset or -offset
zh_HANS-CN: +offset或-offset

note: type: Plain text
en: This is only valid for '<end>' and will specify a number of lines before or after the line given by '<start>'.
zh_HANS-CN: 这只对'<end>'有效，将指定'<start>'所给的行前或行后的数量。

note: type: Plain text
en: If `:<funcname>` is given in place of '<start>' and '<end>', it is a regular expression that denotes the range from the first funcname line that matches '<funcname>', up to the next funcname line. `:<funcname>` searches from the end of the previous `-L` range, if any, otherwise from the start of file. `^:<funcname>` searches from the start of file. The function names are determined in the same way as `git diff` works out patch hunk headers (see 'Defining a custom hunk-header' in linkgit:gitattributes[5]).
zh_HANS-CN: 如果`:<funcname>`代替了'<start>'和'<end>'，它是一个正则表达式，表示从第一个匹配'<funcname>'的funcname行开始，直到下一个funcname行的范围。`:<funcname>`从上一个`-L'范围的末尾开始搜索，如果有的话，则从文件的开始搜索。`^:<funcname>`从文件的开始搜索。函数名的确定方式与 `git diff`确定补丁组头的方式相同（见 linkgit:gitattributes[5] 中的'定义自定义组头'）。

note: type: Plain text
en: Trace the evolution of the line range given by '<start>,<end>', or by the function name regex '<funcname>', within the '<file>'. You may not give any pathspec limiters.  This is currently limited to a walk starting from a single revision, i.e., you may only give zero or one positive revision arguments, and '<start>' and '<end>' (or '<funcname>') must exist in the starting revision.  You can specify this option more than once. Implies `--patch`.  Patch output can be suppressed using `--no-patch`, but other diff formats (namely `--raw`, `--numstat`, `--shortstat`, `--dirstat`, `--summary`, `--name-only`, `--name-status`, `--check`) are not currently implemented.
zh_HANS-CN: 追踪由'<start>,<end>'给出的行的范围，或由函数名称重合词'<funcname>'给出的行的演变，在'<file>'中。你不能给出任何pathspec限制条件。  目前这只限于从一个修订版开始的行走，也就是说，你只能给出零或一个正的修订版参数，而且'<start>'和'<end>'（或'<funcname>'）必须存在于起始修订版中。  你可以多次指定这个选项。  补丁输出可以用`--no-patch`来抑制，但其他差异格式（即`--raw`、`-numstat`、`-shortstat`、`-dirstat`、`-summary`、`-name-only`、`-name-status`、`-check`）目前没有实现。

note: type: Plain text
en: Perform the merge and commit the result. This option can be used to override --no-commit.
zh_HANS-CN: 执行合并并提交结果。这个选项可以用来覆盖 --no-commit。

note: type: Plain text
en: 	Only useful when merging.
zh_HANS-CN: 	只有在合并的时候才有用。

note: type: Plain text
en: With --no-commit perform the merge and stop just before creating a merge commit, to give the user a chance to inspect and further tweak the merge result before committing.
zh_HANS-CN: 用 --no-commit 来执行合并，并在创建合并提交前停止，以便让用户有机会在提交前检查和进一步调整合并结果。

note: type: Plain text
en: Note that fast-forward updates do not create a merge commit and therefore there is no way to stop those merges with --no-commit.  Thus, if you want to ensure your branch is not changed or updated by the merge command, use --no-ff with --no-commit.
zh_HANS-CN: 请注意，快进更新并不产生合并提交，因此没有办法用 --no-commit 停止这些合并。  因此，如果你想确保你的分支不被合并命令改变或更新，请一起使用 --no-ff 和 --no-commit选项。

note: type: Plain text
en: Invoke an editor before committing successful mechanical merge to further edit the auto-generated merge message, so that the user can explain and justify the merge. The `--no-edit` option can be used to accept the auto-generated message (this is generally discouraged).
zh_HANS-CN: 在提交成功的机械合并之前，调用一个编辑器来进一步编辑自动生成的合并信息，以便用户可以解释和证明合并的合理性。可以使用`--no-edit`选项来接受自动生成的信息（但是不鼓励亲这么做）。

note: type: Plain text
en: The `--edit` (or `-e`) option is still useful if you are giving a draft message with the `-m` option from the command line and want to edit it in the editor.
zh_HANS-CN: 如果你在命令行中用`-m`选项给出一个草稿信息，并想在编辑器中编辑它，`--edit`（或`-e`）选项仍然有用。

note: type: Plain text
en: Older scripts may depend on the historical behaviour of not allowing the user to edit the merge log message. They will see an editor opened when they run `git merge`. To make it easier to adjust such scripts to the updated behaviour, the environment variable `GIT_MERGE_AUTOEDIT` can be set to `no` at the beginning of them.
zh_HANS-CN: 旧的脚本可能依赖于不允许用户编辑合并日志信息的历史行为。他们会在运行`git merge`时看到一个编辑器被打开。为了使这些脚本更容易调整到最新的行为，可以在脚本的开头将环境变量`GIT_MERGE_AUTOEDIT`设置为`no`。

note: type: Plain text
en: This option determines how the merge message will be cleaned up before committing. See linkgit:git-commit[1] for more details. In addition, if the '<mode>' is given a value of `scissors`, scissors will be appended to `MERGE_MSG` before being passed on to the commit machinery in the case of a merge conflict.
zh_HANS-CN: 这个选项决定了在提交前如何清理合并信息。更多细节见linkgit:git-commit[1]。此外，如果`<模式>`的值为 `scissors`，在发生合并冲突时，scissors将被附加到 "MERGE_MSG "上，然后传递给提交机制。

note: type: Plain text
en: Specifies how a merge is handled when the merged-in history is already a descendant of the current history.  `--ff` is the default unless merging an annotated (and possibly signed) tag that is not stored in its natural place in the `refs/tags/` hierarchy, in which case `--no-ff` is assumed.
zh_HANS-CN: 指定当被合并的历史已经是当前历史的后代时，如何处理合并的问题。  默认为`--ff`，除非合并的是一个有注释的（可能是有签名的）标签，在这种情况下，`--no-ff`假设这个标签并没有存储在`refs/tags/`层次结构中的自然位置。

note: type: Plain text
en: Only update to the new history if there is no divergent local history.  This is the default when no method for reconciling divergent histories is provided (via the --rebase=* flags).
zh_HANS-CN: 只有在没有分歧的本地历史时才更新到新的历史。  当没有提供调和分歧历史的方法时（通过--rebase=*标志），这是默认的。

note: type: Plain text
en: When merging rather than rebasing, specifies how a merge is handled when the merged-in history is already a descendant of the current history.  If merging is requested, `--ff` is the default unless merging an annotated (and possibly signed) tag that is not stored in its natural place in the `refs/tags/` hierarchy, in which case `--no-ff` is assumed.
zh_HANS-CN: 当合并而不是变基时，指定当被合并的历史已经是当前历史的后代时如何处理合并。  如果要求合并，`--ff`是默认的，除非合并的是一个有注释的（可能是有签名的）标签，而这个标签没有存储在`refs/tags/`层次结构中的自然位置，在这种情况下，假定`--no-ff`。

note: type: Plain text
en: With `--ff`, when possible resolve the merge as a fast-forward (only update the branch pointer to match the merged branch; do not create a merge commit).  When not possible (when the merged-in history is not a descendant of the current history), create a merge commit.
zh_HANS-CN: 如果使用 `--ff`，可能的话，以快进方式解决合并问题（只更新分支指针以匹配合并后的分支；不创建合并提交）。  当不可能时（当合并的历史不是当前历史的后代），创建一个合并提交。

note: type: Plain text
en: With `--no-ff`, create a merge commit in all cases, even when the merge could instead be resolved as a fast-forward.
zh_HANS-CN: 使用`--no-ff`，在所有情况下都创建一个合并提交，即使该合并可以作为一个快进解决。

note: type: Plain text
en: With `--ff-only`, resolve the merge as a fast-forward when possible.  When not possible, refuse to merge and exit with a non-zero status.
zh_HANS-CN: 使用`--ff-only`，在可能的情况下，以快进的方式解决合并的问题。  当不可能时，拒绝合并并以非零状态退出。

note: type: Plain text
en: GPG-sign the resulting merge commit. The `keyid` argument is optional and defaults to the committer identity; if specified, it must be stuck to the option without a space. `--no-gpg-sign` is useful to countermand both `commit.gpgSign` configuration variable, and earlier `--gpg-sign`.
zh_HANS-CN: 对合并后的提交进行 GPG 签名。`keyid` 参数是可选的，默认为提交者的身份；如果指定，它必须与选项连在一起，不能有空格。`--no-gpg-sign` 对于反命令 `commit.gpgSign` 配置变量和早期的 `--gpg-sign` 都很有用。

note: type: Plain text
en: In addition to branch names, populate the log message with one-line descriptions from at most <n> actual commits that are being merged. See also linkgit:git-fmt-merge-msg[1].
zh_HANS-CN: 除了分支名称外，在日志信息中最多只用<n>个正在合并的实际提交的单行描述来填充。参见 linkgit:git-fmt-merge-msg[1]。

note: type: Plain text
en: With --no-log do not list one-line descriptions from the actual commits being merged.
zh_HANS-CN: 如果使用 --no-log，则不列出被合并的实际提交内容的单行描述。

note: type: Plain text
en: Show a diffstat at the end of the merge. The diffstat is also controlled by the configuration option merge.stat.
zh_HANS-CN: 在合并结束时显示一个差异状态。差异状态也由配置选项merge.stat控制。

note: type: Plain text
en: With -n or --no-stat do not show a diffstat at the end of the merge.
zh_HANS-CN: 使用-n或--no-stat，在合并结束时不显示差异状态。

note: type: Plain text
en: Produce the working tree and index state as if a real merge happened (except for the merge information), but do not actually make a commit, move the `HEAD`, or record `$GIT_DIR/MERGE_HEAD` (to cause the next `git commit` command to create a merge commit).  This allows you to create a single commit on top of the current branch whose effect is the same as merging another branch (or more in case of an octopus).
zh_HANS-CN: 产生工作区和索引状态，就像发生了真正的合并一样（除了合并信息），但不实际提交，不移动`HEAD`，也不记录`$GIT_DIR/Merge_HEAD`（以导致下一个`git commit`命令创建一个合并提交）。  这允许你在当前分支的基础上创建一个单一的提交，其效果与合并另一个分支相同（如果是多路分支，则更多）。

note: type: Plain text
en: With --no-squash perform the merge and commit the result. This option can be used to override --squash.
zh_HANS-CN: 使用 --no-squash 进行合并并提交结果。这个选项可以用来覆盖 --quash 选项。

note: type: Plain text
en: With --squash, --commit is not allowed, and will fail.
zh_HANS-CN: 使用 --squash，--commit 是不允许的，而且会失败。

note: type: Plain text
en: Only useful when merging.
zh_HANS-CN: 只有在合并的时候才有用。

note: type: Plain text
en: By default, the pre-merge and commit-msg hooks are run.  When `--no-verify` is given, these are bypassed.  See also linkgit:githooks[5].
zh_HANS-CN: 默认情况下，会运行 pre-merge 和 commit-msg 事件hook。  当给定 `--no-verify`时，这些将不会执行。  参见 linkgit:githooks[5]。

note: type: Plain text
en: Use the given merge strategy; can be supplied more than once to specify them in the order they should be tried.  If there is no `-s` option, a built-in list of strategies is used instead (`ort` when merging a single head, `octopus` otherwise).
zh_HANS-CN: 使用给定的合并策略；可以多次提供，以指定它们应该被尝试的顺序。  如果没有`-s`选项，则使用一个内置的策略列表（当合并单个头时使用`ort`，否则使用`octopus`）。

note: type: Labeled list
en: -X <option>
zh_HANS-CN: -X <选项>

note: type: Plain text
en: Pass merge strategy specific option through to the merge strategy.
zh_HANS-CN: 将合并策略的特定选项传递给合并策略。

note: type: Plain text
en: Verify that the tip commit of the side branch being merged is signed with a valid key, i.e. a key that has a valid uid: in the default trust model, this means the signing key has been signed by a trusted key.  If the tip commit of the side branch is not signed with a valid key, the merge is aborted.
zh_HANS-CN: 验证被合并的侧边分支的提示提交是否用有效的密钥签署，即一个具有有效uid的密钥：在默认的信任模型中，这意味着签署密钥是由一个受信任的密钥签署。  如果侧边分支的提示提交没有用有效的密钥签名，则合并被终止。

note: type: Plain text
en: Synonyms to --stat and --no-stat; these are deprecated and will be removed in the future.
zh_HANS-CN: 与 --stat 和 --no-stat 同义；这些都弃用了，将来会被删除。

note: type: Plain text
en: Operate quietly. Implies --no-progress.
zh_HANS-CN: 安静地操作。暗指 --no-progress。

note: type: Plain text
en: Turn progress on/off explicitly. If neither is specified, progress is shown if standard error is connected to a terminal.  Note that not all merge strategies may support progress reporting.
zh_HANS-CN: 明确地打开/关闭进度。如果两者都没有指定，如果标准错误连接到终端，就会显示进度。  注意，并非所有的合并策略都支持进度报告。

note: type: Plain text
en: By default, `git merge` command refuses to merge histories that do not share a common ancestor.  This option can be used to override this safety when merging histories of two projects that started their lives independently. As that is a very rare occasion, no configuration variable to enable this by default exists and will not be added.
zh_HANS-CN: 默认情况下，`git merge`命令拒绝合并那些没有共同祖先的历史。  当合并两个独立开始的项目的历史时，这个选项可以用来覆盖这个安全性。由于这是一个非常罕见的情况，没有配置变量来默认启用，也不会被添加。

note: type: Title -
en: MERGE STRATEGIES
zh_HANS-CN: 合并战略

note: type: Plain text
en: The merge mechanism (`git merge` and `git pull` commands) allows the backend 'merge strategies' to be chosen with `-s` option.  Some strategies can also take their own options, which can be passed by giving `-X<option>` arguments to `git merge` and/or `git pull`.
zh_HANS-CN: 合并机制（`git merge`和`git pull`命令）允许用`s`选项来选择后端'合并策略'。  一些策略也可以采取自己的选项，可以通过给`git merge`和/或`git pull`的`-X<选项>`参数来传递。

note: type: Plain text
en: This is the default merge strategy when pulling or merging one branch.  This strategy can only resolve two heads using a 3-way merge algorithm.  When there is more than one common ancestor that can be used for 3-way merge, it creates a merged tree of the common ancestors and uses that as the reference tree for the 3-way merge.  This has been reported to result in fewer merge conflicts without causing mismerges by tests done on actual merge commits taken from Linux 2.6 kernel development history.  Additionally this strategy can detect and handle merges involving renames.  It does not make use of detected copies.  The name for this algorithm is an acronym ("Ostensibly Recursive's Twin") and came from the fact that it was written as a replacement for the previous default algorithm, `recursive`.
zh_HANS-CN: 这是拉取或合并一个分支时的默认合并策略。  这个策略只能使用三方合并算法解决两个头。  当有一个以上的共同祖先可用于三方合并时，它会创建一个共同祖先的合并树，并将其作为三方合并的参考树。  据报道，通过对Linux 2.6内核开发历史中的实际合并提交的测试，这导致了较少的合并冲突，而不会引起错误的合并。  此外，这个策略可以检测并处理涉及重命名的合并。  它并不使用检测到的副本。  这个算法的名字是一个缩写（"Ostensibly Recursive's Twin"），来自于它是作为以前的默认算法`recursive`的替代而编写的。

note: type: Plain text
en: The 'ort' strategy can take the following options:
zh_HANS-CN: 'ort' 策略可以采取以下选项：

note: type: Plain text
en: This option forces conflicting hunks to be auto-resolved cleanly by favoring 'our' version.  Changes from the other tree that do not conflict with our side are reflected in the merge result.  For a binary file, the entire contents are taken from our side.
zh_HANS-CN: 这个选项通过倾向于 "我们" 的版本，迫使冲突的猎物被自动解决。  另一棵目录树上与我们这边不冲突的变化会反映在合并结果中。  对于一个二进制文件，整个内容都来自我们这边。

note: type: Plain text
en: This should not be confused with the 'ours' merge strategy, which does not even look at what the other tree contains at all.  It discards everything the other tree did, declaring 'our' history contains all that happened in it.
zh_HANS-CN: 这不应该与 "我们的" 合并策略相混淆，后者甚至根本不看另一棵目录树包含了什么。  它抛弃了其他树所做的一切，宣布 "我们的" 历史包含了其中所发生的一切。

note: type: Plain text
en: This is the opposite of 'ours'; note that, unlike 'ours', there is no 'theirs' merge strategy to confuse this merge option with.
zh_HANS-CN: 这与 "我们的" 相反；注意，与 "我们的" 不同，没有 "他们的" 合并策略来混淆这个合并选项。

note: type: Plain text
en: Treats lines with the indicated type of whitespace change as unchanged for the sake of a three-way merge.  Whitespace changes mixed with other changes to a line are not ignored.  See also linkgit:git-diff[1] `-b`, `-w`, `--ignore-space-at-eol`, and `--ignore-cr-at-eol`.
zh_HANS-CN: 为了进行三方合并，将具有指定类型的空白变化的行视为没有变化。  但混合了其他改动的行的空白改动不会被忽略。  参见linkgit:git-diff[1] `-b`, `-w`, `-ignore-space-at-eol`, 和 `-ignore-cr-at-eol`。

note: type: Plain text
en: If 'their' version only introduces whitespace changes to a line, 'our' version is used;
zh_HANS-CN: 如果 "他们的" 版本只在一行中引入了空白的变化，则使用 "我们的" 版本；

note: type: Plain text
en: If 'our' version introduces whitespace changes but 'their' version includes a substantial change, 'their' version is used;
zh_HANS-CN: 如果 "我们的" 版本引入了空白的变化，但 "他们的" 版本包括一个实质性的变化，则使用 "他们的" 版本;

note: type: Plain text
en: Otherwise, the merge proceeds in the usual way.
zh_HANS-CN: 否则，合并将以常规方式进行。

note: type: Plain text
en: This runs a virtual check-out and check-in of all three stages of a file when resolving a three-way merge.  This option is meant to be used when merging branches with different clean filters or end-of-line normalization rules.  See "Merging branches with differing checkin/checkout attributes" in linkgit:gitattributes[5] for details.
zh_HANS-CN: 在解决三方合并时，这将对一个文件的所有三个阶段运行虚拟检出和检入。  这个选项是为了在合并具有不同清洁过滤器或行末规范化规则的分支时使用。  详情见 linkgit:gitattributes[5] 中的 "合并具有不同检入/检出属性的分支"。

note: type: Plain text
en: Disables the `renormalize` option.  This overrides the `merge.renormalize` configuration variable.
zh_HANS-CN: 禁用 `renormalize` 选项。  这覆盖了 `merge.renormalize` 配置变量。

note: type: Plain text
en: Turn on rename detection, optionally setting the similarity threshold.  This is the default. This overrides the 'merge.renames' configuration variable.  See also linkgit:git-diff[1] `--find-renames`.
zh_HANS-CN: 开启重名检测，可选择设置相似度阈值。  这是默认的。这覆盖了 'merge.renames' 配置变量。  参见linkgit:git-diff[1] `--find-renames`。

note: type: Plain text
en: Deprecated synonym for `find-renames=<n>`.
zh_HANS-CN: 废弃的，`find-renames=<n>` 的同义词。

note: type: Labeled list
en: subtree[=<path>]
zh_HANS-CN: subtree[=<路径>]

note: type: Plain text
en: This option is a more advanced form of 'subtree' strategy, where the strategy makes a guess on how two trees must be shifted to match with each other when merging.  Instead, the specified path is prefixed (or stripped from the beginning) to make the shape of two trees to match.
zh_HANS-CN: 这个选项是 '子树' 策略的更高级形式，该策略对两棵树在合并时必须如何移位以相互匹配进行猜测。  相反，指定的路径是前缀（或从开始剥离），以使两棵树的形状相匹配。

note: type: Plain text
en: This can only resolve two heads using a 3-way merge algorithm.  When there is more than one common ancestor that can be used for 3-way merge, it creates a merged tree of the common ancestors and uses that as the reference tree for the 3-way merge.  This has been reported to result in fewer merge conflicts without causing mismerges by tests done on actual merge commits taken from Linux 2.6 kernel development history.  Additionally this can detect and handle merges involving renames.  It does not make use of detected copies.  This was the default strategy for resolving two heads from Git v0.99.9k until v2.33.0.
zh_HANS-CN: 这只能用三方合并算法解决两个头。  当有一个以上的共同祖先可用于三方合并时，它会创建一个共同祖先的合并树，并使用它作为三方合并的参考树。  据报道，通过对Linux 2.6内核开发历史中的实际合并提交的测试，这导致了较少的合并冲突，而不会引起错误的合并。  此外，它可以检测并处理涉及重命名的合并。  它并不使用检测到的副本。  从Git v0.99.9k到v2.33.0，这是解决双头的默认策略。

note: type: Plain text
en: The 'recursive' strategy takes the same options as 'ort'.  However, there are three additional options that 'ort' ignores (not documented above) that are potentially useful with the 'recursive' strategy:
zh_HANS-CN: 'recursive'  策略采用与 'ort' 相同的选项。  然而，有三个 'ort' 忽略的额外选项（上面没有记录），对 'recursive' 策略有潜在的作用：

note: type: Plain text
en: Deprecated synonym for `diff-algorithm=patience`.
zh_HANS-CN: 废弃的，`diff-algorithm=patience` 的同义词。

note: type: Plain text
en: Use a different diff algorithm while merging, which can help avoid mismerges that occur due to unimportant matching lines (such as braces from distinct functions).  See also linkgit:git-diff[1] `--diff-algorithm`.  Note that `ort` specifically uses `diff-algorithm=histogram`, while `recursive` defaults to the `diff.algorithm` config setting.
zh_HANS-CN: 在合并时使用不同的差异算法，这可以帮助避免由于不重要的匹配行（比如不同函数的大括号）而发生的错误合并。  参见linkgit:git-diff[1] `--diff-algorithm`。  注意，`ort` 特定 `diff-algorithm=histogram`，而`recursive`默认为`diff.algorithm`配置设置。

note: type: Plain text
en: Turn off rename detection. This overrides the `merge.renames` configuration variable.  See also linkgit:git-diff[1] `--no-renames`.
zh_HANS-CN: 关闭重名检测。这覆盖了 `merge.renames` 的配置变量。  参见linkgit:git-diff[1] `--no-renames`。

note: type: Plain text
en: This can only resolve two heads (i.e. the current branch and another branch you pulled from) using a 3-way merge algorithm.  It tries to carefully detect criss-cross merge ambiguities.  It does not handle renames.
zh_HANS-CN: 这只能用三方合并算法解决两个头（即当前分支和你拉来的另一个分支）。  它试图仔细检测纵横交错的合并歧义。  它不处理重名。

note: type: Plain text
en: This resolves cases with more than two heads, but refuses to do a complex merge that needs manual resolution.  It is primarily meant to be used for bundling topic branch heads together.  This is the default merge strategy when pulling or merging more than one branch.
zh_HANS-CN: 这可以解决有两个以上头的情况，但拒绝做复杂的合并，需要手动解决。  它主要是用于将主题分支头捆绑在一起。  当拉动或合并一个以上的分支时，这是默认的合并策略。

note: type: Plain text
en: This resolves any number of heads, but the resulting tree of the merge is always that of the current branch head, effectively ignoring all changes from all other branches.  It is meant to be used to supersede old development history of side branches.  Note that this is different from the -Xours option to the 'recursive' merge strategy.
zh_HANS-CN: 这可以解决任何数量的头，但合并的结果总是当前分支头的树，有效地忽略了所有其他分支的变化。  它是用来取代侧边分支的旧开发历史的。  注意，这与 'recursive' 合并策略的-Xours选项不同。

note: type: Plain text
en: This is a modified `ort` strategy. When merging trees A and B, if B corresponds to a subtree of A, B is first adjusted to match the tree structure of A, instead of reading the trees at the same level. This adjustment is also done to the common ancestor tree.
zh_HANS-CN: 这是一个修正的 `ort` 策略。当合并树A和B时，如果B对应于A的子树，B首先被调整为与A的树结构相匹配，而不是在同一级别读取树。这种调整也是针对共同祖先树进行的。

note: type: Plain text
en: With the strategies that use 3-way merge (including the default, 'ort'), if a change is made on both branches, but later reverted on one of the branches, that change will be present in the merged result; some people find this behavior confusing.  It occurs because only the heads and the merge base are considered when performing a merge, not the individual commits.  The merge algorithm therefore considers the reverted change as no change at all, and substitutes the changed version instead.
zh_HANS-CN: 对于使用三方合并的策略（包括默认的 'ort' 策略），如果在两个分支上都做了修改，但后来在其中一个分支上被撤销，那么这个修改就会出现在合并后的结果中；有些人觉得这种行为令人困惑。  出现这种情况是因为在执行合并时只考虑头部和合并基数，而不是单个提交。  因此，合并算法认为被恢复的修改根本就没有变化，而是用被修改的版本来代替。

note: type: Plain text
en: Use Araxis Merge (requires a graphical session)
zh_HANS-CN: 使用 Araxis 合并（需要图形会话）

note: type: Plain text
en: Use Beyond Compare (requires a graphical session)
zh_HANS-CN: 使用 Beyond Compare（需要图形会话）

note: type: Plain text
en: Use Code Compare (requires a graphical session)
zh_HANS-CN: 使用代码比较（需要图形会话）

note: type: Plain text
en: Use DeltaWalker (requires a graphical session)
zh_HANS-CN: 使用 DeltaWalker（需要图形会话）

note: type: Plain text
en: Use DiffMerge (requires a graphical session)
zh_HANS-CN: 使用 DiffMerge（需要图形会话）

note: type: Plain text
en: Use Diffuse (requires a graphical session)
zh_HANS-CN: 使用 Diffuse（需要图形会话）

note: type: Plain text
en: Use ECMerge (requires a graphical session)
zh_HANS-CN: 使用 ECMerge（需要图形会话）

note: type: Plain text
en: Use Emacs' Emerge
zh_HANS-CN: 使用 Emacs 的 Emerge

note: type: Plain text
en: Use ExamDiff Pro (requires a graphical session)
zh_HANS-CN: 使用 ExamDiff Pro（需要图形会话）

note: type: Plain text
en: Use Guiffy's Diff Tool (requires a graphical session)
zh_HANS-CN: 使用 Guiffy 的 Diff 工具（需要图形会话）

note: type: Plain text
en: Use gVim (requires a graphical session) with a custom layout (see `git help mergetool`'s `BACKEND SPECIFIC HINTS` section)
zh_HANS-CN: 使用 gVim（需要图形会话）和自定义布局（参见 `git help mergetool` 的 `BACKEND SPECIFIC HINTS` 部分）

note: type: Plain text
en: Use gVim (requires a graphical session) with a 2 panes layout (LOCAL and REMOTE)
zh_HANS-CN: 使用 gVim（需要图形会话），采用双窗格布局（本地和远程）

note: type: Plain text
en: Use gVim (requires a graphical session) with a 3 panes layout (LOCAL, MERGED and REMOTE)
zh_HANS-CN: 使用 gVim（需要图形会话），采用 3 个面板布局（本地、合并和远程）

note: type: Plain text
en: Use gVim (requires a graphical session) where only the MERGED file is shown
zh_HANS-CN: 使用 gVim（需要图形会话），只显示 MERGED 文件

note: type: Plain text
en: Use KDiff3 (requires a graphical session)
zh_HANS-CN: 使用 KDiff3（需要图形会话）

note: type: Plain text
en: Use Meld (requires a graphical session) with optional `auto merge` (see `git help mergetool`'s `CONFIGURATION` section)
zh_HANS-CN: 使用带可选 `auto merge` 功能的 Meld（需要图形会话）（请参阅 `git help mergetool` 的 `配置` 部分）

note: type: Plain text
en: Use Neovim with a custom layout (see `git help mergetool`'s `BACKEND SPECIFIC HINTS` section)
zh_HANS-CN: 使用带有自定义布局的 Neovim（请参阅 `git help mergetool` 的 `BACKEND SPECIFIC HINTS` 部分）

note: type: Plain text
en: Use Neovim with a 2 panes layout (LOCAL and REMOTE)
zh_HANS-CN: 使用 Neovim 的双窗格布局（本地和远程）

note: type: Plain text
en: Use Neovim with a 3 panes layout (LOCAL, MERGED and REMOTE)
zh_HANS-CN: 使用 Neovim 的 3 个面板布局（本地、合并和远程）

note: type: Plain text
en: Use Neovim where only the MERGED file is shown
zh_HANS-CN: 使用 Neovim，只显示合并文件

note: type: Plain text
en: Use FileMerge (requires a graphical session)
zh_HANS-CN: 使用文件合并（需要图形会话）

note: type: Plain text
en: Use HelixCore P4Merge (requires a graphical session)
zh_HANS-CN: 使用 HelixCore P4Merge（需要图形会话）

note: type: Plain text
en: Use Sublime Merge (requires a graphical session)
zh_HANS-CN: 使用 Sublime Merge（需要图形会话）

note: type: Plain text
en: Use TkDiff (requires a graphical session)
zh_HANS-CN: 使用 TkDiff（需要图形会话）

note: type: Plain text
en: Use TortoiseMerge (requires a graphical session)
zh_HANS-CN: 使用 TortoiseMerge（需要图形会话）

note: type: Plain text
en: Use Vim with a custom layout (see `git help mergetool`'s `BACKEND SPECIFIC HINTS` section)
zh_HANS-CN: 使用自定义布局的 Vim（请参阅 `git help mergetool` 的 `后端特定提示` 部分）

note: type: Plain text
en: Use Vim with a 2 panes layout (LOCAL and REMOTE)
zh_HANS-CN: 使用双窗格布局（本地和远程）的 Vim

note: type: Plain text
en: Use Vim with a 3 panes layout (LOCAL, MERGED and REMOTE)
zh_HANS-CN: 使用 Vim 的 3 个面板布局（本地、合并和远程）

note: type: Plain text
en: Use Vim where only the MERGED file is shown
zh_HANS-CN: 使用 Vim，只显示合并后的文件

note: type: Plain text
en: Use WinMerge (requires a graphical session)
zh_HANS-CN: 使用 WinMerge（需要图形会话）

note: type: Plain text
en: Use xxdiff (requires a graphical session)
zh_HANS-CN: 使用 xxdiff（需要图形会话）

note: type: Plain text
en: THIS OPTION IS EXPERIMENTAL! SHA-256 support is experimental and still in an early stage.  A SHA-256 repository will in general not be able to share work with "regular" SHA-1 repositories.  It should be assumed that, e.g., Git internal file formats in relation to SHA-256 repositories may change in backwards-incompatible ways.  Only use `--object-format=sha256` for testing purposes.
zh_HANS-CN: 此选项是实验性的！SHA-256 支持是实验性的，仍然处于早期阶段。一般来说，SHA-256 仓库不能与 "常规" SHA-1 仓库共同工作。应该假定，例如，与 SHA-256 仓库有关的 Git 内部文件格式可能会以向后不兼容的方式改变。仅在测试时使用 `--object-format=sha256` 选项。

note: type: Title -
en: PRETTY FORMATS
zh_HANS-CN: 漂亮的格式

note: type: Plain text
en: If the commit is a merge, and if the pretty-format is not 'oneline', 'email' or 'raw', an additional line is inserted before the 'Author:' line.  This line begins with "Merge: " and the hashes of ancestral commits are printed, separated by spaces.  Note that the listed commits may not necessarily be the list of the *direct* parent commits if you have limited your view of history: for example, if you are only interested in changes related to a certain directory or file.
zh_HANS-CN: 如果提交是一个合并，并且如果pretty-format不是 "oneline"、"email "或 "raw"，那么在 "Author: "一行之前会插入一个附加行。  这一行的开头是 "Merge:这一行以 "Merge: "开头，并打印出祖先提交的哈希值，用空格分隔。  请注意，如果你限制了你的历史视图，那么列出的提交不一定是*直接*父级提交的列表：例如，如果你只对与某个目录或文件有关的修改感兴趣。

note: type: Plain text
en: There are several built-in formats, and you can define additional formats by setting a pretty.<name> config option to either another format name, or a 'format:' string, as described below (see linkgit:git-config[1]). Here are the details of the built-in formats:
zh_HANS-CN: 有几种内置的格式，你可以通过将 pretty.<name> 配置选项设置为另一种格式名称或 "format: "字符串来定义额外的格式，如下所述（见 linkgit:git-config[1] ）。下面是内置格式的细节。

note: type: Plain text
en: This is designed to be as compact as possible.
zh_HANS-CN: 这个设计是为了尽可能的紧凑。

note: type: Plain text
en: commit <hash>
    Author: <author>
zh_HANS-CN: 承诺<hash>
    作者。<作者>的情况

note: type: Plain text
en: commit <hash>
    Author: <author>
    Commit: <committer>
zh_HANS-CN: 承诺<hash>
    作者。< Author>
    承诺。<committer>（提交者）。

note: type: Plain text
en: This format is used to refer to another commit in a commit message and is the same as `--pretty='format:%C(auto)%h (%s, %ad)'`.  By default, the date is formatted with `--date=short` unless another `--date` option is explicitly specified.  As with any `format:` with format placeholders, its output is not affected by other options like `--decorate` and `--walk-reflogs`.
zh_HANS-CN: 这种格式用于在提交信息中引用另一个提交，与`--pretty='format:%C(auto)%h (%s, %ad)'相同。  默认情况下，日期的格式为`--date=short`，除非明确指定其他`--date`选项。  与任何带有格式占位符的`format:`一样，其输出不受其他选项的影响，如`--decorate`和`--walk-reflogs`。

note: type: Plain text
en: Like 'email', but lines in the commit message starting with "From " (preceded by zero or more ">") are quoted with ">" so they aren't confused as starting a new commit.
zh_HANS-CN: 和 "email "一样，但提交信息中以 "From "开头的行（前面有零个或多个">"）用">"引出，这样就不会被混淆为开始了一个新的提交。

note: type: Plain text
en: The 'raw' format shows the entire commit exactly as stored in the commit object.  Notably, the hashes are displayed in full, regardless of whether --abbrev or --no-abbrev are used, and 'parents' information show the true parent commits, without taking grafts or history simplification into account. Note that this format affects the way commits are displayed, but not the way the diff is shown e.g. with `git log --raw`. To get full object names in a raw diff format, use `--no-abbrev`.
zh_HANS-CN: 原始 "格式显示的是整个提交对象中存储的内容。  值得注意的是，无论是否使用了 --abbrev 或 --no-abbrev，哈希值都会被完整地显示出来，而'parent'信息会显示真正的父级提交，不会考虑移花接木或历史简化。注意，这种格式会影响提交的显示方式，但不会影响diff的显示方式，比如用`git log --raw`来显示。要获得原始差异格式的完整对象名称，请使用`--no-abbrev`。

note: type: Plain text
en: E.g, 'format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"' would show something like this:
zh_HANS-CN: 例如，'format: "The author of %h was %an, %ar%nThe title was >>%s<<%n"'会显示这样的内容。

note: type: delimited block -
en: The author of fe6e0ee was Junio C Hamano, 23 hours ago
    The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
zh_HANS-CN: fe6e0ee的作者是Junio C Hamano, 23小时前
    标题是 >>t4119: 测试传统diff输入的自动计算-p<n>。

note: type: Plain text
en: The placeholders are:
zh_HANS-CN: 占位符是。

note: type: Plain text
en: Placeholders that expand to a single literal character:
zh_HANS-CN: 占位符，可扩展为一个字面字符。

note: type: Plain text
en: newline
zh_HANS-CN: 换行

note: type: Plain text
en: a raw '%'
zh_HANS-CN: 一个原始的'%'

note: type: Plain text
en: print a byte from a hex code
zh_HANS-CN: 打印十六进制代码中的一个字节

note: type: Plain text
en: Placeholders that affect formatting of later placeholders:
zh_HANS-CN: 影响后面占位符的格式化的占位符。

note: type: Plain text
en: switch color to red
zh_HANS-CN: 切换颜色为红色

note: type: Plain text
en: switch color to green
zh_HANS-CN: 切换颜色为绿色

note: type: Plain text
en: switch color to blue
zh_HANS-CN: 将颜色改为蓝色

note: type: Plain text
en: reset color
zh_HANS-CN: 重置颜色

note: type: Plain text
en: color specification, as described under Values in the "CONFIGURATION FILE" section of linkgit:git-config[1].  By default, colors are shown only when enabled for log output (by `color.diff`, `color.ui`, or `--color`, and respecting the `auto` settings of the former if we are going to a terminal). `%C(auto,...)` is accepted as a historical synonym for the default (e.g., `%C(auto,red)`). Specifying `%C(always,...)` will show the colors even when color is not otherwise enabled (though consider just using `--color=always` to enable color for the whole output, including this format and anything else git might color).  `auto` alone (i.e. `%C(auto)`) will turn on auto coloring on the next placeholders until the color is switched again.
zh_HANS-CN: 颜色规范，如linkgit:git-config[1]的 "配置文件 "部分中的数值描述。  默认情况下，只有在启用日志输出时才会显示颜色（通过 `color.diff`, `color.ui`, 或 `-color`, 如果我们要去终端，要尊重前者的`auto`设置）。`%C(auto,...)`被接受为默认的历史同义词（例如，`%C(auto,red)`）。指定`%C(always,...)`将显示颜色，即使没有启用颜色（尽管考虑使用`-color=always`来启用整个输出的颜色，包括这个格式和其他任何git可能的颜色）。  `auto`单独使用（即`%C(auto)`）将在下一个占位符上开启自动着色，直到再次切换颜色。

note: type: Plain text
en: left (`<`), right (`>`) or boundary (`-`) mark
zh_HANS-CN: 左（`<`）、右（`>`）或边界（`-`）标记

note: type: Plain text
en: switch line wrapping, like the -w option of linkgit:git-shortlog[1].
zh_HANS-CN: 开关包行，就像 linkgit:git-shortlog[1] 的 -w 选项。

note: type: Plain text
en: Placeholders that expand to information extracted from the commit:
zh_HANS-CN: 占位符，扩展到从提交中提取的信息。

note: type: Plain text
en: abbreviated commit hash
zh_HANS-CN: 简称提交哈希

note: type: Plain text
en: abbreviated tree hash
zh_HANS-CN: 简称树形哈希

note: type: Plain text
en: parent hashes
zh_HANS-CN: 父类哈希值

note: type: Plain text
en: abbreviated parent hashes
zh_HANS-CN: 缩写的父母哈希值

note: type: Plain text
en: author email local-part (the part before the '@' sign)
zh_HANS-CN: 作者电子邮件的本地部分（"@"符号之前的部分）。

note: type: Plain text
en: author date (format respects --date= option)
zh_HANS-CN: 作者日期（格式尊重--date=选项

note: type: Plain text
en: author date, RFC2822 style
zh_HANS-CN: 作者日期，RFC2822风格

note: type: Plain text
en: author date, relative
zh_HANS-CN: 作者日期，相对

note: type: Plain text
en: author date, UNIX timestamp
zh_HANS-CN: 作者日期，UNIX时间戳

note: type: Plain text
en: author date, ISO 8601-like format
zh_HANS-CN: 作者日期，类似ISO 8601的格式

note: type: Plain text
en: author date, strict ISO 8601 format
zh_HANS-CN: 作者日期，严格的ISO 8601格式

note: type: Plain text
en: author date, short format (`YYYY-MM-DD`)
zh_HANS-CN: 作者日期，短格式（`YYYY-MM-DD`）。

note: type: Plain text
en: author date, human style (like the `--date=human` option of linkgit:git-rev-list[1])
zh_HANS-CN: 作者日期，人类风格（就像linkgit:git-rev-list[1]的`--date=human`选项）。

note: type: Plain text
en: committer email local-part (the part before the '@' sign)
zh_HANS-CN: 承诺人电子邮件的本地部分（"@"符号之前的部分）。

note: type: Plain text
en: committer date (format respects --date= option)
zh_HANS-CN: 承诺人日期（格式尊重--date=选项

note: type: Plain text
en: committer date, RFC2822 style
zh_HANS-CN: 承诺人日期，RFC2822风格

note: type: Plain text
en: committer date, relative
zh_HANS-CN: 承诺人日期，相对

note: type: Plain text
en: committer date, UNIX timestamp
zh_HANS-CN: 提交者日期，UNIX时间戳

note: type: Plain text
en: committer date, ISO 8601-like format
zh_HANS-CN: 承诺人日期，类似ISO 8601的格式

note: type: Plain text
en: committer date, strict ISO 8601 format
zh_HANS-CN: 承诺人日期，严格的ISO 8601格式

note: type: Plain text
en: committer date, short format (`YYYY-MM-DD`)
zh_HANS-CN: 承诺人日期，短格式（`YYYY-MM-DD`）。

note: type: Plain text
en: committer date, human style (like the `--date=human` option of linkgit:git-rev-list[1])
zh_HANS-CN: 提交者的日期，人类风格（就像linkgit:git-rev-list[1]的`--date=human`选项）。

note: type: Plain text
en: ref names, like the --decorate option of linkgit:git-log[1]
zh_HANS-CN: ref名称，就像linkgit:git-log[1]的-decorate选项。

note: type: Plain text
en: ref names without the " (", ")" wrapping.
zh_HANS-CN: 没有"（"、"）"包装的参考文献名称。

note: type: Labeled list
en: '%(describe[:options])'
zh_HANS-CN: '%(description[:options])'

note: type: Plain text
en: human-readable name, like linkgit:git-describe[1]; empty string for undescribable commits.  The `describe` string may be followed by a colon and zero or more comma-separated options.  Descriptions can be inconsistent when tags are added or removed at the same time.
zh_HANS-CN: 人类可读的名字，像linkgit:git-describe[1]；空字符串表示不可描述的提交。  `describe`字符串后面可以有冒号和零个或多个逗号分隔的选项。  当标签同时被添加或删除时，描述可能不一致。

note: type: Plain text
en: 'tags[=<bool-value>]': Instead of only considering annotated tags, consider lightweight tags as well.
zh_HANS-CN: 'tags[=<bool-value>]'：不仅考虑带注释的标签，还考虑轻量级标签。

note: type: Plain text
en: 'match=<pattern>': Only consider tags matching the given `glob(7)` pattern, excluding the "refs/tags/" prefix.
zh_HANS-CN: 'match=<pattern>':只考虑与给定的`glob(7)`模式匹配的标签，不包括 "refs/tags/"前缀。

note: type: Plain text
en: 'exclude=<pattern>': Do not consider tags matching the given `glob(7)` pattern, excluding the "refs/tags/" prefix.
zh_HANS-CN: 'exclude=<pattern>':不考虑匹配给定`glob(7)`模式的标签，排除 "refs/tags/"前缀。

note: type: Plain text
en: ref name given on the command line by which the commit was reached (like `git log --source`), only works with `git log`
zh_HANS-CN: 在命令行中给出的提交名称（如`git log --source`），只对`git log`起作用。

note: type: Plain text
en: sanitized subject line, suitable for a filename
zh_HANS-CN: 经过消毒的主题行，适合于文件名

note: type: Plain text
en: raw body (unwrapped subject and body)
zh_HANS-CN: 原始体（未包装的主题和体）。

note: type: Plain text
en: commit notes
zh_HANS-CN: 承诺说明

note: type: Plain text
en: raw verification message from GPG for a signed commit
zh_HANS-CN: 来自GPG的签名提交的原始验证信息

note: type: Plain text
en: show "G" for a good (valid) signature, "B" for a bad signature, "U" for a good signature with unknown validity, "X" for a good signature that has expired, "Y" for a good signature made by an expired key, "R" for a good signature made by a revoked key, "E" if the signature cannot be checked (e.g. missing key)  and "N" for no signature
zh_HANS-CN: 显示 "G "代表一个好的（有效的）签名，"B "代表一个坏的签名，"U "代表一个有效性未知的好的签名，"X "代表一个已经过期的好的签名，"Y "代表一个由过期的钥匙制作的好的签名，"R "代表一个由撤销的钥匙制作的好的签名，"E "如果不能检查签名（如缺少钥匙），"N "代表没有签名。

note: type: Plain text
en: show the name of the signer for a signed commit
zh_HANS-CN: 显示已签名的提交的签名者的名字

note: type: Plain text
en: show the key used to sign a signed commit
zh_HANS-CN: 显示用于签署已签名的承诺的密钥

note: type: Plain text
en: show the fingerprint of the key used to sign a signed commit
zh_HANS-CN: 显示用于签署已签名提交文件的密钥的指纹。

note: type: Plain text
en: show the fingerprint of the primary key whose subkey was used to sign a signed commit
zh_HANS-CN: 显示主键的指纹，该主键的子键被用来签署一个已签署的提交。

note: type: Plain text
en: show the trust level for the key used to sign a signed commit
zh_HANS-CN: 显示用于签署已签名的承诺的密钥的信任级别

note: type: Plain text
en: reflog selector, e.g., `refs/stash@{1}` or `refs/stash@{2 minutes ago}`; the format follows the rules described for the `-g` option. The portion before the `@` is the refname as given on the command line (so `git log -g refs/heads/master` would yield `refs/heads/master@{0}`).
zh_HANS-CN: reflog选择器，例如，`refs/stash@{1}`或`refs/stash@{2分钟前}`；其格式遵循`-g`选项的规则。`@'前面的部分是命令行上给出的参考文献名称（所以`git log -g refs/heads/master`会产生`refs/heads/master@{0}`）。

note: type: Plain text
en: shortened reflog selector; same as `%gD`, but the refname portion is shortened for human readability (so `refs/heads/master` becomes just `master`).
zh_HANS-CN: 简化的 reflog 选择器；与 `%gD` 相同，但 refname 部分被缩短以利于人类阅读（因此 `refs/heads/master` 变成了 `master`）。

note: type: Plain text
en: reflog identity name
zh_HANS-CN: 记录身份名称

note: type: Plain text
en: reflog identity email
zh_HANS-CN: 重新记录身份邮件

note: type: Plain text
en: reflog subject
zh_HANS-CN: 记录主题

note: type: Labeled list
en: '%(trailers[:options])'
zh_HANS-CN: '%(trailer[:options])'

note: type: Plain text
en: display the trailers of the body as interpreted by linkgit:git-interpret-trailers[1]. The `trailers` string may be followed by a colon and zero or more comma-separated options.  If any option is provided multiple times the last occurrence wins.
zh_HANS-CN: 显示由linkgit:git-interpret-trailers[1]解释的正文的预告片。`trailers`字符串后面可以有冒号和零个或多个逗号分隔的选项。  如果任何选项被多次提供，则最后出现的选项获胜。

note: type: Plain text
en: Some placeholders may depend on other options given to the revision traversal engine. For example, the `%g*` reflog options will insert an empty string unless we are traversing reflog entries (e.g., by `git log -g`). The `%d` and `%D` placeholders will use the "short" decoration format if `--decorate` was not already provided on the command line.
zh_HANS-CN: 一些占位符可能取决于给修订版遍历引擎的其他选项。例如，`%g*` reflog选项将插入一个空字符串，除非我们正在遍历reflog条目（例如，通过`git log -g`）。`%d`和`%D`占位符将使用 "短 "装饰格式，如果`--decorate`没有在命令行上提供。

note: type: Plain text
en: If you add a `+` (plus sign) after '%' of a placeholder, a line-feed is inserted immediately before the expansion if and only if the placeholder expands to a non-empty string.
zh_HANS-CN: 如果你在占位符的'%'后面加了一个`+'（加号），当且仅当占位符扩展为一个非空字符串时，在扩展前会立即插入换行符。

note: type: Plain text
en: If you add a `-` (minus sign) after '%' of a placeholder, all consecutive line-feeds immediately preceding the expansion are deleted if and only if the placeholder expands to an empty string.
zh_HANS-CN: 如果你在占位符的'%'后面加了一个`-'（减号），如果且仅当占位符扩展为空字符串时，紧接着扩展前的所有连续换行将被删除。

note: type: Plain text
en: If you add a ` ` (space) after '%' of a placeholder, a space is inserted immediately before the expansion if and only if the placeholder expands to a non-empty string.
zh_HANS-CN: 如果你在占位符的'%'后面加了一个``（空格），当且仅当占位符扩展到一个非空字符串时，空格就会紧接着插入扩展。

note: type: Plain text
en: The 'tformat:' format works exactly like 'format:', except that it provides "terminator" semantics instead of "separator" semantics. In other words, each commit has the message terminator character (usually a newline) appended, rather than a separator placed between entries.  This means that the final entry of a single-line format will be properly terminated with a new line, just as the "oneline" format does.  For example:
zh_HANS-CN: tformat: "格式的工作原理与 "format: "完全一样，只是它提供了 "终止符 "语义，而不是 "分隔符 "语义。换句话说，每个提交都附加了信息结束符（通常是换行符），而不是在条目之间放置一个分隔符。  这意味着单行格式的最后一个条目将正确地以新行结束，就像 "单行 "格式那样。  比如说

note: type: Plain text
en: In addition, any unrecognized string that has a `%` in it is interpreted as if it has `tformat:` in front of it.  For example, these two are equivalent:
zh_HANS-CN: 此外，任何未被识别的字符串，如果其中有`%`，将被解释为前面有`tformat:`。  例如，这两个是等同的。

note: type: Plain text
en: Pretty-print the contents of the commit logs in a given format, where '<format>' can be one of 'oneline', 'short', 'medium', 'full', 'fuller', 'reference', 'email', 'raw', 'format:<string>' and 'tformat:<string>'.  When '<format>' is none of the above, and has '%placeholder' in it, it acts as if '--pretty=tformat:<format>' were given.
zh_HANS-CN: 以指定的格式打印提交日志的内容，其中'<format>'可以是'oneline'、'short'、'medium'、'full'、'fuller'、'reference'、'email'、'raw'、'format:<string>'和'tformat:<string>'之一。  当'<format>'不是上述任何一种，并且其中有'%placeholder'时，它的作用就像给出'--pretty=tformat:<format>'一样。

note: type: Plain text
en: See the "PRETTY FORMATS" section for some additional details for each format.  When '=<format>' part is omitted, it defaults to 'medium'.
zh_HANS-CN: 参见 "PRETTY FORMATS "部分，了解每种格式的一些额外细节。  当'=<格式>'部分被省略时，它默认为'中等'。

note: type: Plain text
en: Note: you can specify the default pretty format in the repository configuration (see linkgit:git-config[1]).
zh_HANS-CN: 注意：你可以在版本库配置中指定默认的漂亮格式（见linkgit:git-config[1]）。

note: type: Plain text
en: Instead of showing the full 40-byte hexadecimal commit object name, show a prefix that names the object uniquely.  "--abbrev=<n>" (which also modifies diff output, if it is displayed)  option can be used to specify the minimum length of the prefix.
zh_HANS-CN: 不要显示完整的40字节的十六进制提交对象名称，而是显示一个前缀，以唯一的方式命名该对象。  "--abbrev=<n>"选项可以用来指定前缀的最小长度（如果显示的话，它也会修改diff输出）。

note: type: Plain text
en: This should make "--pretty=oneline" a whole lot more readable for people using 80-column terminals.
zh_HANS-CN: 这应该使"--pretty=oneline "对于使用80列终端的人来说更容易阅读。

note: type: Plain text
en: Show the full 40-byte hexadecimal commit object name. This negates `--abbrev-commit`, either explicit or implied by other options such as "--oneline". It also overrides the `log.abbrevCommit` variable.
zh_HANS-CN: 显示完整的40字节十六进制的提交对象名称。这否定了`--abbrev-commit`，无论是明确的还是由其他选项如"--oneline "暗示的。它还覆盖了`log.abbrevCommit`变量。

note: type: Plain text
en: This is a shorthand for "--pretty=oneline --abbrev-commit" used together.
zh_HANS-CN: 这是"--pretty=oneline --abbrev-commit "的简写，一起使用。

note: type: Plain text
en: Perform a tab expansion (replace each tab with enough spaces to fill to the next display column that is multiple of '<n>')  in the log message before showing it in the output.  `--expand-tabs` is a short-hand for `--expand-tabs=8`, and `--no-expand-tabs` is a short-hand for `--expand-tabs=0`, which disables tab expansion.
zh_HANS-CN: 在输出中显示之前，在日志信息中进行标签扩展（用足够的空格替换每个标签，以填充到下一个显示列的'<n>'的倍数）。  `--expand-tabs`是`--expand-tabs=8`的简写，`--no-expand-tabs`是`--expand-tabs=0`的简写，它禁止标签扩展。

note: type: Plain text
en: By default, tabs are expanded in pretty formats that indent the log message by 4 spaces (i.e.  'medium', which is the default, 'full', and 'fuller').
zh_HANS-CN: 默认情况下，标签会以漂亮的格式展开，将日志信息缩进4个空格（即 "中"，这是默认的，"全"，和 "更全"）。

note: type: Plain text
en: Show the notes (see linkgit:git-notes[1]) that annotate the commit, when showing the commit log message.  This is the default for `git log`, `git show` and `git whatchanged` commands when there is no `--pretty`, `--format`, or `--oneline` option given on the command line.
zh_HANS-CN: 在显示提交日志信息时，显示注释提交的说明（见linkgit:git-notes[1]）。  这是`git log`、`git show`和`git whatchanged`命令的默认设置，当命令行中没有给出`--pretty`、`--format`或`--oneline`选项时。

note: type: Plain text
en: By default, the notes shown are from the notes refs listed in the `core.notesRef` and `notes.displayRef` variables (or corresponding environment overrides). See linkgit:git-config[1] for more details.
zh_HANS-CN: 默认情况下，显示的注释来自于`core.notesRef`和`notes.displayRef`变量（或相应的环境覆盖）中列出的注释参考。更多细节见linkgit:git-config[1]。

note: type: Plain text
en: With an optional '<ref>' argument, use the ref to find the notes to display.  The ref can specify the full refname when it begins with `refs/notes/`; when it begins with `notes/`, `refs/` and otherwise `refs/notes/` is prefixed to form a full name of the ref.
zh_HANS-CN: 有了一个可选的'<ref>'参数，就可以使用ref来寻找要显示的笔记。  当ref以`refs/notes/`开头时，可以指定完整的ref名称；当它以`notes/`开头时，`refs/`，否则`refs/notes/`前缀，形成ref的全名。

note: type: Plain text
en: Multiple --notes options can be combined to control which notes are being displayed. Examples: "--notes=foo" will show only notes from "refs/notes/foo"; "--notes=foo --notes" will show both notes from "refs/notes/foo" and from the default notes ref(s).
zh_HANS-CN: 多个--音符选项可以组合起来，控制哪些音符被显示。例如。"--notes=foo "将只显示来自 "refs/notes/foo "的注释；"--notes=foo --notes "将同时显示来自 "refs/notes/foo "和默认注释的注释。

note: type: Plain text
en: Do not show notes. This negates the above `--notes` option, by resetting the list of notes refs from which notes are shown.  Options are parsed in the order given on the command line, so e.g.  "--notes --notes=foo --no-notes --notes=bar" will only show notes from "refs/notes/bar".
zh_HANS-CN: 不显示注释。这否定了上面的`--notes`选项，因为它重新设置了显示注释的注释列表。  选项按照命令行给出的顺序进行解析，因此，例如"--notes --notes=foo --no-notes --notes=bar "将只显示来自 "refs/notes/bar "的注释。

note: type: Plain text
en: These options are deprecated. Use the above --notes/--no-notes options instead.
zh_HANS-CN: 这些选项已被废弃。请使用上面的 --notes/-no-notes 选项来代替。

note: type: Plain text
en: Check the validity of a signed commit object by passing the signature to `gpg --verify` and show the output.
zh_HANS-CN: 通过将签名传递给 `gpg --verify` 来检查已签名的提交对象的有效性，并显示输出。

note: type: Plain text
en: The "remote" repository that is the source of a fetch or pull operation.  This parameter can be either a URL (see the section <<URLS,GIT URLS>> below) or the name of a remote (see the section <<REMOTES,REMOTES>> below).
zh_HANS-CN: 作为获取或拉动操作的来源的 "remote" 仓库。 这个参数可以是一个 URL（见下面 <<URLS,GIT URLS>> 一节），也可以是一个远程仓库的名称（见下面 <<远程,REMOTES>> 一节）。

note: type: Labeled list
en: <group>
zh_HANS-CN: <组>

note: type: Plain text
en: A name referring to a list of repositories as the value of remotes.<group> in the configuration file.  (See linkgit:git-config[1]).
zh_HANS-CN: 指向仓库列表的名称，作为配置文件中 remotes.<组> 的值。 (参见 linkgit:git-config[1]）。

note: type: Plain text
en: Specifies which refs to fetch and which local refs to update.  When no <refspec>s appear on the command line, the refs to fetch are read from `remote.<repository>.fetch` variables instead
zh_HANS-CN: 指定要获取哪些引用，以及要更新哪些本地引用。 当命令行上没有出现 <引用规范> 时，将从`remote.<仓库>.fetch` 变量中读取要获取的引用

note: type: Plain text
en: 	(see the section "CONFIGURED REMOTE-TRACKING BRANCHES"
    	in linkgit:git-fetch[1]).
zh_HANS-CN: 	(参见 linkgit:git-fetch[1] 中
    	 “配置远程跟踪分支” 一节）。

note: type: Plain text
en: The format of a <refspec> parameter is an optional plus `+`, followed by the source <src>, followed by a colon `:`, followed by the destination ref <dst>.  The colon can be omitted when <dst> is empty.  <src> is typically a ref, but it can also be a fully spelled hex object name.
zh_HANS-CN: <引用规范> 参数的格式是一个可选的加号 `+` ，后面是源 <src>，后面是冒号 `:`，后面是目标引用 <dst>。 当 <dst> 为空时，冒号可以被省略。 <src> 通常是一个引用，但它也可以是一个完全拼写的十六进制对象名称。

note: type: Plain text
en: A <refspec> may contain a `*` in its <src> to indicate a simple pattern match. Such a refspec functions like a glob that matches any ref with the same prefix. A pattern <refspec> must have a `*` in both the <src> and <dst>. It will map refs to the destination by replacing the `*` with the contents matched from the source.
zh_HANS-CN: 一个 <引用规范> 可以在其<src>中包含一个`*'来表示一个简单的模式匹配。这样的 refspec 的功能就像一个 glob，可以匹配任何具有相同前缀的 ref。匹配 <引用规范> 必须在 <src> 和 <dst> 中都有一个 `*`。它将通过把 `*` 替换成从源头匹配的内容来把引用映射到目的地。

note: type: Plain text
en: If a refspec is prefixed by `^`, it will be interpreted as a negative refspec. Rather than specifying which refs to fetch or which local refs to update, such a refspec will instead specify refs to exclude. A ref will be considered to match if it matches at least one positive refspec, and does not match any negative refspec. Negative refspecs can be useful to restrict the scope of a pattern refspec so that it will not include specific refs.  Negative refspecs can themselves be pattern refspecs. However, they may only contain a <src> and do not specify a <dst>. Fully spelled out hex object names are also not supported.
zh_HANS-CN: 如果一个 引用规范的前缀是 `^`，它将被解释为一个负向引用规范。这样的引用规范不是指定要获取哪些引用或更新哪些本地引用，而是指定要排除的引用。如果一个引用至少与一个正向引用规范匹配，并且不与任何负向引用规范匹配，那么该引用将被视为匹配。负向引用规范可以用来限制引用规范匹配的范围，使其不包括特定的引用。 负向引用规范本身可以是模式引用规范。然而，它们可能只包含一个 <src>，而不指定一个 <dst>。完全拼出的十六进制对象名称也不被支持。

note: type: Plain text
en: `tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`; it requests fetching everything up to the given tag.
zh_HANS-CN: `tag <标签>`的意思与`refs/tags/<标签>:refs/tags/<标签>` 相同；它要求获取到给定标签的所有内容。

note: type: Plain text
en: The remote ref that matches <src> is fetched, and if <dst> is not an empty string, an attempt is made to update the local ref that matches it.
zh_HANS-CN: 获取与 <src> 相匹配的远程引用，如果 <dst> 不是一个空字符串，就会尝试更新与之相匹配的本地引用。

note: type: Plain text
en: Whether that update is allowed without `--force` depends on the ref namespace it's being fetched to, the type of object being fetched, and whether the update is considered to be a fast-forward. Generally, the same rules apply for fetching as when pushing, see the `<refspec>...` section of linkgit:git-push[1] for what those are. Exceptions to those rules particular to 'git fetch' are noted below.
zh_HANS-CN: 该更新是否允许不使用 `--force`，取决于它被获取的引用命名空间、被获取的对象的类型，以及该更新是否被认为是一个快速合并。一般来说，获取的规则与推送的规则相同，参见 linkgit:git-push[1] 的 `<引用规范>...' 部分。以下是 "git fetch" 特殊规则的例外情况。

note: type: Plain text
en: Until Git version 2.20, and unlike when pushing with linkgit:git-push[1], any updates to `refs/tags/*` would be accepted without `+` in the refspec (or `--force`). When fetching, we promiscuously considered all tag updates from a remote to be forced fetches.  Since Git version 2.20, fetching to update `refs/tags/*` works the same way as when pushing. I.e. any updates will be rejected without `+` in the refspec (or `--force`).
zh_HANS-CN: 在 Git 2.20 版本之前，与使用 linkgit:git-push[1] 推送时不同，任何对 `refs/tags/*` 的更新都会被接受，在引用规范中没有 `+`（或`--force`）。在获取的时候，我们把所有来自远程的标签更新都视为强制获取。 从 Git 2.20 版本开始，获取更新 `refs/tags/*` 的方式与推送时相同。也就是说，任何在引用规范中没有 `+` 的更新都会被拒绝（或`--force`）。

note: type: Plain text
en: Unlike when pushing with linkgit:git-push[1], any updates outside of `refs/{tags,heads}/*` will be accepted without `+` in the refspec (or `--force`), whether that's swapping e.g. a tree object for a blob, or a commit for another commit that's doesn't have the previous commit as an ancestor etc.
zh_HANS-CN: 与使用 linkgit:git-push[1] 推送时不同，任何在 `refs/{tags,heads}/*` 之外的更新都会被接受，在引用规范中没有 `+`（或`--force`），无论是将树对象换成二进制文件，还是将一个提交换成另一个没有前一个提交作为祖先的提交等等。

note: type: Plain text
en: Unlike when pushing with linkgit:git-push[1], there is no configuration which'll amend these rules, and nothing like a `pre-fetch` hook analogous to the `pre-receive` hook.
zh_HANS-CN: 与使用 linkgit:git-push[1] 推送时不同，没有任何配置可以修改这些规则，也没有类似于 `pre-receive` 的 `pre-fetch` 钩子。

note: type: Plain text
en: As with pushing with linkgit:git-push[1], all of the rules described above about what's not allowed as an update can be overridden by adding an the optional leading `+` to a refspec (or using `--force` command line option). The only exception to this is that no amount of forcing will make the `refs/heads/*` namespace accept a non-commit object.
zh_HANS-CN: 就像用 linkgit:git-push[1] 推送一样，上面描述的所有关于不允许更新的规则都可以通过在引用规范中添加一个可选的前导词 `+` 来覆盖（或者使用 `--force` 命令行选项）。唯一的例外是，无论如何强制都不能使 `refs/heads/*` 命名空间接受一个非提交对象。

note: type: Plain text
en: When the remote branch you want to fetch is known to be rewound and rebased regularly, it is expected that its new tip will not be descendant of its previous tip (as stored in your remote-tracking branch the last time you fetched).  You would want to use the `+` sign to indicate non-fast-forward updates will be needed for such branches.  There is no way to determine or declare that a branch will be made available in a repository with this behavior; the pulling user simply must know this is the expected usage pattern for a branch.
zh_HANS-CN: 当你想获取的远程分支已知会被定期回溯和重定向时，预计它的新提示不会是其先前提示的后代（如你上次获取时存储在远程跟踪分支中的提示）。  你应该使用 `+` 号来表示对这类分支需要进行非快速合并式更新。  没有办法确定或声明一个分支将以这种行为在仓库中提供；拉取的用户只是必须知道这是一个分支的预期使用模式。

note: type: Plain text
en: There is a difference between listing multiple <refspec> directly on 'git pull' command line and having multiple `remote.<repository>.fetch` entries in your configuration for a <repository> and running a 'git pull' command without any explicit <refspec> parameters.  <refspec>s listed explicitly on the command line are always merged into the current branch after fetching.  In other words, if you list more than one remote ref, 'git pull' will create an Octopus merge.  On the other hand, if you do not list any explicit <refspec> parameter on the command line, 'git pull' will fetch all the <refspec>s it finds in the `remote.<repository>.fetch` configuration and merge only the first <refspec> found into the current branch.  This is because making an Octopus from remote refs is rarely done, while keeping track of multiple remote heads in one-go by fetching more than one is often useful.
zh_HANS-CN: 在 'git pull' 命令行上直接列出多个 <引用规范> 和在 <仓库> 的配置中拥有多个`remote.<仓库>.fetch` 条目以及在没有任何明确的 <引用规范> 参数的情况下运行 'git pull' 命令是有区别的。 在命令行上明确列出的 <引用规范> 在获取后总是被合并到当前分支。  换句话说，如果你列出一个以上的远程引用，'git pull' 将创建一个多路合并。  另一方面，如果你没有在命令行中列出任何明确的 <引用规范> 参数，'git pull' 将获取它在 `remote.<仓库>.fetch` 配置中发现的所有 <引用规范>，并且只将发现的第一个<引用规范> 合并到当前分支。  这是因为很少有人从远程引用中多路合并，而通过获取多个远程头来一次性跟踪多个远程头往往是有用的。

note: type: Plain text
en: When combining multiple `--contains` and `--no-contains` filters, only references that contain at least one of the `--contains` commits and contain none of the `--no-contains` commits are shown.
zh_HANS-CN: 当组合多个"---包含 "和"---不包含 "过滤器时，只显示至少包含一个"---包含 "的提交，并且不包含"---不包含 "的提交的参考。

note: type: Plain text
en: When combining multiple `--merged` and `--no-merged` filters, only references that are reachable from at least one of the `--merged` commits and from none of the `--no-merged` commits are shown.
zh_HANS-CN: 当结合多个 "合并 "和 "未合并 "过滤器时，只显示至少有一个 "合并 "提交和没有 "未合并 "提交的引用。

note: type: Plain text
en: After the rerere mechanism reuses a recorded resolution on the current conflict to update the files in the working tree, allow it to also update the index with the result of resolution.  `--no-rerere-autoupdate` is a good way to double-check what `rerere` did and catch potential mismerges, before committing the result to the index with a separate `git add`.
zh_HANS-CN: 在 rerere 机制重用当前冲突的记录解析来更新工作树中的文件后，允许它也用解析的结果来更新索引。  `--no-rerere-auto-oupdate`是一个很好的方法，在用单独的 `git add` 提交结果到索引之前，可以反复检查 `rerere` 所做的事情，并抓住潜在的错误合并。

note: type: Title -
en: SPECIFYING REVISIONS
zh_HANS-CN: 规定修订

note: type: Plain text
en: A revision parameter '<rev>' typically, but not necessarily, names a commit object.  It uses what is called an 'extended SHA-1' syntax.  Here are various ways to spell object names.  The ones listed near the end of this list name trees and blobs contained in a commit.
zh_HANS-CN: 修订参数 '<rev>' 通常（但不一定）命名一个提交对象。  它使用所谓的 ‘扩展 SHA-1’ 语法。  这里有多种对象名称的拼写方式。  本列表末尾列出的对象名称用于命名提交中包含的树和二进制对象。

note: type: Plain text
en: This document shows the "raw" syntax as seen by git. The shell and other UIs might require additional quoting to protect special characters and to avoid word splitting.
zh_HANS-CN: 本文档显示的是 git 所看到的 “原始” 语法。shell 和其他用户界面可能需要额外的引号来保护特殊字符和避免分词。

note: type: Plain text
en: The full SHA-1 object name (40-byte hexadecimal string), or a leading substring that is unique within the repository.  E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both name the same commit object if there is no other object in your repository whose object name starts with dae86e.
zh_HANS-CN: 完整的 SHA-1 对象名称（40 字节十六进制字符串），或在仓库中唯一的前导子串。  例如，如果仓库中没有其他对象名称以 dae86e 开头的对象，则 dae86e1950b1277e545cee180551750029cfe735 和 dae86e 都是同一个提交对象的名称。

note: type: Labeled list
en: '<describeOutput>', e.g. 'v1.7.4.2-679-g3bee7fb'
zh_HANS-CN: '<describeOutput（描述输出）>'，例如 'v1.7.4.2-679-g3bee7fb'

note: type: Plain text
en: Output from `git describe`; i.e. a closest tag, optionally followed by a dash and a number of commits, followed by a dash, a 'g', and an abbreviated object name.
zh_HANS-CN: 来自 `git describe` 的输出；即一个最接近的标记，后面可选择一个破折号和提交次数，再后面是一个破折号、一个 'g' 和一个缩写的对象名称。

note: type: Labeled list
en: '<refname>', e.g. 'master', 'heads/master', 'refs/heads/master'
zh_HANS-CN: '<引用名>'， 例如 'master', 'heads/master', 'refs/heads/master'

note: type: Plain text
en: A symbolic ref name.  E.g. 'master' typically means the commit object referenced by 'refs/heads/master'.  If you happen to have both 'heads/master' and 'tags/master', you can explicitly say 'heads/master' to tell Git which one you mean.  When ambiguous, a '<refname>' is disambiguated by taking the first match in the following rules:
zh_HANS-CN: 符号引用名称。  例如，'master' 通常指 'refs/heads/master' 引用的提交对象。  如果你同时拥有 'heads/master' 和 'tags/master' ，你可以明确地说 'heads/master' 来告诉 Git 你指的是哪一个。  当 '<引用名>' 有歧义时，会根据以下规则取第一个匹配项来消除歧义：

note: type: Plain text
en: If '$GIT_DIR/<refname>' exists, that is what you mean (this is usually useful only for `HEAD`, `FETCH_HEAD`, `ORIG_HEAD`, `MERGE_HEAD`, `REBASE_HEAD`, `REVERT_HEAD`, `CHERRY_PICK_HEAD`, `BISECT_HEAD` and `AUTO_MERGE`);
zh_HANS-CN: 如果'$GIT_DIR/<引用名>' 存在，这就是你的意思（这通常只对 `HEAD`、`FETCH_HEAD`、`ORIG_HEAD`、`MERGE_HEAD`、`REBASE_HEAD`、`REVERT_HEAD`、`CHERRY_PICK_HEAD`、`BISECT_HEAD` 和 `AUTO_MERGE` 有用）;

note: type: Plain text
en: otherwise, 'refs/<refname>' if it exists;
zh_HANS-CN: 否则，如果存在，则使用 'refs/<引用名>';

note: type: Plain text
en: otherwise, 'refs/tags/<refname>' if it exists;
zh_HANS-CN: 否则，如果存在 'refs/tags/<引用名>'，则使用 'refs/tags/<引用名>';

note: type: Plain text
en: otherwise, 'refs/heads/<refname>' if it exists;
zh_HANS-CN: 否则，如果存在 'refs/heads/<引用名>'，则使用 'refs/heads/<引用名>';

note: type: Plain text
en: otherwise, 'refs/remotes/<refname>' if it exists;
zh_HANS-CN: 否则，如果存在 'refs/remotes/<引用名>'，则使用 'refs/remotes/<引用名>';

note: type: Plain text
en: otherwise, 'refs/remotes/<refname>/HEAD' if it exists.
zh_HANS-CN: 否则，如果存在 'refs/remotes/<引用名>/HEAD'，则使用 'refs/remotes/<引用名>/HEAD'。

note: type: Plain text
en: records the branch which you fetched from a remote repository with
    your last `git fetch` invocation.
zh_HANS-CN: 记录您上次调用 `git fetch` 时
    从远程仓库获取的分支。

note: type: Plain text
en: is created by commands that move your `HEAD` in a drastic way (`git
    am`, `git merge`, `git rebase`, `git reset`), to record the position
    of the `HEAD` before their operation, so that you can easily change
    the tip of the branch back to the state before you ran them.
zh_HANS-CN: 命令（`git am`、`git merge`、`git rebase`、`git reset`）时创建的，
    用于记录这些命令执行前`HEAD`的位置，
    以便于将分支的顶端
    改回执行这些命令前的状态。

note: type: Plain text
en: records the commit(s) which you are merging into your branch when you
    run `git merge`.
zh_HANS-CN: 记录您在运行 `git merge` 时
    要合并到分支中的提交。

note: type: Plain text
en: during a rebase, records the commit at which the operation is
    currently stopped, either because of conflicts or an `edit` command in
    an interactive rebase.
zh_HANS-CN: 会记录当前停止操作的提交，
    原因可能是冲突或
    交互式变基中的 `edit` 命令。

note: type: Plain text
en: records the commit which you are reverting when you run `git revert`.
zh_HANS-CN: 记录您在运行 `git revert` 时要还原的提交。

note: type: Plain text
en: records the commit which you are cherry-picking when you run `git
    cherry-pick`.
zh_HANS-CN: 会记录您在运行 `git cherry-pick` 时
    要 cherry-pick 的提交。

note: type: Plain text
en: records the current commit to be tested when you run `git bisect
    --no-checkout`.
zh_HANS-CN: 记录运行 `git bisect --no-checkout` 时
    要测试的当前提交。

note: type: Plain text
en: records a tree object corresponding to the state the
    'ort' merge strategy wrote to the working tree when a merge operation
    resulted in conflicts.
zh_HANS-CN: 当合并操作导致冲突时，
    记录与 'ort' 合并策略写入工作树的状态
    相对应的树对象。

note: type: Plain text
en: Note that any of the 'refs/*' cases above may come either from the `$GIT_DIR/refs` directory or from the `$GIT_DIR/packed-refs` file.  While the ref name encoding is unspecified, UTF-8 is preferred as some output processing may assume ref names in UTF-8.
zh_HANS-CN: 请注意，上述任何 'refs/*' 都可能来自 `$GIT_DIR/refs` 目录或 `$GIT_DIR/packed-refs` 文件。  虽然引用名称编码未指定，但 UTF-8 是首选，因为某些输出处理可能会假定引用名称为 UTF-8 编码。

note: type: Plain text
en: '@' alone is a shortcut for `HEAD`.
zh_HANS-CN: '@' 本身就是 `HEAD` 的快捷方式。

note: type: Labeled list
en: '[<refname>]@{<date>}', e.g. 'master@\{yesterday\}', 'HEAD@{5 minutes ago}'
zh_HANS-CN: '[<引用名>]@{<日期>}', 例如： 'master@\{yesterday\}', 'HEAD@{5 minutes ago}'

note: type: Plain text
en: A ref followed by the suffix '@' with a date specification enclosed in a brace pair (e.g. '\{yesterday\}', '{1 month 2 weeks 3 days 1 hour 1 second ago}' or '{1979-02-26 18:30:00}') specifies the value of the ref at a prior point in time.  This suffix may only be used immediately following a ref name and the ref must have an existing log ('$GIT_DIR/logs/<ref>'). Note that this looks up the state of your *local* ref at a given time; e.g., what was in your local 'master' branch last week. If you want to look at commits made during certain times, see `--since` and `--until`.
zh_HANS-CN: 在后缀为'@' 的引用后，用一对括号括起来的日期说明（例如 '\{yesterday/}'、'{1 个月 2 周 3 天 1 小时 1 秒前}' 或 '{1979-02-26 18:30:00}'）指定了引用在之前某个时间点的值。  该后缀只能紧跟在引用名称之后使用，且引用必须有现存日志（'$GIT_DIR/logs/<ref>'）。需要注意的是，这个后缀查找的是*本地*引用在给定时间内的状态；例如，上周本地 'master' 分支中的情况。如果要查看特定时间内的提交，请参阅 `-since` 和 `--until`。

note: type: Labeled list
en: '<refname>@{<n>}', e.g. 'master@\{1\}'
zh_HANS-CN: '<引用名>@{<n>}', e.g. 'master@\{1\}'

note: type: Plain text
en: A ref followed by the suffix '@' with an ordinal specification enclosed in a brace pair (e.g. '\{1\}', '\{15\}') specifies the n-th prior value of that ref.  For example 'master@\{1\}' is the immediate prior value of 'master' while 'master@\{5\}' is the 5th prior value of 'master'. This suffix may only be used immediately following a ref name and the ref must have an existing log ('$GIT_DIR/logs/<refname>').
zh_HANS-CN: 在后缀为 '@' 的引用后，用一对括号（如 '\{1\}'、'\{15\}'）括起来的序号说明指定了该引用的 n 次先验值。  例如，'master@\{1\}' 是 'master' 的直接先验值，而 'master@\{5\}' 是 'master' 的第 5 个先验值。该后缀只能紧跟在引用名称之后使用，并且引用必须有现存日志（'$GIT_DIR/logs/<引用名>'）。

note: type: Plain text
en: You can use the '@' construct with an empty ref part to get at a reflog entry of the current branch. For example, if you are on branch 'blabla' then '@\{1\}' means the same as 'blabla@\{1\}'.
zh_HANS-CN: 你可以使用带有空引用部分的"@"结构来获取当前分支的引用日志条目。例如，如果你在分支 'blabla' 上，那么 '@\{1\}' 与 'blabla@\{1\}' 的意思相同。

note: type: Plain text
en: The construct '@{-<n>}' means the <n>th branch/commit checked out before the current one.
zh_HANS-CN: 结构体 '@{-<n>}' 表示在当前分支/提交之前签出的第 <n> 个分支/提交。

note: type: Labeled list
en: '[<branchname>]@\{upstream\}', e.g. 'master@\{upstream\}', '@\{u\}'
zh_HANS-CN: '[<分支名>]@\{upstream\}', e.g. 'master@\{upstream\}', '@\{u\}'

note: type: Plain text
en: A branch B may be set up to build on top of a branch X (configured with `branch.<name>.merge`) at a remote R (configured with `branch.<name>.remote`). B@{u} refers to the remote-tracking branch for the branch X taken from remote R, typically found at `refs/remotes/R/X`.
zh_HANS-CN: 分支 B 可以设置为在远程 R 的分支 X（使用 `branch.<名称>.merge` 配置）（使用 `branch.<名称>.remote`配置）之上构建。B@{u} 指的是远程 R 分支 X 的远程跟踪分支，通常位于 `refs/remotes/R/X`。

note: type: Labeled list
en: '[<branchname>]@\{push\}', e.g. 'master@\{push\}', '@\{push\}'
zh_HANS-CN: '[<分支名>]@\{push\}', e.g. 'master@\{push\}', '@\{push\}'

note: type: Plain text
en: The suffix '@\{push}' reports the branch "where we would push to" if `git push` were run while `branchname` was checked out (or the current `HEAD` if no branchname is specified). Like for '@\{upstream\}', we report the remote-tracking branch that corresponds to that branch at the remote.
zh_HANS-CN: 后缀 '@\{push}' 报告的是在 `branchname` 签出时运行 `git push` 时 “我们会推送到哪里” 的分支（如果没有指定分支名，则报告当前的 `HEAD`）。就像 '@\{upstream\}' 一样，我们会报告与该分支相对应的远程跟踪分支。

note: type: Plain text
en: Here's an example to make it more clear:
zh_HANS-CN: 这里有一个例子，可以更清楚地说明这一点:

note: type: Plain text
en: Note in the example that we set up a triangular workflow, where we pull from one location and push to another. In a non-triangular workflow, '@\{push}' is the same as '@\{upstream}', and there is no need for it.
zh_HANS-CN: 请注意，我们在示例中设置了一个三角工作流，即从一个位置提取数据，然后推送到另一个位置。在非三角工作流中，'@\{push}' 与 '@\{upstream}' 相同，没有必要使用。

note: type: Plain text
en: This suffix is also accepted when spelled in uppercase, and means the same thing no matter the case.
zh_HANS-CN: 这个后缀用大写字母拼写时也被接受，无论大小写，意思都一样。

note: type: Labeled list
en: '<rev>{caret}[<n>]', e.g. 'HEAD{caret}, v1.5.1{caret}0'
zh_HANS-CN: '<修订号>{caret}[<n>]'，例如 'HEAD{caret}, v1.5.1{caret}0'

note: type: Plain text
en: A suffix '{caret}' to a revision parameter means the first parent of that commit object.  '{caret}<n>' means the <n>th parent (i.e.  '<rev>{caret}' is equivalent to '<rev>{caret}1').  As a special rule, '<rev>{caret}0' means the commit itself and is used when '<rev>' is the object name of a tag object that refers to a commit object.
zh_HANS-CN: 修订参数的后缀 '{caret}' 表示该提交对象的第一个父对象。  '{caret}<n>'表示第 <n> 个父提交（即 '<rev>{caret}' 等同于 '<rev>{caret}1'）。  作为一条特殊规则，'<rev>{caret}0' 表示提交本身，在 '<rev>' 是指向提交对象的标记对象的对象名时使用。

note: type: Plain text
en: A suffix '{tilde}' to a revision parameter means the first parent of that commit object.  A suffix '{tilde}<n>' to a revision parameter means the commit object that is the <n>th generation ancestor of the named commit object, following only the first parents.  I.e. '<rev>{tilde}3' is equivalent to '<rev>{caret}{caret}{caret}' which is equivalent to '<rev>{caret}1{caret}1{caret}1'.  See below for an illustration of the usage of this form.
zh_HANS-CN: 修订参数的后缀 '{tilde}' 表示该提交对象的第一代父对象。  修订参数的后缀 '{tilde}<n>' 表示该提交对象的 <n> 代祖先，仅次于第一代父对象。  例如，'<rev>{tilde}3' 等同于 '<rev>{caret}{caret}{caret}'，后者等同于 '<rev>{caret}1{caret}1{caret}1'。  请参阅下面的示例，了解这种形式的用法。

note: type: Labeled list
en: '<rev>{caret}{<type>}', e.g. 'v0.99.8{caret}\{commit\}'
zh_HANS-CN: '<修订>{caret}{<类型>}', e.g. 'v0.99.8{caret}\{commit\}'

note: type: Plain text
en: A suffix '{caret}' followed by an object type name enclosed in brace pair means dereference the object at '<rev>' recursively until an object of type '<type>' is found or the object cannot be dereferenced anymore (in which case, barf).  For example, if '<rev>' is a commit-ish, '<rev>{caret}\{commit\}' describes the corresponding commit object.  Similarly, if '<rev>' is a tree-ish, '<rev>{caret}\{tree\}' describes the corresponding tree object.  '<rev>{caret}0' is a short-hand for '<rev>{caret}\{commit\}'.
zh_HANS-CN: 后缀 '{caret}' 后跟有一对括号的对象类型名称，表示在 '<修订>' 处递归引用该对象，直到找到 '<类型>' 类型的对象或该对象无法再被引用（在这种情况下，barf）。  例如，如果 '<修订>' 是一个提交对象，那么 '<修订>{caret}/{commit/}' 就描述了相应的提交对象。  同样，如果 '<修订>' 是一个树对象，那么 '<修订>{caret}/{tree/}' 就描述了相应的树对象。  '<修订>{caret}0' 是 '<rev>{caret}/{commit/}' 的简写。

note: type: Plain text
en: '<rev>{caret}\{object\}' can be used to make sure '<rev>' names an object that exists, without requiring '<rev>' to be a tag, and without dereferencing '<rev>'; because a tag is already an object, it does not have to be dereferenced even once to get to an object.
zh_HANS-CN: '<修订>{caret}/{object/}' 可以用来确保 '<修订>' 命名了一个存在的对象，而不要求 '<修订>' 是一个标记，也不需要取消引用 '<修订>'；因为一个标记已经是一个对象，所以即使取消引用一次也不一定能找到一个对象。

note: type: Plain text
en: '<rev>{caret}\{tag\}' can be used to ensure that '<rev>' identifies an existing tag object.
zh_HANS-CN: 可以使用 '<修订>{caret}/{tag\}' 来确保 '<修订>' 标识现有的标记对象。

note: type: Plain text
en: A suffix '{caret}' followed by an empty brace pair means the object could be a tag, and dereference the tag recursively until a non-tag object is found.
zh_HANS-CN: 后缀 '{caret}' 后跟一个空括号对，表示该对象可能是一个标记，并递归引用该标记，直到找到一个非标记对象。

note: type: Labeled list
en: '<rev>{caret}{/<text>}', e.g. 'HEAD^{/fix nasty bug}'
zh_HANS-CN: '<修订>{caret}{/<文本>}'，例如 'HEAD^{/fix nasty bug（修复讨厌的 BUG）}'

note: type: Plain text
en: A suffix '{caret}' to a revision parameter, followed by a brace pair that contains a text led by a slash, is the same as the ':/fix nasty bug' syntax below except that it returns the youngest matching commit which is reachable from the '<rev>' before '{caret}'.
zh_HANS-CN: 版本参数的后缀 '{caret}'，后面是包含以斜线为首的文本的括号对，与下面的 ':/fix nasty bug' 语法相同，但它返回的是 '{caret}' 之前的 '<修订>' 中最年轻的匹配提交。

note: type: Labeled list
en: ':/<text>', e.g. ':/fix nasty bug'
zh_HANS-CN: ':/<文本>'，例如 ':/fix nasty bug'

note: type: Plain text
en: A colon, followed by a slash, followed by a text, names a commit whose commit message matches the specified regular expression.  This name returns the youngest matching commit which is reachable from any ref, including HEAD.  The regular expression can match any part of the commit message. To match messages starting with a string, one can use e.g. ':/^foo'. The special sequence ':/!' is reserved for modifiers to what is matched. ':/!-foo' performs a negative match, while ':/!!foo' matches a literal '!' character, followed by 'foo'. Any other sequence beginning with ':/!' is reserved for now.  Depending on the given text, the shell's word splitting rules might require additional quoting.
zh_HANS-CN: 冒号后的斜线和文本，用于命名提交信息与指定正则表达式匹配的提交。  该名称会返回可从任何引用（包括 HEAD）到达的最年轻的匹配提交。  正则表达式可以匹配提交信息的任何部分。要匹配以字符串开头的提交信息，可以使用 ':/^foo'。特殊序列 ':/!' 用于修饰匹配内容。':/!-foo' 执行负匹配，而 ':/!!foo' 则匹配字面意义上的 '!' 字符，后接 'foo'。以 ':/!' 开头的其他序列暂时保留。  根据给定的文本，shell 的分词规则可能需要额外的引号。

note: type: Labeled list
en: '<rev>:<path>', e.g. 'HEAD:README', 'master:./README'
zh_HANS-CN: '<修订>:<路径>'，例如 'HEAD:README', 'master:./README'

note: type: Plain text
en: A suffix ':' followed by a path names the blob or tree at the given path in the tree-ish object named by the part before the colon.  A path starting with './' or '../' is relative to the current working directory.  The given path will be converted to be relative to the working tree's root directory.  This is most useful to address a blob or tree from a commit or tree that has the same tree structure as the working tree.
zh_HANS-CN: 后缀 ':' 和路径会在冒号前的树状对象中命名给定路径上的 blob 或树。  以'./' 或 '../' 开头的路径是相对于当前工作目录的。  给定路径将转换为相对于工作树根目录的路径。  这对于从与工作树具有相同树形结构的提交或树中查找 blob 或树最为有用。

note: type: Plain text
en: A colon, optionally followed by a stage number (0 to 3) and a colon, followed by a path, names a blob object in the index at the given path. A missing stage number (and the colon that follows it) names a stage 0 entry. During a merge, stage 1 is the common ancestor, stage 2 is the target branch's version (typically the current branch), and stage 3 is the version from the branch which is being merged.
zh_HANS-CN: 一个冒号（可选）后面跟一个阶段编号（0 至 3）和一个冒号，冒号后面跟一个路径，用于命名索引中位于给定路径的 Blob 对象。如果缺少阶段号（以及后面的冒号），则命名为阶段 0 条目。在合并过程中，阶段 1 是共同祖先，阶段 2 是目标分支的版本（通常是当前分支），阶段 3 是被合并分支的版本。

note: type: Plain text
en: Here is an illustration, by Jon Loeliger.  Both commit nodes B and C are parents of commit node A.  Parent commits are ordered left-to-right.
zh_HANS-CN: 下面是 Jon Loeliger 绘制的一幅插图。  提交节点 B 和 C 都是提交节点 A 的父节点。  父提交从左到右排序。

note: type: Plain text
en: History traversing commands such as `git log` operate on a set of commits, not just a single commit.
zh_HANS-CN: 历史记录遍历命令，如 `git log` 会对一组提交进行操作，而不仅仅是单个提交。

note: type: Plain text
en: For these commands, specifying a single revision, using the notation described in the previous section, means the set of commits `reachable` from the given commit.
zh_HANS-CN: 对于这些命令，使用上一节中描述的符号指定一个修订版本，意味着从给定的提交开始 `可达到` 的一组提交。

note: type: Plain text
en: Specifying several revisions means the set of commits reachable from any of the given commits.
zh_HANS-CN: 指定多个修订版本指的是可从任何给定的提交版本到达的提交版本集。

note: type: Plain text
en: A commit's reachable set is the commit itself and the commits in its ancestry chain.
zh_HANS-CN: 提交的可达集合是指提交本身及其祖先链中的提交。

note: type: Plain text
en: There are several notations to specify a set of connected commits (called a "revision range"), illustrated below.
zh_HANS-CN: 有几种符号可以指定一组相连的提交（称为 “修订范围”），如下图所示。

note: type: Title ~
en: Commit Exclusions
zh_HANS-CN: 排除提交

note: type: Labeled list
en: '{caret}<rev>' (caret) Notation
zh_HANS-CN: '{caret}<修订号>'（catet）表示

note: type: Plain text
en: To exclude commits reachable from a commit, a prefix '{caret}' notation is used.  E.g. '{caret}r1 r2' means commits reachable from 'r2' but exclude the ones reachable from 'r1' (i.e. 'r1' and its ancestors).
zh_HANS-CN: 要排除某个提交中可触及的提交，可使用前缀 '{caret}' 表示。  例如，'{caret}r1 r2' 表示可从 'r2' 到达的提交，但不包括可从 'r1' 到达的提交（即 'r1' 及其祖先）。

note: type: Title ~
en: Dotted Range Notations
zh_HANS-CN: 虚线范围符号

note: type: Labeled list
en: The '..' (two-dot) Range Notation
zh_HANS-CN: '..'（双点）范围符号

note: type: Plain text
en: The '{caret}r1 r2' set operation appears so often that there is a shorthand for it.  When you have two commits 'r1' and 'r2' (named according to the syntax explained in SPECIFYING REVISIONS above), you can ask for commits that are reachable from r2 excluding those that are reachable from r1 by '{caret}r1 r2' and it can be written as 'r1..r2'.
zh_HANS-CN: 由于 '{caret}r1 r2' 的设置操作经常出现，所以有了一种速记方法。  当你有两个提交 'r1' 和 'r2'（根据上文 “指定修订” 中解释的语法命名）时，你可以通过 '{caret}r1 r2' 请求从 r2 可以访问的提交，但不包括从 r1 可以访问的提交，可以写成 'r1...r2'。

note: type: Labeled list
en: The '\...' (three-dot) Symmetric Difference Notation
zh_HANS-CN: '\...'（三点）对称差符号

note: type: Plain text
en: A similar notation 'r1\...r2' is called symmetric difference of 'r1' and 'r2' and is defined as 'r1 r2 --not $(git merge-base --all r1 r2)'.  It is the set of commits that are reachable from either one of 'r1' (left side) or 'r2' (right side) but not from both.
zh_HANS-CN: 类似的符号 'r1\...r2' 被称为 'r1' 和 'r2' 的对称差值，定义为 'r1 r2 --not $(git merge-base --all r1 r2)'。  它是可以从 'r1'（左侧）或 'r2'（右侧）之一到达，但不能同时从两处到达的提交的集合。

note: type: Plain text
en: In these two shorthand notations, you can omit one end and let it default to HEAD.  For example, 'origin..' is a shorthand for 'origin..HEAD' and asks "What did I do since I forked from the origin branch?" Similarly, '..origin' is a shorthand for 'HEAD..origin' and asks "What did the origin do since I forked from them?" Note that '..' would mean 'HEAD..HEAD' which is an empty range that is both reachable and unreachable from HEAD.
zh_HANS-CN: 在这两种速记符号中，你可以省略一端，让它默认为 HEAD。  例如，'origin..' 是 'origin..HEAD' 的简写，问的是 “我从起源分支分叉后做了什么？” 同样，'..origin' 是 'HEAD..origin' 的简写，问的是 “我从起源分支分叉后做了什么？” 请注意，'..' 指的是 'HEAD..HEAD'，它是一个空范围，既可从 HEAD 访问，也不可从 HEAD 访问。

note: type: Plain text
en: Commands that are specifically designed to take two distinct ranges (e.g. "git range-diff R1 R2" to compare two ranges) do exist, but they are exceptions.  Unless otherwise noted, all "git" commands that operate on a set of commits work on a single revision range.  In other words, writing two "two-dot range notation" next to each other, e.g.
zh_HANS-CN: 也有专门针对两个不同范围的命令（例如 "git range-diff R1 R2"，用于比较两个范围），但它们都是例外。  除非另有说明，否则所有对一组提交进行操作的 "git "命令都是针对单一修订范围的。  换句话说，将两个 “双点范围符号” 写在一起，例如

note: type: Plain text
en: does *not* specify two revision ranges for most commands.  Instead it will name a single connected set of commits, i.e. those that are reachable from either B or D but are reachable from neither A or C.  In a linear history like this:
zh_HANS-CN: *不* 会为大多数命令指定两个修订范围。  取而代之的是，它将命名单个相连的提交集，即那些从 B 或 D 可以到达，但从 A 或 C 都不能到达的提交集：

note: type: Plain text
en: because A and B are reachable from C, the revision range specified by these two dotted ranges is a single commit D.
zh_HANS-CN: 因为 A 和 B 可以从 C 处到达，所以这两个虚线范围指定的修订范围是单一的提交 D。

note: type: Title ~
en: Other <rev>{caret} Parent Shorthand Notations
zh_HANS-CN: 其他 <修订号>{caret}父级速记符号

note: type: Plain text
en: Three other shorthands exist, particularly useful for merge commits, for naming a set that is formed by a commit and its parent commits.
zh_HANS-CN: 还有其他三种简称，特别适用于合并提交，用于命名由提交及其父提交组成的集合。

note: type: Plain text
en: The 'r1{caret}@' notation means all parents of 'r1'.
zh_HANS-CN: 'r1{caret}@' 表示 'r1' 的所有父代。

note: type: Plain text
en: The 'r1{caret}!' notation includes commit 'r1' but excludes all of its parents.  By itself, this notation denotes the single commit 'r1'.
zh_HANS-CN: 'r1{caret}!' 表示包含提交 'r1'，但不包括其所有父提交。  就其本身而言，该符号表示单个提交 'r1'。

note: type: Plain text
en: The '<rev>{caret}-[<n>]' notation includes '<rev>' but excludes the <n>th parent (i.e. a shorthand for '<rev>{caret}<n>..<rev>'), with '<n>' = 1 if not given. This is typically useful for merge commits where you can just pass '<commit>{caret}-' to get all the commits in the branch that was merged in merge commit '<commit>' (including '<commit>' itself).
zh_HANS-CN: '<修订号>{caret}-[<n>]' 符号包括 '<修订号>' ，但不包括第 <n> 次父提交（即 '<修订号>{caret}<n>..<修订号>' 的速记形式），如果没有给出，则 '<n>'= 1。这对合并提交非常有用，只需传递 '<提交号>{caret}-'，就能获得在合并提交 '<提交号>' 中被合并的分支的所有提交（包括 '<提交号>' 本身）。

note: type: Plain text
en: While '<rev>{caret}<n>' was about specifying a single commit parent, these three notations also consider its parents. For example you can say 'HEAD{caret}2{caret}@', however you cannot say 'HEAD{caret}@{caret}2'.
zh_HANS-CN: 虽然 '<修订号>{caret}<n>' 是指定单个提交的父提交，但这三种符号也会考虑其父提交。例如，你可以说 'HEAD{caret}2{caret}@'，但不能说 'HEAD{caret}@{caret}2'。

note: type: Title -
en: Revision Range Summary
zh_HANS-CN: 修订范围摘要

note: type: Plain text
en: Include commits that are reachable from <rev> (i.e. <rev> and its ancestors).
zh_HANS-CN: 包括可从 <修订号> 到达的提交（即 <修订号> 及其祖先）。

note: type: Labeled list
en: '{caret}<rev>'
zh_HANS-CN: '{caret}<修订号>'

note: type: Plain text
en: Exclude commits that are reachable from <rev> (i.e. <rev> and its ancestors).
zh_HANS-CN: 排除可从 <修订号> 到达的提交（即 <修订号> 及其祖先）。

note: type: Plain text
en: Include commits that are reachable from <rev2> but exclude those that are reachable from <rev1>.  When either <rev1> or <rev2> is omitted, it defaults to `HEAD`.
zh_HANS-CN: 包括可从 <修订号2> 进入的提交，但不包括可从 <修订号1> 进入的提交。  如果省略 <修订号1> 或 <修订号2>，则默认为 `HEAD`。

note: type: Labeled list
en: '<rev1>\...<rev2>'
zh_HANS-CN: '<修订号1>\...<修订号2>'

note: type: Plain text
en: Include commits that are reachable from either <rev1> or <rev2> but exclude those that are reachable from both.  When either <rev1> or <rev2> is omitted, it defaults to `HEAD`.
zh_HANS-CN: 包括 <修订号1> 或 <修订号2> 均可访问的提交，但不包括 <修订号1> 和 <修订号2> 均可访问的提交。  省略 <修订号1> 或 <修订号2> 时，默认为 `HEAD`。

note: type: Plain text
en: A suffix '{caret}' followed by an at sign is the same as listing all parents of '<rev>' (meaning, include anything reachable from its parents, but not the commit itself).
zh_HANS-CN: 后缀 '{caret}' 后跟一个 at(@) 符号，就等于列出了 '<修订号>' 的所有父提交（意思是，包括父提交中可触及的任何内容，但不包括提交本身）。

note: type: Labeled list
en: '<rev>{caret}!', e.g. 'HEAD{caret}!'
zh_HANS-CN: '<修订号>{caret}!'，例如 'HEAD{caret}!'

note: type: Plain text
en: A suffix '{caret}' followed by an exclamation mark is the same as giving commit '<rev>' and all its parents prefixed with '{caret}' to exclude them (and their ancestors).
zh_HANS-CN: 带感叹号的后缀 '{caret}' 与提交 '<修订号>' 及其所有前缀为 '{caret}' 的父节点相同，都是为了排除它们（及其祖先）。

note: type: Labeled list
en: '<rev>{caret}-<n>', e.g. 'HEAD{caret}-, HEAD{caret}-2'
zh_HANS-CN: '<修订号>{caret}-<n>'，例如 'HEAD{caret}-, HEAD{caret}-2'

note: type: Plain text
en: Equivalent to '<rev>{caret}<n>..<rev>', with '<n>' = 1 if not given.
zh_HANS-CN: 等价于 '<修订号>{caret}<n>..<修订号>'，如果未给出，则 '<n>'= 1。

note: type: Plain text
en: Here are a handful of examples using the Loeliger illustration above, with each step in the notation's expansion and selection carefully spelt out:
zh_HANS-CN: 下面是一些使用上述 Loeliger 插图的示例，其中仔细说明了符号扩展和选择的每个步骤：

note: type: delimited block .
en:    Args   Expanded arguments    Selected commits
       D                            G H D
       D F                          G H I J D F
       ^G D                         H D
       ^D B                         E I J F B
       ^D B C                       E I J F B C
       C                            I J F C
       B..C   = ^B C                C
       B...C  = B ^F C              G H D E B C
       B^-    = B^..B
    	  = ^B^1 B              E I J F B
       C^@    = C^1
    	  = F                   I J F
       B^@    = B^1 B^2 B^3
    	  = D E F               D G H E F I J
       C^!    = C ^C^@
    	  = C ^C^1
    	  = C ^F                C
       B^!    = B ^B^@
    	  = B ^B^1 ^B^2 ^B^3
    	  = B ^D ^E ^F          B
       F^! D  = F ^I ^J D           G H D F
zh_HANS-CN:    参数   扩展参数    选定的提交
       D                            G H D
       D F                          G H I J D F
       ^G D                         H D
       ^D B                         E I J F B
       ^D B C                       E I J F B C
       C                            I J F C
       B..C   = ^B C                C
       B...C  = B ^F C              G H D E B C
       B^-    = B^..B
    	  = ^B^1 B              E I J F B
       C^@    = C^1
    	  = F                   I J F
       B^@    = B^1 B^2 B^3
    	  = D E F               D G H E F I J
       C^!    = C ^C^@
    	  = C ^C^1
    	  = C ^F                C
       B^!    = B ^B^@
    	  = B ^B^1 ^B^2 ^B^3
    	  = B ^D ^E ^F          B
       F^! D  = F ^I ^J D           G H D F

note: type: Plain text
en: List commits that are reachable by following the `parent` links from the given commit(s), but exclude commits that are reachable from the one(s)  given with a '{caret}' in front of them.  The output is given in reverse chronological order by default.
zh_HANS-CN: 列出可以从给定的提交中通过 "父 "链接到达的提交，但不包括可以从前面有"{caret}"的提交中到达的提交。  默认情况下，输出结果是按时间顺序倒置的。

note: type: Plain text
en: You can think of this as a set operation. Commits reachable from any of the commits given on the command line form a set, and then commits reachable from any of the ones given with '{caret}' in front are subtracted from that set.  The remaining commits are what comes out in the command's output.  Various other options and paths parameters can be used to further limit the result.
zh_HANS-CN: 你可以把它看成是一个集合操作。从命令行上给出的任何一个提交中可以到达的提交形成一个集合，然后从这个集合中减去任何一个前面带有'{caret}'的提交。  剩下的提交内容就是命令的输出结果。  其他各种选项和路径参数也可以用来进一步限制结果。

note: type: Plain text
en: means "list all the commits which are reachable from 'foo' or 'bar', but not from 'baz'".
zh_HANS-CN: 意思是 "列出所有可以从'foo'或'bar'，但不能从'baz'到达的提交"。

note: type: Plain text
en: A special notation "'<commit1>'..'<commit2>'" can be used as a short-hand for "^'<commit1>' '<commit2>'". For example, either of the following may be used interchangeably:
zh_HANS-CN: 一个特殊的符号"'<commit1>'...'<commit2>'"可以作为"^'<commit1>' '<commit2>'"的简称。例如，以下两种情况可以互换使用。

note: type: Plain text
en: Another special notation is "'<commit1>'...'<commit2>'" which is useful for merges.  The resulting set of commits is the symmetric difference between the two operands.  The following two commands are equivalent:
zh_HANS-CN: 另一个特殊的符号是"'<commit1>'...'<commit2>'"，对合并很有用。  由此产生的提交集合是两个操作数之间的对称差。  以下两个命令是等价的。

note: type: Title ~
en: Commit Limiting
zh_HANS-CN: 承诺限制

note: type: Plain text
en: Besides specifying a range of commits that should be listed using the special notations explained in the description, additional commit limiting may be applied.
zh_HANS-CN: 除了使用描述中解释的特殊符号指定应列出的提交范围，还可以应用额外的提交限制。

note: type: Plain text
en: Using more options generally further limits the output (e.g.  `--since=<date1>` limits to commits newer than `<date1>`, and using it with `--grep=<pattern>` further limits to commits whose log message has a line that matches `<pattern>`), unless otherwise noted.
zh_HANS-CN: 使用更多的选项通常会进一步限制输出（例如，`--since=<date1>`限制在比`<date1>`新的提交，与`--grep=<pattern>`一起使用会进一步限制在日志信息中有一行符合`<pattern>`的提交），除非另有说明。

note: type: Plain text
en: Note that these are applied before commit ordering and formatting options, such as `--reverse`.
zh_HANS-CN: 请注意，这些都是在提交排序和格式化选项之前应用的，如`--反转`。

note: type: Plain text
en: Limit the number of commits to output.
zh_HANS-CN: 限制输出的提交数量。

note: type: Plain text
en: Skip 'number' commits before starting to show the commit output.
zh_HANS-CN: 在开始显示提交输出之前，跳过'数'的提交。

note: type: Labeled list
en: --after=<date>
zh_HANS-CN: --after=<日期>

note: type: Plain text
en: Show commits more recent than a specific date.
zh_HANS-CN: 显示比某一特定日期更近的提交。

note: type: Plain text
en: Show all commits more recent than a specific date. This visits all commits in the range, rather than stopping at the first commit which is older than a specific date.
zh_HANS-CN: 显示所有比指定日期更近的提交。这将访问该范围内的所有提交，而不是停在第一个比指定日期更早的提交。

note: type: Labeled list
en: --until=<date>
zh_HANS-CN: --until=<日期>

note: type: Plain text
en: Show commits older than a specific date.
zh_HANS-CN: 显示超过特定日期的提交。

note: type: Plain text
en: Limit the commits output to specified time range.
zh_HANS-CN: 将提交的结果限制在指定的时间范围内。

note: type: Plain text
en: Limit the commits output to ones with author/committer header lines that match the specified pattern (regular expression).  With more than one `--author=<pattern>`, commits whose author matches any of the given patterns are chosen (similarly for multiple `--committer=<pattern>`).
zh_HANS-CN: 将提交文件的输出限制在作者/提交人标题行符合指定模式（正则表达式）的文件。  如果有多个`--author=<pattern>`，则会选择作者符合任何一个给定模式的提交（对于多个`--committer=<pattern>`也是如此）。

note: type: Plain text
en: Limit the commits output to ones with reflog entries that match the specified pattern (regular expression). With more than one `--grep-reflog`, commits whose reflog message matches any of the given patterns are chosen.  It is an error to use this option unless `--walk-reflogs` is in use.
zh_HANS-CN: 将提交文件的输出限制在有符合指定模式（正则表达式）的reflog条目的提交文件。如果有多个 `--grep-reflog`，则会选择那些 reflog 信息符合任何指定模式的提交。  除非使用了`--walk-reflogs`，否则使用此选项是错误的。

note: type: Plain text
en: Limit the commits output to ones with log message that matches the specified pattern (regular expression).  With more than one `--grep=<pattern>`, commits whose message matches any of the given patterns are chosen (but see `--all-match`).
zh_HANS-CN: 将提交结果限制在日志信息与指定模式（正则表达式）相匹配的提交。  如果有多个`--grep=<pattern>`，则会选择那些日志信息与任何指定模式相匹配的提交（但见`--all-match`）。

note: type: Plain text
en: When `--notes` is in effect, the message from the notes is matched as if it were part of the log message.
zh_HANS-CN: 当`--笔记`生效时，笔记中的信息被匹配，就像它是日志信息的一部分。

note: type: Plain text
en: Limit the commits output to ones that match all given `--grep`, instead of ones that match at least one.
zh_HANS-CN: 将输出的提交限制在符合所有给定`--grep`的提交，而不是至少符合一个的提交。

note: type: Plain text
en: Limit the commits output to ones with log message that do not match the pattern specified with `--grep=<pattern>`.
zh_HANS-CN: 限定输出的提交信息与`--grep=<pattern>指定的模式不匹配。

note: type: Plain text
en: Match the regular expression limiting patterns without regard to letter case.
zh_HANS-CN: 匹配正则表达式的限制模式，不考虑字母大小写。

note: type: Plain text
en: Consider the limiting patterns to be basic regular expressions; this is the default.
zh_HANS-CN: 将限制性模式视为基本的正则表达式；这是默认的。

note: type: Plain text
en: Consider the limiting patterns to be extended regular expressions instead of the default basic regular expressions.
zh_HANS-CN: 将限制性模式视为扩展的正则表达式，而不是默认的基本正则表达式。

note: type: Plain text
en: Consider the limiting patterns to be fixed strings (don't interpret pattern as a regular expression).
zh_HANS-CN: 将限制性模式视为固定字符串（不要将模式解释为正则表达式）。

note: type: Plain text
en: Consider the limiting patterns to be Perl-compatible regular expressions.
zh_HANS-CN: 将限制性模式视为与Perl兼容的正则表达式。

note: type: Plain text
en: Stop when a given path disappears from the tree.
zh_HANS-CN: 当一个给定的路径从树上消失时停止。

note: type: Plain text
en: Print only merge commits. This is exactly the same as `--min-parents=2`.
zh_HANS-CN: 只打印合并后的提交。这与`--min-parents=2`完全相同。

note: type: Plain text
en: Do not print commits with more than one parent. This is exactly the same as `--max-parents=1`.
zh_HANS-CN: 不打印有一个以上父级的提交。这与`--max-parents=1`完全相同。

note: type: Plain text
en: Show only commits which have at least (or at most) that many parent commits. In particular, `--max-parents=1` is the same as `--no-merges`, `--min-parents=2` is the same as `--merges`.  `--max-parents=0` gives all root commits and `--min-parents=3` all octopus merges.
zh_HANS-CN: 只显示至少（或最多）有那么多父提交的提交。特别是，`--max-parents=1`等同于`--no-merges`，`--min-parents=2`等同于`--merges`。  `--max-parents=0`给出所有根提交，`--min-parents=3`给出所有章鱼合并。

note: type: Plain text
en: This option also changes default diff format for merge commits to `first-parent`, see `--diff-merges=first-parent` for details.
zh_HANS-CN: 这个选项也改变了合并提交的默认差异格式为 "first-parent"，详见"-diff-merges=first-parent"。

note: type: Plain text
en: When finding commits to exclude (with a '{caret}'), follow only the first parent commit upon seeing a merge commit.  This can be used to find the set of changes in a topic branch from the point where it diverged from the remote branch, given that arbitrary merges can be valid topic branch changes.
zh_HANS-CN: 在寻找要排除的提交（用'{caret}'）时，在看到合并提交时只跟随第一个父提交。  考虑到任意的合并都可以成为有效的主题分支变化，这可以用来查找主题分支中从它与远程分支的分歧点开始的变化集合。

note: type: Plain text
en: Reverses the meaning of the '{caret}' prefix (or lack thereof)  for all following revision specifiers, up to the next `--not`.
zh_HANS-CN: 颠倒"{caret}"前缀（或没有前缀）对所有后续修订指定符的意义，直到下一个`--not`。

note: type: Plain text
en: Pretend as if all the refs in `refs/`, along with `HEAD`, are listed on the command line as '<commit>'.
zh_HANS-CN: 假设`refs/`中的所有参考文献，连同`HEAD`一起，在命令行中被列为'<commit>'。

note: type: Labeled list
en: --branches[=<pattern>]
zh_HANS-CN: --支部[=<模式>]

note: type: Plain text
en: Pretend as if all the refs in `refs/heads` are listed on the command line as '<commit>'. If '<pattern>' is given, limit branches to ones matching given shell glob. If pattern lacks '?', '{asterisk}', or '[', '/{asterisk}' at the end is implied.
zh_HANS-CN: 假设`refs/heads`中的所有 refs 在命令行中被列为 '<commit>'。如果给出了'<pattern>'，将分支限制在与给定的shell glob相匹配的分支。如果pattern缺少'?'、'{asterisk}'或'['，则末尾的'/{asterisk}'是暗示的。

note: type: Plain text
en: Pretend as if all the refs in `refs/tags` are listed on the command line as '<commit>'. If '<pattern>' is given, limit tags to ones matching given shell glob. If pattern lacks '?', '{asterisk}', or '[', '/{asterisk}' at the end is implied.
zh_HANS-CN: 假设`refs/tags`中的所有参考文献在命令行中被列为'<commit>'。如果给出了'<pattern>'，将标签限制在与给定的shell glob相匹配的标签。如果pattern缺少'?'、'{asterisk}'或'['，则暗示最后的'/{asterisk}'。

note: type: Plain text
en: Pretend as if all the refs in `refs/remotes` are listed on the command line as '<commit>'. If '<pattern>' is given, limit remote-tracking branches to ones matching given shell glob.  If pattern lacks '?', '{asterisk}', or '[', '/{asterisk}' at the end is implied.
zh_HANS-CN: 假设`refs/remotes`中的所有 refs 在命令行中被列为 '<commit>'。如果给出了'<pattern>'，将远程跟踪分支限制在与给定的shell glob相匹配的分支。  如果pattern缺少'?'、'{asterisk}'或'['，则末尾的'/{asterisk}'是暗示的。

note: type: Plain text
en: Pretend as if all the refs matching shell glob '<glob-pattern>' are listed on the command line as '<commit>'. Leading 'refs/', is automatically prepended if missing. If pattern lacks '?', '{asterisk}', or '[', '/{asterisk}' at the end is implied.
zh_HANS-CN: 假设所有与shell glob '<glob-pattern>相匹配的refs在命令行中被列为'<commit>'。前面的'refs/'，如果缺少的话会自动预加。如果模式中缺少'?'、'{asterisk}'或'['，则在结尾处隐含'/{asterisk}'。

note: type: Plain text
en: Pretend as if all objects mentioned by reflogs are listed on the command line as `<commit>`.
zh_HANS-CN: 假设reflogs提到的所有对象都在命令行中被列为`<commit>`。

note: type: Plain text
en: Pretend as if all objects mentioned as ref tips of alternate repositories were listed on the command line. An alternate repository is any repository whose object directory is specified in `objects/info/alternates`.  The set of included objects may be modified by `core.alternateRefsCommand`, etc. See linkgit:git-config[1].
zh_HANS-CN: 假设所有提到的作为备用仓库的参考提示的对象都列在命令行上。备用资源库是任何资源库，其对象目录在`objects/info/alternates`中指定。  包含的对象集可以通过`core.alternateRefsCommand`等修改。见linkgit:git-config[1]。

note: type: Plain text
en: By default, all working trees will be examined by the following options when there are more than one (see linkgit:git-worktree[1]): `--all`, `--reflog` and `--indexed-objects`.  This option forces them to examine the current working tree only.
zh_HANS-CN: 默认情况下，当有多个工作树时，所有工作树都会被以下选项检查（见linkgit:git-worktree[1]）：`--all`，`--reflog`和`--indexed-objects`。  这个选项强制它们只检查当前的工作树。

note: type: Plain text
en: Upon seeing an invalid object name in the input, pretend as if the bad input was not given.
zh_HANS-CN: 在看到输入中无效的对象名称时，假装没有给出坏的输入。

note: type: Plain text
en: Pretend as if the bad bisection ref `refs/bisect/bad` was listed and as if it was followed by `--not` and the good bisection refs `refs/bisect/good-*` on the command line.
zh_HANS-CN: 假设坏的二分法参考文献`refs/bisect/bad`被列出，并且在命令行中假设它后面是`--not`和好的二分法参考文献`refs/bisect/good-*`。

note: type: Plain text
en: Don't print anything to standard output.  This form is primarily meant to allow the caller to test the exit status to see if a range of objects is fully connected (or not).  It is faster than redirecting stdout to `/dev/null` as the output does not have to be formatted.
zh_HANS-CN: 不要打印任何东西到标准输出。  这种形式主要是为了让调用者测试退出状态，看看一系列的对象是否完全连接（或没有）。  它比将stdout重定向到`/dev/null`要快，因为输出不需要被格式化。

note: type: Plain text
en: Like `--cherry-pick` (see below) but mark equivalent commits with `=` rather than omitting them, and inequivalent ones with `+`.
zh_HANS-CN: 就像`--cherry-pick`（见下文），但用`=`标记同等的提交，而不是省略，用`+`标记不同等的提交。

note: type: Plain text
en: Omit any commit that introduces the same change as another commit on the ``other side'' when the set of commits are limited with symmetric difference.
zh_HANS-CN: 当提交的集合有对称差异时，省略任何与 "另一边 "的另一个提交相同的提交。

note: type: Plain text
en: For example, if you have two branches, `A` and `B`, a usual way to list all commits on only one side of them is with `--left-right` (see the example below in the description of the `--left-right` option). However, it shows the commits that were cherry-picked from the other branch (for example, ``3rd on b'' may be cherry-picked from branch A). With this option, such pairs of commits are excluded from the output.
zh_HANS-CN: 例如，如果你有两个分支，`A`和`B`，通常的方法是用`--左--右`列出其中一边的所有提交（见下面关于`--左--右`选项的描述）。然而，它显示的是从另一个分支中偷梁换柱的提交（例如，"3rd on b "可能是从分支A中偷梁换柱的）。有了这个选项，这样的提交对将从输出中排除。

note: type: Plain text
en: List only commits on the respective side of a symmetric difference, i.e. only those which would be marked `<` resp. `>` by `--left-right`.
zh_HANS-CN: 只列出对称性差异各自一侧的提交，即只列出那些通过"--左--右 "标记的"<"或">"。

note: type: Plain text
en: For example, `--cherry-pick --right-only A...B` omits those commits from `B` which are in `A` or are patch-equivalent to a commit in `A`. In other words, this lists the `+` commits from `git cherry A B`.  More precisely, `--cherry-pick --right-only --no-merges` gives the exact list.
zh_HANS-CN: 例如，`--cherry-pick --right-only A...B`省略了`B`中那些在`A`中的提交或与`A`中的提交相等的补丁。换句话说，它列出了 "git cherry A B "的 "+"的提交。  更准确地说，`--cherry-pick --right-only --no-merges`可以得到准确的列表。

note: type: Plain text
en: A synonym for `--right-only --cherry-mark --no-merges`; useful to limit the output to the commits on our side and mark those that have been applied to the other side of a forked history with `git log --cherry upstream...mybranch`, similar to `git cherry upstream mybranch`.
zh_HANS-CN: `--right-only --cherry-mark --no-merges`的同义词；有助于将输出限制在我们这边的提交，并标记那些已经应用到分叉历史的另一边的提交，`git log --cherry upstream...mybranch`，类似于`git cherry upstream mybranch`。

note: type: Plain text
en: Instead of walking the commit ancestry chain, walk reflog entries from the most recent one to older ones.  When this option is used you cannot specify commits to exclude (that is, '{caret}commit', 'commit1..commit2', and 'commit1\...commit2' notations cannot be used).
zh_HANS-CN: 不走提交祖先链，而走从最近的提交到更早的提交的reflog条目。  使用这个选项时，你不能指定要排除的提交（也就是说，不能使用'{caret}commit'、'commit1...commit2'和'commit1/...commit2'的符号）。

note: type: Plain text
en: With `--pretty` format other than `oneline` and `reference` (for obvious reasons), this causes the output to have two extra lines of information taken from the reflog.  The reflog designator in the output may be shown as `ref@{Nth}` (where `Nth` is the reverse-chronological index in the reflog) or as `ref@{timestamp}` (with the timestamp for that entry), depending on a few rules:
zh_HANS-CN: 在`--pretty`格式下，除了`oneline`和`reference`（由于明显的原因），这将导致输出有两行额外的信息来自reflog。  输出中的reflog代号可以显示为`ref@{Nth}`（其中`Nth`是reflog中的逆序索引）或`ref@{timestamp}`（带有该条目的时间戳），取决于一些规则。

note: type: Plain text
en: If the starting point is specified as `ref@{Nth}`, show the index format.
zh_HANS-CN: 如果起点被指定为`ref@{Nth}`，显示索引格式。

note: type: Plain text
en: If the starting point was specified as `ref@{now}`, show the timestamp format.
zh_HANS-CN: 如果起点被指定为`ref@{now}`，显示时间戳格式。

note: type: Plain text
en: If neither was used, but `--date` was given on the command line, show the timestamp in the format requested by `--date`.
zh_HANS-CN: 如果两者都没有使用，但在命令行中给出了`--date`，则按照`--date`所要求的格式显示时间戳。

note: type: Plain text
en: Otherwise, show the index format.
zh_HANS-CN: 否则，显示索引格式。

note: type: Plain text
en: Under `--pretty=oneline`, the commit message is prefixed with this information on the same line.  This option cannot be combined with `--reverse`.  See also linkgit:git-reflog[1].
zh_HANS-CN: 在`--pretty=oneline`下，提交信息的前缀是同一行中的这些信息。  这个选项不能与 `--reverse`结合使用。  参见 linkgit:git-reflog[1]。

note: type: Plain text
en: Under `--pretty=reference`, this information will not be shown at all.
zh_HANS-CN: 在`--pretty=reference`下，这些信息将完全不显示。

note: type: Plain text
en: After a failed merge, show refs that touch files having a conflict and don't exist on all heads to merge.
zh_HANS-CN: 在合并失败后，显示触及有冲突的文件且不存在于所有要合并的头的参考文件。

note: type: Plain text
en: Output excluded boundary commits. Boundary commits are prefixed with `-`.
zh_HANS-CN: 输出排除的边界提交。边界提交的前缀是"-"。

note: type: Plain text
en: Try to speed up the traversal using the pack bitmap index (if one is available). Note that when traversing with `--objects`, trees and blobs will not have their associated path printed.
zh_HANS-CN: 尝试使用包位图索引（如果有的话）来加快遍历的速度。注意，当使用`--对象`进行遍历时，树和blobs不会打印出它们的相关路径。

note: type: Labeled list
en: --progress=<header>
zh_HANS-CN: --progress=<header>。

note: type: Plain text
en: Show progress reports on stderr as objects are considered. The `<header>` text will be printed with each progress update.
zh_HANS-CN: 在考虑对象时在stderr上显示进度报告。`<标题>`文本将在每次进度更新时打印。

note: type: Title ~
en: History Simplification
zh_HANS-CN: 简化历史

note: type: Plain text
en: Sometimes you are only interested in parts of the history, for example the commits modifying a particular <path>. But there are two parts of 'History Simplification', one part is selecting the commits and the other is how to do it, as there are various strategies to simplify the history.
zh_HANS-CN: 有时你只对历史的一部分感兴趣，例如修改某个<路径>的提交。但 "历史简化 "有两部分，一部分是选择提交，另一部分是如何做，因为有各种策略来简化历史。

note: type: Plain text
en: The following options select the commits to be shown:
zh_HANS-CN: 以下选项选择要显示的提交。

note: type: Plain text
en: Commits modifying the given <paths> are selected.
zh_HANS-CN: 修改给定<路径>的提交会被选中。

note: type: Plain text
en: Commits that are referred by some branch or tag are selected.
zh_HANS-CN: 被某个分支或标签引用的提交被选中。

note: type: Plain text
en: Note that extra commits can be shown to give a meaningful history.
zh_HANS-CN: 请注意，可以显示额外的提交，以提供一个有意义的历史。

note: type: Plain text
en: The following options affect the way the simplification is performed:
zh_HANS-CN: 以下选项会影响简化的执行方式。

note: type: Plain text
en: Simplifies the history to the simplest history explaining the final state of the tree. Simplest because it prunes some side branches if the end result is the same (i.e. merging branches with the same content)
zh_HANS-CN: 将历史简化为解释树的最终状态的最简单的历史。最简单的原因是，如果最终结果相同，它会修剪一些侧枝（即合并具有相同内容的分支）。

note: type: Plain text
en: Include all commits from the default mode, but also any merge commits that are not TREESAME to the first parent but are TREESAME to a later parent. This mode is helpful for showing the merge commits that "first introduced" a change to a branch.
zh_HANS-CN: 包括默认模式下的所有提交，但也包括任何与第一个父分支不相干但与后来的父分支相干的合并提交。这种模式有助于显示 "首次引入 "某个分支的合并提交。

note: type: Plain text
en: Same as the default mode, but does not prune some history.
zh_HANS-CN: 与默认模式相同，但不修剪一些历史记录。

note: type: Plain text
en: Only the selected commits are shown, plus some to have a meaningful history.
zh_HANS-CN: 只显示所选的提交，再加上一些才有意义的历史。

note: type: Plain text
en: All commits in the simplified history are shown.
zh_HANS-CN: 简化历史中的所有提交都会显示出来。

note: type: Plain text
en: Additional option to `--full-history` to remove some needless merges from the resulting history, as there are no selected commits contributing to this merge.
zh_HANS-CN: 为`--full-history`增加了一个选项，可以从结果的历史中删除一些不必要的合并，因为没有选定的提交对这次合并有贡献。

note: type: Plain text
en: A more detailed explanation follows.
zh_HANS-CN: 以下是更详细的解释。

note: type: Plain text
en: Suppose you specified `foo` as the <paths>.  We shall call commits that modify `foo` !TREESAME, and the rest TREESAME.  (In a diff filtered for `foo`, they look different and equal, respectively.)
zh_HANS-CN: 假设你指定了`foo`作为<paths>。  我们将把修改`foo`的提交称为 !TREESAME，其余的称为 TREESAME。  (在为`foo`过滤的diff中，它们看起来分别是不同的和相同的)。

note: type: Plain text
en: In the following, we will always refer to the same example history to illustrate the differences between simplification settings.  We assume that you are filtering for a file `foo` in this commit graph:
zh_HANS-CN: 在下文中，我们将始终引用同一个历史实例来说明简化设置之间的差异。  我们假设你在这个提交图中过滤的是一个文件`foo`。

note: type: Plain text
en: The horizontal line of history A---Q is taken to be the first parent of each merge.  The commits are:
zh_HANS-CN: 历史A---Q的横线被认为是每次合并的第一个父本。  这些提交是

note: type: Plain text
en: `I` is the initial commit, in which `foo` exists with contents ``asdf'', and a file `quux` exists with contents ``quux''. Initial commits are compared to an empty tree, so `I` is !TREESAME.
zh_HANS-CN: `I`是初始提交，其中`foo`存在，内容是`asdf''，文件`quux`存在，内容是`quux''。初始提交与空树比较，所以`I`是！`TREESAME。

note: type: Plain text
en: In `A`, `foo` contains just ``foo''.
zh_HANS-CN: 在`A`中，`foo`只包含`foo''。

note: type: Plain text
en: `B` contains the same change as `A`.  Its merge `M` is trivial and hence TREESAME to all parents.
zh_HANS-CN: `B`包含与`A`相同的变化。  它的合并`M`是微不足道的，因此对所有父类来说是TREESAME。

note: type: Plain text
en: `C` does not change `foo`, but its merge `N` changes it to ``foobar'', so it is not TREESAME to any parent.
zh_HANS-CN: `C`没有改变`foo`，但是它的合并`N`将其改为`foobar''，所以它与任何父类都不存在TREESAME。

note: type: Plain text
en: `D` sets `foo` to ``baz''. Its merge `O` combines the strings from `N` and `D` to ``foobarbaz''; i.e., it is not TREESAME to any parent.
zh_HANS-CN: `D`将`foo`设置为`baz''。它的合并项`O`将`N`和`D`的字符串合并为`foobarbaz''；也就是说，它与任何父类都不是TREESAME。

note: type: Plain text
en: `E` changes `quux` to ``xyzzy'', and its merge `P` combines the strings to ``quux xyzzy''. `P` is TREESAME to `O`, but not to `E`.
zh_HANS-CN: `E`将`quux`改为`xyzzy''，其合并的`P`将这些字符串合并为`quux xyzzy''。`P'与`O'的关系是TREESAME，但与`E'不是。

note: type: Plain text
en: `X` is an independent root commit that added a new file `side`, and `Y` modified it. `Y` is TREESAME to `X`. Its merge `Q` added `side` to `P`, and `Q` is TREESAME to `P`, but not to `Y`.
zh_HANS-CN: `X`是一个独立的根提交，添加了一个新文件`side`，`Y`修改了它。`Y`与`X`同为TREESAME。它的合并文件`Q`在`P`上添加了`side`，`Q`与`P`是同源，但与`Y`不是同源。

note: type: Plain text
en: `rev-list` walks backwards through history, including or excluding commits based on whether `--full-history` and/or parent rewriting (via `--parents` or `--children`) are used. The following settings are available.
zh_HANS-CN: `rev-list`在历史中倒退，根据是否使用`--full-history`和/或父代重写（通过`--parents`或`--children`），包括或排除提交。以下设置是可用的。

note: type: Plain text
en: Commits are included if they are not TREESAME to any parent (though this can be changed, see `--sparse` below).  If the commit was a merge, and it was TREESAME to one parent, follow only that parent.  (Even if there are several TREESAME parents, follow only one of them.)  Otherwise, follow all parents.
zh_HANS-CN: 如果提交的内容与任何父类不相干，则被包括在内（当然这一点可以改变，见下面的`--sparse`）。  如果该提交是一个合并，并且它与一个父类是同源的，则只跟随该父类。  (即使有几个TREESAME父类，也只跟随其中一个。) 否则，跟随所有父类。

note: type: Plain text
en: Note how the rule to only follow the TREESAME parent, if one is available, removed `B` from consideration entirely.  `C` was considered via `N`, but is TREESAME.  Root commits are compared to an empty tree, so `I` is !TREESAME.
zh_HANS-CN: 请注意，如果有TREESAME父类的话，只遵循TREESAME父类的规则，将`B'完全排除在考虑之外。  `C`是通过`N`考虑的，但也是TREESAME。  根提交是与空树比较的，所以`I`是!!TREESAME。

note: type: Plain text
en: Parent/child relations are only visible with `--parents`, but that does not affect the commits selected in default mode, so we have shown the parent lines.
zh_HANS-CN: 父/子关系只有在`--父母`的情况下才能看到，但这并不影响在默认模式下选择的提交，所以我们显示了父行。

note: type: Plain text
en: This mode differs from the default in one point: always follow all parents of a merge, even if it is TREESAME to one of them.  Even if more than one side of the merge has commits that are included, this does not imply that the merge itself is! In the example, we get
zh_HANS-CN: 这种模式与默认模式有一点不同：总是跟随一个合并的所有父本，即使它与其中一个父本是TREESAME。  即使合并的一方有多个提交被包括在内，这也不意味着合并本身也是如此在这个例子中，我们得到

note: type: Plain text
en: `M` was excluded because it is TREESAME to both parents.  `E`, `C` and `B` were all walked, but only `B` was !TREESAME, so the others do not appear.
zh_HANS-CN: `M'被排除在外，因为它与父母都是TREESAME。  `E'、`C'和`B'都走了，但只有`B'是！"TREESAME"，所以其他的都没有出现。

note: type: Plain text
en: Note that without parent rewriting, it is not really possible to talk about the parent/child relationships between the commits, so we show them disconnected.
zh_HANS-CN: 请注意，如果没有父子重写，其实是不可能谈论提交之间的父子关系的，所以我们显示它们是不相连的。

note: type: Plain text
en: Ordinary commits are only included if they are !TREESAME (though this can be changed, see `--sparse` below).
zh_HANS-CN: 普通的提交只有当它们是！TREESAME时才会被包括在内（尽管这一点可以改变，见下面的`--sparse`）。

note: type: Plain text
en: Merges are always included.  However, their parent list is rewritten: Along each parent, prune away commits that are not included themselves.  This results in
zh_HANS-CN: 合并总是被包括在内。  然而，他们的父级列表会被重写。沿着每个父级，修剪掉那些不包括自己的提交。  这样做的结果是

note: type: Plain text
en: Compare to `--full-history` without rewriting above.  Note that `E` was pruned away because it is TREESAME, but the parent list of P was rewritten to contain `E`'s parent `I`.  The same happened for `C` and `N`, and `X`, `Y` and `Q`.
zh_HANS-CN: 与上面的`--full-history`相比，没有重写。  请注意，`E`被修剪掉了，因为它是TREESAME，但是P的父列表被改写为包含`E`的父`I`。  同样的情况发生在`C`和`N`，以及`X`、`Y`和`Q`。

note: type: Plain text
en: In addition to the above settings, you can change whether TREESAME affects inclusion:
zh_HANS-CN: 除了上述设置外，你还可以改变TRESAME是否会影响收录。

note: type: Plain text
en: Commits that are walked are included if they are not TREESAME to any parent.
zh_HANS-CN: 如果不与任何父类有TREESAME关系，则包括走过的承诺。

note: type: Plain text
en: All commits that are walked are included.
zh_HANS-CN: 所有走过的提交都包括在内。

note: type: Plain text
en: Note that without `--full-history`, this still simplifies merges: if one of the parents is TREESAME, we follow only that one, so the other sides of the merge are never walked.
zh_HANS-CN: 请注意，如果没有`--full-history`，这仍然可以简化合并：如果父代之一是TREESAME，我们只跟随这个父代，所以合并的其他方面永远不会被走。

note: type: Plain text
en: First, build a history graph in the same way that `--full-history` with parent rewriting does (see above).
zh_HANS-CN: 首先，按照`--full-history`与父级改写的相同方式建立一个历史图（见上文）。

note: type: Plain text
en: Then simplify each commit `C` to its replacement `C'` in the final history according to the following rules:
zh_HANS-CN: 然后根据以下规则将每个提交的`C'简化为最终历史中的替换`C'。

note: type: Plain text
en: Set `C'` to `C`.
zh_HANS-CN: 将 "C "设为 "C"。

note: type: Plain text
en: Replace each parent `P` of `C'` with its simplification `P'`.  In the process, drop parents that are ancestors of other parents or that are root commits TREESAME to an empty tree, and remove duplicates, but take care to never drop all parents that we are TREESAME to.
zh_HANS-CN: 将`C'`的每个父类`P'替换成其简化的`P'`。  在这个过程中，放弃那些是其他父类的祖先的父类，或者是根部提交TREESAME的空树，并删除重复的父类，但注意不要放弃所有我们是TREESAME的父类。

note: type: Plain text
en: If after this parent rewriting, `C'` is a root or merge commit (has zero or >1 parents), a boundary commit, or !TREESAME, it remains.  Otherwise, it is replaced with its only parent.
zh_HANS-CN: 如果在这次父级改写之后，`C'`是一个根或合并提交（有0个或>1个父级），一个边界提交，或！TREESAME，那么它将被保留。  否则，它将被替换为其唯一的父类。

note: type: Plain text
en: The effect of this is best shown by way of comparing to `--full-history` with parent rewriting.  The example turns into:
zh_HANS-CN: 通过与`--full-history`的父级改写进行比较，可以最好地显示其效果。  这个例子变成了。

note: type: Plain text
en: Note the major differences in `N`, `P`, and `Q` over `--full-history`:
zh_HANS-CN: 注意`N'、`P'和`Q'与`--full-history'的主要区别。

note: type: Plain text
en: `N`'s parent list had `I` removed, because it is an ancestor of the other parent `M`.  Still, `N` remained because it is !TREESAME.
zh_HANS-CN: `N`的父列表中删除了`I`，因为它是另一个父`M`的一个祖先。  但是，`N`仍然存在，因为它是!TREESAME。

note: type: Plain text
en: `P`'s parent list similarly had `I` removed.  `P` was then removed completely, because it had one parent and is TREESAME.
zh_HANS-CN: `P`的父级列表也同样删除了`I`。  然后`P`被完全删除，因为它有一个父本，并且是TREESAME。

note: type: Plain text
en: `Q`'s parent list had `Y` simplified to `X`. `X` was then removed, because it was a TREESAME root. `Q` was then removed completely, because it had one parent and is TREESAME.
zh_HANS-CN: `Q`的父列表中有`Y`简化为`X`。然后`X`被删除，因为它是一个TREESAME根。然后`Q`被完全删除，因为它有一个父级，是TREESAME。

note: type: Plain text
en: There is another simplification mode available:
zh_HANS-CN: 还有一种简化模式可用。

note: type: Plain text
en: Limit the displayed commits to those which are an ancestor of <commit>, or which are a descendant of <commit>, or are <commit> itself.
zh_HANS-CN: 将显示的提交限制在<提交>的祖先，或<提交>的后代，或<提交>本身。

note: type: Plain text
en: As an example use case, consider the following commit history:
zh_HANS-CN: 作为一个用例，请考虑以下提交历史：

note: type: delimited block -
en: 	    D---E-------F
    	   /     \       \
    	  B---C---G---H---I---J
    	 /                     \
    	A-------K---------------L--M
zh_HANS-CN: 	    D--E-------F
    	   / \ \
    	  B---C---G---H---I---J
    	 / \
    	A-------K---------------L--M

note: type: Plain text
en: A regular 'D..M' computes the set of commits that are ancestors of `M`, but excludes the ones that are ancestors of `D`. This is useful to see what happened to the history leading to `M` since `D`, in the sense that ``what does `M` have that did not exist in `D`''. The result in this example would be all the commits, except `A` and `B` (and `D` itself, of course).
zh_HANS-CN: 有规律的 "D...M "会计算出作为`M`的祖先的提交集合，但不包括作为`D`的祖先的提交。这对了解`M'的历史在`D'之后发生了什么很有用，也就是说`M'有什么东西是`D'没有的'。这个例子中的结果是所有的提交，除了`A`和`B`（当然还有`D`本身）。

note: type: Plain text
en: When we want to find out what commits in `M` are contaminated with the bug introduced by `D` and need fixing, however, we might want to view only the subset of 'D..M' that are actually descendants of `D`, i.e.  excluding `C` and `K`. This is exactly what the `--ancestry-path` option does. Applied to the 'D..M' range, it results in:
zh_HANS-CN: 然而，当我们想找出`M'中哪些提交被`D'引入的错误所污染而需要修复时，我们可能只想查看'D...M'中实际上是`D'的后代的子集，即排除`C'和`K'。这正是`--ancestry-path`选项的作用。应用于'D...M'范围，它的结果是：

note: type: delimited block -
en: 		E-------F
    		 \       \
    		  G---H---I---J
    			       \
    				L--M
zh_HANS-CN: 		E-------F
    		 \ \
    		  G--H--I--J
    			       \
    				L--M

note: type: Plain text
en: We can also use `--ancestry-path=D` instead of `--ancestry-path` which means the same thing when applied to the 'D..M' range but is just more explicit.
zh_HANS-CN: 我们也可以用`--ancestry-path=D`来代替`--ancestry-path`，这在应用于'D...M'范围时意思相同，只是更加明确。

note: type: Plain text
en: If we instead are interested in a given topic within this range, and all commits affected by that topic, we may only want to view the subset of `D..M` which contain that topic in their ancestry path.  So, using `--ancestry-path=H D..M` for example would result in:
zh_HANS-CN: 如果我们感兴趣的是这个范围内的某个主题，以及受该主题影响的所有提交，我们可能只想查看祖先路径中包含该主题的`D...M`子集。  因此，以`--ancestry-path=H D...M`为例，会形成以下结果：

note: type: Plain text
en: Whereas `--ancestry-path=K D..M` would result in
zh_HANS-CN: 而`--ancestry-path=K D...M`会形成以下结果

note: type: Plain text
en: Before discussing another option, `--show-pulls`, we need to create a new example history.
zh_HANS-CN: 在讨论另一个选项，`--show-pulls`之前，我们需要创建一个新的历史实例。

note: type: Plain text
en: A common problem users face when looking at simplified history is that a commit they know changed a file somehow does not appear in the file's simplified history. Let's demonstrate a new example and show how options such as `--full-history` and `--simplify-merges` works in that case:
zh_HANS-CN: 用户在查看简化的提交历史时经常遇到的一个问题是，他们知道的对某个文件的修改提交并没有出现在该文件的简史中。让我们演示一个新的例子，并说明`--full-history`和`--simplify-merges`等选项在这种情况下是如何工作的：

note: type: Plain text
en: For this example, suppose `I` created `file.txt` which was modified by `A`, `B`, and `X` in different ways. The single-parent commits `C`, `Z`, and `Y` do not change `file.txt`. The merge commit `M` was created by resolving the merge conflict to include both changes from `A` and `B` and hence is not TREESAME to either. The merge commit `R`, however, was created by ignoring the contents of `file.txt` at `M` and taking only the contents of `file.txt` at `X`. Hence, `R` is TREESAME to `X` but not `M`. Finally, the natural merge resolution to create `N` is to take the contents of `file.txt` at `R`, so `N` is TREESAME to `R` but not `C`.  The merge commits `O` and `P` are TREESAME to their first parents, but not to their second parents, `Z` and `Y` respectively.
zh_HANS-CN: 在这个例子中，假设`I`创建了`file.txt`，并被`A`、`B`和`X`以不同方式修改。单亲提交的`C`、`Z`和`Y`没有修改`file.txt`。合并提交 `M`是通过解决合并冲突而产生的，包括了 `A `和 `B `的修改，因此与其中任何一个都不是同源的。然而，合并提交`R`是通过忽略`M`处的`file.txt`的内容，而只采用`X`处的`file.txt`的内容而产生的。因此，`R`与`X`是同源的，但不是`M`。最后，创建`N'的自然合并决议是取`file.txt`在`R'的内容，所以`N'与`R`是同源的，但不是`C`。  合并提交的  `O` 和 `P` 与它们的第一代父母是同源的，但与它们的第二代父母 `Z` 和 `Y `则不是同源的。

note: type: Plain text
en: When using the default mode, `N` and `R` both have a TREESAME parent, so those edges are walked and the others are ignored. The resulting history graph is:
zh_HANS-CN: 当使用默认模式时，`N'和`R`都有一个TREESAME父级，所以这些边被展示出来，其他边被忽略。由此产生的历史图是：

note: type: delimited block -
en: 	I---X
zh_HANS-CN: 	I--X

note: type: Plain text
en: When using `--full-history`, Git walks every edge. This will discover the commits `A` and `B` and the merge `M`, but also will reveal the merge commits `O` and `P`. With parent rewriting, the resulting graph is:
zh_HANS-CN: 当使用`--full-history`时，Git会行走每条边。这将发现提交`A`和`B`以及合并`M`，但也将揭示合并提交`O`和`P`。通过父级改写，得到的图是。

note: type: Plain text
en: When using the `--simplify-merges` option, the commits `O` and `P` disappear from the results. This is because the rewritten second parents of `O` and `P` are reachable from their first parents. Those edges are removed and then the commits look like single-parent commits that are TREESAME to their parent. This also happens to the commit `N`, resulting in a history view as follows:
zh_HANS-CN: 当使用`--简化合并`选项时，提交的`O`和`P`从结果中消失。这是因为 "O "和 "P "重写的第二父本可以从它们的第一父本到达。这些边被移除，然后这些提交看起来就像与它们的父类一样的单亲提交。这也发生在提交`N`上，导致历史视图如下。

note: type: Plain text
en: In this view, we see all of the important single-parent changes from `A`, `B`, and `X`. We also see the carefully-resolved merge `M` and the not-so-carefully-resolved merge `R`. This is usually enough information to determine why the commits `A` and `B` "disappeared" from history in the default view. However, there are a few issues with this approach.
zh_HANS-CN: 在这个视图中，我们看到了所有来自`A`，`B`和`X`的重要单亲变化。我们还可以看到仔细解决的合并`M`和不那么仔细解决的合并`R`。这些信息通常足以确定为什么`A`和`B`的提交在默认视图中从历史中 "消失 "了。然而，这种方法也有一些问题。

note: type: Plain text
en: The first issue is performance. Unlike any previous option, the `--simplify-merges` option requires walking the entire commit history before returning a single result. This can make the option difficult to use for very large repositories.
zh_HANS-CN: 第一个问题是性能。与之前的任何选项不同，`--简化合并'选项需要在返回一个结果之前走完整个提交历史。这可能使该选项难以用于非常大的仓库。

note: type: Plain text
en: The second issue is one of auditing. When many contributors are working on the same repository, it is important which merge commits introduced a change into an important branch. The problematic merge `R` above is not likely to be the merge commit that was used to merge into an important branch. Instead, the merge `N` was used to merge `R` and `X` into the important branch. This commit may have information about why the change `X` came to override the changes from `A` and `B` in its commit message.
zh_HANS-CN: 第二个问题是审计的问题。当许多贡献者在同一个版本库中工作时，哪些合并提交将一个变化引入到一个重要的分支是很重要的。上面有问题的合并`R`不可能是用来合并到一个重要分支的合并提交。相反，`N'是用来将`R'和`X'合并到重要分支的。这个提交可能有关于为什么`X'会覆盖`A'和`B'的修改的信息，在其提交信息中。

note: type: Plain text
en: In addition to the commits shown in the default history, show each merge commit that is not TREESAME to its first parent but is TREESAME to a later parent.
zh_HANS-CN: 除了在默认历史中显示的提交之外，还要显示每一个与第一个父本不相同但与后来的父本相同的合并提交。

note: type: Plain text
en: When a merge commit is included by `--show-pulls`, the merge is treated as if it "pulled" the change from another branch. When using `--show-pulls` on this example (and no other options) the resulting graph is:
zh_HANS-CN: 当一个合并提交被`--show-pulls`包含时，该合并被视为从另一个分支 "拉 "来的修改。在这个例子中使用`--show-pulls`时（没有其他选项），得到的图表是。

note: type: delimited block -
en: 	I---X---R---N
zh_HANS-CN: 	I--X--R--N

note: type: Plain text
en: Here, the merge commits `R` and `N` are included because they pulled the commits `X` and `R` into the base branch, respectively. These merges are the reason the commits `A` and `B` do not appear in the default history.
zh_HANS-CN: 这里，合并后的提交`R`和`N`被包括在内，因为它们分别将提交`X`和`R`拉到了基础分支。这些合并是`A`和`B`的提交没有出现在默认历史中的原因。

note: type: Plain text
en: When `--show-pulls` is paired with `--simplify-merges`, the graph includes all of the necessary information:
zh_HANS-CN: 当`--show-pulls`与`--simplify-merges`配对时，该图包括所有必要的信息。

note: type: Plain text
en: Notice that since `M` is reachable from `R`, the edge from `N` to `M` was simplified away. However, `N` still appears in the history as an important commit because it "pulled" the change `R` into the main branch.
zh_HANS-CN: 请注意，由于`M`可以从`R`到达，从`N`到`M`的边被简化掉了。然而，`N`仍然作为一个重要的提交出现在历史中，因为它把`R`的修改 "拉 "进了主分支。

note: type: Plain text
en: The `--simplify-by-decoration` option allows you to view only the big picture of the topology of the history, by omitting commits that are not referenced by tags.  Commits are marked as !TREESAME (in other words, kept after history simplification rules described above) if (1) they are referenced by tags, or (2) they change the contents of the paths given on the command line.  All other commits are marked as TREESAME (subject to be simplified away).
zh_HANS-CN: `--按装饰简化'选项允许你只查看历史拓扑的全貌，省略那些没有被标签引用的提交。  如果(1)提交被标签引用，或者(2)提交改变了命令行上给出的路径内容，则被标记为！TREESAME（换句话说，按照上述历史简化规则保留）。  所有其他的提交都被标记为TREESAME（会被简化掉）。

note: type: Title ~
en: Bisection Helpers
zh_HANS-CN: 剖腹产助手

note: type: Plain text
en: Limit output to the one commit object which is roughly halfway between included and excluded commits. Note that the bad bisection ref `refs/bisect/bad` is added to the included commits (if it exists) and the good bisection refs `refs/bisect/good-*` are added to the excluded commits (if they exist). Thus, supposing there are no refs in `refs/bisect/`, if
zh_HANS-CN: 将输出限制在一个提交对象上，该对象大致在包含和排除的提交之间。请注意，坏的分界参考`refs/bisect/bad`会被添加到包含的提交中（如果它存在的话），好的分界参考`refs/bisect/good-*`会被添加到排除的提交中（如果它们存在的话）。因此，假设`refs/bisect/`中没有参考文献，如果

note: type: Plain text
en: outputs 'midpoint', the output of the two commands
zh_HANS-CN: 输出'midpoint'，即两个命令的输出。

note: type: Plain text
en: would be of roughly the same length.  Finding the change which introduces a regression is thus reduced to a binary search: repeatedly generate and test new 'midpoint's until the commit chain is of length one.
zh_HANS-CN: 的长度大致相同。  因此，找到引入回归的变化就变成了一个二进制搜索：反复生成和测试新的 "中点"，直到提交链的长度为1。

note: type: Plain text
en: This calculates the same as `--bisect`, except that refs in `refs/bisect/` are not used, and except that this outputs text ready to be eval'ed by the shell. These lines will assign the name of the midpoint revision to the variable `bisect_rev`, and the expected number of commits to be tested after `bisect_rev` is tested to `bisect_nr`, the expected number of commits to be tested if `bisect_rev` turns out to be good to `bisect_good`, the expected number of commits to be tested if `bisect_rev` turns out to be bad to `bisect_bad`, and the number of commits we are bisecting right now to `bisect_all`.
zh_HANS-CN: 这与`--bisect`的计算方法相同，只是不使用`refs/bisect/`中的参考文献，而且输出的文本可以被shell评估。这几行将把中点修订的名称分配给变量`bisect_rev`，并把`bisect_rev`测试后的预期提交数分配给`bisect_nr`。如果`bisect_rev'结果是好的，预计测试的提交数量为`bisect_good'，如果`bisect_rev'结果是坏的，预计测试的提交数量为`bisect_bad'，以及我们现在正在分叉的提交数量为`bisect_all'。

note: type: Plain text
en: This outputs all the commit objects between the included and excluded commits, ordered by their distance to the included and excluded commits. Refs in `refs/bisect/` are not used. The farthest from them is displayed first. (This is the only one displayed by `--bisect`.)
zh_HANS-CN: 这将输出包含的提交和排除的提交之间的所有提交对象，按照它们与包含的提交和排除的提交的距离排序。`refs/bisect/`中的参考文献不被使用。离它们最远的会先显示出来。这也是`--bisect`唯一显示的对象）。

note: type: Plain text
en: This is useful because it makes it easy to choose a good commit to test when you want to avoid to test some of them for some reason (they may not compile for example).
zh_HANS-CN: 这很有用，因为当你因为某些原因想避免测试某些提交时（例如，它们可能无法编译），可以很容易地选择一个好的提交来测试。

note: type: Plain text
en: This option can be used along with `--bisect-vars`, in this case, after all the sorted commit objects, there will be the same text as if `--bisect-vars` had been used alone.
zh_HANS-CN: 这个选项可以和`--bisect-vars`一起使用，在这种情况下，在所有排序的提交对象之后，会有和`--bisect-vars`单独使用一样的文本。

note: type: Title ~
en: Commit Ordering
zh_HANS-CN: 承诺订购

note: type: Plain text
en: By default, the commits are shown in reverse chronological order.
zh_HANS-CN: 默认情况下，提交的内容是按时间顺序倒序显示的。

note: type: Plain text
en: Show no parents before all of its children are shown, but otherwise show commits in the commit timestamp order.
zh_HANS-CN: 在显示所有子代之前不显示父代，否则按提交时间戳顺序显示提交。

note: type: Plain text
en: Show no parents before all of its children are shown, but otherwise show commits in the author timestamp order.
zh_HANS-CN: 在显示所有子代之前不显示父代，否则按作者时间戳顺序显示提交。

note: type: Plain text
en: Show no parents before all of its children are shown, and avoid showing commits on multiple lines of history intermixed.
zh_HANS-CN: 在显示所有子代之前不显示父代，并避免显示多行历史交错的提交。

note: type: Plain text
en: For example, in a commit history like this:
zh_HANS-CN: 例如，在这样的一个提交历史中。

note: type: Plain text
en: where the numbers denote the order of commit timestamps, `git rev-list` and friends with `--date-order` show the commits in the timestamp order: 8 7 6 5 4 3 2 1.
zh_HANS-CN: 其中数字表示提交时间戳的顺序，`git rev-list`和带有`--date-order`的朋友显示提交的时间戳顺序。8 7 6 5 4 3 2 1.

note: type: Plain text
en: With `--topo-order`, they would show 8 6 5 3 7 4 2 1 (or 8 7 4 2 6 5 3 1); some older commits are shown before newer ones in order to avoid showing the commits from two parallel development track mixed together.
zh_HANS-CN: 如果使用`--topo-order`，它们会显示8 6 5 3 7 4 2 1（或8 7 4 2 6 5 3 1）；一些较早的提交会显示在较新的提交之前，以避免显示两个平行开发轨道的提交混在一起。

note: type: Plain text
en: Output the commits chosen to be shown (see Commit Limiting section above) in reverse order. Cannot be combined with `--walk-reflogs`.
zh_HANS-CN: 以相反的顺序输出选择显示的提交（见上面的提交限制部分）。不能与`--walk-reflogs`结合使用。

note: type: Title ~
en: Object Traversal
zh_HANS-CN: 对象遍历

note: type: Plain text
en: These options are mostly targeted for packing of Git repositories.
zh_HANS-CN: 这些选项主要是针对Git存储库的打包。

note: type: Plain text
en: Print tree and blob ids in order of the commits. The tree and blob ids are printed after they are first referenced by a commit.
zh_HANS-CN: 按照提交的顺序打印树和blob的id。树和blob的id会在它们第一次被提交者引用后打印。

note: type: Plain text
en: Similar to `--objects`, but also print the IDs of excluded commits prefixed with a ``-'' character.  This is used by linkgit:git-pack-objects[1] to build a ``thin'' pack, which records objects in deltified form based on objects contained in these excluded commits to reduce network traffic.
zh_HANS-CN: 类似于 `--objects`，但也会打印被排除的提交物的 ID，前缀为 `-''字符。  这被 linkgit:git-pack-objects[1] 用来建立一个 "瘦身 "包，它基于这些被排除的提交中包含的对象，以删除的形式记录对象，以减少网络流量。

note: type: Plain text
en: Similar to `--objects-edge`, but it tries harder to find excluded commits at the cost of increased time.  This is used instead of `--objects-edge` to build ``thin'' packs for shallow repositories.
zh_HANS-CN: 类似于 `--objects-edge`，但它更努力地寻找被排除的提交，代价是增加时间。  它被用来代替`--objects-edge`，为浅层仓库建立 "薄 "的包。

note: type: Plain text
en: Pretend as if all trees and blobs used by the index are listed on the command line.  Note that you probably want to use `--objects`, too.
zh_HANS-CN: 假设索引使用的所有树和blobs都列在命令行中。  注意，你可能也想使用`--objects`。

note: type: Plain text
en: Only useful with `--objects`; print the object IDs that are not in packs.
zh_HANS-CN: 只对`---对象`有用；打印不在包中的对象ID。

note: type: Plain text
en: Only useful with `--objects`; print the names of the object IDs that are found. This is the default behavior. Note that the "name" of each object is ambiguous, and mostly intended as a hint for packing objects. In particular: no distinction is made between the names of tags, trees, and blobs; path names may be modified to remove newlines; and if an object would appear multiple times with different names, only one name is shown.
zh_HANS-CN: 只对 `--objects` 有用；打印找到的对象ID的名称。这是默认的行为。注意，每个对象的 "名字" 是模糊的，主要是作为打包对象的提示。特别是：标签、树和二进制文件的名字不作区分；路径名称可以被修改以删除换行；如果一个对象会以不同的名字出现多次，则只显示一个名字。

note: type: Plain text
en: Only useful with `--objects`; does not print the names of the object IDs that are found. This inverts `--object-names`. This flag allows the output to be more easily parsed by commands such as linkgit:git-cat-file[1].
zh_HANS-CN: 只对`--对象`有用；不打印找到的对象ID的名称。这与`--object-names`相反。这个标志允许输出更容易被linkgit:git-cat-file[1]等命令解析。

note: type: Plain text
en: Only useful with one of the `--objects*`; omits objects (usually blobs) from the list of printed objects.  The '<filter-spec>' may be one of the following:
zh_HANS-CN: 只对其中一个`--objects*`有用；从打印对象列表中省略对象（通常是blobs）。  <filter-spec>'可以是下列之一。

note: type: Plain text
en: The form '--filter=blob:none' omits all blobs.
zh_HANS-CN: '--filter=blob:none'的形式可以省略所有的blob。

note: type: Plain text
en: The form '--filter=blob:limit=<n>[kmg]' omits blobs larger than n bytes or units.  n may be zero.  The suffixes k, m, and g can be used to name units in KiB, MiB, or GiB.  For example, 'blob:limit=1k' is the same as 'blob:limit=1024'.
zh_HANS-CN: '--filter=blob:limit=<n>[kmg]'的形式可以省略大于n个字节或单位的blob，n可以是0。  后缀k、m和g可以用来命名KiB、MiB或GiB等单位。  例如，'blob:limit=1k'和'blob:limit=1024'是一样的。

note: type: Plain text
en: The form '--filter=object:type=(tag|commit|tree|blob)' omits all objects which are not of the requested type.
zh_HANS-CN: '--filter=object:type=(tag|commit|tree|blob)'的形式会省略所有不属于请求类型的对象。

note: type: Plain text
en: The form '--filter=tree:<depth>' omits all blobs and trees whose depth from the root tree is >= <depth> (minimum depth if an object is located at multiple depths in the commits traversed). <depth>=0 will not include any trees or blobs unless included explicitly in the command-line (or standard input when --stdin is used). <depth>=1 will include only the tree and blobs which are referenced directly by a commit reachable from <commit> or an explicitly-given object. <depth>=2 is like <depth>=1 while also including trees and blobs one more level removed from an explicitly-given commit or tree.
zh_HANS-CN: '--filter=tree:<depth>'的形式省略了所有从根树开始深度>=<depth>（如果一个对象在所穿越的提交中位于多个深度，则为最小深度）的blobs和树。<depth>=0 将不包括任何树或blobs，除非在命令行中明确包括（或使用-stdin时的标准输入）。<depth>=1 将只包括由<commit>或明确指定的对象所能到达的提交直接引用的树和blobs。<深度>=2与<深度>=1类似，同时也包括从明确给出的提交或树中移出的多一级的树和blobs。

note: type: Plain text
en: Note that the form '--filter=sparse:path=<path>' that wants to read from an arbitrary path on the filesystem has been dropped for security reasons.
zh_HANS-CN: 注意，出于安全原因，想要从文件系统上的任意路径读取的'--过滤器=sparse:path=<path>'形式已经被放弃了。

note: type: Plain text
en: Multiple '--filter=' flags can be specified to combine filters. Only objects which are accepted by every filter are included.
zh_HANS-CN: 可以指定多个'--过滤器='标志来组合过滤器。只有那些被每个过滤器接受的对象才会被包括在内。

note: type: Plain text
en: The form '--filter=combine:<filter1>+<filter2>+...<filterN>' can also be used to combined several filters, but this is harder than just repeating the '--filter' flag and is usually not necessary. Filters are joined by '{plus}' and individual filters are %-encoded (i.e. URL-encoded).  Besides the '{plus}' and '%' characters, the following characters are reserved and also must be encoded: `~!@#$^&*()[]{}\;",<>?`+&#39;&#96;+ as well as all characters with ASCII code &lt;= `0x20`, which includes space and newline.
zh_HANS-CN: '--filter=combine:<filter1>+<filter2>+...<filterN>'的形式也可以用来组合几个过滤器，但这比重复'--filter'标志要难，通常没有必要。过滤器用'{plus}'连接，单个过滤器用%编码（即用URL编码）。  除了'{plus}'和'%'字符，以下字符是保留字符，也必须进行编码：`~！@#$^&*()[]{}/;",<>?`+&#39;&#96;+以及所有ASCII代码为&lt;=`0x20`的字符，其中包括空格和换行。

note: type: Plain text
en: Other arbitrary characters can also be encoded. For instance, 'combine:tree:3+blob:none' and 'combine:tree%3A3+blob%3Anone' are equivalent.
zh_HANS-CN: 其他任意的字符也可以被编码。例如，'combined:tree:3+blob:none'和'combined:tree%3A3+blob%3Anone'是等同的。

note: type: Plain text
en: Turn off any previous `--filter=` argument.
zh_HANS-CN: 关掉之前的任何`--filter=`参数。

note: type: Plain text
en: Filter the list of explicitly provided objects, which would otherwise always be printed even if they did not match any of the filters. Only useful with `--filter=`.
zh_HANS-CN: 过滤明确提供的对象的列表，否则，即使它们不符合任何过滤器，也会被打印出来。只对`--filter=`有用。

note: type: Plain text
en: Only useful with `--filter=`; prints a list of the objects omitted by the filter.  Object IDs are prefixed with a ``~'' character.
zh_HANS-CN: 只对`--filter=`有用；打印出被过滤器省略的对象的列表。  对象ID的前缀是``~''字符。

note: type: Plain text
en: The form '--missing=error' requests that rev-list stop with an error if a missing object is encountered.  This is the default action.
zh_HANS-CN: 形式'--missing=error'要求rev-list在遇到丢失的对象时以错误方式停止。  这是默认动作。

note: type: Plain text
en: The form '--missing=allow-any' will allow object traversal to continue if a missing object is encountered.  Missing objects will silently be omitted from the results.
zh_HANS-CN: '--missing=allow-any'的形式将允许在遇到缺失对象时继续进行对象遍历。  缺少的对象将被默默地从结果中省略掉。

note: type: Plain text
en: The form '--missing=allow-promisor' is like 'allow-any', but will only allow object traversal to continue for EXPECTED promisor missing objects.  Unexpected missing objects will raise an error.
zh_HANS-CN: '--missing=allow-promisor'的形式与'allow-any'相似，但只允许对预期的promisor缺失对象继续进行遍历。  意外的缺失对象将引发一个错误。

note: type: Plain text
en: The form '--missing=print' is like 'allow-any', but will also print a list of the missing objects.  Object IDs are prefixed with a ``?'' character.
zh_HANS-CN: '--missing=print'的形式与'allow-any'相似，但也会打印出遗失对象的列表。  对象ID的前缀是"？"。

note: type: Plain text
en: (For internal use only.)  Prefilter object traversal at promisor boundary.  This is used with partial clone.  This is stronger than `--missing=allow-promisor` because it limits the traversal, rather than just silencing errors about missing objects.
zh_HANS-CN: 仅供内部使用。）在希望者边界预过滤对象的遍历。  这是与部分克隆一起使用的。  这比`--missing=allow-promisor`更强，因为它限制了遍历，而不仅仅是消除了关于丢失对象的错误。

note: type: Plain text
en: Overrides a previous `--no-walk`.
zh_HANS-CN: 覆盖之前的`--不走'。

note: type: Title ~
en: Commit Formatting
zh_HANS-CN: 承诺格式化

note: type: Plain text
en: Using these options, linkgit:git-rev-list[1] will act similar to the more specialized family of commit log tools: linkgit:git-log[1], linkgit:git-show[1], and linkgit:git-whatchanged[1]
zh_HANS-CN: 使用这些选项，linkgit:git-rev-list[1] 的作用类似于更专业的提交日志工具系列：linkgit:git-log[1]，linkgit:git-show[1]，和linkgit:git-whatchanged[1] 。

note: type: Plain text
en: Synonym for `--date=relative`.
zh_HANS-CN: `--date=relative`的同义词。

note: type: Plain text
en: Only takes effect for dates shown in human-readable format, such as when using `--pretty`. `log.date` config variable sets a default value for the log command's `--date` option. By default, dates are shown in the original time zone (either committer's or author's). If `-local` is appended to the format (e.g., `iso-local`), the user's local time zone is used instead.
zh_HANS-CN: 只对以人类可读格式显示的日期生效，例如使用`--pretty`时。`log.date`配置变量为日志命令的`--date`选项设置默认值。默认情况下，日期显示在原始时区（提交者或作者的时区）。如果`-local`被附加到格式中（例如，`iso-local`），就会使用用户的本地时区。

note: type: Plain text
en: `--date=relative` shows dates relative to the current time, e.g. ``2 hours ago''. The `-local` option has no effect for `--date=relative`.
zh_HANS-CN: `--date=relative`显示相对于当前时间的日期，例如：`2小时前''。`--local`选项对`--date=relative`没有影响。

note: type: Plain text
en: `--date=local` is an alias for `--date=default-local`.
zh_HANS-CN: `--date=local`是`--date=default-local`的一个别名。

note: type: Plain text
en: `--date=iso` (or `--date=iso8601`) shows timestamps in a ISO 8601-like format.  The differences to the strict ISO 8601 format are:
zh_HANS-CN: `--date=iso`（或`--date=iso8601`）以类似ISO 8601的格式显示时间戳。  与严格的ISO 8601格式的区别是。

note: type: Plain text
en: a space instead of the `T` date/time delimiter
zh_HANS-CN: 用空格代替`T`日期/时间分隔符

note: type: Plain text
en: a space between time and time zone
zh_HANS-CN: 时间和时区之间的空间

note: type: Plain text
en: no colon between hours and minutes of the time zone
zh_HANS-CN: 时区的小时和分钟之间没有冒号

note: type: Plain text
en: `--date=iso-strict` (or `--date=iso8601-strict`) shows timestamps in strict ISO 8601 format.
zh_HANS-CN: `--date=iso-strict`（或`--date=iso8601-strict`）显示严格的ISO 8601格式的时间戳。

note: type: Plain text
en: `--date=rfc` (or `--date=rfc2822`) shows timestamps in RFC 2822 format, often found in email messages.
zh_HANS-CN: `--date=rfc`（或`--date=rfc2822`）显示RFC 2822格式的时间戳，经常出现在电子邮件中。

note: type: Plain text
en: `--date=short` shows only the date, but not the time, in `YYYY-MM-DD` format.
zh_HANS-CN: `--date=short`只显示日期，而不是时间，格式为`YYYY-MM-DD`。

note: type: Plain text
en: `--date=raw` shows the date as seconds since the epoch (1970-01-01 00:00:00 UTC), followed by a space, and then the timezone as an offset from UTC (a `+` or `-` with four digits; the first two are hours, and the second two are minutes). I.e., as if the timestamp were formatted with `strftime("%s %z")`).  Note that the `-local` option does not affect the seconds-since-epoch value (which is always measured in UTC), but does switch the accompanying timezone value.
zh_HANS-CN: `--date=raw`显示日期为自纪元以来的秒数（1970-01-01 00:00:00 UTC），后面是空格，然后是时区为UTC的偏移量（一个`+`或`-`的四位数字；前两位是小时，后两位是分钟）。也就是说，就像时间戳的格式为`strftime("%s %z")`)。  请注意，`-local`选项不影响自始至终的秒数值（它总是以UTC为单位），但会切换伴随的时区值。

note: type: Plain text
en: `--date=human` shows the timezone if the timezone does not match the current time-zone, and doesn't print the whole date if that matches (ie skip printing year for dates that are "this year", but also skip the whole date itself if it's in the last few days and we can just say what weekday it was).  For older dates the hour and minute is also omitted.
zh_HANS-CN: `--date=human`如果时区与当前时区不匹配，则显示时区，如果匹配则不打印整个日期（即对于 "今年 "的日期，跳过打印年份，但如果是最近几天的日期，也跳过整个日期本身，我们可以只说是哪个工作日）。  对于较早的日期，小时和分钟也被省略了。

note: type: Plain text
en: `--date=unix` shows the date as a Unix epoch timestamp (seconds since 1970).  As with `--raw`, this is always in UTC and therefore `-local` has no effect.
zh_HANS-CN: `--date=unix`显示日期为Unix纪元时间戳（自1970年以来的秒数）。  与`--raw`一样，这总是以UTC为单位，因此`--local`没有影响。

note: type: Plain text
en: `--date=default` is the default format, and is based on ctime(3)  output.  It shows a single line with three-letter day of the week, three-letter month, day-of-month, hour-minute-seconds in "HH:MM:SS" format, followed by 4-digit year, plus timezone information, unless the local time zone is used, e.g. `Thu Jan 1 00:00:00 1970 +0000`.
zh_HANS-CN: `--date=default`是默认格式，基于ctime(3)输出。  它仅仅在一行中显示缩写的星期、缩写的月份、一月中的第几天、"HH:MM:SS "格式的小时-分钟-秒，然后是年份，除非使用本地时区，在末尾都会加上时区信息，例如`Thu Jan 1 00:00:00 1970 +0000`。

note: type: Plain text
en: Print the contents of the commit in raw-format; each record is separated with a NUL character.
zh_HANS-CN: 以原始格式打印提交的内容；每条记录用NUL字符分隔。

note: type: Plain text
en: Suppress the header line containing "commit" and the object ID printed before the specified format.  This has no effect on the built-in formats; only custom formats are affected.
zh_HANS-CN: 抑制包含“提交”的标题行和在指定格式之前打印的对象 ID。这对内置格式没有影响；只有自定义格式会受到影响。

note: type: Plain text
en: Print also the parents of the commit (in the form "commit parent...").  Also enables parent rewriting, see 'History Simplification' above.
zh_HANS-CN: 也可以打印提交的父类（以 "提交父类... "的形式）。  也可以启用父级改写，见上面的 "历史简化"。

note: type: Plain text
en: Print also the children of the commit (in the form "commit child...").  Also enables parent rewriting, see 'History Simplification' above.
zh_HANS-CN: 同时打印提交的子项（以 "提交子项... "的形式）。  也可以启用父级改写，见上面的 "历史简化"。

note: type: Plain text
en: Print the raw commit timestamp.
zh_HANS-CN: 打印原始提交时间戳。

note: type: Plain text
en: Mark which side of a symmetric difference a commit is reachable from.  Commits from the left side are prefixed with `<` and those from the right with `>`.  If combined with `--boundary`, those commits are prefixed with `-`.
zh_HANS-CN: 标明提交可以从对称性差异的哪一边到达。  左边的提交以`<`为前缀，右边的则以`>`为前缀。  如果与"--边界 "结合，这些提交的前缀为"-"。

note: type: Plain text
en: For example, if you have this topology:
zh_HANS-CN: 例如，如果你有这样的拓扑结构。

note: type: Plain text
en: you would get an output like this:
zh_HANS-CN: 你会得到这样的输出。

note: type: Plain text
en: Draw a text-based graphical representation of the commit history on the left hand side of the output.  This may cause extra lines to be printed in between commits, in order for the graph history to be drawn properly.  Cannot be combined with `--no-walk`.
zh_HANS-CN: 在输出的左手边绘制基于文本的提交历史图表。  这可能会导致在提交之间打印出额外的行，以便正确地绘制图形历史。  不能与`--no-walk`结合使用。

note: type: Plain text
en: This enables parent rewriting, see 'History Simplification' above.
zh_HANS-CN: 这可以使父代改写，见上面的'历史简化'。

note: type: Plain text
en: This implies the `--topo-order` option by default, but the `--date-order` option may also be specified.
zh_HANS-CN: 这意味着默认情况下是`--topo-order`选项，但也可以指定`--date-order`选项。

note: type: Plain text
en: When --graph is not used, all history branches are flattened which can make it hard to see that the two consecutive commits do not belong to a linear branch. This option puts a barrier in between them in that case. If `<barrier>` is specified, it is the string that will be shown instead of the default one.
zh_HANS-CN: 如果不使用 --graph，所有的历史分支都会被压扁，这就很难看出两个连续的提交并不属于一个线性分支。在这种情况下，该选项会在它们之间设置一个障碍。如果指定了"<barrier>"，就会显示这个字符串，而不是默认的。

note: type: Plain text
en: Print a number stating how many commits would have been listed, and suppress all other output.  When used together with `--left-right`, instead print the counts for left and right commits, separated by a tab. When used together with `--cherry-mark`, omit patch equivalent commits from these counts and print the count for equivalent commits separated by a tab.
zh_HANS-CN: 打印一个数字，说明有多少提交会被列出，并抑制所有其他输出。  当与`--左--右'一起使用时，会打印左和右的提交计数，用制表符分开。当与`--cherry-mark`一起使用时，从这些计数中省略补丁等价提交，而打印等价提交的计数，用tab分隔。

note: type: Plain text
en: Continue the operation in progress using the information in `.git/sequencer`.  Can be used to continue after resolving conflicts in a failed cherry-pick or revert.
zh_HANS-CN: 使用`.git/sequencer`中的信息继续进行中的操作。  可以用来在解决拣选或还原失败的冲突后继续执行。

note: type: Plain text
en: Skip the current commit and continue with the rest of the sequence.
zh_HANS-CN: 跳过当前的提交，继续进行队列中其余的命令。

note: type: Plain text
en: Forget about the current operation in progress.  Can be used to clear the sequencer state after a failed cherry-pick or revert.
zh_HANS-CN: 忽略当前正在进行的操作。  可以用来在拣选或还原失败之后清除序列器的状态。

note: type: Plain text
en: Cancel the operation and return to the pre-sequence state.
zh_HANS-CN: 取消操作并返回到预排序状态。

note: type: Plain text
en: Add a `Signed-off-by` trailer by the committer at the end of the commit log message.  The meaning of a signoff depends on the project to which you're committing.  For example, it may certify that the committer has the rights to submit the work under the project's license or agrees to some contributor representation, such as a Developer Certificate of Origin.  (See http://developercertificate.org for the one used by the Linux kernel and Git projects.)  Consult the documentation or leadership of the project to which you're contributing to understand how the signoffs are used in that project.
zh_HANS-CN: 在提交日志信息的末尾添加提交者的 "Signed-off-by "预告片。  签名的意义取决于你所提交的项目。  例如，它可以证明提交者有权利在项目许可下提交作品，或者同意一些贡献者的陈述，如开发者的原产地证书。  关于Linux内核和Git项目使用的证书，请参见http://developercertificate.org）。  请查阅你要贡献的项目的文档或领导层，以了解该项目如何使用签名。

note: type: Plain text
en: The --no-signoff option can be used to countermand an earlier --signoff option on the command line.
zh_HANS-CN: --no-signoff选项可以用来反驳先前在命令行上的-signoff选项。

note: type: Plain text
en: The fetch and push protocols are not designed to prevent one side from stealing data from the other repository that was not intended to be shared. If you have private data that you need to protect from a malicious peer, your best option is to store it in another repository. This applies to both clients and servers. In particular, namespaces on a server are not effective for read access control; you should only grant read access to a namespace to clients that you would trust with read access to the entire repository.
zh_HANS-CN: 获取和推送协议并不是为了防止一方从另一个版本库窃取不打算共享的数据。如果你有需要保护的私人数据不被恶意的同行窃取，你最好的选择是把它存储在另一个资源库中。这同时适用于客户端和服务器。特别是，服务器上的命名空间对于读取访问控制是无效的；你应该只将命名空间的读取访问权授予那些你信任的可以读取整个版本库的客户。

note: type: Plain text
en: The known attack vectors are as follows:
zh_HANS-CN: 已知的攻击媒介如下：

note: type: Plain text
en: The victim sends "have" lines advertising the IDs of objects it has that are not explicitly intended to be shared but can be used to optimize the transfer if the peer also has them. The attacker chooses an object ID X to steal and sends a ref to X, but isn't required to send the content of X because the victim already has it. Now the victim believes that the attacker has X, and it sends the content of X back to the attacker later. (This attack is most straightforward for a client to perform on a server, by creating a ref to X in the namespace the client has access to and then fetching it. The most likely way for a server to perform it on a client is to "merge" X into a public branch and hope that the user does additional work on this branch and pushes it back to the server without noticing the merge.)
zh_HANS-CN: 受害者发送 "have" 行，宣传它所拥有的对象的 ID，这些对象并没有明确地打算被共享，但如果对等体也有这些对象，就可以用来优化传输。攻击者选择了一个对象 ID X 来窃取，并向 X 发送了一个引用，但不需要发送 X 的内容，因为受害者已经拥有它。现在，受害者认为攻击者拥有 X，它稍后将 X 的内容发回给攻击者。(这种攻击对于客户端来说在服务器上执行是最直接的，通过在客户端可以访问的命名空间中创建一个 X 的引用，然后获取它。服务器最可能在客户端执行的方式是将 X "合并" 到一个公共分支，并希望用户在这个分支上做额外的工作，然后在没有注意到合并的情况下将其推回给服务器。）

note: type: Plain text
en: 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.
zh_HANS-CN: 和 #1 一样，攻击者选择了一个对象 ID X 来偷窃。受害者发送了一个攻击者已经拥有的对象 Y，攻击者谎称拥有 X 而没有 Y，因此受害者发送 Y 作为对 X 的d elta，delta 向攻击者显示了 X 中与 Y 相似的区域。

note: type: Title -
en: REMOTES[[REMOTES]]
zh_HANS-CN: REMOTES[[REMOTES]

note: type: Plain text
en: The name of one of the following can be used instead of a URL as `<repository>` argument:
zh_HANS-CN: 可以用下面的一个名称代替URL作为`<repository>`的参数：

note: type: Plain text
en: a remote in the Git configuration file: `$GIT_DIR/config`,
zh_HANS-CN: 一个远端的配置文件在此仓库的git配置文件： `$GIT_DIR/config`、

note: type: Plain text
en: a file in the `$GIT_DIR/remotes` directory, or
zh_HANS-CN: 这个文件在`$GIT_DIR/remotes`目录下，或者

note: type: Plain text
en: All of these also allow you to omit the refspec from the command line because they each contain a refspec which git will use by default.
zh_HANS-CN: 所有这些也允许你从命令行中省略refspec，因为它们都包含一个git默认使用的refspec。

note: type: Title ~
en: Named remote in configuration file
zh_HANS-CN: 在配置文件中命名为 remote

note: type: Plain text
en: You can choose to provide the name of a remote which you had previously configured using linkgit:git-remote[1], linkgit:git-config[1] or even by a manual edit to the `$GIT_DIR/config` file.  The URL of this remote will be used to access the repository.  The refspec of this remote will be used by default when you do not provide a refspec on the command line.  The entry in the config file would appear like this:
zh_HANS-CN: 你可以选择提供你之前用 linkgit:git-remote[1]、linkgit:git-config[1] 或甚至通过手动编辑 `$GIT_DIR/config` 文件配置的远程名称。  这个远程的 URL 将被用来访问仓库。  当你没有在命令行上提供引用规范时，这个远程仓库的引用规范将被默认使用。  配置文件中的条目会像这样：

note: type: Title ~
en: Named file in `$GIT_DIR/remotes`
zh_HANS-CN: `$GIT_DIR/remotes` 中的命名文件

note: type: Plain text
en: You can choose to provide the name of a file in `$GIT_DIR/remotes`.  The URL in this file will be used to access the repository.  The refspec in this file will be used as default when you do not provide a refspec on the command line.  This file should have the following format:
zh_HANS-CN: 你可以选择提供 `$GIT_DIR/remotes` 中的文件名。  这个文件中的 URL 将被用来访问仓库。  当你没有在命令行上提供引用规范时，该文件中的引用规范将被作为默认使用。  这个文件应该有以下格式：

note: type: delimited block -
en: 	URL: one of the above URL format
    	Push: <refspec>
    	Pull: <refspec>
zh_HANS-CN: 	URL: one of the above URL format
    	Push: <引用规范>
    	Pull: <引用规范>

note: type: Plain text
en: `Push:` lines are used by 'git push' and `Pull:` lines are used by 'git pull' and 'git fetch'.  Multiple `Push:` and `Pull:` lines may be specified for additional branch mappings.
zh_HANS-CN: `Push:` 行被 'git push' 使用，`Pull:` 行被 'git pull' 和 'git fetch' 使用。  可以为额外的分支映射指定多个 `Push:` 和 `Pull:` 行。

note: type: Title ~
en: Named file in `$GIT_DIR/branches`
zh_HANS-CN: `$GIT_DIR/branches` 中的命名文件

note: type: Plain text
en: You can choose to provide the name of a file in `$GIT_DIR/branches`.  The URL in this file will be used to access the repository.  This file should have the following format:
zh_HANS-CN: 你可以选择提供 `$GIT_DIR/branches` 中的文件名。  这个文件中的 URL 将被用来访问仓库。  这个文件应该有以下格式：

note: type: Plain text
en: `<URL>` is required; `#<head>` is optional.
zh_HANS-CN: `<URL>` 是必须的；`#<head>` 是可选的。

note: type: Plain text
en: Depending on the operation, git will use one of the following refspecs, if you don't provide one on the command line.  `<branch>` is the name of this file in `$GIT_DIR/branches` and `<head>` defaults to `master`.
zh_HANS-CN: 根据不同的操作，如果你没有在命令行上提供一个引用规范，git 会使用以下其中一个。  `<分支>` 是该文件在 `$GIT_DIR/branches` 中的名称，`<头分支>` 默认为 `master`。

note: type: Plain text
en: git fetch uses:
zh_HANS-CN: git fetch 使用：

note: type: delimited block -
en: 	refs/heads/<head>:refs/heads/<branch>
zh_HANS-CN: 	refs/heads/<头分支>:refs/heads/<分支>。

note: type: delimited block -
en: 	HEAD:refs/heads/<head>
zh_HANS-CN: 	HEAD:refs/heads/<头分支>。

note: type: Title =
en: Fighting regressions with git bisect
zh_HANS-CN: 用Git二分查找解决回退问题

note: type: Plain text
en: "git bisect" enables software users and developers to easily find the commit that introduced a regression. We show why it is important to have good tools to fight regressions. We describe how "git bisect" works from the outside and the algorithms it uses inside. Then we explain how to take advantage of "git bisect" to improve current practices. And we discuss how "git bisect" could improve in the future.
zh_HANS-CN: "Git二分查找"使软件用户和开发者能够轻松找到引入回退的提交。我们展示了为什么拥有好的工具来解决回退是很重要的。我们描述了 "Git二分查找 "从外部如何工作，以及它在内部使用的算法。然后我们解释如何利用 "Git二分查找"来改进当前的体验。我们还讨论了 "Git二分查找"在未来可以如何改进。

note: type: Plain text
en: Git is a Distributed Version Control system (DVCS) created by Linus Torvalds and maintained by Junio Hamano.
zh_HANS-CN: Git是一个分布式版本控制系统（DVCS），由Linus Torvalds（一般指 林纳斯·本纳第克特·托瓦兹；Linux之父）创建，由Junio Hamano（ Junio C Hamano；滨野 纯）维护。

note: type: Plain text
en: In Git like in many other Version Control Systems (VCS), the different states of the data that is managed by the system are called commits. And, as VCS are mostly used to manage software source code, sometimes "interesting" changes of behavior in the software are introduced in some commits.
zh_HANS-CN: 在Git中，像许多其他版本控制系统（VCS）一样，由系统管理的数据的不同状态被称为提交。而且，由于版本控制系统主要用于管理软件源代码，有时会在一些提交中引入软件中 "有趣 "的行为变化。

note: type: Plain text
en: In fact people are specially interested in commits that introduce a "bad" behavior, called a bug or a regression. They are interested in these commits because a commit (hopefully) contains a very small set of source code changes. And it's much easier to understand and properly fix a problem when you only need to check a very small set of changes, than when you don't know where look in the first place.
zh_HANS-CN: 事实上，人们对那些引入 "坏 "行为的提交特别感兴趣，这些行为被称为错误或回归。他们之所以对这些提交感兴趣，是因为一个提交（希望）只包含一组非常小的源代码改动。当你只需要检查很小的改动时，理解和正确修复一个问题要比你不知道从哪里找问题容易得多。

note: type: Plain text
en: So to help people find commits that introduce a "bad" behavior, the "git bisect" set of commands was invented. And it follows of course that in "git bisect" parlance, commits where the "interesting behavior" is present are called "bad" commits, while other commits are called "good" commits. And a commit that introduce the behavior we are interested in is called a "first bad commit". Note that there could be more than one "first bad commit" in the commit space we are searching.
zh_HANS-CN: 所以为了帮助人们找到引入 "坏 "行为的提交，发明了 "Git二分查找"命令集。当然，在 "Git二分查找"的说法中，存在 "有趣行为 "的提交被称为 "坏 "提交，而其他提交被称为 "好 "提交。而引入我们感兴趣的行为的提交被称为 "第一个坏提交"。请注意，在我们搜索的提交空间中，可能存在不止一个 "第一个坏提交"。

note: type: Plain text
en: So "git bisect" is designed to help find a "first bad commit". And to be as efficient as possible, it tries to perform a binary search.
zh_HANS-CN: 因此，"Git二分查找"被设计用来帮助找到 "第一个坏提交"。为了尽可能的高效，它试图进行二分查找。

note: type: Title -
en: Fighting regressions overview
zh_HANS-CN: 解决回退概述

note: type: Title ~
en: Regressions: a big problem
zh_HANS-CN: 回退：一个大问题

note: type: Plain text
en: Regressions are a big problem in the software industry. But it's difficult to put some real numbers behind that claim.
zh_HANS-CN: 回退是软件行业的一个大问题。但是很难用数字来说明这个问题。

note: type: Plain text
en: There are some numbers about bugs in general, like a NIST study in 2002 <<1>> that said:
zh_HANS-CN: 有一些关于一般bug的数字，比如2002年NIST的一项研究<<1>>写道：

note: type: delimited block _
en: Software bugs, or errors, are so prevalent and so detrimental that they cost the U.S. economy an estimated $59.5 billion annually, or about 0.6 percent of the gross domestic product, according to a newly released study commissioned by the Department of Commerce's National Institute of Standards and Technology (NIST). At the national level, over half of the costs are borne by software users and the remainder by software developers/vendors.  The study also found that, although all errors cannot be removed, more than a third of these costs, or an estimated $22.2 billion, could be eliminated by an improved testing infrastructure that enables earlier and more effective identification and removal of software defects. These are the savings associated with finding an increased percentage (but not 100 percent) of errors closer to the development stages in which they are introduced. Currently, over half of all errors are not found until "downstream" in the development process or during post-sale software use.
zh_HANS-CN: 根据美国商务部国家标准与技术研究所（NIST）新近发布的一项研究，软件缺陷或错误是非常普遍且是灾难性的，以至于它们每年给美国经济造成约595亿美元的损失，或约占国内生产总值的0.6%。在全国范围内，超过一半的成本由软件用户承担，其余的由软件开发商/供应商承担。  该研究还发现，尽管所有的错误都无法消除，但通过改进测试基础架构，能够更早、更有效地识别和消除软件缺陷，可以消除这些成本的三分之一以上，即估计为222亿美元。这些都是在更接近错误发生的开发阶段发现更高比例（但不是100%）的错误所带来的节约。目前，超过一半的错误是在开发过程的 "下游 "或售后软件使用期间才被发现的。

note: type: Plain text
en: And then:
zh_HANS-CN: 然后：

note: type: delimited block _
en: Software developers already spend approximately 80 percent of development costs on identifying and correcting defects, and yet few products of any type other than software are shipped with such high levels of errors.
zh_HANS-CN: 软件开发人员已经将大约80%的开发成本用于识别和纠正缺陷，然而，除了软件之外，很少有其他类型的产品在出厂时出现如此高的错误。

note: type: Plain text
en: Eventually the conclusion started with:
zh_HANS-CN: 最终结论是：

note: type: delimited block _
en: The path to higher software quality is significantly improved software testing.
zh_HANS-CN: 改善软件测试是通往更高的软件质量的道路最为有效的方式。

note: type: Plain text
en: There are other estimates saying that 80% of the cost related to software is about maintenance <<2>>.
zh_HANS-CN: 还有人估计说，与软件有关的成本中有80%是关于维护的<<2>>。

note: type: Plain text
en: Though, according to Wikipedia <<3>>:
zh_HANS-CN: 尽管，根据维基百科<<3>>的说法：

note: type: delimited block _
en: A common perception of maintenance is that it is merely fixing bugs. However, studies and surveys over the years have indicated that the majority, over 80%, of the maintenance effort is used for non-corrective actions (Pigosky 1997). This perception is perpetuated by users submitting problem reports that in reality are functionality enhancements to the system.
zh_HANS-CN: 人们对维护工作的普遍看法是，它仅仅是在修复错误。然而，多年来的研究和调查表明，大部分（超过80%）的维护工作都是用于非纠正性的行动（Pigosky 1997）。用户提交的问题报告实际上是对系统功能的提升，这使得这种看法得以延续。

note: type: Plain text
en: But we can guess that improving on existing software is very costly because you have to watch out for regressions. At least this would make the above studies consistent among themselves.
zh_HANS-CN: 但我们可以猜测，在现有软件上进行改进的代价是非常昂贵的，因为你必须注意功能退步的问题。至少这可以使上述研究之间保持一致。

note: type: Plain text
en: Of course some kind of software is developed, then used during some time without being improved on much, and then finally thrown away. In this case, of course, regressions may not be a big problem. But on the other hand, there is a lot of big software that is continually developed and maintained during years or even tens of years by a lot of people. And as there are often many people who depend (sometimes critically) on such software, regressions are a really big problem.
zh_HANS-CN: 当然，有些软件被开发出来，然后在一段时间内使用中，没有得到很大的改进，最后被废弃。当然，在这种情况下，退步可能不是一个大问题。但另一方面，有很多大型软件是由很多人在几年甚至几十几年的时间里不断开发和维护的。由于经常有许多人依赖这种软件（有时是关键性的），所以回退是一个真正的大问题。

note: type: Plain text
en: One such software is the Linux kernel. And if we look at the Linux kernel, we can see that a lot of time and effort is spent to fight regressions. The release cycle start with a 2 weeks long merge window. Then the first release candidate (rc) version is tagged. And after that about 7 or 8 more rc versions will appear with around one week between each of them, before the final release.
zh_HANS-CN: Linux内核就是这样一个软件。如果我们看一下Linux内核，我们可以看到花了大量的时间和精力来对抗退步。发布周期从2周的合并窗口开始。然后，第一个候选版本（rc）被标记。在那之后，在最终发布之前，大约还有7到8个rc版本会出现，每个版本之间相隔一周左右。

note: type: Plain text
en: The time between the first rc release and the final release is supposed to be used to test rc versions and fight bugs and especially regressions. And this time is more than 80% of the release cycle time. But this is not the end of the fight yet, as of course it continues after the release.
zh_HANS-CN: 从第一个rc版本到最终版本之间的时间应该是用来测试rc版本和解决bug，特别是回退问题。而这段时间占到了发布周期的80%以上。发布并不意味着战斗结束，因为bug在发布后还会继续出现。

note: type: Plain text
en: And then this is what Ingo Molnar (a well known Linux kernel developer) says about his use of git bisect:
zh_HANS-CN: 然后这是Ingo Molnar（一位知名的Linux内核开发者）对他正在使用的Git二分查找的评价：

note: type: delimited block _
en: I most actively use it during the merge window (when a lot of trees get merged upstream and when the influx of bugs is the highest) - and yes, there have been cases that i used it multiple times a day. My average is roughly once a day.
zh_HANS-CN: 我在合并窗口期最积极地使用它（当大量的树被合并到上游时，也是bug涌入最多的时候），有一些情况下，我一天要多次使用。我的平均使用频率大约是每天一次。

note: type: Plain text
en: So regressions are fought all the time by developers, and indeed it is well known that bugs should be fixed as soon as possible, so as soon as they are found. That's why it is interesting to have good tools for this purpose.
zh_HANS-CN: 因此，开发人员一直在与回退作斗争，事实上，众所周知，错误应该被尽快修复，所以一旦发现就应该尽快修复。这就是为什么有好的工具来达到这个目的是很有趣的。

note: type: Title ~
en: Other tools to fight regressions
zh_HANS-CN: 解决回退的其他工具

note: type: Plain text
en: So what are the tools used to fight regressions? They are nearly the same as those used to fight regular bugs. The only specific tools are test suites and tools similar as "git bisect".
zh_HANS-CN: 那么，用于解决回退的工具是什么呢？它们几乎与那些用来对付常规bug的工具相同。唯一特殊的工具是测试套件和类似于 "Git二分查找"的工具。

note: type: Plain text
en: Test suites are very nice. But when they are used alone, they are supposed to be used so that all the tests are checked after each commit. This means that they are not very efficient, because many tests are run for no interesting result, and they suffer from combinatorial explosion.
zh_HANS-CN: 测试套件是非常好的。但当它们被单独使用时，它们应该被用来在每次提交后检查所有的测试。这意味着它们的效率并不高，因为许多测试的运行并没有意外的结果，而且它们会受到组合的影响。

note: type: Plain text
en: In fact the problem is that big software often has many different configuration options and that each test case should pass for each configuration after each commit. So if you have for each release: N configurations, M commits and T test cases, you should perform:
zh_HANS-CN: 事实上，问题在于大型软件通常有许多不同的配置选项，每次提交后，每个测试用例都应该通过每个配置。因此，如果你对每个版本有N个配置，M个提交，T个测试用例，你应该执行：

note: type: delimited block -
en: N * M * T tests
zh_HANS-CN: N * M * T 个测试

note: type: Plain text
en: where N, M and T are all growing with the size your software.
zh_HANS-CN: 其中N、M和T都是随着你的软件大小而增长的。

note: type: Plain text
en: So very soon it will not be possible to completely test everything.
zh_HANS-CN: 因此，很快就不可能对所有的东西进行测试。

note: type: Plain text
en: And if some bugs slip through your test suite, then you can add a test to your test suite. But if you want to use your new improved test suite to find where the bug slipped in, then you will either have to emulate a bisection process or you will perhaps bluntly test each commit backward starting from the "bad" commit you have which may be very wasteful.
zh_HANS-CN: 而如果有些bug在你的测试套件中溜走了，那么你可以在你的测试套件中增加一个测试。但是，如果你想用你新改进的测试套件来找到bug溜进去的地方，那么你将不得不模仿一分为二的过程，或者你也许会直截了当地从你的 "坏 "提交开始向后测试每个提交，这可能是非常浪费的。

note: type: Title ~
en: Starting a bisection
zh_HANS-CN: 开始二分

note: type: Plain text
en: The first "git bisect" subcommand to use is "git bisect start" to start the search. Then bounds must be set to limit the commit space. This is done usually by giving one "bad" and at least one "good" commit. They can be passed in the initial call to "git bisect start" like this:
zh_HANS-CN: 第一个要使用的 "Git二分查找"子命令是 "git bisect start "来开始搜索。然后必须设置边界来限制提交空间。这通常是通过给出一个 "坏 "和至少一个 "好 "的提交来实现的。它们可以像这样在初始调用 "git bisect start "时传递：

note: type: Plain text
en: or they can be set using:
zh_HANS-CN: 或者可以用以下方式设置：

note: type: Plain text
en: where BAD, GOOD and COMMIT are all names that can be resolved to a commit.
zh_HANS-CN: 其中BAD、GOOD和COMMIT都可以解析为提交的名称。

note: type: Plain text
en: Then "git bisect" will checkout a commit of its choosing and ask the user to test it, like this:
zh_HANS-CN: 然后 "git bisect "会给出它所选择的一个提交，并要求用户测试它，就像这样：

note: type: Plain text
en: Note that the example that we will use is really a toy example, we will be looking for the first commit that has a version like "2.6.26-something", that is the commit that has a "SUBLEVEL = 26" line in the top level Makefile. This is a toy example because there are better ways to find this commit with Git than using "git bisect" (for example "git blame" or "git log -S<string>").
zh_HANS-CN: 请注意，我们将使用的例子实际上是一个小型例子，我们将寻找第一个版本为 "2.6.26-something "的提交，即在顶层 Makefile 中有 "SUBLEVEL = 26 "行的提交。这只是一个小型例子，因为除了使用 "git bisect"，还有更好的方法来找到这个提交（例如 "git blame "或 "git log -S<string>"）。

note: type: Title ~
en: Driving a bisection manually
zh_HANS-CN: 手动驱动二分

note: type: Plain text
en: At this point there are basically 2 ways to drive the search. It can be driven manually by the user or it can be driven automatically by a script or a command.
zh_HANS-CN: 在这一点上，基本上有两种方式来驱动搜索。它可以由用户手动驱动，也可以由一个脚本或命令自动驱动。

note: type: Plain text
en: If the user is driving it, then at each step of the search, the user will have to test the current commit and say if it is "good" or "bad" using the "git bisect good" or "git bisect bad" commands respectively that have been described above. For example:
zh_HANS-CN: 如果由用户来驱动，那么在搜索的每一步，用户都必须测试当前的提交，并分别使用上文所述的 "git bisect good "或 "git bisect bad "命令说它是 "好 "还是 "坏"。比如：

note: type: Plain text
en: And after a few more steps like that, "git bisect" will eventually find a first bad commit:
zh_HANS-CN: 继续这样做，"git bisect "最终会找到第一个坏提交：

note: type: Plain text
en: At this point we can see what the commit does, check it out (if it's not already checked out) or tinker with it, for example:
zh_HANS-CN: 在这一点上，我们可以看到提交的内容，检查（如果它还没有被检查出来）或修补它，比如：

note: type: delimited block -
en:  # *DOCUMENTATION*
zh_HANS-CN:  # *文档*

note: type: Plain text
en: And when we are finished we can use "git bisect reset" to go back to the branch we were in before we started bisecting:
zh_HANS-CN: 当我们完成后，我们可以使用 "git bisect reset "回到我们开始二分前所在的分支：

note: type: Title ~
en: Driving a bisection automatically
zh_HANS-CN: 自动驱动一个二分查找

note: type: Plain text
en: The other way to drive the bisection process is to tell "git bisect" to launch a script or command at each bisection step to know if the current commit is "good" or "bad". To do that, we use the "git bisect run" command. For example:
zh_HANS-CN: 另一种驱动分界进程的方法是告诉 "git bisect "在每个分界步骤启动一个脚本或命令，以了解当前提交是 "好 "还是 "坏"。要做到这一点，我们使用 "git bisect run "命令。比如说：

note: type: Plain text
en: In this example, we passed "grep '^SUBLEVEL = 25' Makefile" as parameter to "git bisect run". This means that at each step, the grep command we passed will be launched. And if it exits with code 0 (that means success) then git bisect will mark the current state as "good". If it exits with code 1 (or any code between 1 and 127 included, except the special code 125), then the current state will be marked as "bad".
zh_HANS-CN: 在这个例子中，我们把 "grep '^SUBLEVEL = 25' Makefile "作为参数传给 "git bisect run"。这意味着在每个步骤中，我们传递的grep命令将被启动。如果它以代码0退出（这意味着成功），那么git bisect将把当前状态标记为 "好"。如果它以代码1退出（或者包括1到127之间的任何代码，除了特殊代码125），那么当前状态将被标记为 "坏"。

note: type: Plain text
en: Exit code between 128 and 255 are special to "git bisect run". They make it stop immediately the bisection process. This is useful for example if the command passed takes too long to complete, because you can kill it with a signal and it will stop the bisection process.
zh_HANS-CN: 128和255之间的退出代码是 "git bisect run "的特殊代码。它们可以让它立即停止二分查找进程。例如，如果传递的命令需要很长时间才能完成，这很有用，因为你可以用一个信号杀掉该进程，它就会停止二分查找。

note: type: Plain text
en: It can also be useful in scripts passed to "git bisect run" to "exit 255" if some very abnormal situation is detected.
zh_HANS-CN: 在传递给 "git bisect run "的脚本中，如果检测到一些极端不正常的情况，它也可以起到 "exit 255 "的作用。

note: type: Title ~
en: Avoiding untestable commits
zh_HANS-CN: 避免不稳定的提交

note: type: Plain text
en: Sometimes it happens that the current state cannot be tested, for example if it does not compile because there was a bug preventing it at that time. This is what the special exit code 125 is for. It tells "git bisect run" that the current commit should be marked as untestable and that another one should be chosen and checked out.
zh_HANS-CN: 有时会发生当前状态无法测试的情况，例如，因为当时有一个错误阻止了它的编译。这就是特殊退出代码125的作用。它告诉 "git bisect run"，当前的提交应该被标记为不可测试，应该选择另一个提交并进行检查。

note: type: Plain text
en: If the bisection process is driven manually, you can use "git bisect skip" to do the same thing. (In fact the special exit code 125 makes "git bisect run" use "git bisect skip" in the background.)
zh_HANS-CN: 如果e=二分查找过程是手动驱动的，你可以使用 "git bisect skip "来做同样的事情。(事实上，特殊的退出代码125使 "git bisect run "在后台使用 "git bisect skip"）。

note: type: Plain text
en: Or if you want more control, you can inspect the current state using for example "git bisect visualize". It will launch gitk (or "git log" if the `DISPLAY` environment variable is not set) to help you find a better bisection point.
zh_HANS-CN: 或者如果你想要更多的控制，你可以使用 "git bisect visualize "检查当前状态。它将启动gitk（如果没有设置`DISPLAY`环境变量，则启动 "git log"）来帮助你找到一个更好的分界点。

note: type: Plain text
en: Either way, if you have a string of untestable commits, it might happen that the regression you are looking for has been introduced by one of these untestable commits. In this case it's not possible to tell for sure which commit introduced the regression.
zh_HANS-CN: 无论如何，如果你有一串不可测试的提交，你要找的回退可能是由其中一个不可测试的提交引入的。在这种情况下，我们不可能确定是哪个提交引入了回退。

note: type: Plain text
en: So if you used "git bisect skip" (or the run script exited with special code 125) you could get a result like this:
zh_HANS-CN: 因此，如果你使用 "git bisect skip"（或者运行脚本以特殊代码125退出），你可以得到这样的结果：

note: type: Title ~
en: Saving a log and replaying it
zh_HANS-CN: 保存日志并重新展示

note: type: Plain text
en: If you want to show other people your bisection process, you can get a log using for example:
zh_HANS-CN: 如果你想向其他人展示你的查找过程，你可以用以下的示例得到一个日志：

note: type: Plain text
en: And it is possible to replay it using:
zh_HANS-CN: 而且可以重新展示：

note: type: Title ~
en: Bisection algorithm
zh_HANS-CN: 二分算法

note: type: Plain text
en: As the Git commits form a directed acyclic graph (DAG), finding the best bisection commit to test at each step is not so simple. Anyway Linus found and implemented a "truly stupid" algorithm, later improved by Junio Hamano, that works quite well.
zh_HANS-CN: 由于Git提交形成了一个有向无环图（DAG），在每一步找到最佳的分界提交来测试并不那么简单。不管怎样，Linus发现并实现了一种 "非常傻瓜"的算法，后来被Junio Hamano改进，效果相当好。

note: type: Plain text
en: So the algorithm used by "git bisect" to find the best bisection commit when there are no skipped commits is the following:
zh_HANS-CN: 因此，当没有跳过的提交时，"git bisect "用来寻找最佳分界提交的算法如下：

note: type: Plain text
en: keep only the commits that:
zh_HANS-CN: 只保留以下的提交：

note: type: Plain text
en: are ancestor of the "bad" commit (including the "bad" commit itself),
zh_HANS-CN: 是"坏 "提交的祖先（包括 "坏 "提交本身），

note: type: Plain text
en: are not ancestor of a "good" commit (excluding the "good" commits).
zh_HANS-CN: 非"好 "提交的祖先（不包括 "好 "提交）。

note: type: Plain text
en: This means that we get rid of the uninteresting commits in the DAG.
zh_HANS-CN: 这意味着我们摆脱了DAG中无趣的提交。

note: type: Plain text
en: For example if we start with a graph like this:
zh_HANS-CN: 例如，如果我们从一个这样的图开始：

note: type: Plain text
en: where B is the "bad" commit, "G" are "good" commits and W, X, and Y are other commits, we will get the following graph after this first step:
zh_HANS-CN: 其中B是 "坏 "的提交，"G "是 "好 "的提交，W、X、Y是其他的提交，经过这第一步，我们会得到以下的图：

note: type: Plain text
en: So only the W and B commits will be kept. Because commits X and Y will have been removed by rules a) and b) respectively, and because commits G are removed by rule b) too.
zh_HANS-CN: 所以只有W和B的提交会被保留。因为X和Y的提交将分别被规则a)和b)所删除，而且G的提交也被规则b)所删除。

note: type: Plain text
en: Note for Git users, that it is equivalent as keeping only the commit given by:
zh_HANS-CN: 请注意，对于Git用户来说，这相当于只保留了所给的这些提交：

note: type: Plain text
en: Also note that we don't require the commits that are kept to be descendants of a "good" commit. So in the following example, commits W and Z will be kept:
zh_HANS-CN: 另外请注意，我们并不要求被保留的提交必须是 "好 "提交的后代。所以在下面的例子中，W和Z的提交将被保留：

note: type: Plain text
en: starting from the "good" ends of the graph, associate to each commit the number of ancestors it has plus one
zh_HANS-CN: 从图中 "好 "的两端开始，将每个提交的祖先数量加上一个并与之相关联

note: type: Plain text
en: For example with the following graph where H is the "bad" commit and A and D are some parents of some "good" commits:
zh_HANS-CN: 例如，下图中H是 "坏 "的提交，A和D是一些 "好 "的提交的父提交：

note: type: Plain text
en: this will give:
zh_HANS-CN: 这将给出：

note: type: Plain text
en: associate to each commit: min(X, N - X)
zh_HANS-CN: 关联到每个提交： min（X， N - X）

note: type: Plain text
en: where X is the value associated to the commit in step 2) and N is the total number of commits in the graph.
zh_HANS-CN: 其中X是与步骤2中的提交相关的数值，N是图中的提交总数。

note: type: Plain text
en: In the above example we have N = 8, so this will give:
zh_HANS-CN: 在上面的例子中，我们有N=8，所以这将得到：

note: type: Plain text
en: the best bisection point is the commit with the highest associated number
zh_HANS-CN: 最佳分界点是具有最高关联数的提交

note: type: Plain text
en: So in the above example the best bisection point is commit C.
zh_HANS-CN: 所以在上面的例子中，最好的分界点是C。

note: type: Plain text
en: note that some shortcuts are implemented to speed up the algorithm
zh_HANS-CN: 请注意，这里实施了一些快捷方式以加速算法

note: type: Plain text
en: As we know N from the beginning, we know that min(X, N - X) can't be greater than N/2. So during steps 2) and 3), if we would associate N/2 to a commit, then we know this is the best bisection point. So in this case we can just stop processing any other commit and return the current commit.
zh_HANS-CN: 由于我们从一开始就知道N，所以知道min(X, N - X)不可能大于N/2。所以在步骤2）和3）中，如果我们将N/2与一个提交相关联，那么我们就知道这是一个最佳的分界点。所以在这种情况下，我们可以直接停止处理任何其他的提交，并返回当前的提交。

note: type: Title ~
en: Bisection algorithm debugging
zh_HANS-CN: 二分法算法调试

note: type: Plain text
en: For any commit graph, you can see the number associated with each commit using "git rev-list --bisect-all".
zh_HANS-CN: 对于任何提交图，你可以用 "git rev-list --bisect-all "查看与每个提交相关的数字。

note: type: Plain text
en: For example, for the above graph, a command like:
zh_HANS-CN: 例如，对于上面的图表，使用如下命令：

note: type: Plain text
en: would output something like:
zh_HANS-CN: 会输出类似的内容：

note: type: Title ~
en: Bisection algorithm discussed
zh_HANS-CN: 讨论二分算法

note: type: Plain text
en: First let's define "best bisection point". We will say that a commit X is a best bisection point or a best bisection commit if knowing its state ("good" or "bad") gives as much information as possible whether the state of the commit happens to be "good" or "bad".
zh_HANS-CN: 首先让我们定义“最佳二分点”。如果知道一个提交的状态(“好”或“坏”)能尽可能多地提供提交状态是“好”还是“坏”的信息，我们就称它为最佳二分点或最佳二分提交。

note: type: Plain text
en: This means that the best bisection commits are the commits where the following function is maximum:
zh_HANS-CN: 这意味着最好的二分提交是以下函数最大的提交：

note: type: Plain text
en: where information_if_good(X) is the information we get if X is good and information_if_bad(X) is the information we get if X is bad.
zh_HANS-CN: 其中information_if_good（X）是X好时我们获得的信息，information_if_bad（X）是X坏时我们得到的信息。

note: type: Plain text
en: Now we will suppose that there is only one "first bad commit". This means that all its descendants are "bad" and all the other commits are "good". And we will suppose that all commits have an equal probability of being good or bad, or of being the first bad commit, so knowing the state of c commits gives always the same amount of information wherever these c commits are on the graph and whatever c is. (So we suppose that these commits being for example on a branch or near a good or a bad commit does not give more or less information).
zh_HANS-CN: 现在我们假设只有一次“第一次错误提交”。这意味着它的所有后代都是“坏的”，而所有其他提交都是“好的”。我们假设所有的提交都有相同的概率是好的或坏的，或者是第一个错误的提交，所以知道c提交的状态给出的信息总是相同的无论这些c提交在图上的哪个位置，无论c是什么。(所以我们假设这些提交是在一个分支上，或者在一个好的或坏的提交附近，不会给出更多或更少的信息)。

note: type: Plain text
en: Let's also suppose that we have a cleaned up graph like one after step
zh_HANS-CN: 我们还假设我们有一个清理过的图表，例如一个步骤后

note: type: Plain text
en: in the bisection algorithm above. This means that we can measure the information we get in terms of number of commit we can remove from the graph..
zh_HANS-CN: 在上面的二分算法中。这意味着我们可以根据可以从图中删除的提交数量来衡量我们获得的信息。

note: type: Plain text
en: And let's take a commit X in the graph.
zh_HANS-CN: 让我们在图中提交一个 X。

note: type: Plain text
en: If X is found to be "good", then we know that its ancestors are all "good", so we want to say that:
zh_HANS-CN: 如果发现X是“好”的，那么我们知道它的祖先都是“好”的，所以我们想说：

note: type: delimited block -
en: information_if_good(X) = number_of_ancestors(X)  (TRUE)
zh_HANS-CN: information_if_good（X） = number_of_ancestors（X） （TRUE）

note: type: Plain text
en: And this is true because at step 1) b) we remove the ancestors of the "good" commits.
zh_HANS-CN: 这是真的，因为在步骤 1） b） 我们删除了“好”提交的祖先。

note: type: Plain text
en: If X is found to be "bad", then we know that its descendants are all "bad", so we want to say that:
zh_HANS-CN: 如果发现 X 是“坏”的，那么我们知道它的后代都是“坏的”，所以我们想说：

note: type: delimited block -
en: information_if_bad(X) = number_of_descendants(X)  (WRONG)
zh_HANS-CN: information_if_bad（X） = number_of_descendants（X） （WRONG）

note: type: Plain text
en: But this is wrong because at step 1) a) we keep only the ancestors of the bad commit. So we get more information when a commit is marked as "bad", because we also know that the ancestors of the previous "bad" commit that are not ancestors of the new "bad" commit are not the first bad commit. We don't know if they are good or bad, but we know that they are not the first bad commit because they are not ancestor of the new "bad" commit.
zh_HANS-CN: 但这是错误的，因为在步骤1）a）我们只保留错误承诺的祖先。因此，当提交被标记为“坏”时，我们会得到更多信息，因为我们也知道，不是新“坏”提交的祖先的上一个“坏”提交的祖先不是第一个错误提交。我们不知道它们是好是坏，但我们知道它们不是第一个错误提交，因为它们不是新“坏”提交的祖先。

note: type: Plain text
en: So when a commit is marked as "bad" we know we can remove all the commits in the graph except those that are ancestors of the new "bad" commit. This means that:
zh_HANS-CN: 因此，当一个提交被标记为“坏”时，我们知道我们可以删除图形中的所有提交，除了那些是新“坏”提交的祖先。这意味着：

note: type: delimited block -
en: information_if_bad(X) = N - number_of_ancestors(X)  (TRUE)
zh_HANS-CN: information_if_bad（X） = N - number_of_ancestors（X） （TRUE）

note: type: Plain text
en: where N is the number of commits in the (cleaned up) graph.
zh_HANS-CN: 其中 N 是（清理的）图中的提交数。

note: type: Plain text
en: So in the end this means that to find the best bisection commits we should maximize the function:
zh_HANS-CN: 所以最后这意味着要找到最好的二分提交，我们应该最大化函数：

note: type: Plain text
en: And this is nice because at step 2) we compute number_of_ancestors(X)  and so at step 3) we compute f(X).
zh_HANS-CN: 这很好，因为在步骤2）我们计算number_of_ancestors(X)，所以在步骤3）我们计算f(X)。

note: type: Plain text
en: Let's take the following graph as an example:
zh_HANS-CN: 让我们以下图为例：

note: type: Plain text
en: If we compute the following non optimal function on it:
zh_HANS-CN: 如果我们在其上计算以下非最优函数：

note: type: Plain text
en: we get:
zh_HANS-CN: 我们得到：

note: type: Plain text
en: but with the algorithm used by git bisect we get:
zh_HANS-CN: 但是使用Git二分查找算法，我们得到：

note: type: Plain text
en: So we chose G, H, K or L as the best bisection point, which is better than F. Because if for example L is bad, then we will know not only that L, M and N are bad but also that G, H, I and J are not the first bad commit (since we suppose that there is only one first bad commit and it must be an ancestor of L).
zh_HANS-CN: 因此，我们选择G、H、K或L作为最佳平分点，这比F更好。因为，如果L是坏的，那么我们不仅知道L、M和N是坏的，而且还知道G、H、I和J不是第一个坏提交(因为我们假设只有一个第一个坏提交，而且它必须是L的祖先)。

note: type: Plain text
en: So the current algorithm seems to be the best possible given what we initially supposed.
zh_HANS-CN: 因此，鉴于我们最初假设的算法，当前的算法似乎是最好的。

note: type: Title ~
en: Skip algorithm
zh_HANS-CN: 跳过算法

note: type: Plain text
en: When some commits have been skipped (using "git bisect skip"), then the bisection algorithm is the same for step 1) to 3). But then we use roughly the following steps:
zh_HANS-CN: 当跳过一些提交（使用“git bisect skip”）时，步骤 1 到 3 的二分算法是相同的）。但是，让我们来使用以下步骤：

note: type: Plain text
en: sort the commit by decreasing associated value
zh_HANS-CN: 通过减少关联值对提交进行排序

note: type: Plain text
en: if the first commit has not been skipped, we can return it and stop here
zh_HANS-CN: 如果没有跳过第一次提交，我们可以返回它并在此处停止

note: type: Plain text
en: otherwise filter out all the skipped commits in the sorted list
zh_HANS-CN: 否则过滤掉排序列表中所有跳过的提交

note: type: Plain text
en: use a pseudo random number generator (PRNG) to generate a random number between 0 and 1
zh_HANS-CN: 使用伪随机数生成器 （PRNG） 生成介于 0 和 1 之间的随机数

note: type: Plain text
en: multiply this random number with its square root to bias it toward 0
zh_HANS-CN: 将此随机数与其平方根相乘，使其偏向 0

note: type: Plain text
en: multiply the result by the number of commits in the filtered list to get an index into this list
zh_HANS-CN: 将结果乘以过滤后的列表中的提交数量，得到该列表的索引

note: type: Plain text
en: return the commit at the computed index
zh_HANS-CN: 返回计算出的索引处的提交

note: type: Title ~
en: Skip algorithm discussed
zh_HANS-CN: 跳过算法讨论

note: type: Plain text
en: After step 7) (in the skip algorithm), we could check if the second commit has been skipped and return it if it is not the case. And in fact that was the algorithm we used from when "git bisect skip" was developed in Git version 1.5.4 (released on February 1st 2008) until Git version 1.6.4 (released July 29th 2009).
zh_HANS-CN: 在步骤7）（跳过算法中）之后，我们可以检查第二次提交是否已经被跳过，如果不是这样，则返回它。事实上，这就是我们从Git 1.5.4版本（2008年2月1日发布）开发 "git bisect skip "时开始使用的算法，直到Git 1.6.4版本（2009年7月29日发布）。

note: type: Plain text
en: But Ingo Molnar and H. Peter Anvin (another well known linux kernel developer) both complained that sometimes the best bisection points all happened to be in an area where all the commits are untestable. And in this case the user was asked to test many untestable commits, which could be very inefficient.
zh_HANS-CN: 但是Ingo Molnar和H. Peter Anvin（另一个著名的Linux内核开发者）都抱怨说，有时最好的分界点都碰巧在一个所有提交都无法测试的区域。而在这种情况下，用户被要求测试许多不可测试的提交，这可能是非常低效的。

note: type: Plain text
en: Indeed untestable commits are often untestable because a breakage was introduced at one time, and that breakage was fixed only after many other commits were introduced.
zh_HANS-CN: 事实上，不可测试的提交往往是因为某次引入了一个破绽，而这个破绽是在引入了许多其他的提交之后才被修复的。

note: type: Plain text
en: This breakage is of course most of the time unrelated to the breakage we are trying to locate in the commit graph. But it prevents us to know if the interesting "bad behavior" is present or not.
zh_HANS-CN: 当然，这种破坏在大多数时候与我们试图在提交图中定位的破坏无关。但它却让我们无法知道有趣的 "坏行为 "是否存在。

note: type: Plain text
en: So it is a fact that commits near an untestable commit have a high probability of being untestable themselves. And the best bisection commits are often found together too (due to the bisection algorithm).
zh_HANS-CN: 因此，在不可测试的提交附近的提交，其本身也有很大可能是不可测试的。而且，最好的分界线提交也经常被发现在一起（由于二分算法的原因）。

note: type: Plain text
en: This is why it is a bad idea to just chose the next best unskipped bisection commit when the first one has been skipped.
zh_HANS-CN: 这就是为什么当第一个分界线被跳过时，直接选择下一个最好的未跳过的分界线提交是个坏主意。

note: type: Plain text
en: We found that most commits on the graph may give quite a lot of information when they are tested. And the commits that will not on average give a lot of information are the one near the good and bad commits.
zh_HANS-CN: 我们发现，图中的大多数提交在被测试时可能会提供相当多的信息。而那些平均来说不会提供大量信息的提交是靠近好的和坏的提交。

note: type: Plain text
en: So using a PRNG with a bias to favor commits away from the good and bad commits looked like a good choice.
zh_HANS-CN: 因此，使用一个有偏向性的PRNG来偏向于远离好的和坏的提交，看起来是一个不错的选择。

note: type: Plain text
en: One obvious improvement to this algorithm would be to look for a commit that has an associated value near the one of the best bisection commit, and that is on another branch, before using the PRNG. Because if such a commit exists, then it is not very likely to be untestable too, so it will probably give more information than a nearly randomly chosen one.
zh_HANS-CN: 这个算法的一个明显的改进是，在使用PRNG之前，寻找一个与最佳分叉提交的值接近的提交，而且是在另一个分支上。因为如果这样的提交存在，那么它也不太可能是不可测试的，所以它可能会比几乎随机选择的提交提供更多信息。

note: type: Title ~
en: Checking merge bases
zh_HANS-CN: 检查合并基础

note: type: Plain text
en: There is another tweak in the bisection algorithm that has not been described in the "bisection algorithm" above.
zh_HANS-CN: 分割算法中还有一个调整，在上面的 "二分算法 "中没有描述。

note: type: Plain text
en: We supposed in the previous examples that the "good" commits were ancestors of the "bad" commit. But this is not a requirement of "git bisect".
zh_HANS-CN: 在前面的例子中，我们认为 "好 "的提交是 "坏 "的提交的祖先。但这并不是 "git bisect "的要求。

note: type: Plain text
en: Of course the "bad" commit cannot be an ancestor of a "good" commit, because the ancestors of the good commits are supposed to be "good". And all the "good" commits must be related to the bad commit.  They cannot be on a branch that has no link with the branch of the "bad" commit. But it is possible for a good commit to be related to a bad commit and yet not be neither one of its ancestor nor one of its descendants.
zh_HANS-CN: 当然，"坏 "提交不可能是 "好 "提交的祖先，因为好提交的祖先应该是 "好 "的。而所有 "好 "的提交必须与坏的提交有关。  它们不可能在一个与 "坏 "提交的分支没有联系的分支上。但是，一个好的提交有可能与一个坏的提交有关系，但既不是它的祖先，也不是它的后代。

note: type: Plain text
en: For example, there can be a "main" branch, and a "dev" branch that was forked of the main branch at a commit named "D" like this:
zh_HANS-CN: 例如，可以有一个 "main"分支和一个 "dev"分支，后者是从main分支中提交名为 "D"的提交克隆出来的，如下所示：

note: type: Plain text
en: The commit "D" is called a "merge base" for branch "main" and "dev" because it's the best common ancestor for these branches for a merge.
zh_HANS-CN: 提交 "D "被称为 "main "和 "dev "分支的 "合并基础"，因为它是这些分支可以进行合并的最佳共同祖先。

note: type: Plain text
en: Now let's suppose that commit J is bad and commit G is good and that we apply the bisection algorithm like it has been previously described.
zh_HANS-CN: 现在我们假设提交J是坏的，提交G是好的，并且我们像之前描述的那样应用二分法。

note: type: Plain text
en: As described in step 1) b) of the bisection algorithm, we remove all the ancestors of the good commits because they are supposed to be good too.
zh_HANS-CN: 正如一分为二算法的步骤1）b）所描述的那样，我们移除所有好提交的祖先，因为他们也应该是好的。

note: type: Plain text
en: So we would be left with only:
zh_HANS-CN: 因此，我们将只剩下：

note: type: Plain text
en: But what happens if the first bad commit is "B" and if it has been fixed in the "main" branch by commit "F"?
zh_HANS-CN: 但如果第一个坏的提交是 "B"，而在 "main"分支中已经被提交 "F "修复，会发生什么？

note: type: Plain text
en: The result of such a bisection would be that we would find that H is the first bad commit, when in fact it's B. So that would be wrong!
zh_HANS-CN: 这样一分为二后，我们会发现H是第一个坏提交，但实际上第一个坏提交是B，所以这将造成错误的结果！

note: type: Plain text
en: And yes it can happen in practice that people working on one branch are not aware that people working on another branch fixed a bug! It could also happen that F fixed more than one bug or that it is a revert of some big development effort that was not ready to be released.
zh_HANS-CN: 在实践中可能会发生这样的情况：在一个分支上工作的人不知道在另一个分支上工作的人修复了一个bug！也可能发生的情况是，F修复了不止一个bug，或者是对一些尚未准备好发布的大型开发工作进行了恢复。

note: type: Plain text
en: In fact development teams often maintain both a development branch and a maintenance branch, and it would be quite easy for them if "git bisect" just worked when they want to bisect a regression on the development branch that is not on the maintenance branch. They should be able to start bisecting using:
zh_HANS-CN: 事实上，开发团队经常同时维护一个开发分支和一个维护分支，如果 "git bisect "只是在他们想对开发分支上的回归进行分流而不在维护分支上的时候发挥作用，那对他们来说会很容易。他们应该可以用以下方法开始二分：

note: type: Plain text
en: To enable that additional nice feature, when a bisection is started and when some good commits are not ancestors of the bad commit, we first compute the merge bases between the bad and the good commits and we chose these merge bases as the first commits that will be checked out and tested.
zh_HANS-CN: 为了实现这个额外的功能，当一个分界开始，一些好的提交不是坏的提交的祖先时，我们首先计算坏的提交和好的提交之间的合并基数，我们选择这些合并基数作为第一个将被检查和测试的提交。

note: type: Plain text
en: If it happens that one merge base is bad, then the bisection process is stopped with a message like:
zh_HANS-CN: 如果有一个合并基数是坏的，那么二分过程就会停止，并发出类似的信息：

note: type: delimited block -
en: The merge base BBBBBB is bad.
    This means the bug has been fixed between BBBBBB and [GGGGGG,...].
zh_HANS-CN: 合并基础BBBBB是坏的。
    这意味着BBBBB和[GGGGG,...]之间的错误已经被修复。

note: type: Plain text
en: where BBBBBB is the sha1 hash of the bad merge base and [GGGGGG,...] is a comma separated list of the sha1 of the good commits.
zh_HANS-CN: 其中BBBBBB是坏合并基础的sha1哈希值，[GGGGG,...]是好提交的sha1的逗号分隔列表。

note: type: Plain text
en: If some of the merge bases are skipped, then the bisection process continues, but the following message is printed for each skipped merge base:
zh_HANS-CN: 如果一些合并基点被跳过，那么二分过程将继续进行，但对于每一个被跳过的合并基点都会打印出以下信息：

note: type: delimited block -
en: Warning: the merge base between BBBBBB and [GGGGGG,...] must be skipped.
    So we cannot be sure the first bad commit is between MMMMMM and BBBBBB.
    We continue anyway.
zh_HANS-CN: 警告：BBBBB和[GGGGG,...]之间的合并基数必须被跳过。
    所以我们不能确定第一个坏提交是在MMMMMM和BBBBB之间。
    我们会继续操作。

note: type: Plain text
en: where BBBBBB is the sha1 hash of the bad commit, MMMMMM is the sha1 hash of the merge base that is skipped and [GGGGGG,...] is a comma separated list of the sha1 of the good commits.
zh_HANS-CN: 其中BBBBB是坏提交的sha1哈希值，MMMMM是被跳过的合并基础的sha1哈希值，[GGGGG,...]是好提交的sha1的逗号分隔列表。

note: type: Plain text
en: So if there is no bad merge base, the bisection process continues as usual after this step.
zh_HANS-CN: 因此，如果没有坏的合并基础，在这一步之后，二分过程照常进行。

note: type: Title -
en: Best bisecting practices
zh_HANS-CN: 最佳的二分做法

note: type: Title ~
en: Using test suites and git bisect together
zh_HANS-CN: 测试套件和git bisect一起使用

note: type: Plain text
en: If you both have a test suite and use git bisect, then it becomes less important to check that all tests pass after each commit. Though of course it is probably a good idea to have some checks to avoid breaking too many things because it could make bisecting other bugs more difficult.
zh_HANS-CN: 如果你有一个测试套件并使用git bisect，那么在每次提交后检查所有测试是否通过就变得不那么重要。当然，为了避免破坏太多的东西，有一些检查可能是个好的做法，因为这可能会使二分其他bug更加困难。

note: type: Plain text
en: You can focus your efforts to check at a few points (for example rc and beta releases) that all the T test cases pass for all the N configurations. And when some tests don't pass you can use "git bisect" (or better "git bisect run"). So you should perform roughly:
zh_HANS-CN: 你可以集中精力在几个点上检查（例如rc和beta版本），所有的T测试用例在所有的N个配置下都能通过。当一些测试没有通过时，你可以使用 "git bisect"（当然"git bisect run"更好）。所以你应该大致上执行：

note: type: Plain text
en: where c is the number of rounds of test (so a small constant) and b is the ratio of bug per commit (hopefully a small constant too).
zh_HANS-CN: 其中c是测试的轮数（所以是一个小常数），b是每次提交的bug比例（希望也是一个小常数）。

note: type: Plain text
en: So of course it's much better as it's O(N * T) vs O(N * T * M) if you would test everything after each commit.
zh_HANS-CN: 所以，如果你在每次提交后都测试所有内容，O(N * T)当然比O(N * T * M)要好得多 。

note: type: Plain text
en: This means that test suites are good to prevent some bugs from being committed and they are also quite good to tell you that you have some bugs. But they are not so good to tell you where some bugs have been introduced. To tell you that efficiently, git bisect is needed.
zh_HANS-CN: 这意味着测试套件对于防止一些bug被提交是很好的，它们对于告诉你有一些bug也是很好的。但它们并不能很好地告诉你一些错误是在哪里被引入的。所以需要git bisect告诉你这些信息。

note: type: Plain text
en: The other nice thing with test suites, is that when you have one, you already know how to test for bad behavior. So you can use this knowledge to create a new test case for "git bisect" when it appears that there is a regression. So it will be easier to bisect the bug and fix it. And then you can add the test case you just created to your test suite.
zh_HANS-CN: 测试套件的另一个好处是，当你有一个测试套件时，你已经知道如何测试不良行为。因此，当出现类似问题时，你可以使用这些知识来创建一个新的 "git bisect "测试案例。这样就能更容易地将bug二分并修复它。然后你就可以把你刚创建的测试用例添加到你的测试套件中。

note: type: Plain text
en: So if you know how to create test cases and how to bisect, you will be subject to a virtuous circle:
zh_HANS-CN: 因此，如果你知道如何创建测试用例和二分，你就会受到良性循环的影响：

note: type: Plain text
en: more tests => easier to create tests => easier to bisect => more tests
zh_HANS-CN: 更多的测试 => 更容易创建测试 => 更容易二分 => 更多的测试

note: type: Plain text
en: So test suites and "git bisect" are complementary tools that are very powerful and efficient when used together.
zh_HANS-CN: 因此，测试套件和 "git bisect "是互补的工具，一起使用时非常强大和高效。

note: type: Title ~
en: Bisecting build failures
zh_HANS-CN: 对构建失败的二分

note: type: Plain text
en: You can very easily automatically bisect broken builds using something like:
zh_HANS-CN: 你可以非常容易地使用类似的东西来自动划分破碎的构建：

note: type: Title ~
en: Passing sh -c "some commands" to "git bisect run"
zh_HANS-CN: 将sh -c "一些命令 "传递给 "git bisect运行"

note: type: Plain text
en: On the other hand if you do this often, then it can be worth having scripts to avoid too much typing.
zh_HANS-CN: 另一方面，如果你经常这样做，那么就值得用脚本来避免过多的输入。

note: type: Title ~
en: Finding performance regressions
zh_HANS-CN: 寻找性能回归

note: type: Plain text
en: Here is an example script that comes slightly modified from a real world script used by Junio Hamano <<4>>.
zh_HANS-CN: 这里有一个例子，它是由Junio Hamano使用真实案例的脚本稍加修改而成的<<4>>。

note: type: Plain text
en: This script can be passed to "git bisect run" to find the commit that introduced a performance regression:
zh_HANS-CN: 这个脚本可以传递给 "git bisect run"，以找到引入性能回归的提交：

note: type: delimited block -
en: # Build errors are not what I am interested in.
    make my_app || exit 255
zh_HANS-CN: # 我并不关心构建中的错误。
    make my_app || exit 255

note: type: delimited block -
en: # We are checking if it stops in a reasonable amount of time, so
    # let it run in the background...
zh_HANS-CN: # 我们要检查它是否在合理的时间内停止，所以
    # 让它在后台运行...

note: type: delimited block -
en: # ... and grab its process ID.
    pid=$!
zh_HANS-CN: # ... 并抓取其进程ID。
    pid=$!

note: type: delimited block -
en: # ... and then wait for sufficiently long.
    sleep $NORMAL_TIME
zh_HANS-CN: # ... 然后等待足够长的时间。
    sleep $NORMAL_TIME

note: type: delimited block -
en: # ... and then see if the process is still there.
    if kill -0 $pid
    then
    	# It is still running -- that is bad.
    	kill $pid; sleep 1; kill $pid;
    	exit 1
    else
    	# It has already finished (the $pid process was no more),
    	# and we are happy.
    	exit 0
    fi
zh_HANS-CN: # ... 然后看看这个进程是否还在那里。
    if kill -0 $pid
    then
    	# 它仍然在运行 -- 有点失望。
    	kill $pid; sleep 1; kill $pid；
    	exit 1
    else
    	# 它已经结束了（$pid进程不再存在）,
    	# 皆大欢喜。
    	exit 0
    fi

note: type: Title ~
en: Following general best practices
zh_HANS-CN: 遵循一般的最佳做法

note: type: Plain text
en: It is obviously a good idea not to have commits with changes that knowingly break things, even if some other commits later fix the breakage.
zh_HANS-CN: 显然，不要在提交时明知故犯是最好的，即使后来有其他的提交修复了错误。

note: type: Plain text
en: It is also a good idea when using any VCS to have only one small logical change in each commit.
zh_HANS-CN: 在使用任何VCS时，最好是每次提交只有一个小的逻辑变化。

note: type: Plain text
en: The smaller the changes in your commit, the most effective "git bisect" will be. And you will probably need "git bisect" less in the first place, as small changes are easier to review even if they are only reviewed by the committer.
zh_HANS-CN: 你的提交中的改动越小，"git bisect "就越有效。并且你可能一开始就不太需要 "git bisect"，因为即使只有提交者审查，小改动也更容易审查。

note: type: Plain text
en: Another good idea is to have good commit messages. They can be very helpful to understand why some changes were made.
zh_HANS-CN: 另一个好的办法是要有一个明确的提交信息。它们对于理解为什么要做一些改动是非常有帮助的。

note: type: Plain text
en: These general best practices are very helpful if you bisect often.
zh_HANS-CN: 如果你经常进行二分操作，一般这些最佳实践是非常有帮助的。

note: type: Title ~
en: Avoiding bug prone merges
zh_HANS-CN: 避免容易出错的合并

note: type: Plain text
en: First merges by themselves can introduce some regressions even when the merge needs no source code conflict resolution. This is because a semantic change can happen in one branch while the other branch is not aware of it.
zh_HANS-CN: 即便合并不需要解决源代码冲突，但一次合并本身就会带来一些回归问题。这是因为语义变化可能发生在一个分支，而另一个分支并不知道该变化。

note: type: Plain text
en: For example one branch can change the semantic of a function while the other branch add more calls to the same function.
zh_HANS-CN: 例如，一个分支可以改变一个函数的语义，而另一个分支则对同一个函数增加更多的调用。

note: type: Plain text
en: This is made much worse if many files have to be fixed to resolve conflicts. That's why such merges are called "evil merges". They can make regressions very difficult to track down. It can even be misleading to know the first bad commit if it happens to be such a merge, because people might think that the bug comes from bad conflict resolution when it comes from a semantic change in one branch.
zh_HANS-CN: 如果为了解决冲突而不得不修复许多文件，情况就会变得更糟。这就是为什么这种合并被称为 "邪恶合并"。它们会使回归变得非常难以追踪。如果恰好合并了一个这样的坏提交，就很可能会产生误会，因为人们可能会认为这个错误来自于糟糕的冲突解决，但事实上它来自于一个分支的语义变化。

note: type: Plain text
en: Anyway "git rebase" can be used to linearize history. This can be used either to avoid merging in the first place. Or it can be used to bisect on a linear history instead of the non linear one, as this should give more information in case of a semantic change in one branch.
zh_HANS-CN: 无论如何，"git rebase "可以用来线性化历史。这也可以用来一开始就避免错误的合并。或者，它可以用来在线性历史上进行二分，而不是在非线性历史上进行二分，因为这在一个分支发生语义变化的情况下会提供更多信息。

note: type: Plain text
en: Merges can be also made simpler by using smaller branches or by using many topic branches instead of only long version related branches.
zh_HANS-CN: 通过使用较小的分支或使用许多主题分支而不是只使用一个非常长的分支，也可以使合并更简单。

note: type: Plain text
en: And testing can be done more often in special integration branches like linux-next for the linux kernel.
zh_HANS-CN: 而测试可以在特殊的集成分支中更频繁地进行，比如linux-next的linux内核。

note: type: Title ~
en: Adapting your work-flow
zh_HANS-CN: 调整你的工作流程

note: type: Plain text
en: A special work-flow to process regressions can give great results.
zh_HANS-CN: 一个处理回归的特殊工作流程可以带来好的结果。

note: type: Plain text
en: Here is an example of a work-flow used by Andreas Ericsson:
zh_HANS-CN: 比如，以下是Andreas Ericsson使用的一个工作流程：

note: type: Plain text
en: write, in the test suite, a test script that exposes the regression
zh_HANS-CN: 在测试套件中，写一个测试脚本，暴露出回归的问题

note: type: Plain text
en: fix the bug that is often made obvious by the previous step
zh_HANS-CN: 修复由上一步骤暴露出来的错误

note: type: Plain text
en: commit both the fix and the test script (and if needed more tests)
zh_HANS-CN: 提交修复和测试脚本（如果需要更多测试）

note: type: Plain text
en: And here is what Andreas said about this work-flow <<5>>:
zh_HANS-CN: 这里是Andreas对这个工作流程的评价<<5>>：

note: type: delimited block _
en: To give some hard figures, we used to have an average report-to-fix cycle of 142.6 hours (according to our somewhat weird bug-tracker which just measures wall-clock time). Since we moved to Git, we've lowered that to 16.2 hours. Primarily because we can stay on top of the bug fixing now, and because everyone's jockeying to get to fix bugs (we're quite proud of how lazy we are to let Git find the bugs for us). Each new release results in ~40% fewer bugs (almost certainly due to how we now feel about writing tests).
zh_HANS-CN: 我们曾经有142.6小时的平均报告到修复周期（由我们只是测量时钟时间的错误跟踪器统计出）。自从我们转移到Git后，我们已经把这个时间降低到了16.2小时。主要是因为我们现在可以保持在最开始进行错误修复，也因为每个人都在争先恐后地修复错误（我们对自己懒得让Git为我们找到错误感到很自豪）。每个新的版本都会减少40%的bug（出于我们现在对编写测试的感觉，这个结果非常可信）。

note: type: Plain text
en: Clearly this work-flow uses the virtuous circle between test suites and "git bisect". In fact it makes it the standard procedure to deal with regression.
zh_HANS-CN: 显然，这个工作流程使用了测试套件和 "git bisect "之间的良性循环。事实上，也正是因此它才成为为处理回归的标准程序。

note: type: Plain text
en: In other messages Andreas says that they also use the "best practices" described above: small logical commits, topic branches, no evil merge,... These practices all improve the bisectability of the commit graph, by making it easier and more useful to bisect.
zh_HANS-CN: 在其他信息中，Andreas说他们也使用了上述的 "最佳实践"：小的逻辑提交，主题分支，没有邪恶的合并，......。这些做法都提高了提交图的可分性，使之更容易、更有用。

note: type: Plain text
en: So a good work-flow should be designed around the above points. That is making bisecting easier, more useful and standard.
zh_HANS-CN: 因此，一个好的工作流程应该围绕以上几点来设计。这就是让分界线变得更容易、更有用和更标准。

note: type: Title ~
en: Involving QA people and if possible end users
zh_HANS-CN: 让QA人员参与进来，如果可能的话，让终端用户参与进来

note: type: Plain text
en: One nice about "git bisect" is that it is not only a developer tool. It can effectively be used by QA people or even end users (if they have access to the source code or if they can get access to all the builds).
zh_HANS-CN: 关于 "git bisect "的一个好处是，它不仅仅是一个开发者工具。它可以有效地被QA人员甚至终端用户使用（如果他们能够访问源代码或者能够获得所有构建的权限）。

note: type: Plain text
en: There was a discussion at one point on the linux kernel mailing list of whether it was ok to always ask end user to bisect, and very good points were made to support the point of view that it is ok.
zh_HANS-CN: 在linux内核邮件列表中曾一度讨论过总是要求终端用户进行分割是否可行，并提出了非常好的观点来支持可以这样做的观点。

note: type: Plain text
en: For example David Miller wrote <<6>>:
zh_HANS-CN: 例如，David Miller写道<<6>>：

note: type: delimited block _
en: What people don't get is that this is a situation where the "end node principle" applies. When you have limited resources (here: developers)  you don't push the bulk of the burden upon them. Instead you push things out to the resource you have a lot of, the end nodes (here: users), so that the situation actually scales.
zh_HANS-CN: 人们不明白的是，这是一个适用 "终端节点原则 "的情况。当你拥有有限的资源时（这里是指开发人员），你不会把大部分的负担推给他们。相反，你要把事情推给你拥有的大量资源，即终端节点（这里：用户），这样情况才会有实际的扩展。

note: type: Plain text
en: This means that it is often "cheaper" if QA people or end users can do it.
zh_HANS-CN: 这意味着，如果QA人员或终端用户能够做到这一点，往往会 "更便宜"。

note: type: Plain text
en: What is interesting too is that end users that are reporting bugs (or QA people that reproduced a bug) have access to the environment where the bug happens. So they can often more easily reproduce a regression. And if they can bisect, then more information will be extracted from the environment where the bug happens, which means that it will be easier to understand and then fix the bug.
zh_HANS-CN: 有趣的是，报告错误的终端用户（或重现错误的QA人员）可以进入发生错误的环境。所以他们通常可以更容易地重现一个回归。如果他们能进行二分法，那么就可以从发生错误的环境中提取更多的信息，这意味着将更容易理解，然后修复错误。

note: type: Plain text
en: For open source projects it can be a good way to get more useful contributions from end users, and to introduce them to QA and development activities.
zh_HANS-CN: 对于开源项目来说，这可能是一个很好的方法，可以从终端用户那里获得更多有用的贡献，并将他们引入QA和开发活动。

note: type: Title ~
en: Using complex scripts
zh_HANS-CN: 使用复杂脚本

note: type: Plain text
en: In some cases like for kernel development it can be worth developing complex scripts to be able to fully automate bisecting.
zh_HANS-CN: 在某些情况下，如内核开发，值得开发复杂的脚本，以便能够完全自动化地进行二分。

note: type: Plain text
en: Here is what Ingo Molnar says about that <<7>>:
zh_HANS-CN: 以下是Ingo Molnar对此的评价<<7>>：

note: type: delimited block _
en: i have a fully automated bootup-hang bisection script. It is based on "git-bisect run". I run the script, it builds and boots kernels fully automatically, and when the bootup fails (the script notices that via the serial log, which it continuously watches - or via a timeout, if the system does not come up within 10 minutes it's a "bad" kernel), the script raises my attention via a beep and i power cycle the test box. (yeah, i should make use of a managed power outlet to 100% automate it)
zh_HANS-CN: 我有一个完全自动化启动并挂起的二分脚本。它是基于 "git-bisect run "的。我运行这个脚本，它完全自动地构建和启动内核，当启动失败时（脚本通过连续观察的串行日志注意到这一点或者是通过超时判断，如果系统在10分钟内没有启动，就是一个 "坏 "内核），脚本通过嘟嘟声引起我的注意，我就给测试机断电。(的确，我应该使用一个可管理的电源插座来实现100%的自动化）

note: type: Title ~
en: Combining test suites, git bisect and other systems together
zh_HANS-CN: 将测试组件、git bisect 和其他系统组合在一起

note: type: Plain text
en: We have seen that test suites and git bisect are very powerful when used together. It can be even more powerful if you can combine them with other systems.
zh_HANS-CN: 我们已经看到，测试套件和git bisect一起使用时已经非常强大了。如果你能把它们和其他系统结合起来，那将更加强大。

note: type: Plain text
en: For example some test suites could be run automatically at night with some unusual (or even random) configurations. And if a regression is found by a test suite, then "git bisect" can be automatically launched, and its result can be emailed to the author of the first bad commit found by "git bisect", and perhaps other people too. And a new entry in the bug tracking system could be automatically created too.
zh_HANS-CN: 例如，一些测试套件可以在晚上以一些不寻常（甚至是随机）的配置自动运行。如果测试套件发现了一个回归问题，那么 "git bisect "可以自动启动，其结果可以通过电子邮件发给 "git bisect"发现的第一个坏提交的作者，也许还有其他人。并且在错误跟踪系统中自动创建一个新条目。

note: type: Title -
en: The future of bisecting
zh_HANS-CN: 未来的二分算法

note: type: Plain text
en: We saw earlier that "git bisect skip" is now using a PRNG to try to avoid areas in the commit graph where commits are untestable. The problem is that sometimes the first bad commit will be in an untestable area.
zh_HANS-CN: 之前，我们发现，"git bisect skip"目前使用PRNG来试图避免提交图中不可测试的区域。但问题是，有时第一个坏的提交恰恰在一个无法测试的区域。

note: type: Plain text
en: To simplify the discussion we will suppose that the untestable area is a simple string of commits and that it was created by a breakage introduced by one commit (let's call it BBC for bisect breaking commit) and later fixed by another one (let's call it BFC for bisect fixing commit).
zh_HANS-CN: 为了简化这个话题，我们将假设不可测试区是一串简单的提交，它是由一个提交（我们称它为BBC，意为双断裂提交）引起的断裂，后来被另一个提交修复（我们称它为BFC，意为双断裂修复提交）。

note: type: Plain text
en: where we know that Y is good and BFC is bad, and where BBC and X1 to X6 are untestable.
zh_HANS-CN: 其中，我们知道Y是好的，BFC是坏的，而BBC和X1到X6不可测试。

note: type: Plain text
en: In this case if you are bisecting manually, what you can do is create a special branch that starts just before the BBC. The first commit in this branch should be the BBC with the BFC squashed into it. And the other commits in the branch should be the commits between BBC and BFC rebased on the first commit of the branch and then the commit after BFC also rebased on.
zh_HANS-CN: 在这种情况下，如果你是手动二分，你可以在BBC开始之前创建一个特殊的分支。这个分支的第一次提交应该是将 BFC 与BBC压缩到一起的。分支中的其他提交应该是在BBC和BFC之间的提交，以该分支的第一次提交为基础，然后再以BFC之后的提交为基础。

note: type: Plain text
en: where commits quoted with ' have been rebased.
zh_HANS-CN: 其中以引号 ' 括起来的的提交已被变基。

note: type: Plain text
en: You can easily create such a branch with Git using interactive rebase.
zh_HANS-CN: 你能够很轻松地用Git的交互式变基来创建这样的分支。

note: type: Plain text
en: For example using:
zh_HANS-CN: 例如：

note: type: Plain text
en: and then moving BFC after BBC and squashing it.
zh_HANS-CN: 然后BFC移动到BBC之后并压缩。

note: type: Plain text
en: After that you can start bisecting as usual in the new branch and you should eventually find the first bad commit.
zh_HANS-CN: 之后，你可以像往常一样在新的分支中开始二分，最终你应该能找到第一个坏的提交。

note: type: Plain text
en: If you are using "git bisect run", you can use the same manual fix up as above, and then start another "git bisect run" in the special branch. Or as the "git bisect" man page says, the script passed to "git bisect run" can apply a patch before it compiles and test the software <<8>>. The patch should turn a current untestable commits into a testable one. So the testing will result in "good" or "bad" and "git bisect" will be able to find the first bad commit. And the script should not forget to remove the patch once the testing is done before exiting from the script.
zh_HANS-CN: 如果你使用命令 "git bisect run"，你可以使用与上述相同的手段进行修复，然后在特殊分支中启动另一个 "git bisect run"。或者如 "git bisect"手册所说，作为"git bisect run"的脚本可以在编译和测试软件之前添加一个补丁<<8>>。这个补丁需要把当前不可测试的提交变成可测试的。这样，"git bisect "将能够找到第一个坏提交，所以测试的结果是 "好 "或 "坏"。但脚本应当在测试完成后退出脚本前删除补丁。

note: type: Plain text
en: (Note that instead of a patch you can use "git cherry-pick BFC" to apply the fix, and in this case you should use "git reset --hard HEAD^" to revert the cherry-pick after testing and before returning from the script.)
zh_HANS-CN: (注意，你可以用 "git cherry-pick BFC"代替补丁来应用修复，在这种情况下，你应该用 "git reset --hard HEAD^"来在测试后和从脚本返回前恢复甄选（cherry-pick））

note: type: Plain text
en: But the above ways to work around untestable areas are a little bit clunky. Using special branches is nice because these branches can be shared by developers like usual branches, but the risk is that people will get many such branches. And it disrupts the normal "git bisect" work-flow. So, if you want to use "git bisect run" completely automatically, you have to add special code in your script to restart bisection in the special branches.
zh_HANS-CN: 但上述绕过不可测试区域的方法有点笨拙。使用特殊分支是最好的，因为这些分支可以像普通分支一样被开发者共享，但风险是会创建很多这样的分支。并且它破坏了正常的 "git bisect "工作流程。因此，如果你想完全自动地使用 "git bisect run"，你必须在你的脚本中添加特殊的代码，以重新启动特殊分支的二分流程。

note: type: Plain text
en: Anyway one can notice in the above special branch example that the Z' and Z commits should point to the same source code state (the same "tree" in git parlance). That's because Z' result from applying the same changes as Z just in a slightly different order.
zh_HANS-CN: 总之，我们可以注意到，在上述特殊分支的例子中，Z'和Z的提交应该指向相同的源代码状态（用git术语说是相同的 "树"）。这是因为Z'的结果是应用了与Z相同的修改，只是顺序略有不同。

note: type: Plain text
en: So if we could just "replace" Z by Z' when we bisect, then we would not need to add anything to a script. It would just work for anyone in the project sharing the special branches and the replacements.
zh_HANS-CN: 因此，如果我们可以在二分时用Z'来 "替换"Z，那么我们就不需要在脚本中添加任何东西。它将对项目中任何共享特殊和替换分支的人起作用。

note: type: Plain text
en: With the example above that would give:
zh_HANS-CN: 通过上面的例子，可以看出：

note: type: Plain text
en: That's why the "git replace" command was created. Technically it stores replacements "refs" in the "refs/replace/" hierarchy. These "refs" are like branches (that are stored in "refs/heads/") or tags (that are stored in "refs/tags"), and that means that they can automatically be shared like branches or tags among developers.
zh_HANS-CN: 这就是"git replace"命令出现的原因。技术层面，它在 "refs/replace/"目录中存储替换的 "refs"。这些 "ref "就像分支（存储在 "refs/heads/"中）或标签（存储在 "refs/tags "中），所以它们可以像分支或标签一样自动地在开发者之间共享。

note: type: Plain text
en: "git replace" is a very powerful mechanism. It can be used to fix commits in already released history, for example to change the commit message or the author. And it can also be used instead of git "grafts" to link a repository with another old repository.
zh_HANS-CN: "git replace"拥有非常强大的机制。它可以用来修复发布历史中的提交，例如改变提交的信息或作者。它也可以用来代替git "grafts"，将一个仓库与另一个旧仓库连接起来。

note: type: Plain text
en: In fact it's this last feature that "sold" it to the Git community, so it is now in the "master" branch of Git's Git repository and it should be released in Git 1.6.5 in October or November 2009.
zh_HANS-CN: 事实上，正是这最后一个功能把它"卖"给了Git社区，所以它目前在Git仓库的"master"分支中，应该是在2009年10月或11月的Git 1.6.5版本中发布的。

note: type: Plain text
en: One problem with "git replace" is that currently it stores all the replacements refs in "refs/replace/", but it would be perhaps better if the replacement refs that are useful only for bisecting would be in "refs/replace/bisect/". This way the replacement refs could be used only for bisecting, while other refs directly in "refs/replace/" would be used nearly all the time.
zh_HANS-CN: "git replace"存在的一个问题是，目前它把所有替换的引用都存放在 "refs/replace/"中，但如果把只对二分有用的替换引用放在 "refs/replace/bisect/"中，也许会更好。这样一来，替换的引用就可以只用于二分，而直接存储在 "refs/replace/"中的其他引用则几乎一直在使用。

note: type: Title ~
en: Bisecting sporadic bugs
zh_HANS-CN: 查找零星的漏洞

note: type: Plain text
en: Another possible improvement to "git bisect" would be to optionally add some redundancy to the tests performed so that it would be more reliable when tracking sporadic bugs.
zh_HANS-CN: 对 "git bisect"的另一个可能的改进是，在所进行的测试中选择性地增加一些冗余，这样在跟踪零星的bug时就会更可靠。

note: type: Plain text
en: This has been requested by some kernel developers because some bugs called sporadic bugs do not appear in all the kernel builds because they are very dependent on the compiler output.
zh_HANS-CN: 这是由一些内核开发者提出的要求，因为一些被称为零星漏洞的漏洞不会出现在所有的内核构建过程中，因为发现它们非常依赖于编译器输出。

note: type: Plain text
en: The idea is that every 3 test for example, "git bisect" could ask the user to test a commit that has already been found to be "good" or "bad" (because one of its descendants or one of its ancestors has been found to be "good" or "bad" respectively). If it happens that a commit has been previously incorrectly classified then the bisection can be aborted early, hopefully before too many mistakes have been made. Then the user will have to look at what happened and then restart the bisection using a fixed bisect log.
zh_HANS-CN: 我们的想法是，每3次测试，"git bisect"可以要求用户测试一个已经被标记为 "好 "或 "坏 "的提交（因为它的一个后代或一个祖先已经被视为 "好 "或 "坏"提交）。如果错误地分类了一个提交，那么可以在酿成大祸之前中止这个过程。接着，用户将不得不查看发生了什么，最后使用固定的日志重新启动二分操作。

note: type: Plain text
en: There is already a project called BBChop created by Ealdwulf Wuffinga on Github that does something like that using Bayesian Search Theory <<9>>:
zh_HANS-CN: 目前，Github上已经有一个由Ealdwulf Wuffinga创建的名为BBChop的项目，其使用贝叶斯搜索理论做了类似的事情<<9>>：

note: type: delimited block _
en: BBChop is like 'git bisect' (or equivalent), but works when your bug is intermittent. That is, it works in the presence of false negatives (when a version happens to work this time even though it contains the bug). It assumes that there are no false positives (in principle, the same approach would work, but adding it may be non-trivial).
zh_HANS-CN: BBChop就像'git bisect'（或就是），但当存在间歇性漏洞的时候，它就会起作用。也就是说，它在存在假阴性的情况下也能工作（尽管这个版本包含了这个漏洞，但也可以运行）。它假定不存在假阳性（原则上，同样的方法也可以，但这可能不容易）。

note: type: Plain text
en: But BBChop is independent of any VCS and it would be easier for Git users to have something integrated in Git.
zh_HANS-CN: 但BBChop是独立于任何VCS的，并且对于Git用户来说，在Git中集成一些东西非常容易。

note: type: Plain text
en: We have seen that regressions are an important problem, and that "git bisect" has nice features that complement very well practices and other tools, especially test suites, that are generally used to fight regressions. But it might be needed to change some work-flows and (bad) habits to get the most out of it.
zh_HANS-CN: 我们已经了解到，回归是一个重要的问题，"git bisect"有强大的功能，同时也可以很好地补充和应用到其他工具中，尤其是通常被用来解决回归问题测试套件。但也需要改变一些工作流程和改正坏习惯，以获得它的最大效益。

note: type: Plain text
en: Some improvements to the algorithms inside "git bisect" are possible and some new features could help in some cases, but overall "git bisect" works already very well, is used a lot, and is already very useful. To back up that last claim, let's give the final word to Ingo Molnar when he was asked by the author how much time does he think "git bisect" saves him when he uses it:
zh_HANS-CN: "git bisect"内部的算法可以进行改进，并且新的功能在特殊情况下也会有帮助，但总的来说，"git bisect "已经被大量使用并且非常优秀。Ingo Molnar的发言是最后一个说法的有力支撑，作者问他认为使用 "git bisect"能够节省他多少时间：

note: type: delimited block _
en: About ten years ago did i do my first 'bisection' of a Linux patch queue. That was prior the Git (and even prior the BitKeeper) days. I literally days spent sorting out patches, creating what in essence were standalone commits that i guessed to be related to that bug.
zh_HANS-CN: 大约十年前，我第一次对Linux补丁队列进行了 "二分算法"。那是在Git（甚至在BitKeeper）出现之前。我真的花了好几天时间来整理补丁，创建了一些我猜测与该错误有关的独立提交。

note: type: delimited block _
en: It was a tool of absolute last resort. I'd rather spend days looking at printk output than do a manual 'patch bisection'.
zh_HANS-CN: 这是一个万不得已的情况下使用的工具。我宁愿花几天时间看printk输出，也不愿意进行手动 的"补丁分割"。

note: type: delimited block _
en: With Git bisect it's a breeze: in the best case i can get a ~15 step kernel bisection done in 20-30 minutes, in an automated way. Even with manual help or when bisecting multiple, overlapping bugs, it's rarely more than an hour.
zh_HANS-CN: 使用Git bisect很容易：在最好的情况下，我可以在20-30分钟内以自动化的方式完成约15个步骤的内核分割。即使需要人工帮助，或者在对多个重叠的bug进行分割时，也很少超过一个小时。

note: type: delimited block _
en: In fact it's invaluable because there are bugs i would never even _try_ to debug if it wasn't for git bisect. In the past there were bug patterns that were immediately hopeless for me to debug - at best i could send the crash/bug signature to lkml and hope that someone else can think of something.
zh_HANS-CN: 事实上，它是非常有价值的，因为如果没有git bisect，有些漏洞我甚至不会尝试去调试。在过去，有些漏洞对我来说基本就没有希望进行调试——我最多只能把崩溃/漏洞签名发给lkml，希望别人能想到一些东西。

note: type: delimited block _
en: And even if a bisection fails today it tells us something valuable about the bug: that it's non-deterministic - timing or kernel image layout dependent.
zh_HANS-CN: 即使是在运行失败的情况下，它也会告诉我们关于这个漏洞一些有价值的东西：它是非决定性的——与时间或内核图像布局有关。

note: type: delimited block _
en: So git bisect is unconditional goodness - and feel free to quote that ;-)
zh_HANS-CN: 因此，git bisect的善良不求回报——请随意引用这句话;-)

note: type: Plain text
en: Many thanks to Junio Hamano for his help in reviewing this paper, for reviewing the patches I sent to the Git mailing list, for discussing some ideas and helping me improve them, for improving "git bisect" a lot and for his awesome work in maintaining and developing Git.
zh_HANS-CN: 非常感谢Junio Hamano在审阅本文时提供的帮助，感谢他审阅我发给Git邮件列表的补丁，感谢他讨论一些想法并帮助我改进，感谢他对 "git bisect"的大量改进，感谢他在维护和开发Git方面的出色工作。

note: type: Plain text
en: Many thanks to Ingo Molnar for giving me very useful information that appears in this paper, for commenting on this paper, for his suggestions to improve "git bisect" and for evangelizing "git bisect" on the linux kernel mailing lists.
zh_HANS-CN: 非常感谢Ingo Molnar给本文提供非常有用的信息，感谢他对本文的评论，感谢他对 "git bisect"的改进建议，感谢他在linux内核邮件列表中对"git bisect"的宣传。

note: type: Plain text
en: Many thanks to Linus Torvalds for inventing, developing and evangelizing "git bisect", Git and Linux.
zh_HANS-CN: 非常感谢Linus Torvalds对 "git bisect"、Git和Linux的发明、开发和宣传。

note: type: Plain text
en: Many thanks to the many other great people who helped one way or another when I worked on Git, especially to Andreas Ericsson, Johannes Schindelin, H. Peter Anvin, Daniel Barkalow, Bill Lear, John Hawley, Shawn O. Pierce, Jeff King, Sam Vilain, Jon Seymour.
zh_HANS-CN: 非常感谢其他许多在我从事Git工作时以这种或那种方式提供帮助的伟大人物，特别是Andreas Ericsson, Johannes Schindelin, H. Peter Anvin, Daniel Barkalow, Bill Lear, John Hawley, Shawn O. Pierce, Jeff King, Sam Vilain, Jon Seymour。

note: type: Plain text
en: Many thanks to the Linux-Kongress program committee for choosing the author to given a talk and for publishing this paper.
zh_HANS-CN: 非常感谢Linux-Kongress计划委员会选择作者进行演讲并发表这篇论文。
