Git 中文参考（四）

ApacheCN_飞龙

发布于 2024-06-26 14:19:30

1050

发布于 2024-06-26 14:19:30

文章被收录于专栏：信数据得永生信数据得永生

原文：Git Reference 协议：CC BY-NC-SA 4.0

git-remote

原文： git-scm.com/docs/git-remote

名称

git-remote - 管理一组跟踪的存储库

概要

git remote [-v | --verbose]
git remote add [-t <branch>] [-m <master>] [-f] [--[no-]tags] [--mirror=<fetch|push>] <name> <url>
git remote rename <old> <new>
git remote remove <name>
git remote set-head <name> (-a | --auto | -d | --delete | <branch>)
git remote set-branches [--add] <name> <branch>…
git remote get-url [--push] [--all] <name>
git remote set-url [--push] <name> <newurl> [<oldurl>]
git remote set-url --add [--push] <name> <newurl>
git remote set-url --delete [--push] <name> <url>
git remote [-v | --verbose] show [-n] <name>…
git remote prune [-n | --dry-run] <name>…
git remote [-v | --verbose] update [-p | --prune] [(<group> | <remote>)…]

描述

管理您跟踪其分支的存储库集（“远程”）。

OPTIONS

-v

 --verbose

稍微冗长一点，并在名字后显示远程网址。注意：必须放在remote和subcommand之间。

COMMANDS

没有参数，显示现有遥控器的列表。有几个子命令可用于对遥控器执行操作。

add

添加名为< name>的远程名称对于< url>的存储库。然后，命令git fetch <name>可用于创建和更新远程跟踪分支< name> /< branch>。

使用-f选项，在设置远程信息后立即运行git fetch <name>。

使用--tags选项，git fetch <name>从远程存储库导入每个标记。

使用--no-tags选项，git fetch <name>不会从远程存储库导入标记。

默认情况下，仅导入已获取分支上的标记（请参阅 git-fetch [1] ）。

使用-t <branch>选项，而不是默认的 glob refspec 用于远程跟踪refs/remotes/<name>/命名空间下的所有分支，而是创建仅跟踪<branch>的 refspec。您可以提供多个-t <branch>来跟踪多个分支而不占用所有分支。

使用-m <master>选项，symbolic-ref refs/remotes/<name>/HEAD被设置为指向远程的<master>分支。另请参见 set-head 命令。

使用--mirror=fetch创建获取镜像时，refs 不会存储在 refs / remotes / 命名空间中，而是遥控器上 refs / 中的所有内容都将被直接镜像进入本地存储库中的 refs / 。此选项仅在裸存储库中有意义，因为获取将覆盖任何本地提交。

使用--mirror=push创建推镜时，git push将始终表现为--mirror通过。

 rename

重命名名为< old>的远程名称到< new>。将更新远程的所有远程跟踪分支和配置设置。

如果< old>和< new>是相同的，< old>是

 remove

rm

删除名为< name>的远程数据库。将删除远程的所有远程跟踪分支和配置设置。

 set-head

设置或删除指定远程的默认分支（即 symbolic-ref refs/remotes/<name>/HEAD的目标）。不需要具有远程的默认分支，但允许指定远程的名称来代替特定分支。例如，如果origin的默认分支设置为master，则可以在通常指定origin/master的任何位置指定origin。

使用-d或--delete，删除符号 ref refs/remotes/<name>/HEAD。

使用-a或--auto，查询远程以确定其HEAD，然后将 symbolic-ref refs/remotes/<name>/HEAD设置为同一分支。例如，如果远程HEAD指向next，“git remote set-head origin -a”将 symbolic-ref refs/remotes/origin/HEAD设置为refs/remotes/origin/next。这仅在refs/remotes/origin/next已存在时才有效;如果不是，它必须先取出。

使用<branch>显式设置 symbolic-ref refs/remotes/<name>/HEAD。例如，“git remote set-head origin master”将 symbolic-ref refs/remotes/origin/HEAD设置为refs/remotes/origin/master。这仅在refs/remotes/origin/master已存在时才有效;如果不是，它必须先取出。

 set-branches

更改命名远程跟踪的分支列表。在初始设置遥控器之后，这可用于跟踪可用远程分支的子集。

命名分支将被解释为使用 git remote add 命令行上的-t选项指定。

使用--add，而不是替换当前跟踪的分支列表，添加到该列表。

 get-url

检索远程的 URL。这里扩展了insteadOf和pushInsteadOf的配置。默认情况下，仅列出第一个 URL。

使用--push，将查询推送 URL 而不是提取 URL。

使用--all，将列出远程的所有 URL。

 set-url

更改远程的 URL。设置远程< name>的第一个网址匹配正则表达式< oldurl> （如果没有给出< oldurl>则是第一个 URL）到< newurl>。如果< oldurl>与任何 URL 都不匹配，发生错误并且没有任何更改。

使用--push，操纵推送 URL 而不是获取 URL。

使用--add，不添加现有 URL，而是添加新 URL。

使用--delete，而不是更改现有网址，所有匹配正则表达式< url>的网址已删除远程< name>。尝试删除所有非推送 URL 是一个错误。

请注意，推送 URL 和提取 URL 即使可以设置不同，仍必须引用相同的位置。您推送到推送 URL 的内容应该是您从提取 URL 中立即获取的内容。如果您尝试从一个位置（例如您的上游）获取并推送到另一个位置（例如您的发布存储库），请使用两个单独的遥控器。

 show

提供有关远程< name>的一些信息。

使用-n选项，不会先使用git ls-remote <name>查询远程磁头;而是使用缓存的信息。

 prune

删除与< name>关联的陈旧引用。默认情况下，< name>下的过时远程跟踪分支被删除，但根据全局配置和远程配置，我们甚至可以修剪那些尚未推送的本地标签。相当于git fetch --prune <name>，但不会获取新的引用。

请参阅 git-fetch [1] 的 PRUNING 部分，了解它将根据各种配置进行修剪的内容。

使用--dry-run选项，报告将修剪哪些分支，但不实际修剪它们。

 update

获取由远程数据库定义的存储库中的远程数据库或远程组的更新。< group>。如果在命令行中既未指定 group 也未指定 remote，则将使用配置参数 remotes.default;如果未定义 remotes.default，则所有没有配置参数 remote 的遥控器将被更新。< name> .skipDefaultUpdate 设置为 true。（参见 git-config [1] ）。

使用--prune选项，对所有已更新的遥控器运行修剪。

讨论

使用remote.origin.url和remote.origin.fetch配置变量实现远程配置。（参见 git-config [1] ）。

例子

添加一个新的远程，获取，并从中检出一个分支

$ git remote
origin
$ git branch -r
  origin/HEAD -&gt; origin/master
  origin/master
$ git remote add staging git://git.kernel.org/.../gregkh/staging.git
$ git remote
origin
staging
$ git fetch staging
...
From git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
 * [new branch]      master     -&gt; staging/master
 * [new branch]      staging-linus -&gt; staging/staging-linus
 * [new branch]      staging-next -&gt; staging/staging-next
$ git branch -r
  origin/HEAD -&gt; origin/master
  origin/master
  staging/master
  staging/staging-linus
  staging/staging-next
$ git checkout -b staging staging/master
...

模仿 git clone 但仅跟踪选定的分支

$ mkdir project.git
$ cd project.git
$ git init
$ git remote add -f -t master -m master origin git://example.com/git.git/
$ git merge origin

也可以看看

git-fetch [1] git-branch [1] git-config [1]

GIT

部分 git [1] 套件

git-submodule

原文： git-scm.com/docs/git-submodule

名称

git-submodule - 初始化，更新或检查子模块

概要

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] summary [<options>] [--] [<path>…]
git submodule [--quiet] foreach [--recursive] <command>
git submodule [--quiet] sync [--recursive] [--] [<path>…]
git submodule [--quiet] absorbgitdirs [--] [<path>…]

描述

检查，更新和管理子模块。

有关子模块的更多信息，请参阅 gitsubmodules [7] 。

COMMANDS

 add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--depth <depth>] [--] <repository> [<path>]

将给定存储库添加为给定路径下的子模块，该路径指向要在当前项目旁边提交的变更集：当前项目称为“超级项目”。

<库>是新子模块的原始存储库的 URL。这可以是绝对 URL，或者（如果它以./或…/开头），相对于超级项目的默认远程存储库的位置（请注意，指定存储库 foo.git ，这是位于超级项目 bar.git 旁边，您必须使用 …/foo.git 而不是 ./foo.git - 作为一个在遵循相对 URL 规则时可能会有所期望 - 因为 Git 中相对 URL 的评估与相对目录的相同。

默认远程是当前分支的远程跟踪分支的远程。如果不存在这样的远程跟踪分支或者 HEAD 被分离，则假定“origin”是默认远程。如果超级项目没有配置默认远程，则超级项目是其自己的权威上游，而是使用当前工作目录。

可选参数< path>是克隆子模块在超级项目中存在的相对位置。如果< path>如果未给出，则使用源存储库的规范部分（“repo”表示“/path/to/repo.git”，“foo”表示“host.xz：foo / .git”）。如果< path>存在并且已经是一个有效的 Git 存储库，然后它将在没有克隆的情况下进行提交。 <路径>除非--name用于指定逻辑名称，否则它也会在其配置条目中用作子模块的逻辑名称。

给定的 URL 记录在.gitmodules中，供后续用户克隆超级项目使用。如果 URL 是相对于超级项目的存储库给出的，则推测是超级项目，子模块存储库将保存在同一相对位置，并且只需要提供超级项目的 URL。 git-submodule 将使用.gitmodules中的相对 URL 正确定位子模块。

 status [--cached] [--recursive] [--] [<path>…]

显示子模块的状态。这将打印每个子模块当前检出的提交的 SHA-1，以及子模块路径和 SHA-1 的 git describe 的输出。如果子模块未初始化，则每个 SHA-1 可能以-为前缀，如果当前检出的子模块提交与包含存储库的索引中找到的 SHA-1 不匹配，则+和U如果子模块有合并冲突。

如果指定了--recursive，则此命令将递归到嵌套的子模块中，并显示其状态。

如果您只对当前初始化的子模块相对于索引或 HEAD 中记录的提交的更改感兴趣， git-status [1] 和 git-diff [1] 也将提供该信息（并且还可以报告对子模块工作树的更改）。

 init [--] [<path>…]

通过在.git / config 中设置submodule.$name.url来初始化索引中记录的子模块（已在其他地方添加并提交）。它使用.gitmodules中的相同设置作为模板。如果 URL 是相对的，则将使用默认远程解析。如果没有默认远程，则假定当前存储库位于上游。

可选<路径>参数限制将初始化哪些子模块。如果未指定路径且已配置 submodule.active，则将初始化配置为活动的子模块，否则将初始化所有子模块。

如果存在，它还将复制submodule.$name.update的值。此命令不会更改.git / config 中的现有信息。然后，您可以在.git / config 中自定义子模块克隆 URL 以进行本地设置，然后继续git submodule update;如果您不打算自定义任何子模块位置，也可以在没有显式 init 步骤的情况下使用git submodule update --init。

有关默认远程的定义，请参阅 add 子命令。

 deinit [-f|--force] (--all|[--] <path>…)

取消注册给定的子模块，即从.git / config 中删除整个submodule.$name部分及其工作树。对git submodule update，git submodule foreach和git submodule sync的进一步调用将跳过任何未注册的子模块，直到它们再次初始化为止，因此如果您不想再在工作树中本地检出子模块，请使用此命令。

当命令在没有 pathspec 的情况下运行时，它会出错，而不是去除所有内容，以防止出错。

如果指定了--force，则即使子模块包含本地修改，也将删除该子模块的工作树。

如果你真的想要从存储库中删除子模块并提交使用 git-rm [1] 。有关删除选项，请参阅 gitsubmodules [7] 。

 update [--init] [--remote] [-N|--no-fetch] [--[no-]recommend-shallow] [-f|--force] [--checkout|--rebase|--merge] [--reference <repository>] [--depth <depth>] [--recursive] [--jobs <n>] [--] [<path>…]

通过克隆缺失的子模块并更新子模块的工作树，更新已注册的子模块以匹配超级项目所期望的内容。 “更新”可以通过多种方式完成，具体取决于命令行选项和submodule.<name>.update配置变量的值。命令行选项优先于配置变量。如果两者都没有给出，则执行 _ 检出 _。从命令行以及通过submodule.<name>.update配置支持的 _ 更新 _ 程序是：

 checkout

超级项目中记录的提交将在分离的 HEAD 上的子模块中检出。

如果指定了--force，则子模块将被检出（使用git checkout --force），即使包含存储库的索引中指定的提交已经与子模块中检出的提交匹配。

 rebase

子模块的当前分支将重新定位到超级项目中记录的提交。

 merge

超级项目中记录的提交将合并到子模块中的当前分支中。

以下 _ 更新 _ 程序仅可通过submodule.<name>.update配置变量获得：

 custom command

执行带有单个参数的任意 shell 命令（超级项目中记录的提交的 sha1）。当submodule.<name>.update设置为 _！命令 _ 时，感叹号后面的余数是自定义命令。

 none

子模块未更新。

如果子模块尚未初始化，并且您只想使用.gitmodules中存储的设置，则可以使用--init选项自动初始化子模块。

如果指定了--recursive，则此命令将递归到已注册的子模块中，并更新其中的任何嵌套子模块。

 summary [--cached|--files] [(-n|--summary-limit) <n>] [commit] [--] [<path>…]

显示给定提交（默认为 HEAD）和工作树/索引之间的提交摘要。对于所讨论的子模块，显示了给定超级项目提交与索引或工作树（由--cached切换）之间的子模块中的一系列提交。如果给出了选项--files，则显示超级项目的索引与子模块的工作树之间的子模块中的一系列提交（此选项不允许使用--cached选项或提供显式承诺）。

在 git-diff [1] 中使用--submodule=log选项也可以提供该信息。

 foreach [--recursive] <command>

在每个签出的子模块中计算任意 shell 命令。该命令可以访问变量 name， sm_path， displaypath， sha1 和 toplevel： name 是.gitmodules中相关子模块部分的名称， sm_path 是直接记录的子模块的路径 superproject， displaypath 包含从当前工作目录到子模块根目录的相对路径， sha1 是直接超级项目中记录的提交， toplevel 是直接超级项目顶级的绝对路径。请注意，为了避免与 Windows 上的 PATH 冲突， path 变量现在是

例如，下面的命令将显示每个子模块的路径和当前检出的提交：

git submodule foreach 'echo $path `git rev-parse HEAD`'

 sync [--recursive] [--] [<path>…]

将子模块的远程 URL 配置设置与.gitmodules中指定的值同步。它只会影响那些已经在.git / config 中有 URL 条目的子模块（初始化或新添加时就是这种情况）。当子模块 URL 更改上游并且您需要相应地更新本地存储库时，这非常有用。

git submodule sync同步所有子模块，而git submodule sync -- A仅同步子模块“A”。

如果指定了--recursive，则此命令将递归到已注册的子模块中，并同步其中的任何嵌套子模块。

 absorbgitdirs

如果子模块的 git 目录在子模块内，则将子模块的 git 目录移动到其 superprojects $GIT_DIR/modules路径，然后通过设置core.worktree并添加指向的.git 文件来连接 git 目录及其工作目录。嵌入在 superprojects git 目录中的 git 目录。

独立克隆并随后作为子模块或旧设置添加的存储库在子模块内部具有子模块 git 目录，而不是嵌入到 superprojects git 目录中。

默认情况下，此命令是递归的。

OPTIONS

-q

 --quiet

仅打印错误消息。

 --progress

此选项仅对添加和更新命令有效。除非指定了-q，否则在将标准错误流附加到终端时，默认情况下会报告进度状态。即使标准错误流未定向到终端，此标志也会强制进度状态。

 --all

此选项仅对 deinit 命令有效。取消注册工作树中的所有子模块。

-b

 --branch

存储库的分支添加为子模块。分支名称在update --remote中记录为update --remote中的submodule.<name>.branch。 .的特殊值用于指示子模块中分支的名称应与当前存储库中的当前分支的名称相同。

-f

 --force

此选项仅对 add，deinit 和 update 命令有效。运行 add 时，允许添加否则忽略的子模块路径。当运行 deinit 时，子模块工作树将被删除，即使它们包含本地更改。运行更新时（仅对结帐过程有效），在切换到其他提交时，丢弃子模块中的本地更改;并且始终在子模块中运行 checkout 操作，即使包含存储库的索引中列出的提交与子模块中签出的提交匹配也是如此。

 --cached

此选项仅对 status 和 summary 命令有效。这些命令通常使用子模块 HEAD 中的提交，但使用此选项时，将使用存储在索引中的提交。

 --files

此选项仅对 summary 命令有效。当使用此选项时，此命令将索引中的提交与子模块 HEAD 中的提交进行比较。

-n

 --summary-limit

此选项仅对 summary 命令有效。限制摘要大小（总计显示的提交数）。给 0 将禁用摘要;负数表示无限制（默认值）。此限制仅适用于已修改的子模块。对于添加/删除/ typechanged 子模块，大小始终限制为 1。

 --remote

此选项仅对 update 命令有效。不使用超级项目记录的 SHA-1 来更新子模块，而是使用子模块的远程跟踪分支的状态。使用的遥控器是分支的遥控器（branch.<name>.remote），默认为origin。使用的远程分支默认为master，但可以通过在.gitmodules或.git/config中设置submodule.<name>.branch选项来覆盖分支名称（优先使用.git/config）。

这适用于任何支持的更新过程（--checkout，--rebase等）。唯一的变化是目标 SHA-1 的来源。例如，submodule update --remote --merge会将上游子模块更改合并到子模块中，而submodule update --merge会将超级项目 gitlink 更改合并到子模块中。

为了确保当前跟踪分支状态，update --remote在计算 SHA-1 之前获取子模块的远程存储库。如果您不想获取，则应使用submodule update --remote --no-fetch。

使用此选项可将上游子项目的更改与子模块的当前 HEAD 集成。或者，您可以从子模块运行git pull，除了远程分支名称之外，它是等效的：update --remote使用默认上游存储库和submodule.<name>.branch，而git pull使用子模块的branch.<name>.merge。如果您想在超级项目中分配默认上游分支，请选择submodule.<name>.branch，如果您希望在子模块本身工作时想要更原始的感觉，请选择branch.<name>.merge。

-N

 --no-fetch

此选项仅对 update 命令有效。不要从远程站点获取新对象。

 --checkout

此选项仅对 update 命令有效。在子模块中的分离 HEAD 上签出超级项目中记录的提交。这是默认行为，此选项的主要用途是在设置为checkout以外的值时覆盖submodule.name.update。如果未将键submodule.name.update显式设置或设置为checkout，则此选项是隐式的。

 --merge

此选项仅对 update 命令有效。将超级项目中记录的提交合并到子模块的当前分支中。如果给出此选项，则不会分离子模块的 HEAD。如果合并失败阻止了此过程，则必须使用通常的冲突解决工具解决子模块中产生的冲突。如果键submodule.$name.update设置为merge，则此选项是隐式的。

 --rebase

此选项仅对 update 命令有效。将当前分支重新引导到超级项目中记录的提交。如果给出此选项，则不会分离子模块的 HEAD。如果合并失败阻止了此过程，则必须使用 git-rebase [1] 解决这些故障。如果键submodule.$name.update设置为rebase，则此选项是隐式的。

 --init

此选项仅对 update 命令有效。初始化所有在更新之前尚未调用“git submodule init”的子模块。

 --name

此选项仅对 add 命令有效。它将子模块的名称设置为给定的字符串，而不是默认为其路径。该名称必须作为目录名有效，并且不能以 / 结尾。

 --reference <repository>

此选项仅对添加和更新命令有效。这些命令有时需要克隆远程存储库。在这种情况下，此选项将传递给 git-clone [1] 命令。

注：不是使用此选项除非您已阅读 git-clone [1] 的--reference，--shared和--dissociate选项仔细。

 --dissociate

此选项仅对添加和更新命令有效。这些命令有时需要克隆远程存储库。在这种情况下，此选项将传递给 git-clone [1] 命令。

注：参见--reference选项的注意事项。

 --recursive

此选项仅对 foreach，update，status 和 sync 命令有效。递归遍历子模块。该操作不仅在当前仓库的子模块中执行，而且还在这些子模块内的任何嵌套子模块中执行（依此类推）。

 --depth

此选项对添加和更新命令有效。创建一个 _ 浅 _ 克隆，其历史记录被截断为指定的修订数。见 git-clone [1]

 --[no-]recommend-shallow

此选项仅对 update 命令有效。子模块的初始克隆将使用默认情况下.gitmodules文件提供的推荐submodule.<name>.shallow。要忽略建议，请使用--no-recommend-shallow。

 -j <n>

 --jobs <n>

此选项仅对 update 命令有效。与多个作业并行克隆新的子模块。默认为submodule.fetchJobs选项。

 <path>…

子模块的路径。指定时，这将限制命令仅对指定路径上找到的子模块进行操作。（添加时需要此参数）。

FILES

初始化子模块时，使用包含存储库的顶级目录中的.gitmodules文件来查找每个子模块的 URL。该文件的格式应与GIT_DIR/config相同。每个子模块 url 的关键是“submodule。 name.url”。有关详细信息，请参阅 gitmodules [5] 。

也可以看看

gitsubmodules [7] ， gitmodules [5] 。

GIT

部分 git [1] 套件

git-show

原文： git-scm.com/docs/git-show

名称

git-show - 显示各种类型的对象

概要

git show [<options>] [<object>…]

描述

显示一个或多个对象（blob，树，标签和提交）。

对于提交，它显示日志消息和文本差异。它还以 git diff-tree --cc 生成的特殊格式显示合并提交。

对于标签，它显示标签消息和引用的对象。

对于树，它显示名称（相当于 git ls-tree 和–name-only）。

对于普通 blob，它显示了普通内容。

该命令采用适用于 git diff-tree 命令的选项来控制如何显示提交引入的更改。

本手册页仅介绍最常用的选项。

OPTIONS

 <object>…

要显示的对象的名称（默认为 HEAD ）。有关拼写对象名称的更完整列表，请参阅 gitrevisions [7] 中的“指定修订”部分。

 --pretty[=<format>]

 --format=<format>

以给定格式打印提交日志的内容，其中 < format> 可以是 oneline ，_ 短，培养基，全，更丰富，之一电子邮件，原始，格式：< string>_ 和 tformat：< string> 。当 < format> 不属于上述情况，并且其中包含 _％占位符 _，其行为就像 –pretty = tformat：< format> 给出了。

有关每种格式的一些其他详细信息，请参阅“PRETTY FORMATS”部分。当 =< format> 部分省略，默认为 medium 。

注意：您可以在存储库配置中指定默认的漂亮格式（请参阅 git-config [1] ）。

 --abbrev-commit

而不是显示完整的 40 字节十六进制提交对象名称，而只显示部分前缀。可以使用“–abbrev =< n>”指定非默认位数（如果显示，也会修改 diff 输出）。

对于使用 80 列终端的人来说，这应该使“–pretty = oneline”更具可读性。

 --no-abbrev-commit

显示完整的 40 字节十六进制提交对象名称。这否定了--abbrev-commit以及暗示它的选项，例如“–oneline”。它还会覆盖log.abbrevCommit变量。

 --oneline

这是一起使用的“–pretty = oneline --abbrev-commit”的简写。

 --encoding=<encoding>

提交对象在其编码头中记录用于日志消息的编码;此选项可用于告诉命令以用户首选的编码重新编码提交日志消息。对于非管道命令，默认为 UTF-8。请注意，如果一个对象声称在X中编码并且我们在X中输出，我们将逐字输出该对象;这意味着原始提交中的无效序列可能会复制到输出中。

 --expand-tabs=<n>

 --expand-tabs

 --no-expand-tabs

执行选项卡扩展（将每个选项卡替换为足够的空格以填充到日志消息中的 < n> 的倍数的下一个显示列），然后在输出中显示它。 --expand-tabs是--expand-tabs=8的简写，--no-expand-tabs是--expand-tabs=0的简写，它会禁用制表符扩展。

默认情况下，选项卡以相当格式展开，将日志消息缩进 4 个空格（即 medium ，默认情况下， full 和 fulller ）。

 --notes[=<treeish>]

在显示提交日志消息时，显示注释提交的注释（请参阅 git-notes [1] ）。当命令行中没有给出--pretty，--format或--oneline选项时，这是git log，git show和git whatchanged命令的默认值。

默认情况下，显示的注释来自core.notesRef和notes.displayRef变量（或相应的环境覆盖）中列出的注释 refs。有关详细信息，请参阅 git-config [1] 。

使用可选的 < treeish> 参数，使用树形查找要显示的注释。树形可以在以refs/notes/开头时指定完整的引用名称;当它以notes/开始时，refs/和其他refs/notes/作为前缀以形成 ref 的全名。

可以组合多个–notes 选项来控制显示哪些音符。示例：“ - notes = foo”将仅显示“refs / notes / foo”中的注释; “–notes = foo --notes”将显示“refs / notes / foo”和默认音符 ref（s）中的两个音符。

 --no-notes

不要显示笔记。这取消了上面的--notes选项，通过重置显示注释的注释列表。选项按命令行中给出的顺序进行解析，例如， “–notes --notes = foo --no-notes --notes = bar”只会显示“refs / notes / bar”中的注释。

 --show-notes[=<treeish>]

 --[no-]standard-notes

不推荐使用这些选项。请使用上面的–notes / - no-notes 选项。

 --show-signature

通过将签名传递给gpg --verify并显示输出来检查已签名的提交对象的有效性。

漂亮的格式

如果提交是合并，并且如果漂亮格式不是 oneline ，_ 电子邮件 _ 或 raw ，则在 _ 作者之前插入另一行：_ 行。该行以“Merge：”开头，并且打印祖先提交的 sha1，用空格分隔。请注意，如果您限制了对历史记录的查看，则列出的提交可能不一定是直接父提交的列表：例如，如果您只对与某个目录或文件相关的更改感兴趣。

有几种内置格式，您可以通过设置漂亮的格式来定义其他格式。< name>将选项配置为另一种格式名称或 _ 格式：_ 字符串，如下所述（参见 git-config [1] ）。以下是内置格式的详细信息：

oneline

&lt;sha1&gt; &lt;title line&gt;

这是为了尽可能紧凑。

_ 短 _

commit &lt;sha1&gt;
Author: &lt;author&gt;

&lt;title line&gt;

_ 中 _

commit &lt;sha1&gt;
Author: &lt;author&gt;
Date:   &lt;author date&gt;

&lt;title line&gt;

&lt;full commit message&gt;

_ 全 _

commit &lt;sha1&gt;
Author: &lt;author&gt;
Commit: &lt;committer&gt;

&lt;title line&gt;

&lt;full commit message&gt;

_ 更丰富 _

commit &lt;sha1&gt;
Author:     &lt;author&gt;
AuthorDate: &lt;author date&gt;
Commit:     &lt;committer&gt;
CommitDate: &lt;committer date&gt;

&lt;title line&gt;

&lt;full commit message&gt;

_ 电子邮件 _

From &lt;sha1&gt; &lt;date&gt;
From: &lt;author&gt;
Date: &lt;author date&gt;
Subject: [PATCH] &lt;title line&gt;

&lt;full commit message&gt;

_ 原始 _

raw 格式显示完整提交，与存储在提交对象中完全相同。值得注意的是，无论是否使用–abbrev 或–no-abbrev，SHA-1 都会完整显示，并且 _ 父 _ 信息显示真正的父提交，而不考虑移植或历史简化。请注意，此格式会影响提交的显示方式，但不会影响显示差异的方式，例如用git log --raw。要以原始 diff 格式获取完整对象名称，请使用--no-abbrev。

_ 格式：< string>_

_ 格式：< string>_ 格式允许您指定要显示的信息。它的工作方式有点像 printf 格式，但有一个值得注意的例外，即你用％n 而不是 \ n 获得换行符。

例如，_ 格式：“％h 的作者是％an，％ar％n 标题是>>％s<<％n”_ 将显示如下内容：

The author of fe6e0ee was Junio C Hamano, 23 hours ago
The title was &gt;&gt;t4119: test autocomputing -p&lt;n&gt; for traditional diff input.&lt;&lt;

占位符是：

％H ：提交哈希
％h ：缩写提交哈希
％T ：树形哈希
％t ：缩写树哈希
％P ：父哈希
％p ：缩写为父哈希值
_％和 _：作者姓名
％aN ：作者姓名（尊重.mailmap，见 git-shortlog [1] 或 git-blame [1] ）
％ae ：作者电邮
％aE ：作者电子邮件（尊重.mailmap，见 git-shortlog [1] 或 git-blame [1] ）
％ad ：作者日期（格式尊重 - 日期=选项）
％aD ：作者日期，RFC2822 风格
％ar ：作者日期，相对
的 _％：作者日期，UNIX 时间戳 _
％ai ：作者日期，ISO 8601 样格式
％aI ：作者日期，严格的 ISO 8601 格式
％cn ：提交者名称
％cN ：提交者名称（尊重.mailmap，见 git-shortlog [1] 或 git-blame [1] ）
％ce ：提交者电子邮件
％cE ：提交者电子邮件（尊重.mailmap，参见 git-shortlog [1] 或 git-blame [1] ）
％cd ：提交者日期（格式尊重 - 日期=选项）
％cD ：提交者日期，RFC2822 样式
％cr ：提交者日期，相对
％ct ：提交者日期，UNIX 时间戳
％ci ：提交者日期，类似 ISO 8601 的格式
％cI ：提交者日期，严格的 ISO 8601 格式
％d ：引用名称，如 git-log [1] 的–decorate 选项
％D ：没有“（”，“）”包装的引用名称。
％S ：在达到提交的命令行上给出的引用名称（如git log --source），仅适用于git log
％e ：编码
％s ：受试者
％f ：已清理的主题行，适用于文件名
％b ：身体
％B ：生体（未包裹的主体和身体）
％N ：提交备注
％GG ：来自 GPG 的签名提交的原始验证消息
％G？ ：显示好的（有效）签名“G”，坏签名显示“B”，有效期未知的好签名显示“U”，已过期的好签名显示“X”，“Y”代表由过期密钥签名的好签名，“R”表示由撤销密钥签名的好签名，“E”表示签名无法检查（例如缺少密钥），“N”表示没有签名
％GS ：显示签名提交的签名者姓名
％GK ：显示用于签署签名提交的密钥
％GF ：显示用于签署签名提交的密钥的指纹
％GP ：显示主键的指纹，其子键用于签名提交的签名
％gD ：reflog 选择器，例如refs/stash@{1}或refs/stash@{2 minutes ago};格式遵循-g选项描述的规则。 @之前的部分是命令行中给出的 refname（因此git log -g refs/heads/master将产生refs/heads/master@{0}）。
％gd ：缩短了 reflog 选择器;与%gD相同，但 refname 部分缩短了人类的可读性（因此refs/heads/master变为master）。
％gn ：reflog 身份名称
％gN ：reflog 身份名称（尊重.mailmap，见 git-shortlog [1] 或 git-blame [1] ）
％ge ：reflog 身份电子邮件
％gE ：reflog 身份邮件（尊重.mailmap，见 git-shortlog [1] 或 git-blame [1] ）
％gs ：reflog 主题
％Cred ：将颜色切换为红色
％Cgreen ：将颜色切换为绿色
％Cblue ：将颜色切换为蓝色
％Creset ：重置颜色
％C（…）：颜色规格，如 git-config [1] 的“CONFIGURATION FILE”部分中的值所述。默认情况下，仅在启用日志输出时显示颜色（通过color.diff，color.ui或--color，并且如果我们要去终端，则尊重前者的auto设置）。 %C(auto,...)被接受为默认的历史同义词（例如，%C(auto,red)）。即使没有启用颜色，指定%C(always,...)也会显示颜色（尽管只考虑使用--color=always为整个输出启用颜色，包括这种格式和其他任何 git 可能颜色的颜色）。单独auto（即%C(auto)）将打开下一个占位符的自动着色，直到再次切换颜色。
％m ：左（<），右（>）或边界（-）标记
％n ：换行符
%% ：原始％
％x00 ：从十六进制代码打印一个字节
％w（[< w> [，< i1> [，< i2>]]]）：切换行换行，类似 git-shortlog [1]的-w 选项。
％<（< N> [，trunc | ltrunc | mtrunc]）：使下一个占位符至少取 N 列，如果需要，在右边填充空格。如果输出长于 N 列，则可以选择在开头（ltrunc），中间（mtrunc）或结尾（trunc）截断。请注意，截断仅适用于 N> = 2。
％< |（< N>）：使下一个占位符至少占用第 N 列，如果需要，在右边填充空格
％>（< N>），％> |（< N>）：与 ％相似，％< |（< N>）_，但左边的填充空格 _
％>（< N>），％> |（< N>）：类似于 ％>（< N>分别是，％> |（< N>），除非下一个占位符占用的空间多于给定的空间并且左侧有空格，请使用这些空格
％><（< N>），％>< |（< N>）：类似于 ％<（< N> ），％< |（< N>），但填充两侧（即文本居中）
％（预告片[：options]）：显示 git-interpret-trailers [1] 解释的正文预告片。 trailers字符串后面可以跟冒号和零个或多个逗号分隔选项。如果给出了only选项，则省略拖车块中的非拖车线。如果给出unfold选项，则表现得就像给出了 interpre-trailer 的--unfold选项一样。例如，%(trailers:only,unfold)两者都做。

| 注意 | 一些占位符可能依赖于修订遍历引擎的其他选项。例如，%g* reflog 选项将插入一个空字符串，除非我们遍历 reflog 条目（例如，通过git log -g）。如果命令行中尚未提供--decorate，%d和%D占位符将使用“短”装饰格式。 |

如果在占位符的％之后添加+（加号），则在扩展之前插入换行符当且仅当占位符扩展为非空字符串时。

如果在占位符的％之后添加-（减号），则当且仅当占位符扩展为空字符串时，才会删除紧接在扩展之前的所有连续换行符。

如果在占位符的％之后添加一个“空格”，则在扩展之前插入一个空格，当且仅当占位符扩展为非空字符串时。

tformat：

_ 格式：_ 格式与 _ 格式完全相同：_，除了它提供“终结符”语义而不是“分隔符”语义。换句话说，每个提交都附加了消息终止符（通常是换行符），而不是在条目之间放置的分隔符。这意味着单行格式的最终输入将使用新行正确终止，就像“oneline”格式一样。例如：

$ git log -2 --pretty=format:%h 4da45bef \
  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
4da45be
7134973 -- NO NEWLINE

$ git log -2 --pretty=tformat:%h 4da45bef \
  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
4da45be
7134973

此外，其中包含%的任何无法识别的字符串都被解释为它前面有tformat:。例如，这两个是等价的：

$ git log -2 --pretty=tformat:%h 4da45bef
$ git log -2 --pretty=%h 4da45bef

常见的 DIFF 选项

-p

-u

 --patch

生成补丁（请参阅生成补丁的部分）。

-s

 --no-patch

抑制差异输出。对于git show等默认显示补丁的命令，或取消--patch的效果很有用。

 -U<n>

 --unified=<n>

用< n>生成差异。上下文而不是通常的三行。意味着-p。

 --raw

对于每个提交，使用原始 diff 格式显示更改摘要。请参阅 git-diff [1] 的“RAW OUTPUT FORMAT”部分。这与以原始格式显示日志本身不同，您可以使用--format=raw来实现。

 --patch-with-raw

-p --raw的同义词。

 --indent-heuristic

启用改变差异块边界的启发式以使补丁更易于阅读。这是默认值。

 --no-indent-heuristic

禁用缩进启发式。

 --minimal

花些额外的时间来确保产生尽可能小的差异。

 --patience

使用“耐心差异”算法生成差异。

 --histogram

使用“histogram diff”算法生成 diff。

 --anchored=<text>

使用“锚定差异”算法生成差异。

可以多次指定此选项。

如果源和目标中都存在一行，只存在一次，并以此文本开头，则此算法会尝试阻止它在输出中显示为删除或添加。它在内部使用“耐心差异”算法。

 --diff-algorithm={patience|minimal|histogram|myers}

选择差异算法。变体如下：

 default, myers

基本的贪心差异算法。目前，这是默认值。

 minimal

花些额外的时间来确保产生尽可能小的差异。

 patience

生成补丁时使用“耐心差异”算法。

 histogram

该算法将耐心算法扩展为“支持低发生的共同元素”。

例如，如果将diff.algorithm变量配置为非默认值并想要使用默认值，则必须使用--diff-algorithm=default选项。

 --stat[=<width>[,<name-width>[,<count>]]]

生成 diffstat。默认情况下，文件名部分将使用必要的空间，图形部分的其余部分将使用。最大宽度默认为终端宽度，如果未连接到终端，则为 80 列，并且可以被<width>覆盖。可以通过在逗号后面给出另一个宽度<name-width>来限制文件名部分的宽度。可以使用--stat-graph-width=<width>（影响生成统计图的所有命令）或设置diff.statGraphWidth=<width>（不影响git format-patch）来限制图形部分的宽度。通过给出第三个参数<count>，可以将输出限制为第一个<count>行，如果有更多，则可以将...限制为...。

也可以使用--stat-width=<width>，--stat-name-width=<name-width>和--stat-count=<count>单独设置这些参数。

 --compact-summary

输出扩展标题信息的精简摘要，例如文件创建或删除（“新”或“消失”，如果是符号链接，则可选“+ l”）和模式更改（“+ x”或“-x”用于添加或删除 diffstat 中的可执行位）。信息放在文件名部分和图形部分之间。意味着--stat。

 --numstat

与--stat类似，但显示十进制表示法中添加和删除的行数以及没有缩写的路径名，以使其更加机器友好。对于二进制文件，输出两个-而不是0 0。

 --shortstat

仅输出--stat格式的最后一行，其中包含已修改文件的总数，以及已添加和已删除行的数量。

 --dirstat[=<param1,param2,…>]

输出每个子目录的相对更改量的分布。 --dirstat的行为可以通过以逗号分隔的参数列表传递来定制。默认值由diff.dirstat配置变量控制（参见 git-config [1] ）。可以使用以下参数：

 changes

通过计算已从源中删除或添加到目标的行来计算 dirstat 数。这忽略了文件中纯代码移动的数量。换句话说，重新排列文件中的行不会像其他更改那样计算。这是没有给出参数时的默认行为。

 lines

通过执行常规的基于行的差异分析来计算 dirstat 数字，并对移除/添加的行数进行求和。（对于二进制文件，计算 64 字节块，因为二进制文件没有自然的线条概念）。这是比changes行为更昂贵的--dirstat行为，但它确实计算文件中重新排列的行与其他更改一样多。结果输出与您从其他--*stat选项获得的输出一致。

 files

通过计算更改的文件数来计算 dirstat 数。在 dirstat 分析中，每个更改的文件都相同。这是计算上最便宜的--dirstat行为，因为它根本不需要查看文件内容。

 cumulative

计算父目录的子目录中的更改。请注意，使用cumulative时，报告的百分比总和可能超过 100％。可以使用noncumulative参数指定默认（非累积）行为。

 <limit>

整数参数指定截止百分比（默认为 3％）。贡献低于此百分比变化的目录不会显示在输出中。

示例：以下将计算已更改的文件，同时忽略少于已更改文件总量的 10％的目录，并在父目录中累计子目录计数：--dirstat=files,10,cumulative。

 --summary

输出扩展标题信息的精简摘要，例如创建，重命名和模式更改。

 --patch-with-stat

-p --stat的同义词。

-z

将提交与 NUL 分开，而不是使用新换行符。

此外，当给出--raw或--numstat时，不要使用路径名并使用 NUL 作为输出字段终止符。

如果没有此选项，则会引用具有“异常”字符的路径名，如配置变量core.quotePath所述（参见 git-config [1] ）。

 --name-only

仅显示已更改文件的名称。

 --name-status

仅显示已更改文件的名称和状态。有关状态字母的含义，请参阅--diff-filter选项的说明。

 --submodule[=<format>]

指定子模块的差异如何显示。指定--submodule=short时，使用 _ 短 _ 格式。此格式仅显示范围开头和结尾的提交名称。指定--submodule或--submodule=log时，使用 log 格式。此格式列出 git-submodule [1] summary等范围内的提交。指定--submodule=diff时，使用 diff 格式。此格式显示提交范围之间子模块内容更改的内联差异。如果未设置配置选项，则默认为diff.submodule或 _ 短 _ 格式。

 --color[=<when>]

显示彩色差异。 --color（即没有 =<当> ）与--color=always相同时。 < when> 可以是always，never或auto之一。

 --no-color

关掉彩色差异。它与--color=never相同。

 --color-moved[=<mode>]

移动的代码行的颜色不同。 <模式>如果没有给出选项，默认为 no ，如果给出没有模式的选项，则默认为 zebra 。模式必须是以下之一：

no

移动的线条不会突出显示。

 default

是zebra的同义词。这可能会在未来转变为更明智的模式。

 plain

在一个位置添加并在另一个位置删除的任何行都将使用 color.diff.newMoved 进行着色。类似地， color.diff.oldMoved 将用于在 diff 中的其他位置添加的已删除行。此模式选择任何已移动的行，但在检查中确定是否在没有置换的情况下移动了代码块时，它不是很有用。

 blocks

贪婪地检测至少 20 个字母数字字符的移动文本块。使用 color.diff。{old，new} Moved 颜色绘制检测到的块。相邻的街区不能分开。

 zebra

在 _ 块 _ 模式中检测移动文本块。使用 color.diff。{old，new} Moved 颜色或 color.diff。{old，new} MovedAlternative 绘制块。两种颜色之间的变化表示检测到新的块。

 dimmed-zebra

与 zebra 类似，但执行了移动代码的无趣部分的额外调暗。两个相邻街区的边界线被认为是有趣的，其余的是无趣的。 dimmed_zebra是不推荐使用的同义词。

 --no-color-moved

关闭移动检测。这可用于覆盖配置设置。它与--color-moved=no相同。

 --color-moved-ws=<modes>

这将配置在执行--color-moved的移动检测时如何忽略空白。这些模式可以以逗号分隔的列表给出：

no

执行移动检测时不要忽略空格。

 ignore-space-at-eol

忽略 EOL 中的空白更改。

 ignore-space-change

忽略空格量的变化。这会忽略行尾的空格，并将一个或多个空白字符的所有其他序列视为等效。

 ignore-all-space

比较线条时忽略空格。即使一行有空格而另一行没有空格，这也会忽略差异。

 allow-indentation-change

最初忽略移动检测中的任何空格，然后如果每行的空白变化相同，则仅将移动的代码块分组到块中。这与其他模式不兼容。

 --no-color-moved-ws

执行移动检测时不要忽略空格。这可用于覆盖配置设置。它与--color-moved-ws=no相同。

 --word-diff[=<mode>]

使用< mode>显示单词 diff。划定改变的单词。默认情况下，单词由空格分隔;见下面的--word-diff-regex。 <模式>默认为 plain ，必须是以下之一：

 color

仅使用颜色突出显示更改的单词。意味着--color。

 plain

将单词显示为[-removed-]和{+added+}。如果它们出现在输入中，则不会尝试转义分隔符，因此输出可能不明确。

 porcelain

使用特殊的基于行的格式用于脚本使用。添加/删除/未更改的运行以通常的统一 diff 格式打印，从行开头的+ / - /``字符开始并延伸到行尾。输入中的换行符由其自身行上的波浪号~表示。

 none

再次禁用字差异。

请注意，尽管第一个模式的名称，但如果启用了颜色，则使用颜色突出显示所有模式中已更改的部分。

 --word-diff-regex=<regex>

使用< regex>决定一个单词是什么，而不是将非空格的运行视为一个单词。除非已经启用，否则还暗示--word-diff。

< regex>的每个非重叠匹配被认为是一个词。这些匹配之间的任何内容都被视为空格并被忽略（！）以查找差异。您可能希望将|[^[:space:]]附加到正则表达式，以确保它匹配所有非空白字符。包含换行符的匹配项会在换行符处以静默方式截断（！）。

例如，--word-diff-regex=.会将每个字符视为一个单词，并相应地逐个字符地显示差异。

正则表达式也可以通过 diff 驱动程序或配置选项设置，参见 gitattributes [5] 或 git-config [1] 。明确地覆盖任何差异驱动程序或配置设置。 Diff 驱动程序覆盖配置设置。

 --color-words[=<regex>]

相当于--word-diff=color加（如果指定了正则表达式）--word-diff-regex=<regex>。

 --no-renames

关闭重命名检测，即使配置文件提供默认值也是如此。

 --check

如果更改引入冲突标记或空白错误，则发出警告。什么被认为是空白错误由core.whitespace配置控制。默认情况下，尾随空格（包括仅由空格组成的行）和在行的初始缩进内紧跟着制表符的空格字符被视为空格错误。如果发现问题，则退出非零状态。与–exit-code 不兼容。

 --ws-error-highlight=<kind>

突出显示差异的context，old或new行中的空白错误。多个值用逗号分隔，none重置先前的值，default将列表重置为new，all是old,new,context的简写。如果未指定此选项，并且未设置配置变量diff.wsErrorHighlight，则仅突出显示new行中的空白错误。空白错误用color.diff.whitespace着色。

 --full-index

在生成补丁格式输出时，在“索引”行上显示完整的前映像和后映像 blob 对象名称，而不是第一个字符。

 --binary

除--full-index外，还可输出可用git-apply应用的二进制差异。

 --abbrev[=<n>]

而不是在 diff-raw 格式输出和 diff-tree 标题行中显示完整的 40 字节十六进制对象名称，而是仅显示部分前缀。这与上面的--full-index选项无关，后者控制 diff-patch 输出格式。可以使用--abbrev=<n>指定非默认位数。

 -B[<n>][/<m>]

 --break-rewrites[=[<n>][/<m>]]

将完整的重写更改分为删除和创建对。这有两个目的：

它影响了一个更改的方式，相当于一个文件的完全重写，而不是一系列的删除和插入混合在一起，只有几行恰好与文本作为上下文匹配，而是作为单个删除所有旧的后跟一个单个插入所有新内容，数字m控制-B 选项的这一方面（默认为 60％）。 -B/70%指定少于 30％的原始文本应保留在结果中，以便 Git 将其视为完全重写（即，否则生成的修补程序将是一系列删除和插入与上下文行混合在一起）。

当与-M 一起使用时，完全重写的文件也被视为重命名的源（通常-M 只考虑作为重命名源消失的文件），并且数字n控制 - 的这方面 - B 选项（默认为 50％）。 -B20%指定添加和删除的更改与文件大小的 20％或更多相比，有资格被选为可能的重命名源到另一个文件。

 -M[<n>]

 --find-renames[=<n>]

如果生成差异，则检测并报告每次提交的重命名。对于遍历历史记录时重命名后续文件，请参阅--follow。如果指定了n，则它是相似性指数的阈值（即与文件大小相比的添加/删除量）。例如，-M90%表示如果超过 90％的文件未更改，Git 应将删除/添加对视为重命名。如果没有%符号，则该数字将作为分数读取，并在其前面加上小数点。即，-M5变为 0.5，因此与-M50%相同。同样，-M05与-M5%相同。要将检测限制为精确重命名，请使用-M100%。默认相似性指数为 50％。

 -C[<n>]

 --find-copies[=<n>]

检测副本以及重命名。另见--find-copies-harder。如果指定了n，则其含义与-M<n>的含义相同。

 --find-copies-harder

出于性能原因，默认情况下，仅当在同一变更集中修改了副本的原始文件时，-C选项才会查找副本。此标志使命令检查未修改的文件作为副本源的候选者。对于大型项目来说，这是一项非常昂贵的操作，因此请谨慎使用。提供多个-C选项具有相同的效果。

-D

 --irreversible-delete

省略删除的原像，即只打印标题而不打印原像和/dev/null之间的差异。得到的贴片不适用于patch或git apply;这仅适用于那些希望在更改后专注于审阅文本的人。此外，输出显然缺乏足够的信息来反向应用这样的补丁，甚至手动，因此选项的名称。

与-B一起使用时，也省略删除/创建对的删除部分中的原像。

 -l<num>

-M和-C选项需要 O（n ^ 2）处理时间，其中 n 是潜在的重命名/复制目标的数量。如果重命名/复制目标的数量超过指定的数量，此选项可防止重命名/复制检测运行。

 --diff-filter=[(A|C|D|M|R|T|U|X|B)…[*]]

仅选择已添加（A），复制（C），已删除（D），已修改（M），已重命名（R）的文件，其类型（即常规文件，符号链接，子模块，…）更改（T），未合并（U），未知（X），或已配对破碎（B）。可以使用过滤器字符的任何组合（包括无）。当*（全部或全部）添加到组合中时，如果有任何文件与比较中的其他条件匹配，则选择所有路径;如果没有与其他条件匹配的文件，则不会选择任何内容。

此外，这些大写字母可以降级为排除。例如。 --diff-filter=ad排除添加和删除的路径。

请注意，并非所有差异都可以包含所有类型。例如，从索引到工作树的差异永远不会有添加条目（因为差异中包含的路径集受限于索引中的内容）。同样，如果禁用了对这些类型的检测，则无法显示复制和重命名的条目。

 -S<string>

查找改变文件中指定字符串出现次数（即添加/删除）的差异。用于脚本编写者的使用。

当你正在寻找一个确切的代码块（比如一个结构体）时，它很有用，并且想要知道该块首次出现以来的历史：迭代地使用该特征将原始图像中的有趣块反馈回-S，继续前进，直到你获得该块的第一个版本。

也搜索二进制文件。

 -G<regex>

查找补丁文本包含与< regex>匹配的添加/删除行的差异。

为了说明-S<regex> --pickaxe-regex和-G<regex>之间的区别，请考虑在同一文件中使用以下 diff 进行提交：

+    return !regexec(regexp, two->ptr, 1, &regmatch, 0);
...
-    hit = !regexec(regexp, mf2.ptr, 1, &regmatch, 0);

虽然git log -G"regexec\(regexp"将显示此提交，但git log -S"regexec\(regexp" --pickaxe-regex不会（因为该字符串的出现次数没有改变）。

除非提供--text，否则将忽略没有 textconv 过滤器的二进制文件的补丁。

有关详细信息，请参阅 gitdiffcore [7] 中的 pickaxe 条目。

 --find-object=<object-id>

查找更改指定对象出现次数的差异。与-S类似，只是参数的不同之处在于它不搜索特定的字符串，而是搜索特定的对象 id。

该对象可以是 blob 或子模块提交。它意味着git-log中的-t选项也可以找到树。

 --pickaxe-all

当-S或-G找到更改时，显示该更改集中的所有更改，而不仅仅是包含< string>中更改的文件。

 --pickaxe-regex

对待< string>赋予-S作为扩展的 POSIX 正则表达式以匹配。

 -O<orderfile>

控制文件在输出中的显示顺序。这会覆盖diff.orderFile配置变量（参见 git-config [1] ）。要取消diff.orderFile，请使用-O/dev/null。

输出顺序由< orderfile>中的 glob 模式的顺序决定。首先输出所有与第一个模式匹配的路径名的文件，然后输出所有与第二个模式（但不是第一个模式）匹配的路径名的文件，依此类推。路径名与任何模式都不匹配的所有文件都是最后输出的，就好像文件末尾有一个隐式匹配所有模式一样。如果多个路径名具有相同的等级（它们匹配相同的模式但没有早期模式），则它们相对于彼此的输出顺序是正常顺序。

< orderfile>解析如下：

空行被忽略，因此可以将它们用作分隔符以提高可读性。
以哈希（“#”）开头的行将被忽略，因此它们可用于注释。如果以散列开头，则将反斜杠（“\”）添加到模式的开头。
每个其他行包含一个模式。

模式与没有 FNM_PATHNAME 标志的 fnmatch（3）使用的模式具有相同的语法和语义，但如果删除任意数量的最终路径名组件与模式匹配，则路径名也匹配模式。例如，模式“foo*bar”匹配“fooasdfbar”和“foo/bar/baz/asdf”而不匹配“foobarx”。

-R

交换两个输入;也就是说，显示从索引或磁盘文件到树内容的差异。

 --relative[=<path>]

从项目的子目录运行时，可以告诉它排除目录外的更改并使用此选项显示相对于它的路径名。当您不在子目录中时（例如，在裸存储库中），您可以通过给出< path>来命名哪个子目录以使输出相对。作为一个论点。

-a

 --text

将所有文件视为文本。

 --ignore-cr-at-eol

进行比较时，忽略行尾的回车。

 --ignore-space-at-eol

忽略 EOL 中的空白更改。

-b

 --ignore-space-change

忽略空格量的变化。这会忽略行尾的空格，并将一个或多个空白字符的所有其他序列视为等效。

-w

 --ignore-all-space

比较线条时忽略空格。即使一行有空格而另一行没有空格，这也会忽略差异。

 --ignore-blank-lines

忽略其行全部为空的更改。

 --inter-hunk-context=<lines>

显示差异之间的上下文，直到指定的行数，从而融合彼此接近的帅哥。如果未设置配置选项，则默认为diff.interHunkContext或 0。

-W

 --function-context

显示整个周围的变化功能。

 --ext-diff

允许执行外部 diff 助手。如果使用 gitattributes [5] 设置外部差异驱动程序，则需要将此选项与 git-log [1] 和朋友一起使用。

 --no-ext-diff

禁止外部差异驱动程序。

 --textconv

 --no-textconv

在比较二进制文件时允许（或禁止）外部文本转换过滤器运行。有关详细信息，请参阅 gitattributes [5] 。由于 textconv 过滤器通常是单向转换，因此生成的差异适合人类使用，但无法应用。因此，默认情况下，textconv 过滤器仅针对 git-diff [1] 和 git-log [1] 启用，但不适用于 git-format-patch [ 1] 或差异管道命令。

 --ignore-submodules[=<when>]

忽略差异生成中子模块的更改。 <当>可以是“none”，“untracked”，“dirty”或“all”，这是默认值。使用“none”时，如果子模块包含未跟踪或修改的文件，或者其 HEAD 与超级项目中记录的提交不同，则可以使用“无”来修改子模块，并可用于覆盖中 ignore 选项的任何设置 git-config [1] 或 gitmodules [5] 。当使用“未跟踪”时，如果子模块仅包含未跟踪的内容（但仍会扫描修改的内容），则子模块不会被视为脏。使用“脏”忽略对子模块工作树的所有更改，仅显示存储在超级项目中的提交的更改（这是 1.7.0 之前的行为）。使用“all”隐藏子模块的所有更改。

 --src-prefix=<prefix>

显示给定的源前缀而不是“a /”。

 --dst-prefix=<prefix>

显示给定的目标前缀而不是“b /”。

 --no-prefix

不显示任何源或目标前缀。

 --line-prefix=<prefix>

为每行输出预先附加前缀。

 --ita-invisible-in-index

默认情况下，“git add -N”添加的条目在“git diff”中显示为现有空文件，在“git diff --cached”中显示为新文件。此选项使条目在“git diff”中显示为新文件，在“git diff --cached”中不存在。可以使用--ita-visible-in-index恢复此选项。这两个选项都是实验性的，将来可以删除。

有关这些常用选项的更详细说明，另请参阅 gitdiffcore [7] 。

使用-p 生成补丁

当“git-diff-index”，“git-diff-tree”或“git-diff-files”使用-p选项运行时，“git diff”不带--raw选项或“git log”使用“-p”选项，它们不会产生上述输出;相反，他们生成一个补丁文件。您可以通过GIT_EXTERNAL_DIFF和GIT_DIFF_OPTS环境变量自定义此类修补程序的创建。

-p 选项产生的内容与传统的 diff 格式略有不同：

它前面有一个“git diff”标题，如下所示：

diff --git a/file1 b/file2

除非涉及重命名/复制，否则a/和b/文件名是相同的。特别是，即使是创建或删除，/dev/null也是 _ 而不是 _ 来代替a/或b/文件名。

当涉及重命名/复制时，file1和file2分别显示重命名/复制的源文件的名称和重命名/复制的文件的名称。

它后跟一个或多个扩展标题行：

old mode &lt;mode&gt;
new mode &lt;mode&gt;
deleted file mode &lt;mode&gt;
new file mode &lt;mode&gt;
copy from &lt;path&gt;
copy to &lt;path&gt;
rename from &lt;path&gt;
rename to &lt;path&gt;
similarity index &lt;number&gt;
dissimilarity index &lt;number&gt;
index &lt;hash&gt;..&lt;hash&gt; &lt;mode&gt;

文件模式打印为 6 位八进制数，包括文件类型和文件权限位。

扩展标头中的路径名不包括a/和b/前缀。

相似性指数是未更改行的百分比，相异性指数是更改行的百分比。它是一个向下舍入的整数，后跟一个百分号。因此，100％的相似性索引值保留用于两个相等的文件，而 100％的相异性意味着旧文件中的任何行都不会成为新文件。

索引行包括更改前后的 SHA-1 校验和。 <模式>如果文件模式没有改变，则包括在内;否则，单独的行表示旧模式和新模式。

具有“异常”字符的路径名被引用，如配置变量core.quotePath所述（参见 git-config [1] ）。

输出中的所有file1文件在提交之前引用文件，并且所有file2文件在提交之后引用文件。将每个更改顺序应用于每个文件是不正确的。例如，此补丁将交换 a 和 b：

diff --git a/a b/b
rename from a
rename to b
diff --git a/b b/a
rename from b
rename to a

组合差异格式

在显示合并时，任何差异生成命令都可以使用-c或--cc选项生成 _ 组合差异 _。当显示与 git-diff [1] 或 git-show [1] 的合并时，这是默认格式。另请注意，您可以为这些命令中的任何一个提供-m选项，以强制使用合并的各个父项生成差异。

_ 组合 diff_ 格式如下所示：

diff --combined describe.c
index fabadb8,cc95eb0..4866510
--- a/describe.c
+++ b/describe.c
@@@ -98,20 -98,12 +98,20 @@@
	return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
  }

- static void describe(char *arg)
 -static void describe(struct commit *cmit, int last_one)
++static void describe(char *arg, int last_one)
  {
 +	unsigned char sha1[20];
 +	struct commit *cmit;
	struct commit_list *list;
	static int initialized = 0;
	struct commit_name *n;

 +	if (get_sha1(arg, sha1) < 0)
 +		usage(describe_usage);
 +	cmit = lookup_commit_reference(sha1);
 +	if (!cmit)
 +		usage(describe_usage);
 +
	if (!initialized) {
		initialized = 1;
		for_each_ref(get_name);

它前面有一个“git diff”标题，看起来像这样（当使用-c选项时）：

diff --combined file

或者像这样（当使用--cc选项时）：

diff --cc file

它后跟一个或多个扩展标题行（此示例显示了与两个父项的合并）：

index &lt;hash&gt;,&lt;hash&gt;..&lt;hash&gt;
mode &lt;mode&gt;,&lt;mode&gt;..&lt;mode&gt;
new file mode &lt;mode&gt;
deleted file mode &lt;mode&gt;,&lt;mode&gt;

只有当< mode>中的至少一个出现时，mode <mode>,<mode>..<mode>行才会出现。与其他人不同。具有关于检测到的内容移动（重命名和复制检测）的信息的扩展标题被设计为与两个< tree-ish>的差异一起工作。并且不会被组合 diff 格式使用。

接下来是两行的文件/文件头

--- a/file
+++ b/file

与传统 _ 统一 _ diff 格式的双行标题类似，/dev/null用于表示创建或删除的文件。

修改了块头格式以防止人们意外地将其馈送到patch -p1。创建组合差异格式用于审查合并提交更改，并不适用于应用。此更改类似于扩展 _ 索引 _ 标头中的更改：

@@@ &lt;from-file-range&gt; &lt;from-file-range&gt; &lt;to-file-range&gt; @@@

组合 diff 格式的块头中有（父项数+ 1）@个字符。

与传统的 _ 统一 _ 差异格式不同，后者显示两个文件 A 和 B，其中一列具有-（减去 - 出现在 A 中但在 B 中删除），+（加 - 缺少 A 但是添加到 B）或" "（空格 - 未更改）前缀，此格式将两个或多个文件 file1，file2，…与一个文件 X 进行比较，并显示 X 与每个文件 N 的不同之处。每个 fileN 的一列被添加到输出行之前，以指示 X 的行与它的不同之处。

N 列中的-字符表示该行出现在 fileN 中，但它不会出现在结果中。列 N 中的+字符表示该行出现在结果中，而 fileN 没有该行（换句话说，从该父项的角度添加了该行）。

在上面的示例输出中，函数签名已从两个文件中更改（因此，file1 和 file2 中的两个-删除加上++表示添加的一行未出现在 file1 或 file2 中）。另外八行与 file1 相同，但不出现在 file2 中（因此以+为前缀）。

当由git diff-tree -c显示时，它将合并提交的父项与合并结果进行比较（即 file1…fileN 是父项）。当由git diff-files -c显示时，它将两个未解析的合并父项与工作树文件进行比较（即 file1 是阶段 2 又名“我们的版本”，file2 是阶段 3 又名“他们的版本”）。

例子

 git show v1.0.0

显示标签v1.0.0以及标签指向的对象。

 git show v1.0.0^{tree}

显示标签v1.0.0指向的树。

 git show -s --format=%s v1.0.0^{commit}

显示标记v1.0.0指向的提交主题。

 git show next~10:Documentation/README

显示文件Documentation/README的内容，因为它们是分支next的第 10 次最后提交时的当前内容。

 git show master:Makefile master:t/Makefile

在分支master的头部连接所述 Makefile 的内容。

讨论

Git 在某种程度上是字符编码不可知的。

blob 对象的内容是未解释的字节序列。核心级别没有编码转换。
路径名以 UTF-8 规范化形式 C 编码。这适用于树对象，索引文件，ref 名称，以及命令行参数，环境变量和配置文件中的路径名（.git/config（参见 git） -config [1] ）， gitignore [5] ， gitattributes [5] 和 gitmodules [5] ）。请注意，核心级别的 Git 仅将路径名称视为非 NUL 字节序列，没有路径名称编码转换（Mac 和 Windows 除外）。因此，即使在使用传统扩展 ASCII 编码的平台和文件系统上，使用非 ASCII 路径名也会起作用。但是，在此类系统上创建的存储库将无法在基于 UTF-8 的系统（例如 Linux，Mac，Windows）上正常工作，反之亦然。此外，许多基于 Git 的工具只是假设路径名为 UTF-8，并且无法正确显示其他编码。
提交日志消息通常以 UTF-8 编码，但也支持其他扩展 ASCII 编码。这包括 ISO-8859-x，CP125x 和许多其他，但 _ 不是 _ UTF-16/32，EBCDIC 和 CJK 多字节编码（GBK，Shift-JIS，Big5，EUC-x，CP9xx 等。）。

虽然我们鼓励提交日志消息以 UTF-8 编码，但核心和 Git 瓷器都不是为了强制项目使用 UTF-8。如果特定项目的所有参与者发现使用遗留编码更方便，Git 不会禁止它。但是，有一些事情需要牢记。

git commit 和 git commit-tree 发出警告，如果提供给它的提交日志消息看起来不像有效的 UTF-8 字符串，除非你明确说你的项目使用了遗产编码。说这个的方法是在.git/config文件中使用 i18n.commitencoding，如下所示：

[i18n]
	commitEncoding = ISO-8859-1

使用上述设置创建的提交对象在其encoding标题中记录i18n.commitEncoding的值。这是为了帮助其他人以后再看。缺少此标头意味着提交日志消息以 UTF-8 编码。

git log ， git show ， git blame 和朋友们查看提交对象的encoding头，并尝试将日志消息重新编码为除非另有说明，否则为 UTF-8。您可以使用.git/config文件中的i18n.logOutputEncoding指定所需的输出编码，如下所示：

[i18n]
	logOutputEncoding = ISO-8859-1

如果您没有此配置变量，则使用i18n.commitEncoding的值。

请注意，我们故意选择在提交以在提交对象级别强制使用 UTF-8 时不重新编写提交日志消息，因为重新编码为 UTF-8 不一定是可逆操作。

GIT

部分 git [1] 套件

git-log

原文： git-scm.com/docs/git-log

名称

git-log - 显示提交日志

概要

git log [<options>] [<revision range>] [[--] <path>…]

描述

显示提交日志。

该命令采用适用于git rev-list命令的选项来控制显示的内容和方式，以及适用于git diff-*命令的选项，以控制每个提交引入的更改的显示方式。

OPTIONS

 --follow

继续列出重命名以外的文件历史记录（仅适用于单个文件）。

 --no-decorate

 --decorate[=short|full|auto|no]

打印出所有提交的引用名称。如果指定 _ 短 _，则引用名称前缀 refs / heads / ， refs / tags / 和 refs / remotes / 将不会打印。如果指定了 full ，将打印完整的引用名称（包括前缀）。如果指定了 auto ，那么如果输出到达终端，则 ref 名称显示为 short ，否则不显示 ref 名称。默认选项为 _ 短 _。

 --decorate-refs=<pattern>

 --decorate-refs-exclude=<pattern>

如果没有给出--decorate-refs，假装好像所有参考都被包括在内。对于每个候选人，如果它与--decorate-refs-exclude给出的任何模式匹配或者与--decorate-refs给出的任何模式都不匹配，请不要将其用于装饰。

 --source

打印出在每个提交到达的命令行上给出的引用名称。

 --use-mailmap

使用 mailmap 文件将作者和提交者名称以及电子邮件地址映射到规范的真实姓名和电子邮件地址。见 git-shortlog [1] 。

 --full-diff

如果没有此标志，git log -p <path>...将显示触摸指定路径的提交，并显示相同指定路径的差异。这样，就会显示完全差异，以便接触指定的路径。这意味着“< path> …”仅限制提交，并不限制这些提交的差异。

请注意，这会影响所有基于差异的输出类型，例如：那些由--stat等产生的

 --log-size

在每次提交的输出中包含“日志大小< number>”行，其中< number>是以字节为单位的提交消息的长度。旨在通过允许它们提前分配空间来加速从git log输出读取日志消息的工具。

 -L <start>,<end>:<file>

 -L :<funcname>:<file>

跟踪“< start>，< end>”给出的行范围的演变（或< file>）中的（或函数名称 regex< funcname>）。你可能不会给任何 pathpec 限制器。目前这仅限于从单个修订开始的步行，即，您可能只提供零个或一个正修订参数。您可以多次指定此选项。

<开始>和< end>可以采取以下形式之一：

数如果< start>或者< end>是一个数字，它指定一个绝对行号（行数从 1 开始）。
/正则表达式/ 此表单将使用与给定 POSIX 正则表达式匹配的第一行。如果< start>是一个正则表达式，它将从前一个-L范围的末尾搜索，如果有的话，否则从文件的开头搜索。如果< start>是“^ / regex /”，它将从文件的开头搜索。如果< end>是一个正则表达式，它将从< start>给出的行开始搜索。
- offset 或-offset
这仅适用于< end>并将在< start>给出的行之前或之后指定行数。

如果给出“：< funcname>”代替< start>和< end>，它是一个正则表达式，表示从匹配< funcname>的第一个 funcname 行到下一个 funcname 行的范围。 “：< funcname>”从上一个-L范围的末尾搜索（如果有的话），否则从文件的开头搜索。 “^：< funcname>”从文件的开头搜索。

 <revision range>

仅显示指定修订范围内的提交。当没有<修订范围>如果指定，则默认为HEAD（即导致当前提交的整个历史记录）。 origin..HEAD指定从当前提交可以访问的所有提交（即HEAD），但不是origin。有关拼写< revision range>的完整列表，请参阅 gitrevisions [7] 的 _ 指定范围 _ 部分。

 [--] <path>…

仅显示足以解释与指定路径匹配的文件的提交。有关详细信息和其他简化模式，请参见下面的 _ 历史简化 _。

当出现混淆时，路径可能需要以--作为前缀，以将它们与选项或修订范围分开。

提交限制

除了使用说明书中解释的特殊符号指定应列出的提交范围之外，还可以应用其他提交限制。

除非另有说明，否则使用更多选项通常会进一步限制输出（例如，--since=<date1>限制提交比<date1>更新，并将其与--grep=<pattern>一起使用进一步限制其日志消息具有与<pattern>匹配的行的提交）。

请注意，这些是在提交排序和格式化选项之前应用的，例如--reverse。

 -<number>

 -n <number>

 --max-count=<number>

限制要输出的提交数量。

 --skip=<number>

在开始显示提交输出之前，跳过 _ 编号 _ 提交。

 --since=<date>

 --after=<date>

显示比特定日期更新的提交。

 --until=<date>

 --before=<date>

显示超过特定日期的提交。

 --author=<pattern>

 --committer=<pattern>

将提交输出限制为具有与指定模式（正则表达式）匹配的作者/提交者标题行的输出。对于多个--author=<pattern>，选择作者与任何给定模式匹配的提交（类似于多个--committer=<pattern>）。

 --grep-reflog=<pattern>

将提交输出限制为具有与指定模式（正则表达式）匹配的 reflog 条目的输出。如果有多个--grep-reflog，则选择其 reflog 消息与任何给定模式匹配的提交。除非正在使用--walk-reflogs，否则使用此选项是错误的。

 --grep=<pattern>

将提交输出限制为具有与指定模式（正则表达式）匹配的日志消息的输出。如果有多个--grep=<pattern>，则会选择其消息与任何给定模式匹配的提交（但请参见--all-match）。

当--show-notes生效时，来自注释的消息将被匹配，就像它是日志消息的一部分一样。

 --all-match

将提交输出限制为匹配所有给定--grep的输出，而不是匹配至少一个的输出。

 --invert-grep

将提交输出限制为具有与--grep=<pattern>指定的模式不匹配的日志消息的输出。

-i

 --regexp-ignore-case

匹配正则表达式限制模式而不考虑字母大小写。

 --basic-regexp

将限制模式视为基本正则表达式;这是默认值。

-E

 --extended-regexp

考虑限制模式是扩展正则表达式而不是默认的基本正则表达式。

-F

 --fixed-strings

将限制模式视为固定字符串（不要将模式解释为正则表达式）。

-P

 --perl-regexp

将限制模式视为与 Perl 兼容的正则表达式。

对这些类型的正则表达式的支持是可选的编译时依赖性。如果 Git 没有编译并支持它们，那么提供此选项将导致它死亡。

 --remove-empty

当给定路径从树中消失时停止。

 --merges

仅打印合并提交。这与--min-parents=2完全相同。

 --no-merges

不要打印具有多个父级的提交。这与--max-parents=1完全相同。

 --min-parents=<number>

 --max-parents=<number>

 --no-min-parents

 --no-max-parents

仅显示至少（或最多）许多父提交的提交。特别是，--max-parents=1与--no-merges相同，--min-parents=2与--merges相同。 --max-parents=0给出所有 root 提交和--min-parents=3所有章鱼合并。

--no-min-parents和--no-max-parents再次重置这些限制（无限制）。等效形式是--min-parents=0（任何提交具有 0 或更多父母）和--max-parents=-1（负数表示无上限）。

 --first-parent

在看到合并提交时，仅遵循第一个父提交。在查看特定主题分支的演变时，此选项可以提供更好的概述，因为合并到主题分支往往只是关于不时调整到更新的上游，并且此选项允许您忽略引入的单个提交通过这样的合并你的历史。不能与–bisect 结合使用。

 --not

反转所有后续修订说明符的 ^ 前缀（或缺少）的含义，直到下一个--not。

 --all

假设refs/中的所有引用与HEAD一起在命令行中列为 < commit> 。

 --branches[=<pattern>]

假设refs/heads中的所有引用都在命令行中列为 < commit> 。如果 < pattern> 给出，将分支限制为匹配给定 shell glob 的分支。如果模式缺乏 _？最后暗示 _， * 或 [， / * 。

 --tags[=<pattern>]

假设refs/tags中的所有引用都在命令行中列为 < commit> 。如果 _< pattern>给出了 _，将标签限制为与给定 shell glob 匹配的标签。如果模式缺乏 _？最后暗示 _， * 或 [， / * 。

 --remotes[=<pattern>]

假设refs/remotes中的所有引用都在命令行中列为 < commit> 。如果 _< pattern>给出了 _，将远程跟踪分支限制为与给定 shell glob 匹配的分支。如果模式缺乏 _？最后暗示 _， * 或 [， / * 。

 --glob=<glob-pattern>

假设所有的 refs 匹配 shell glob < glob-pattern> 在命令行中列为 < commit> 。领先的 refs / 会在缺失时自动添加。如果模式缺乏 _？最后暗示 _， * 或 [， / * 。

 --exclude=<glob-pattern>

不包括引用匹配 < glob-pattern> 否则会考虑下一个--all，--branches，--tags，--remotes或--glob。重复此选项会累积排除模式，直至下一个--all，--branches，--tags，--remotes或--glob选项（其他选项或参数不会清除累积模式）。

当应用于--branches，--tags或--remotes时，给出的模式不应以refs/heads，refs/tags或refs/remotes开始，并且当应用于--glob时，它们必须以refs/开头]或--all。如果打算使用尾随 / * ，则必须明确给出。

 --reflog

假设 reflog 所提到的所有对象都在命令行中列为<commit>。

 --single-worktree

默认情况下，当有多个工作树时，将通过以下选项检查所有工作树（参见 git-worktree [1] ）：--all，--reflog和--indexed-objects。此选项强制它们仅检查当前工作树。

 --ignore-missing

在输入中看到无效的对象名称时，假装没有给出错误的输入。

 --bisect

假设好像已经列出了错误的二分法refs/bisect/bad并且好像它后面跟着--not并且良好的二分法在命令行上引用了refs/bisect/good-*。不能与–first-parent 结合使用。

 --stdin

除了 _< commit>在命令行中列出 _，从标准输入中读取它们。如果看到--分隔符，请停止读取提交并开始读取路径以限制结果。

 --cherry-mark

与--cherry-pick（见下文）相同，但标记等效提交与=而不是省略它们，而与+不等价。

 --cherry-pick

当提交集受限于对称差异时，省略任何引用与“另一方”上的另一个提交相同的更改的提交。

例如，如果您有两个分支，A和B，通常只在一侧列出所有提交的方法是使用--left-right（请参阅下面--left-right选项说明中的示例）。但是，它显示了从另一个分支中挑选出来的提交（例如，“b 上的第 3 个”可以从分支 A 中挑选出来）。使用此选项，将从输出中排除此类提交对。

 --left-only

 --right-only

列表仅在对称差异的相应侧提交，即仅在那些将被标记为<的那些。 > --left-right。

例如，--cherry-pick --right-only A...B省略了来自B的提交，这些提交位于A中，或者补丁等效于A中的提交。换句话说，这列出了git cherry A B的+提交。更确切地说，--cherry-pick --right-only --no-merges给出了确切的列表。

 --cherry

--right-only --cherry-mark --no-merges的同义词;有用的是将输出限制在我们这一侧的提交中，并用git log --cherry upstream...mybranch标记已应用于分叉历史记录另一侧的输出，类似于git cherry upstream mybranch。

-g

 --walk-reflogs

而不是走提交祖先链，将 reflog 条目从最新的条目转到较旧的条目。使用此选项时，您无法指定要排除的提交（即 ^ commit ， commit1…commit2 ， commit1 … commit2 表示法不能用过的）。

使用oneline以外的--pretty格式（出于显而易见的原因），这会导致输出从 reflog 中获取两行额外的信息。输出中的 reflog 指示符可能显示为ref@{Nth}（其中Nth是 reflog 中的反向时间顺序索引）或ref@{timestamp}（带有该条目的时间戳），具体取决于以下几条规则：

如果起始点指定为ref@{Nth}，则显示索引格式。
如果起始点指定为ref@{now}，则显示时间戳格式。
如果两者均未使用，但在命令行中给出了--date，则以--date请求的格式显示时间戳。
否则，显示索引格式。

在--pretty=oneline下，提交消息在同一行上以此信息为前缀。此选项不能与--reverse组合使用。另见 git-reflog [1] 。

 --merge

合并失败后，show refs 触摸有冲突的文件，并且在所有头上都不存在要合并的文件。

 --boundary

输出排除边界提交。边界提交以-为前缀。

历史简化

有时您只对历史记录的某些部分感兴趣，例如修改特定< path>的提交。但 _ 历史简化 _ 有两个部分，一部分是选择提交，另一部分是如何做，因为有各种策略来简化历史。

以下选项选择要显示的提交：

 <paths>

提交修改给定的<路径>被选中。

 --simplify-by-decoration

选择某些分支或标记引用的提交。

请注意，可以显示额外的提交以提供有意义的历史记录。

以下选项会影响简化的执行方式：

 Default mode

将历史简化为最简单的历史，解释树的最终状态。最简单的，因为如果最终结果相同（即合并具有相同内容的分支），它会修剪一些侧分支

 --full-history

与默认模式相同，但不修剪某些历史记录。

 --dense

仅显示选定的提交，并显示一些具有有意义的历史记录。

 --sparse

显示简化历史记录中的所有提交。

 --simplify-merges

--full-history的附加选项，用于从生成的历史记录中删除一些不必要的合并，因为没有选定的提交有助于此合并。

 --ancestry-path

当给出一系列要显示的提交时（例如 commit1…commit2 或 commit2 ^ commit1 ），只显示直接存在于 commit1 之间的祖先链上的提交]和 commit2 ，即提交既是 commit1 的后代，又是 commit2 的祖先。

下面是更详细的解释。

假设您将foo指定为< paths>。我们将调用修改foo！TREESAME 的提交，以及其余的 TREESAME。（在foo的差异滤波中，它们分别看起来不同且相等。）

在下文中，我们将始终参考相同的示例历史记录来说明简化设置之间的差异。我们假设您正在过滤此提交图中的文件foo：

	  .-A---M---N---O---P---Q
	 /     /   /   /   /   /
	I     B   C   D   E   Y
	 \   /   /   /   /   /
	  `-------------'   X

历史 A — Q 的水平线被视为每次合并的第一个父级。提交是：

I是初始提交，其中foo存在内容“asdf”，文件quux存在，内容为“quux”。初始提交与空树进行比较，因此I是！TREESAME。
在A中，foo仅包含“foo”。
B包含与A相同的更改。它的合并M是微不足道的，因此对所有父母都是 TREESAME。
C不会更改foo，但是它的合并N会将其更改为“foobar”，因此它不是任何父级的 TREESAME。
D将foo设置为“baz”。它的合并O将N和D的字符串组合成“foobarbaz”;即，它不是任何父母的 TREESAME。
E将quux更改为“xyzzy”，其合并P将字符串组合为“quux xyzzy”。 P是 TREESAME 到O，但不是E。
X是一个独立的根提交，它添加了一个新文件side，Y修改了它。 Y是 TREESAME 到X。它的合并Q将side添加到P，Q将 TREESAME 添加到P，但不添加到Y。

rev-list根据是否使用--full-history和/或父改写（通过--parents或--children）来回溯历史记录，包括或排除提交。可以使用以下设置。

 Default mode

如果对任何父母不是 TREESAME，则包含提交（尽管可以更改，请参阅下面的--sparse）。如果提交是合并，并且它是一个父级的 TREESAME，则只关注该父级。（即使有几个 TREESAME 父母，也只能跟随他们中的一个。）否则，请跟随所有父母。

这导致：

	  .-A---N---O
	 /     /   /
	I---------D

请注意，仅遵循 TREESAME 父级的规则（如果有的话）将完全从考虑中删除B。 C被认为是通过N，但是是 TREESAME。 Root 提交与空树进行比较，因此I是！TREESAME。

父/子关系仅在--parents中可见，但这不会影响在默认模式下选择的提交，因此我们显示了父行。

 --full-history without parent rewriting

此模式与默认值在一点上不同：始终跟随合并的所有父项，即使它是其中一个的 TREESAME。即使合并的多个方面包含了包含的提交，这并不意味着合并本身就是！在这个例子中，我们得到了

	I  A  B  N  D  O  P  Q

M被排除在外，因为对父母双方都是 TREESAME。 E，C和B都走了，但只有B是！TREESAME，所以没有出现。

请注意，如果没有父改写，就不可能谈论提交之间的父/子关系，因此我们将它们显示为断开连接。

 --full-history with parent rewriting

只有普通提交才包括在内！TREESAME（虽然可以更改，但请参见下面的--sparse）。

合并始终包括在内。但是，它们的父列表会被重写：沿着每个父项删除不包含在其中的提交。这导致了

	  .-A---M---N---O---P---Q
	 /     /   /   /   /
	I     B   /   D   /
	 \   /   /   /   /
	  `-------------'

与--full-history比较而不重写上述内容。请注意，E被删除，因为它是 TREESAME，但是 P 的父列表被重写为包含E的父I。 C和N，X，Y和Q也发生了同样的情况。

除上述设置外，您还可以更改 TREESAME 是否影响包含：

 --dense

如果他们不是任何父母的 TREESAME，则包括走路的提交。

 --sparse

包括所有步行的提交。

请注意，如果没有--full-history，这仍然可以简化合并：如果其中一个父项是 TREESAME，我们只遵循那个，所以合并的其他方面永远不会走。

 --simplify-merges

首先，以与父改写的--full-history相同的方式构建历史图（参见上文）。

然后根据以下规则将每个提交C简化为最终历史记录中的替换C'：

将C'设置为C。
将C'的每个父P替换为其简化P'。在这个过程中，删除作为其他父母或祖先的祖先的父母将 TREESAME 提交到空树，并删除重复项，但要注意永远不要删除我们所有父母的 TREESAME。
如果在此父级重写之后，C'是根或合并提交（具有零或> 1 父级），边界提交或！TREESAME，它仍然存在。否则，它将替换为其唯一的父级。

通过与--full-history与父重写进行比较，可以最好地显示出这种效果。这个例子变成了：

	  .-A---M---N---O
	 /     /       /
	I     B       D
	 \   /       /
	  `---------'

注意N，P和Q与--full-history的主要差异：

N的父列表删除了I，因为它是另一个父M的祖先。仍然，N仍然是因为它是！TREESAME。
P的父列表同样删除了I。 P然后被完全删除，因为它有一个父母并且是 TREESAME。
Q的父列表将Y简化为X。然后删除X，因为它是 TREESAME 根。 Q然后被完全删除，因为它有一个父母并且是 TREESAME。

最后，还有第五种简化模式：

 --ancestry-path

将显示的提交限制为直接在给定提交范围中的“from”和“to”提交之间的祖先链上的提交。即只显示“to”提交的祖先和“from”提交的后代的提交。

作为示例用例，请考虑以下提交历史记录：

	    D---E-------F
	   /     \       \
	  B---C---G---H---I---J
	 /                     \
	A-------K---------------L--M

常规 D…M 计算作为M的祖先的提交集，但不包括作为D的祖先的提交。这对于从D以来导致M的历史发生了什么是有用的，因为“D中没有M具有什么M”。这个例子中的结果将是所有提交，除了A和B（当然还有D本身）。

当我们想知道M中的提交被D引入的 bug 污染并需要修复时，我们可能只想查看实际上 D…M 的子集D的后代，即排除C和K。这正是--ancestry-path选项的作用。应用于 D…M 范围，它会导致：

		E-------F
		 \       \
		  G---H---I---J
			       \
				L--M

--simplify-by-decoration选项允许您通过省略未由标记引用的提交来仅查看历史拓扑的大图。如果（1）它们被标记引用，或（2）它们改变命令行上给出的路径的内容，则提交被标记为！TREESAME（换句话说，保持在上述历史简化规则之后）。所有其他提交都标记为 TREESAME（可以简化）。

提交订购

默认情况下，提交以反向时间顺序显示。

 --date-order

在显示所有子项之前不显示父项，但在提交时间戳顺序中显示提交。

 --author-date-order

在显示所有子项之前不显示父项，但在作者时间戳顺序中显示提交。

 --topo-order

在显示所有子项之前不显示父项，并避免在多行历史记录中显示混合的提交。

例如，在这样的提交历史中：

    ---1----2----4----7
	\	       \
	 3----5----6----8---

其中数字表示提交时间戳的顺序，git rev-list和--date-order的朋友按时间戳顺序显示提交：8 7 6 5 4 3 2 1。

使用--topo-order，他们将显示 8 6 5 3 7 4 2 1（或 8 7 4 2 6 5 3 1）;为了避免将两个并行开发轨道的提交混合在一起，显示一些较旧的提交在较新的提交之前。

 --reverse

输出要以相反顺序显示的提交（请参阅上面的“提交限制”部分）。不能与--walk-reflogs结合使用。

对象遍历

这些选项主要用于打包 Git 存储库。

 --no-walk[=(sorted|unsorted)]

只显示给定的提交，但不要遍历他们的祖先。如果指定了范围，则无效。如果给出了参数unsorted，则提交将按命令行中给出的顺序显示。否则（如果sorted或没有给出参数），提交按提交时间以反向时间顺序显示。不能与--graph结合使用。

 --do-walk

覆盖之前的--no-walk。

提交格式

 --pretty[=<format>]

 --format=<format>

有关每种格式的一些其他详细信息，请参阅“PRETTY FORMATS”部分。当 =< format> 部分省略，默认为 medium 。

注意：您可以在存储库配置中指定默认的漂亮格式（请参阅 git-config [1] ）。

 --abbrev-commit

而不是显示完整的 40 字节十六进制提交对象名称，而只显示部分前缀。可以使用“–abbrev =< n>”指定非默认位数（如果显示，也会修改 diff 输出）。

对于使用 80 列终端的人来说，这应该使“–pretty = oneline”更具可读性。

 --no-abbrev-commit

显示完整的 40 字节十六进制提交对象名称。这否定了--abbrev-commit以及暗示它的选项，例如“–oneline”。它还会覆盖log.abbrevCommit变量。

 --oneline

这是一起使用的“–pretty = oneline --abbrev-commit”的简写。

 --encoding=<encoding>

 --expand-tabs=<n>

 --expand-tabs

 --no-expand-tabs

默认情况下，选项卡以相当格式展开，将日志消息缩进 4 个空格（即 medium ，默认情况下， full 和 fulller ）。

 --notes[=<treeish>]

默认情况下，显示的注释来自core.notesRef和notes.displayRef变量（或相应的环境覆盖）中列出的注释 refs。有关详细信息，请参阅 git-config [1] 。

 --no-notes

 --show-notes[=<treeish>]

 --[no-]standard-notes

不推荐使用这些选项。请使用上面的–notes / - no-notes 选项。

 --show-signature

通过将签名传递给gpg --verify并显示输出来检查已签名的提交对象的有效性。

 --relative-date

--date=relative的同义词。

 --date=<format>

仅对以人类可读格式显示的日期生效，例如使用--pretty时。 log.date config 变量为日志命令的--date选项设置默认值。默认情况下，日期显示在原始时区（提交者或作者）中。如果-local附加到格式（例如，iso-local），则使用用户的本地时区。

--date=relative显示相对于当前时间的日期，例如“2 小时前”。 -local选项对--date=relative无效。

--date=local是--date=default-local的别名。

--date=iso（或--date=iso8601）以类似 ISO 8601 的格式显示时间戳。与严格的 ISO 8601 格式的区别在于：

空格而不是T日期/时间分隔符
时区和时区之间的空间
时区的小时和分钟之间没有冒号

--date=iso-strict（或--date=iso8601-strict）以严格的 ISO 8601 格式显示时间戳。

--date=rfc（或--date=rfc2822）以 RFC 2822 格式显示时间戳，通常在电子邮件中找到。
--date=short仅以YYYY-MM-DD格式显示日期，但不显示时间。
--date=raw显示自纪元以来的秒数（1970-01-01 00:00:00 UTC），后跟一个空格，然后将时区显示为与 UTC 的偏移量（+或-与四位数;前两位是小时，后两位是分钟）。即，好像时间戳是用strftime("%s %z")格式化的。请注意，-local选项不会影响秒 - 自 - 纪元值（始终以 UTC 为单位），但会切换附带的时区值。
--date=human如果时区与当前时区不匹配则显示时区，如果匹配则不显示整个日期（即跳过“今年”日期的打印年份，但也跳过整个日期如果它是在过去几天，我们可以说它是什么工作日）。对于较旧的日期，小时和分钟也被省略。
--date=unix将日期显示为 Unix 纪元时间戳（自 1970 年以来的秒数）。与--raw一样，它始终为 UTC，因此-local无效。
--date=format:...将格式...输入系统strftime，％z 和％Z 除外，它们在内部处理。使用--date=format:%c以系统区域设置的首选格式显示日期。有关格式占位符的完整列表，请参阅strftime手册。使用-local时，正确的语法是--date=format-local:...。
--date=default是默认格式，类似于--date=rfc2822，但有一些例外：
星期几之后没有逗号
使用本地时区时，省略时区

 --parents

同时打印提交的父级（以“提交父级”的形式）。也可以启用父重写，请参阅上面的 _ 历史简化 _。

 --children

同时打印提交的子项（以“提交子项…”的形式）。也可以启用父重写，请参阅上面的 _ 历史简化 _。

 --left-right

标记可以从中获取提交的对称差异的哪一侧。左侧的提示以<为前缀，右侧的提示以>为前缀。如果与--boundary结合使用，则这些提交以-为前缀。

例如，如果您有此拓扑：

	     y---b---b  branch B
	    / \ /
	   /   .
	  /   / \
	 o---x---a---a  branch A

你会得到这样的输出：

	$ git rev-list --left-right --boundary --pretty=oneline A...B

	>bbbbbbb... 3rd on b
	>bbbbbbb... 2nd on b
	<aaaaaaa... 3rd on a
	<aaaaaaa... 2nd on a
	-yyyyyyy... 1st on b
	-xxxxxxx... 1st on a

 --graph

在输出的左侧绘制提交历史的基于文本的图形表示。这可能会导致在提交之间打印额外的行，以便正确绘制图形历史记录。不能与--no-walk结合使用。

这使父进行重写，参见上面的 _ 历史简化 _。

默认情况下，这意味着--topo-order选项，但也可以指定--date-order选项。

 --show-linear-break[=<barrier>]

当不使用–graph 时，所有历史分支都被展平，这使得很难看出两个连续的提交不属于线性分支。在这种情况下，此选项会在它们之间设置障碍。如果指定了<barrier>，则显示的是字符串而不是默认字符串。

差异格式化

下面列出了控制 diff 输出格式的选项。其中一些特定于 git-rev-list [1] ，但是可以给出其他差异选项。有关更多选项，请参阅 git-diff-files [1] 。

-c

使用此选项，合并提交的 diff 输出同时显示每个父项与合并结果的差异，而不是一次显示父项和结果之间的成对差异。此外，它仅列出从所有父母修改的文件。

 --cc

这个标志意味着-c选项并通过省略不感兴趣的帅哥进一步压缩补丁输出，其中父母的内容只有两个变体，合并结果选择其中一个而不做修改。

-m

此标志使合并提交像常规提交一样显示完整差异;对于每个合并父项，将生成单独的日志条目和差异。一个例外是，当给出--first-parent选项时，只显示对第一个父项的差异;在这种情况下，输出表示合并带来的变化 _ 进入当前分支的 _。

-r

显示递归差异。

-t

在 diff 输出中显示树对象。这意味着-r。

漂亮的格式

oneline

&lt;sha1&gt; &lt;title line&gt;

这是为了尽可能紧凑。

_ 短 _

commit &lt;sha1&gt;
Author: &lt;author&gt;

&lt;title line&gt;

_ 中 _

commit &lt;sha1&gt;
Author: &lt;author&gt;
Date:   &lt;author date&gt;

&lt;title line&gt;

&lt;full commit message&gt;

_ 全 _

commit &lt;sha1&gt;
Author: &lt;author&gt;
Commit: &lt;committer&gt;

&lt;title line&gt;

&lt;full commit message&gt;

_ 更丰富 _

commit &lt;sha1&gt;
Author:     &lt;author&gt;
AuthorDate: &lt;author date&gt;
Commit:     &lt;committer&gt;
CommitDate: &lt;committer date&gt;

&lt;title line&gt;

&lt;full commit message&gt;

_ 电子邮件 _

From &lt;sha1&gt; &lt;date&gt;
From: &lt;author&gt;
Date: &lt;author date&gt;
Subject: [PATCH] &lt;title line&gt;

&lt;full commit message&gt;

_ 原始 _

_ 格式：< string>_

_ 格式：< string>_ 格式允许您指定要显示的信息。它的工作方式有点像 printf 格式，但有一个值得注意的例外，即你用％n 而不是 \ n 获得换行符。

例如，_ 格式：“％h 的作者是％an，％ar％n 标题是>>％s<<％n”_ 将显示如下内容：

The author of fe6e0ee was Junio C Hamano, 23 hours ago
The title was &gt;&gt;t4119: test autocomputing -p&lt;n&gt; for traditional diff input.&lt;&lt;

占位符是：

％H ：提交哈希
％h ：缩写提交哈希
％T ：树形哈希
％t ：缩写树哈希
％P ：父哈希
％p ：缩写为父哈希值
_％和 _：作者姓名
％aN ：作者姓名（尊重.mailmap，见 git-shortlog [1] 或 git-blame [1] ）
％ae ：作者电邮
％aE ：作者电子邮件（尊重.mailmap，见 git-shortlog [1] 或 git-blame [1] ）
％ad ：作者日期（格式尊重 - 日期=选项）
％aD ：作者日期，RFC2822 风格
％ar ：作者日期，相对
的 _％：作者日期，UNIX 时间戳 _
％ai ：作者日期，ISO 8601 样格式
％aI ：作者日期，严格的 ISO 8601 格式
％cn ：提交者名称
％cN ：提交者名称（尊重.mailmap，见 git-shortlog [1] 或 git-blame [1] ）
％ce ：提交者电子邮件
％cE ：提交者电子邮件（尊重.mailmap，参见 git-shortlog [1] 或 git-blame [1] ）
％cd ：提交者日期（格式尊重 - 日期=选项）
％cD ：提交者日期，RFC2822 样式
％cr ：提交者日期，相对
％ct ：提交者日期，UNIX 时间戳
％ci ：提交者日期，类似 ISO 8601 的格式
％cI ：提交者日期，严格的 ISO 8601 格式
％d ：引用名称，如 git-log [1] 的–decorate 选项
％D ：没有“（”，“）”包装的引用名称。
％S ：在达到提交的命令行上给出的引用名称（如git log --source），仅适用于git log
％e ：编码
％s ：受试者
％f ：已清理的主题行，适用于文件名
％b ：身体
％B ：生体（未包裹的主体和身体）
％N ：提交备注
％GG ：来自 GPG 的签名提交的原始验证消息
％G？ ：显示好的（有效）签名“G”，坏签名显示“B”，有效期未知的好签名显示“U”，已过期的好签名显示“X”，“Y”代表由过期密钥签名的好签名，“R”表示由撤销密钥签名的好签名，“E”表示签名无法检查（例如缺少密钥），“N”表示没有签名
％GS ：显示签名提交的签名者姓名
％GK ：显示用于签署签名提交的密钥
％GF ：显示用于签署签名提交的密钥的指纹
％GP ：显示主键的指纹，其子键用于签名提交的签名
％gD ：reflog 选择器，例如refs/stash@{1}或refs/stash@{2 minutes ago};格式遵循-g选项描述的规则。 @之前的部分是命令行中给出的 refname（因此git log -g refs/heads/master将产生refs/heads/master@{0}）。
％gd ：缩短了 reflog 选择器;与%gD相同，但 refname 部分缩短了人类的可读性（因此refs/heads/master变为master）。
％gn ：reflog 身份名称
％gN ：reflog 身份名称（尊重.mailmap，见 git-shortlog [1] 或 git-blame [1] ）
％ge ：reflog 身份电子邮件
％gE ：reflog 身份邮件（尊重.mailmap，见 git-shortlog [1] 或 git-blame [1] ）
％gs ：reflog 主题
％Cred ：将颜色切换为红色
％Cgreen ：将颜色切换为绿色
％Cblue ：将颜色切换为蓝色
％Creset ：重置颜色
％C（…）：颜色规格，如 git-config [1] 的“CONFIGURATION FILE”部分中的值所述。默认情况下，仅在启用日志输出时显示颜色（通过color.diff，color.ui或--color，并且如果我们要去终端，则尊重前者的auto设置）。 %C(auto,...)被接受为默认的历史同义词（例如，%C(auto,red)）。即使没有启用颜色，指定%C(always,...)也会显示颜色（尽管只考虑使用--color=always为整个输出启用颜色，包括这种格式和其他任何 git 可能颜色的颜色）。单独auto（即%C(auto)）将打开下一个占位符的自动着色，直到再次切换颜色。
％m ：左（<），右（>）或边界（-）标记
％n ：换行符
%% ：原始％
％x00 ：从十六进制代码打印一个字节
％w（[< w> [，< i1> [，< i2>]]]）：切换行换行，类似 git-shortlog [1]的-w 选项。
％<（< N> [，trunc | ltrunc | mtrunc]）：使下一个占位符至少取 N 列，如果需要，在右边填充空格。如果输出长于 N 列，则可以选择在开头（ltrunc），中间（mtrunc）或结尾（trunc）截断。请注意，截断仅适用于 N> = 2。
％< |（< N>）：使下一个占位符至少占用第 N 列，如果需要，在右边填充空格
％>（< N>），％> |（< N>）：与 ％相似，％< |（< N>）_，但左边的填充空格 _
％>（< N>），％> |（< N>）：类似于 ％>（< N>分别是，％> |（< N>），除非下一个占位符占用的空间多于给定的空间并且左侧有空格，请使用这些空格
％><（< N>），％>< |（< N>）：类似于 ％<（< N> ），％< |（< N>），但填充两侧（即文本居中）
％（预告片[：options]）：显示 git-interpret-trailers [1] 解释的正文预告片。 trailers字符串后面可以跟冒号和零个或多个逗号分隔选项。如果给出了only选项，则省略拖车块中的非拖车线。如果给出unfold选项，则表现得就像给出了 interpre-trailer 的--unfold选项一样。例如，%(trailers:only,unfold)两者都做。

如果在占位符的％之后添加+（加号），则在扩展之前插入换行符当且仅当占位符扩展为非空字符串时。

如果在占位符的％之后添加-（减号），则当且仅当占位符扩展为空字符串时，才会删除紧接在扩展之前的所有连续换行符。

如果在占位符的％之后添加一个“空格”，则在扩展之前插入一个空格，当且仅当占位符扩展为非空字符串时。

tformat：

$ git log -2 --pretty=format:%h 4da45bef \
  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
4da45be
7134973 -- NO NEWLINE

$ git log -2 --pretty=tformat:%h 4da45bef \
  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
4da45be
7134973

此外，其中包含%的任何无法识别的字符串都被解释为它前面有tformat:。例如，这两个是等价的：

$ git log -2 --pretty=tformat:%h 4da45bef
$ git log -2 --pretty=%h 4da45bef

常见的 DIFF 选项

-p

-u

 --patch

生成补丁（请参阅生成补丁的部分）。

-s

 --no-patch

抑制差异输出。对于git show等默认显示补丁的命令，或取消--patch的效果很有用。

 -U<n>

 --unified=<n>

用< n>生成差异。上下文而不是通常的三行。意味着-p。

 --raw

 --patch-with-raw

-p --raw的同义词。

 --indent-heuristic

启用改变差异块边界的启发式以使补丁更易于阅读。这是默认值。

 --no-indent-heuristic

禁用缩进启发式。

 --minimal

花些额外的时间来确保产生尽可能小的差异。

 --patience

使用“耐心差异”算法生成差异。

 --histogram

使用“histogram diff”算法生成 diff。

 --anchored=<text>

使用“锚定差异”算法生成差异。

可以多次指定此选项。

如果源和目标中都存在一行，只存在一次，并以此文本开头，则此算法会尝试阻止它在输出中显示为删除或添加。它在内部使用“耐心差异”算法。

 --diff-algorithm={patience|minimal|histogram|myers}

选择差异算法。变体如下：

 default, myers

基本的贪心差异算法。目前，这是默认值。

 minimal

花些额外的时间来确保产生尽可能小的差异。

 patience

生成补丁时使用“耐心差异”算法。

 histogram

该算法将耐心算法扩展为“支持低发生的共同元素”。

例如，如果将diff.algorithm变量配置为非默认值并想要使用默认值，则必须使用--diff-algorithm=default选项。

 --stat[=<width>[,<name-width>[,<count>]]]

也可以使用--stat-width=<width>，--stat-name-width=<name-width>和--stat-count=<count>单独设置这些参数。

 --compact-summary

 --numstat

与--stat类似，但显示十进制表示法中添加和删除的行数以及没有缩写的路径名，以使其更加机器友好。对于二进制文件，输出两个-而不是0 0。

 --shortstat

仅输出--stat格式的最后一行，其中包含已修改文件的总数，以及已添加和已删除行的数量。

 --dirstat[=<param1,param2,…>]

 changes

 lines

 files

 cumulative

计算父目录的子目录中的更改。请注意，使用cumulative时，报告的百分比总和可能超过 100％。可以使用noncumulative参数指定默认（非累积）行为。

 <limit>

整数参数指定截止百分比（默认为 3％）。贡献低于此百分比变化的目录不会显示在输出中。

示例：以下将计算已更改的文件，同时忽略少于已更改文件总量的 10％的目录，并在父目录中累计子目录计数：--dirstat=files,10,cumulative。

 --summary

输出扩展标题信息的精简摘要，例如创建，重命名和模式更改。

 --patch-with-stat

-p --stat的同义词。

-z

将提交与 NUL 分开，而不是使用新换行符。

此外，当给出--raw或--numstat时，不要使用路径名并使用 NUL 作为输出字段终止符。

如果没有此选项，则会引用具有“异常”字符的路径名，如配置变量core.quotePath所述（参见 git-config [1] ）。

 --name-only

仅显示已更改文件的名称。

 --name-status

仅显示已更改文件的名称和状态。有关状态字母的含义，请参阅--diff-filter选项的说明。

 --submodule[=<format>]

 --color[=<when>]

显示彩色差异。 --color（即没有 =<当> ）与--color=always相同时。 < when> 可以是always，never或auto之一。

 --no-color

关掉彩色差异。它与--color=never相同。

 --color-moved[=<mode>]

移动的代码行的颜色不同。 <模式>如果没有给出选项，默认为 no ，如果给出没有模式的选项，则默认为 zebra 。模式必须是以下之一：

no

移动的线条不会突出显示。

 default

是zebra的同义词。这可能会在未来转变为更明智的模式。

 plain

 blocks

贪婪地检测至少 20 个字母数字字符的移动文本块。使用 color.diff。{old，new} Moved 颜色绘制检测到的块。相邻的街区不能分开。

 zebra

 dimmed-zebra

 --no-color-moved

关闭移动检测。这可用于覆盖配置设置。它与--color-moved=no相同。

 --color-moved-ws=<modes>

这将配置在执行--color-moved的移动检测时如何忽略空白。这些模式可以以逗号分隔的列表给出：

no

执行移动检测时不要忽略空格。

 ignore-space-at-eol

忽略 EOL 中的空白更改。

 ignore-space-change

忽略空格量的变化。这会忽略行尾的空格，并将一个或多个空白字符的所有其他序列视为等效。

 ignore-all-space

比较线条时忽略空格。即使一行有空格而另一行没有空格，这也会忽略差异。

 allow-indentation-change

最初忽略移动检测中的任何空格，然后如果每行的空白变化相同，则仅将移动的代码块分组到块中。这与其他模式不兼容。

 --no-color-moved-ws

执行移动检测时不要忽略空格。这可用于覆盖配置设置。它与--color-moved-ws=no相同。

 --word-diff[=<mode>]

使用< mode>显示单词 diff。划定改变的单词。默认情况下，单词由空格分隔;见下面的--word-diff-regex。 <模式>默认为 plain ，必须是以下之一：

 color

仅使用颜色突出显示更改的单词。意味着--color。

 plain

将单词显示为[-removed-]和{+added+}。如果它们出现在输入中，则不会尝试转义分隔符，因此输出可能不明确。

 porcelain

 none

再次禁用字差异。

请注意，尽管第一个模式的名称，但如果启用了颜色，则使用颜色突出显示所有模式中已更改的部分。

 --word-diff-regex=<regex>

使用< regex>决定一个单词是什么，而不是将非空格的运行视为一个单词。除非已经启用，否则还暗示--word-diff。

例如，--word-diff-regex=.会将每个字符视为一个单词，并相应地逐个字符地显示差异。

 --color-words[=<regex>]

相当于--word-diff=color加（如果指定了正则表达式）--word-diff-regex=<regex>。

 --no-renames

关闭重命名检测，即使配置文件提供默认值也是如此。

 --check

 --ws-error-highlight=<kind>

 --full-index

在生成补丁格式输出时，在“索引”行上显示完整的前映像和后映像 blob 对象名称，而不是第一个字符。

 --binary

除--full-index外，还可输出可用git-apply应用的二进制差异。

 --abbrev[=<n>]

 -B[<n>][/<m>]

 --break-rewrites[=[<n>][/<m>]]

将完整的重写更改分为删除和创建对。这有两个目的：

 -M[<n>]

 --find-renames[=<n>]

 -C[<n>]

 --find-copies[=<n>]

检测副本以及重命名。另见--find-copies-harder。如果指定了n，则其含义与-M<n>的含义相同。

 --find-copies-harder

-D

 --irreversible-delete

与-B一起使用时，也省略删除/创建对的删除部分中的原像。

 -l<num>

 --diff-filter=[(A|C|D|M|R|T|U|X|B)…[*]]

此外，这些大写字母可以降级为排除。例如。 --diff-filter=ad排除添加和删除的路径。

 -S<string>

查找改变文件中指定字符串出现次数（即添加/删除）的差异。用于脚本编写者的使用。

也搜索二进制文件。

 -G<regex>

查找补丁文本包含与< regex>匹配的添加/删除行的差异。

为了说明-S<regex> --pickaxe-regex和-G<regex>之间的区别，请考虑在同一文件中使用以下 diff 进行提交：

+    return !regexec(regexp, two->ptr, 1, &regmatch, 0);
...
-    hit = !regexec(regexp, mf2.ptr, 1, &regmatch, 0);

虽然git log -G"regexec\(regexp"将显示此提交，但git log -S"regexec\(regexp" --pickaxe-regex不会（因为该字符串的出现次数没有改变）。

除非提供--text，否则将忽略没有 textconv 过滤器的二进制文件的补丁。

有关详细信息，请参阅 gitdiffcore [7] 中的 pickaxe 条目。

 --find-object=<object-id>

查找更改指定对象出现次数的差异。与-S类似，只是参数的不同之处在于它不搜索特定的字符串，而是搜索特定的对象 id。

该对象可以是 blob 或子模块提交。它意味着git-log中的-t选项也可以找到树。

 --pickaxe-all

当-S或-G找到更改时，显示该更改集中的所有更改，而不仅仅是包含< string>中更改的文件。

 --pickaxe-regex

对待< string>赋予-S作为扩展的 POSIX 正则表达式以匹配。

 -O<orderfile>

控制文件在输出中的显示顺序。这会覆盖diff.orderFile配置变量（参见 git-config [1] ）。要取消diff.orderFile，请使用-O/dev/null。

< orderfile>解析如下：

空行被忽略，因此可以将它们用作分隔符以提高可读性。
以哈希（“#”）开头的行将被忽略，因此它们可用于注释。如果以散列开头，则将反斜杠（“\”）添加到模式的开头。
每个其他行包含一个模式。

-R

交换两个输入;也就是说，显示从索引或磁盘文件到树内容的差异。

 --relative[=<path>]

-a

 --text

将所有文件视为文本。

 --ignore-cr-at-eol

进行比较时，忽略行尾的回车。

 --ignore-space-at-eol

忽略 EOL 中的空白更改。

-b

 --ignore-space-change

忽略空格量的变化。这会忽略行尾的空格，并将一个或多个空白字符的所有其他序列视为等效。

-w

 --ignore-all-space

比较线条时忽略空格。即使一行有空格而另一行没有空格，这也会忽略差异。

 --ignore-blank-lines

忽略其行全部为空的更改。

 --inter-hunk-context=<lines>

显示差异之间的上下文，直到指定的行数，从而融合彼此接近的帅哥。如果未设置配置选项，则默认为diff.interHunkContext或 0。

-W

 --function-context

显示整个周围的变化功能。

 --ext-diff

允许执行外部 diff 助手。如果使用 gitattributes [5] 设置外部差异驱动程序，则需要将此选项与 git-log [1] 和朋友一起使用。

 --no-ext-diff

禁止外部差异驱动程序。

 --textconv

 --no-textconv

 --ignore-submodules[=<when>]

 --src-prefix=<prefix>

显示给定的源前缀而不是“a /”。

 --dst-prefix=<prefix>

显示给定的目标前缀而不是“b /”。

 --no-prefix

不显示任何源或目标前缀。

 --line-prefix=<prefix>

为每行输出预先附加前缀。

 --ita-invisible-in-index

有关这些常用选项的更详细说明，另请参阅 gitdiffcore [7] 。

使用-p 生成补丁

-p 选项产生的内容与传统的 diff 格式略有不同：

它前面有一个“git diff”标题，如下所示：

diff --git a/file1 b/file2

除非涉及重命名/复制，否则a/和b/文件名是相同的。特别是，即使是创建或删除，/dev/null也是 _ 而不是 _ 来代替a/或b/文件名。

当涉及重命名/复制时，file1和file2分别显示重命名/复制的源文件的名称和重命名/复制的文件的名称。

它后跟一个或多个扩展标题行：

old mode &lt;mode&gt;
new mode &lt;mode&gt;
deleted file mode &lt;mode&gt;
new file mode &lt;mode&gt;
copy from &lt;path&gt;
copy to &lt;path&gt;
rename from &lt;path&gt;
rename to &lt;path&gt;
similarity index &lt;number&gt;
dissimilarity index &lt;number&gt;
index &lt;hash&gt;..&lt;hash&gt; &lt;mode&gt;

文件模式打印为 6 位八进制数，包括文件类型和文件权限位。

扩展标头中的路径名不包括a/和b/前缀。

索引行包括更改前后的 SHA-1 校验和。 <模式>如果文件模式没有改变，则包括在内;否则，单独的行表示旧模式和新模式。

具有“异常”字符的路径名被引用，如配置变量core.quotePath所述（参见 git-config [1] ）。

diff --git a/a b/b
rename from a
rename to b
diff --git a/b b/a
rename from b
rename to a

组合差异格式

_ 组合 diff_ 格式如下所示：

diff --combined describe.c
index fabadb8,cc95eb0..4866510
--- a/describe.c
+++ b/describe.c
@@@ -98,20 -98,12 +98,20 @@@
	return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
  }

- static void describe(char *arg)
 -static void describe(struct commit *cmit, int last_one)
++static void describe(char *arg, int last_one)
  {
 +	unsigned char sha1[20];
 +	struct commit *cmit;
	struct commit_list *list;
	static int initialized = 0;
	struct commit_name *n;

 +	if (get_sha1(arg, sha1) < 0)
 +		usage(describe_usage);
 +	cmit = lookup_commit_reference(sha1);
 +	if (!cmit)
 +		usage(describe_usage);
 +
	if (!initialized) {
		initialized = 1;
		for_each_ref(get_name);

它前面有一个“git diff”标题，看起来像这样（当使用-c选项时）：

diff --combined file

或者像这样（当使用--cc选项时）：

diff --cc file

它后跟一个或多个扩展标题行（此示例显示了与两个父项的合并）：

index &lt;hash&gt;,&lt;hash&gt;..&lt;hash&gt;
mode &lt;mode&gt;,&lt;mode&gt;..&lt;mode&gt;
new file mode &lt;mode&gt;
deleted file mode &lt;mode&gt;,&lt;mode&gt;

接下来是两行的文件/文件头

--- a/file
+++ b/file

与传统 _ 统一 _ diff 格式的双行标题类似，/dev/null用于表示创建或删除的文件。

@@@ &lt;from-file-range&gt; &lt;from-file-range&gt; &lt;to-file-range&gt; @@@

组合 diff 格式的块头中有（父项数+ 1）@个字符。

例子

 git log --no-merges

显示整个提交历史记录，但跳过任何合并

 git log v2.6.12.. include/scsi drivers/scsi

显示自版本 v2.6.12 以来更改include/scsi或drivers/scsi子目录中的任何文件的所有提交

 git log --since="2 weeks ago" -- gitk

在过去两周内将更改显示到文件 gitk 。 --是必要的，以避免与名为 gitk 的分支混淆

 git log --name-status release..test

显示“test”分支中但尚未在“release”分支中的提交，以及每个提交修改的路径列表。

 git log --follow builtin/rev-list.c

显示更改builtin/rev-list.c的提交，包括在文件被赋予其当前名称之前发生的提交。

 git log --branches --not --remotes=origin

显示任何本地分支中的所有提交，但不显示 _ 原点 _ 的任何远程跟踪分支中的所有提交（您的原点没有）。

 git log master --not --remotes=*/master

显示本地主服务器中但不在任何远程存储库主分支中的所有提交。

 git log -p -m --first-parent

显示包含更改差异的历史记录，但仅显示“主分支”透视图，跳过来自合并分支的提交，并显示合并引入的完整更改差异。只有遵循严格的策略，在停留在单个集成分支上时合并所有主题分支才有意义。

 git log -L '/int main/',/^}/:main.c

显示文件main.c中的函数main()如何随时间演变。

 git log -3

将要显示的提交数限制为 3。

讨论

Git 在某种程度上是字符编码不可知的。

blob 对象的内容是未解释的字节序列。核心级别没有编码转换。
路径名以 UTF-8 规范化形式 C 编码。这适用于树对象，索引文件，ref 名称，以及命令行参数，环境变量和配置文件中的路径名（.git/config（参见 git） -config [1] ）， gitignore [5] ， gitattributes [5] 和 gitmodules [5] ）。请注意，核心级别的 Git 仅将路径名称视为非 NUL 字节序列，没有路径名称编码转换（Mac 和 Windows 除外）。因此，即使在使用传统扩展 ASCII 编码的平台和文件系统上，使用非 ASCII 路径名也会起作用。但是，在此类系统上创建的存储库将无法在基于 UTF-8 的系统（例如 Linux，Mac，Windows）上正常工作，反之亦然。此外，许多基于 Git 的工具只是假设路径名为 UTF-8，并且无法正确显示其他编码。
提交日志消息通常以 UTF-8 编码，但也支持其他扩展 ASCII 编码。这包括 ISO-8859-x，CP125x 和许多其他，但 _ 不是 _ UTF-16/32，EBCDIC 和 CJK 多字节编码（GBK，Shift-JIS，Big5，EUC-x，CP9xx 等。）。

[i18n]
	commitEncoding = ISO-8859-1

[i18n]
	logOutputEncoding = ISO-8859-1

如果您没有此配置变量，则使用i18n.commitEncoding的值。

请注意，我们故意选择在提交以在提交对象级别强制使用 UTF-8 时不重新编写提交日志消息，因为重新编码为 UTF-8 不一定是可逆操作。

组态

对于核心变量，请参见 git-config [1] ，对于差异生成，请参见 git-diff [1] 。

 format.pretty

--format选项的默认值。（参见上面的 _ 漂亮格式 _。）默认为medium。

 i18n.logOutputEncoding

显示日志时使用的编码。（参见上面的 _ 讨论 _。）如果设置，则默认为i18n.commitEncoding的值，否则为 UTF-8。

 log.date

人类可读日期的默认格式。（比较--date选项。）默认为“默认”，表示写入Sat May 8 19:35:34 2010 -0500等日期。

如果格式设置为“auto：foo”并且正在使用寻呼机，则格式“foo”将用于日期格式。否则将使用“默认”。

 log.follow

如果true，git log将像单个<路径>一样使用--follow选项。给出。这与--follow具有相同的限制，即它不能用于跟踪多个文件，并且在非线性历史记录上不能很好地工作。

 log.showRoot

如果false，git log和相关命令不会将初始提交视为大创建事件。 git log -p输出中的任何根提交都将显示没有附加差异。默认值为true。

 log.showSignature

如果true，git log和相关命令的作用就像传递了--show-signature选项一样。

 mailmap.*

见 git-shortlog [1] 。

 notes.displayRef

除了core.notesRef或GIT_NOTES_REF设置的默认值之外，还使用log系列命令显示提交消息时的注释。见 git-notes [1] 。

可以是未缩写的引用名称或 glob，可以多次指定。将为不存在的引用发出警告，但是会自动忽略与任何引用不匹配的 glob。

可以通过--no-notes选项禁用此设置，由GIT_NOTES_DISPLAY_REF环境变量覆盖，并由--notes=<ref>选项覆盖。

GIT

部分 git [1] 套件

git-shortlog

原文： git-scm.com/docs/git-shortlog

名称

git-shortlog - 汇总 git log 输出

概要

git shortlog [<options>] [<revision range>] [[--] <path>…]
git log --pretty=short | git shortlog [<options>]

描述

以适合包含在发布公告中的格式汇总 git log 输出。每个提交将按作者和标题分组。

此外，“[PATCH]”将从提交说明中删除。

如果命令行上没有传递任何修订，并且标准输入不是终端或者没有当前分支， git shortlog 将输出从标准输入读取的日志摘要，而不引用当前存储库。

OPTIONS

-n

 --numbered

根据每位作者的提交次数而不是作者字母顺序对输出进行排序。

-s

 --summary

禁止提交描述并仅提供提交计数摘要。

-e

 --email

显示每位作者的电子邮件地址。

 --format[=<format>]

而不是提交主题，使用一些其他信息来描述每个提交。 < format> 可以是 git log 的--format选项接受的任何字符串，例如 * [％h]％s 。（参见 git-log [1] 的“PRETTY FORMATS”部分。）

Each pretty-printed commit will be rewrapped before it is shown.

-c

 --committer

收集并显示提交者身份而不是作者。

 -w[<width>[,<indent1>[,<indent2>]]]

通过在width处包裹每一行来包装输出。每个条目的第一行由indent1空格缩进，第二行和后续行由indent2空格缩进。 width，indent1和indent2分别默认为 76,6 和 9。

如果 width 是0（零），则缩进输出行而不包装它们。

 <revision range>

 [--] <path>…

只考虑足以解释与指定路径匹配的文件的提交。

当出现混淆时，路径可能需要以--作为前缀，以将它们与选项或修订范围分开。

映射作者

.mailmap功能用于将短名中的同一个人合并到一起，其中他们的姓名和/或电子邮件地址拼写不同。

如果文件.mailmap存在于存储库的顶层，或者位于 mailmap.file 或 mailmap.blob 配置选项所指向的位置，则它用于将作者和提交者名称以及电子邮件地址映射到规范的真实姓名和电子邮件地址。

在简单形式中，文件中的每一行都包含作者的规范实名，空格和提交中使用的电子邮件地址（由 < 和 > 括起来）映射到名称。例如：

Proper Name <commit@email.xx>

更复杂的形式是：

<proper@email.xx> <commit@email.xx>

允许 mailmap 仅替换提交的电子邮件部分，并且：

Proper Name <proper@email.xx> <commit@email.xx>

它允许 mailmap 替换与指定的提交电子邮件地址匹配的提交的名称和电子邮件，并且：

Proper Name <proper@email.xx> Commit Name <commit@email.xx>

它允许 mailmap 替换与指定的提交名称和电子邮件地址匹配的提交的名称和电子邮件。

示例 1：您的历史记录包含两位作者 Jane 和 Joe 的提交，其名称以多种形式出现在存储库中：

Joe Developer <joe@example.com>
Joe R. Developer <joe@example.com>
Jane Doe <jane@example.com>
Jane Doe <jane@laptop.(none)>
Jane D. <jane@desktop.(none)>

现在假设 Joe 希望他的中间名最初使用，而 Jane 更喜欢她的姓氏完全拼写出来。一个合适的.mailmap文件看起来像：

Jane Doe         <jane@desktop.(none)>
Joe R. Developer <joe@example.com>

注意如何不需要<jane@laptop.(none)>的条目，因为该作者的真实姓名已经正确。

示例 2：您的存储库包含以下作者的提交：

nick1 <bugs@company.xx>
nick2 <bugs@company.xx>
nick2 <nick2@company.xx>
santa <me@company.xx>
claus <me@company.xx>
CTO <cto@coompany.xx>

然后你可能想要一个看起来像这样的.mailmap文件：

<cto@company.xx>                       <cto@coompany.xx>
Some Dude <some@dude.xx>         nick1 <bugs@company.xx>
Other Author <other@author.xx>   nick2 <bugs@company.xx>
Other Author <other@author.xx>         <nick2@company.xx>
Santa Claus <santa.claus@northpole.xx> <me@company.xx>

将哈希＃用于自己的行或电子邮件地址之后的注释。

GIT

部分 git [1] 套件

git-describe

原文： git-scm.com/docs/git-describe

名称

git-describe - 根据可用的 ref 给对象一个人类可读的名称

概要

git describe [--all] [--tags] [--contains] [--abbrev=<n>] [<commit-ish>…]
git describe [--all] [--tags] [--contains] [--abbrev=<n>] --dirty[=<mark>]
git describe <blob>

描述

该命令查找可从提交访问的最新标记。如果标记指向提交，则仅显示标记。否则，它将标记名称后缀为标记对象顶部的附加提交数和最近提交的缩写对象名称。结果是一个“人类可读”的对象名称，它也可用于标识对其他 git 命令的提交。

默认情况下（不带–all 或–tags）git describe仅显示带注释的标签。有关创建带注释标签的更多信息，请参阅 git-tag [1] 的-a 和-s 选项。

如果给定对象引用 blob，则将其描述为<commit-ish>:<path>，以便可以在<commit-ish>中的<path>处找到 blob，它本身描述了在反向修订中出现此 blob 的第一次提交从 HEAD 步行。

OPTIONS

 <commit-ish>…

要描述的 Commit-ish 对象名称。如果省略，则默认为 HEAD。

 --dirty[=<mark>]

 --broken[=<mark>]

描述工作树的状态。当工作树与 HEAD 匹配时，输出与“git describe HEAD”相同。如果工作树具有本地修改，则附加“-dirty”。如果存储库已损坏并且 Git 无法确定是否存在本地修改，则 Git 将出错，除非给出“–broken”，而后缀为“-broken”。

 --all

不要只使用带注释的标签，而是使用refs/命名空间中的任何引用。此选项可以匹配任何已知分支，远程跟踪分支或轻量级标记。

 --tags

不使用带注释的标签，而是使用refs/tags命名空间中的任何标签。此选项可以匹配轻量级（非注释）标记。

 --contains

而不是找到提交之前的标记，找到提交后出现的标记，从而包含它。自动暗示–tags。

 --abbrev=<n>

不使用默认的 7 个十六进制数字作为缩写对象名称，而是使用< n>数字，或形成唯一对象名称所需的数字。 < n> 0 将禁止长格式，仅显示最接近的标记。

 --candidates=<n>

而不是仅仅考虑 10 个最近的标签作为描述输入提交的候选者，而是考虑到< n>。候选人。增加< n>超过 10 将需要稍长但可能产生更准确的结果。 < n>为 0 将导致仅输出完全匹配。

 --exact-match

仅输出完全匹配（标记直接引用提供的提交）。这是–candidates = 0 的同义词。

 --debug

详细显示有关用于标准错误的搜索策略的信息。标签名称仍将打印到标准输出。

 --long

即使与标记匹配，也始终输出长格式（标记，提交数和缩写提交名称）。当您想要在“describe”输出中查看提交对象名称的某些部分时，这很有用，即使有问题的提交恰好是标记版本。它不会仅仅发出标记名称，而是将这样的提交描述为 v1.2-0-gdeadbee（自标记 v1.2 以来第 0 次提交指向对象 deadbee …）。

 --match <pattern>

仅考虑与给定glob(7)模式匹配的标记，不包括“refs / tags /”前缀。如果与--all一起使用，它还会考虑与模式匹配的本地分支和远程跟踪引用，分别排除“refs / heads /”和“refs / remotes /”前缀;从不考虑其他类型的参考。如果多次给出，将累积模式列表，并且将考虑匹配任何模式的标签。使用--no-match清除和重置模式列表。

 --exclude <pattern>

不要考虑与给定glob(7)模式匹配的标记，不包括“refs / tags /”前缀。如果与--all一起使用，它也不会考虑与模式匹配的本地分支和远程跟踪引用，分别排除“refs / heads /”和“refs / remotes /”前缀;从不考虑其他类型的参考。如果多次给出，则将累积模式列表，并且将排除匹配任何模式的标签。与–match 结合使用时，如果标记与至少一个匹配模式匹配且与任何–exclude 模式不匹配，则会考虑使用该标记。使用--no-exclude清除和重置模式列表。

 --always

将唯一缩写的提交对象显示为后备。

 --first-parent

在看到合并提交时，仅遵循第一个父提交。当您希望不匹配目标提交历史记录中合并的分支上的标记时，这非常有用。

例子

有了类似 git.git 当前树的东西，我得到：

[torvalds@g5 git]$ git describe parent
v1.0.4-14-g2414721

即我的“父”分支的当前头部基于 v1.0.4，但由于它上面有一些提交，因此 describe 添加了额外提交的数量（“14”）和提交的缩写对象名称本身（“2414721”）在最后。

附加提交的数量是“git log v1.0.4…parent”显示的提交数。哈希后缀是父项提示提交的“-g”+ 7-char 缩写（即2414721b194453f058079d897d13c4e377f92dc6）。 “g”前缀代表“git”，用于根据管理软件的 SCM 描述软件版本。这在人们可能使用不同 SCM 的环境中很有用。

在标签名称上执行 git describe 只会显示标签名称：

[torvalds@g5 git]$ git describe v1.0.4
v1.0.4

使用–all，该命令可以使用分支头作为引用，因此输出也显示引用路径：

[torvalds@g5 git]$ git describe --all --abbrev=4 v1.0.5²
tags/v1.0.0-21-g975b

[torvalds@g5 git]$ git describe --all --abbrev=4 HEAD^
heads/lt/describe-7-g975b

将–abbrev 设置为 0，该命令可用于查找最接近的标记名，不带任何后缀：

[torvalds@g5 git]$ git describe --abbrev=0 v1.0.5²
tags/v1.0.0

请注意，如果今天键入这些命令，您获得的后缀可能比 Linus 在运行这些命令时看到的更长，因为您的 Git 存储库可能有新的提交，其对象名称以 975b 开头，当时不存在，并且“ - g975b“单独的后缀可能不足以消除这些提交的歧义。

搜索策略

对于每个提交的提交， git describe 将首先查找标记该提交的标记。带注释的标签将始终优先于轻量级标签，具有较新日期的标签将始终优先于具有较旧日期的标签。如果找到完全匹配，将输出其名称并停止搜索。

如果未找到完全匹配， git describe 将返回提交历史记录以找到已标记的祖先提交。祖先的标记将与输入 commit-ish 的 SHA-1 的缩写一起输出。如果指定了--first-parent，则 walk 将仅考虑每个提交的第一个父级。

如果在步行期间发现多个标签，则将选择并输出具有与输入 commit-ish 不同的最少提交的标签。这里提交的最小不同定义为git log tag..input显示的提交数量将是可能的最小提交数量。

BUGS

无法描述树对象以及不指向提交的标记对象。在描述 blob 时，忽略指向 blob 的轻量级标记，但 blob 仍被描述为< committ-ish>：< path>尽管轻量级标签是有利的。

GIT

部分 git [1] 套件

git-apply

原文： git-scm.com/docs/git-apply

名称

git-apply - 将补丁应用于文件和/或索引

概要

git apply [--stat] [--numstat] [--summary] [--check] [--index | --intent-to-add] [--3way]
	  [--apply] [--no-add] [--build-fake-ancestor=<file>] [-R | --reverse]
	  [--allow-binary-replacement | --binary] [--reject] [-z]
	  [-p<n>] [-C<n>] [--inaccurate-eof] [--recount] [--cached]
	  [--ignore-space-change | --ignore-whitespace]
	  [--whitespace=(nowarn|warn|fix|error|error-all)]
	  [--exclude=<path>] [--include=<path>] [--directory=<root>]
	  [--verbose] [--unsafe-paths] [<patch>…]

描述

读取提供的 diff 输出（即“补丁”）并将其应用于文件。从存储库中的子目录运行时，将忽略目录外的修补路径。使用--index选项，补丁也会应用于索引，而使用--cached选项，补丁仅应用于索引。如果没有这些选项，该命令仅将补丁应用于文件，并且不要求它们位于 Git 存储库中。

此命令应用修补程序但不创建提交。使用 git-am [1] 从 git-format-patch [1] 生成的补丁创建提交和/或通过电子邮件接收。

OPTIONS

 <patch>…

从中读取补丁的文件。 - 可用于从标准输入读取。

 --stat

而不是应用补丁，输入 diffstat 作为输入。关闭“申请”。

 --numstat

与--stat类似，但以十进制表示法显示添加和删除的行数，不使用缩写表示路径名，以使其更加机器友好。对于二进制文件，输出两个-而不是0 0。关闭“申请”。

 --summary

而不是应用补丁，输出从 git diff 扩展头获取的信息的精简摘要，例如创建，重命名和模式更改。关闭“申请”。

 --check

而不是应用修补程序，查看修补程序是否适用于当前工作树和/或索引文件并检测错误。关闭“申请”。

 --index

当--check生效时，或者应用补丁时（默认情况下，如果没有禁用它的选项生效），请确保补丁适用于当前索引文件记录的内容。如果要在工作树中修补的文件不是最新的，则会将其标记为错误。此标志还会导致更新索引文件。

 --cached

在不触及工作树的情况下应用补丁。而是使用缓存数据，应用补丁，并将结果存储在索引中，而不使用工作树。这意味着--index。

 --intent-to-add

仅将补丁应用于工作树时，请稍后将新文件标记为添加到索引中（请参阅 git-add [1] 中的--intent-to-add选项）。除非在 Git 存储库中运行并且未指定--index，否则将忽略此选项。请注意，--index可能隐含在--cached或--3way等其他选项中。

-3

 --3way

当补丁不能干净地应用时，如果补丁记录了应该应用的 blob 的身份，则回退到三向合并，并且我们在本地可以使用这些 blob，可能会将冲突标记留在工作树中的文件中供用户解决。此选项隐含--index选项，与--reject和--cached选项不兼容。

 --build-fake-ancestor=<file>

较新的 git diff 输出为每个 blob 嵌入了 _ 索引信息 _，以帮助识别该补丁适用的原始版本。给出此标志，并且如果 Blob 的原始版本在本地可用，则构建包含这些 blob 的临时索引。

遇到纯模式更改（没有索引信息）时，将从当前索引读取信息。

-R

 --reverse

反向应用补丁。

 --reject

对于原子性，默认情况下 git apply 会使整个补丁失败，并且当某些黑客不适用时不会触及工作树。此选项使其应用适用的修补程序部分，并将拒绝的数据保留在相应的* .rej 文件中。

-z

当给出--numstat时，不要使用路径名，而是使用 NUL 终止的机器可读格式。

如果没有此选项，则会引用具有“异常”字符的路径名，如配置变量core.quotePath所述（参见 git-config [1] ）。

 -p<n>

删除< n>传统差异路径的前导路径组件（由斜线分隔）。例如，使用-p2，针对a/dir/file的补丁将直接应用于file。默认值为 1。

 -C<n>

确保至少< n>周围环境的线在每次更改之前和之后匹配。当存在较少的周围环境线时，它们都必须匹配。默认情况下，不会忽略任何上下文。

 --unidiff-zero

默认情况下， git apply 期望应用的补丁是具有至少一行上下文的统一差异。这提供了良好的安全措施，但在应用--unified=0生成的差异时会出现故障。要绕过这些检查，请使用--unidiff-zero。

请注意，由于上述原因，不鼓励使用无上下文补丁。

 --apply

如果您使用上面标记为“关闭 _ 应用 _”的任何选项， git apply 将读取并输出所请求的信息，而不实际应用该补丁。在这些标志之后给这个标志也应用补丁。

 --no-add

应用补丁时，忽略补丁所做的添加。这可用于通过首先在它们上运行 diff 并使用此选项应用结果来提取两个文件之间的公共部分，这将应用删除部分但不应用添加部分。

 --allow-binary-replacement

 --binary

从历史上看，我们不允许在没有用户明确许可的情况下应用二进制补丁，并且这个标志就是这样做的。目前我们总是允许二进制补丁应用，所以这是一个无操作。

 --exclude=<path-pattern>

不要对与给定路径模式匹配的文件应用更改。在导入要在其中排除某些文件或目录的补丁集时，这非常有用。

 --include=<path-pattern>

将更改应用于与给定路径模式匹配的文件。在导入要包含某些文件或目录的补丁集时，这非常有用。

使用--exclude和--include模式时，将按照它们在命令行中出现的顺序检查它们，第一个匹配项确定是否使用了每个路径的补丁。如果命令行上没有包含模式，则默认情况下使用与任何包含/排除模式不匹配的路径的修补程序，如果存在任何包含模式，则忽略该修补程序。

 --ignore-space-change

 --ignore-whitespace

应用修补程序时，如有必要，请忽略上下文行中的空白更改。上下文行将保留其空白，并且无论--whitespace选项的值如何，它们都不会进行空白修复。不过，新线仍将被修复。

 --whitespace=<action>

应用修补程序时，检测具有空白错误的新行或已修改行。什么被认为是空白错误由core.whitespace配置控制。默认情况下，尾随空格（包括仅由空格组成的行）和在行的初始缩进内紧跟着制表符的空格字符被视为空格错误。

默认情况下，该命令会输出警告消息，但会应用修补程序。当git-apply用于统计而不应用补丁时，默认为nowarn。

您可以使用不同的<action>值来控制此行为：

nowarn关闭尾随空白警告。
warn输出一些此类错误的警告，但按原样应用补丁（默认）。
fix输出一些此类错误的警告，并在修复它们之后应用补丁（strip是一个同义词—用于考虑仅将空白字符作为错误尾随的工具，并且修复涉及 _ 剥离 _ 他们，但现代 Gits 做得更多）。
error输出一些此类错误的警告，并拒绝应用补丁。
error-all类似于error，但显示所有错误。

 --inaccurate-eof

在某些情况下， diff 的某些版本无法在文件末尾正确检测到丢失的换行符。因此，由 diff 程序创建的补丁不能正确记录不完整的行。此选项通过解决此错误添加了对应用此类修补程序的支持。

-v

 --verbose

向 stderr 报告进度。默认情况下，仅打印有关当前正在应用的修补程序的消息。此选项将导致报告其他信息。

 --recount

不要信任 hunk 标头中的行数，而是通过检查补丁来推断它们（例如，在编辑补丁之后没有适当地调整 hunk 标头）。

 --directory=<root>

前置< root>到所有文件名。如果还传递了“-p”参数，则在添加新根之前应用它。

例如，通过运行git apply --directory=modules/git-gui，可以将关于更新a/git-gui.sh到b/git-gui.sh的补丁应用于工作树modules/git-gui/git-gui.sh中的文件。

 --unsafe-paths

默认情况下，影响工作区域外的补丁（Git 控制的工作树或当“git apply”用作 GNU 补丁的替代时的当前工作目录）被拒绝为错误（或恶作剧）。

当git apply用作“更好的 GNU 补丁”时，用户可以通过--unsafe-paths选项来覆盖此安全检查。使用--index或--cached时，此选项无效。

组态

 apply.ignoreWhitespace

如果要在默认情况下忽略空白更改，请设置为 _ 更改 _。如果您希望空格中的更改很重要，请设置为以下之一：no，none，never，false。

 apply.whitespace

如果没有从命令行给出--whitespace标志，则此配置项将用作默认值。

子模

如果补丁包含对子模块的任何更改，则 git apply 会按如下方式处理这些更改。

如果指定--index（显式或隐式），则子模块提交必须与要应用的修补程序的索引完全匹配。如果检出任何子模块，则完全忽略这些检出，即，它们不需要是最新的或清洁的，并且它们不会被更新。

如果未指定--index，则忽略补丁中的子模块提交，并且仅检查相应子目录的缺失或存在，并且（如果可能）更新。

也可以看看

git-am [1] 。

GIT

部分 git [1] 套件

git-cherry-pick

原文： git-scm.com/docs/git-cherry-pick

名称

git-cherry-pick - 应用某些现有提交引入的更改

概要

git cherry-pick [--edit] [-n] [-m parent-number] [-s] [-x] [--ff]
		  [-S[<keyid>]] <commit>…
git cherry-pick --continue
git cherry-pick --quit
git cherry-pick --abort

描述

给定一个或多个现有提交，应用每个引入的更改，为每个提交记录一个新提交。这需要您的工作树是干净的（没有 HEAD 提交的修改）。

如果不明显如何应用更改，则会发生以下情况：

当前分支和HEAD指针保持在最后一次成功提交。
CHERRY_PICK_HEAD ref 设置为指向引入难以应用的更改的提交。
干净地应用更改的路径在索引文件和工作树中都会更新。
对于冲突路径，索引文件最多可记录三个版本，如 git-merge [1] 的“TRUE MERGE”部分所述。工作树文件将包含由通常的冲突标记<<<<<<<和>>>>>>>括起来的冲突的描述。
没有进行其他修改。

有关解决此类冲突的一些提示，请参阅 git-merge [1] 。

OPTIONS

 <commit>…

承诺挑选樱桃。有关拼写提交方法的更完整列表，请参阅 gitrevisions [7] 。可以传递提交集，但默认情况下不执行遍历，就像指定了--no-walk选项一样，请参阅 git-rev-list [1] 。请注意，指定范围会将所有< commit> …参数提供给单个修订版步行（请参阅后面使用 maint master…next 的示例）。

-e

 --edit

使用此选项， git cherry-pick 将允许您在提交之前编辑提交消息。

-x

记录提交时，在原始提交消息中附加一行“（从提交中挑选出来的樱桃）”，以指示从哪个提交中挑选出这个更改。这只适用于没有冲突的樱桃选择。如果您从私人分支机构挑选，则不要使用此选项，因为该信息对收件人无用。另一方面，如果您在两个公开可见的分支之间进行挑选（例如，从开发分支向旧版本的维护分支向后端移植修复），添加此信息可能很有用。

-r

过去，命令默认执行上述-x，-r禁用它。现在默认情况下不执行-x所以此选项是无操作。

 -m parent-number

 --mainline parent-number

通常你不能挑选合并因为你不知道合并的哪一边应该被认为是主线。此选项指定主线的父编号（从 1 开始），并允许 cherry-pick 重放相对于指定父级的更改。

-n

 --no-commit

通常，该命令会自动创建一系列提交。此标志应用必要的更改来挑选您的工作树和索引的每个命名提交，而不进行任何提交。此外，使用此选项时，索引不必与 HEAD 提交匹配。樱桃选择是针对索引的开始状态完成的。

当在一行中挑选多个提交效果时，这非常有用。

-s

 --signoff

在提交消息的末尾添加 Sign-by-by 行。有关详细信息，请参阅 git-commit [1] 中的签收选项。

 -S[<keyid>]

 --gpg-sign[=<keyid>]

GPG 签名提交。 keyid参数是可选的，默认为提交者标识;如果指定，它必须粘在没有空格的选项上。

 --ff

如果当前 HEAD 与 cherry-pick’ed 提交的父级相同，则将执行此提交的快进。

 --allow-empty

在默认情况下，挑选空提交将失败，表明需要显式调用git commit --allow-empty。此选项会覆盖该行为，允许在提取中自动保留空提交。请注意，当“ - ff”生效时，即使没有此选项，也会保留满足“快进”要求的空提交。另请注意，使用此选项仅保留最初为空的提交（即提交记录与其父项相同的树）。由于先前提交而变为空的提交被删除。要强制包含这些提交，请使用--keep-redundant-commits。

 --allow-empty-message

默认情况下，使用空消息挑选提交将失败。此选项会覆盖该行为，允许提取空消息的提交。

 --keep-redundant-commits

如果提取的提交重复了当前历史记录中的提交，则它将变为空。默认情况下，这些冗余提交会导致cherry-pick停止，以便用户可以检查提交。此选项会覆盖该行为并创建一个空提交对象。意味着--allow-empty。

 --strategy=<strategy>

使用给定的合并策略。应该只使用一次。有关详细信息，请参阅 git-merge [1] 中的 MERGE STRATEGIES 部分。

 -X<option>

 --strategy-option=<option>

将合并策略特定选项传递给合并策略。有关详细信息，请参阅 git-merge [1] 。

SEQUENCER SUBCOMMANDS

 --continue

使用 .git / sequencer 中的信息继续进行中的操作。可以在解决失败的挑选或恢复中的冲突后继续使用。

 --quit

忘记当前正在进行的操作。在樱桃挑选或恢复失败后，可用于清除顺序器状态。

 --abort

取消操作并返回到预序列状态。

例子

 git cherry-pick master

应用 master 分支顶端提交引入的更改，并使用此更改创建新提交。

 git cherry-pick ..master

 git cherry-pick ^HEAD master

应用所有提交引入的更改，这些提交是 master 的祖先但不是 HEAD 的祖先，以生成新的提交。

 git cherry-pick maint next ^master

 git cherry-pick maint master..next

应用作为 maint 或 next 的祖先的所有提交所引入的更改，但不应包含 master 或其任何祖先。注意，后者并不意味着maint和master和next之间的所有内容;具体而言，如果master中包含maint，则不会使用maint。

 git cherry-pick master~4 master~2

应用 master 指向的第五个和第三个最后提交所引入的更改，并使用这些更改创建 2 个新提交。

 git cherry-pick -n master~1 next

将工作树和索引应用于 master 指向的第二个最后一次提交所引入的更改以及 next 指向的最后一个提交，但不要使用这些更改创建任何提交。

 git cherry-pick --ff ..next

如果历史是线性的并且 HEAD 是 next 的祖先，则更新工作树并使 HEAD 指针前进以匹配 next。否则，将下一个但不是 HEAD 的提交引入的更改应用于当前分支，为每个新更改创建一个新提交。

 git rev-list --reverse master -- README | git cherry-pick -n --stdin

将触及 README 的主分支上的所有提交引入的更改应用到工作树和索引，因此可以检查结果并将其作为单个新提交（如果合适）。

以下序列尝试向后移植补丁，因为补丁适用的代码已经发生了太大的变化，然后再次尝试，这次会更加关注匹配上下文行。

$ git cherry-pick topic^             (1)
$ git diff                           (2)
$ git reset --merge ORIG_HEAD        (3)
$ git cherry-pick -Xpatience topic^  (4)

应用git show topic^显示的更改。在此示例中，修补程序不能完全应用，因此有关冲突的信息将写入索引和工作树，而不会产生新的提交结果。
总结要调和的变化
取消樱桃挑选。换句话说，返回 pre-cherry-pick 状态，保留您在工作树中的任何本地修改。
尝试再次应用topic^引入的更改，花费额外的时间来避免基于错误匹配的上下文行的错误。

也可以看看

git-revert [1]

GIT

部分 git [1] 套件

git-rebase

原文： git-scm.com/docs/git-rebase

名称

git-rebase - 重新应用提交在另一个基本提示之上

概要

git rebase [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>]
	[<upstream> [<branch>]]
git rebase [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>]
	--root [<branch>]
git rebase --continue | --skip | --abort | --quit | --edit-todo | --show-current-patch

描述

如果< branch>如果指定， git rebase 将在执行任何其他操作之前执行自动git checkout <branch>。否则它仍然在当前分支上。

如果< upstream>未指定，上游在分支中配置。< name> .remote 和 branch。将使用< name> .merge 选项（详见 git-config [1] ）和--fork-point假设选项。如果您当前不在任何分支上，或者当前分支没有配置上游，则 rebase 将中止。

由当前分支中的提交进行的所有更改，但不在< upstream>中。被保存到临时区域。这是git log <upstream>..HEAD显示的同一组提交;或git log 'fork_point'..HEAD，如果--fork-point有效（参见下面--fork-point的说明）;如果指定了--root选项，则按git log HEAD。

当前分支重置为< upstream>或< newbase>如果提供了–onto 选项。这与git reset --hard <upstream>（或< newbase>）具有完全相同的效果。 ORIG_HEAD 设置为在重置之前指向分支的尖端。

之前保存到临时区域的提交将按顺序逐个重新应用于当前分支。请注意，HEAD 中的任何提交都会引入与 HEAD 中的提交相同的文本更改。< upstream>被省略（即，将跳过已经在上游接受的具有不同提交消息或时间戳的补丁）。

合并失败可能会阻止此过程完全自动化。您必须解决任何此类合并失败并运行git rebase --continue。另一种选择是绕过导致合并失败的提交git rebase --skip。要查看原始<分支>并删除.git / rebase-apply 工作文件，改为使用命令git rebase --abort。

假设存在以下历史记录，并且当前分支是“主题”：

          A---B---C topic
         /
    D---E---F---G master

从这一点来看，以下任一命令的结果：

git rebase master
git rebase master topic

将会：

                  A'--B'--C' topic
                 /
    D---E---F---G master

**注意：**后一种形式只是git checkout topic的简写，后跟git rebase master。当 rebase 退出topic时，将保留签出分支。

如果上游分支已经包含您所做的更改（例如，因为您邮寄了上游应用的补丁），那么将跳过该提交。例如，在以下历史记录中运行git rebase master（其中A'和A引入相同的更改集，但具有不同的提交者信息）：

          A---B---C topic
         /
    D---E---A'---F master

将导致：

                   B'---C' topic
                  /
    D---E---A'---F master

以下是如何将基于一个分支的主题分支移植到另一个分支，假设您使用rebase --onto从后一分支分叉主题分支。

首先让我们假设您的 _ 主题 _ 基于分支 _ 下一个 。例如， 主题 _ 中开发的功能取决于 _ 下一个 _ 中的某些功能。

    o---o---o---o---o  master
         \
          o---o---o---o---o  next
                           \
                            o---o---o  topic

我们想从分支 master 分叉 _ 主题 _;例如，因为 _ 主题 _ 所依赖的功能被合并到更稳定的 _ 主 _ 分支中。我们希望我们的树看起来像这样：

    o---o---o---o---o  master
        |            \
        |             o'--o'--o'  topic
         \
          o---o---o---o---o  next

我们可以使用以下命令获取此信息：

git rebase --onto master next topic

–onto 选项的另一个例子是重新定义分支的一部分。如果我们有以下情况：

                            H---I---J topicB
                           /
                  E---F---G  topicA
                 /
    A---B---C---D  master

那么命令

git rebase --onto master topicA topicB

会导致：

                 H'--I'--J'  topicB
                /
                | E---F---G  topicA
                |/
    A---B---C---D  master

当 topicB 不依赖于 topicA 时，这很有用。

也可以使用 rebase 删除一系列提交。如果我们有以下情况：

    E---F---G---H---I---J  topicA

那么命令

git rebase --onto topicA~5 topicA~3 topicA

会导致删除提交 F 和 G：

    E---H'---I'---J'  topicA

如果 F 和 G 在某种程度上存在缺陷，或者不应该成为 topicA 的一部分，那么这很有用。注意 - -onto 和< upstream>的参数。参数可以是任何有效的 commit-ish。

如果发生冲突， git rebase 将在第一个有问题的提交时停止，并在树中留下冲突标记。您可以使用 git diff 来定位标记（<<<<<<<<<<<<<<<<<<<<<<<<对于您编辑的每个文件，您需要告诉 Git 冲突已经解决，通常可以这样做

git add <filename>

手动解决冲突并使用所需的分辨率更新索引后，您可以继续使用

git rebase --continue

或者，您可以撤消 git rebase

git rebase --abort

组态

 rebase.useBuiltin

设置为false以使用 git-rebase [1] 的旧版 shellcript 实现。默认情况下是true，这意味着在 C 中使用内置的重写。

C 重写首先包含在 Git 版本 2.20 中。如果在重写中发现任何错误，此选项可用于重新启用旧版本。此选项和 git-rebase [1] 的 shellscript 版本将在以后的某个版本中删除。

如果您发现某些理由将此选项设置为false而非一次性测试，则应将行为差异报告为 git 中的错误。

 rebase.stat

是否显示自上次 rebase 以来上游改变的差异。默认为 False。

 rebase.autoSquash

如果设置为 true，则默认启用--autosquash选项。

 rebase.autoStash

设置为 true 时，在操作开始之前自动创建临时存储条目，并在操作结束后应用它。这意味着您可以在脏工作树上运行 rebase。但是，谨慎使用：成功重组后的最终存储应用程序可能会导致非平凡的冲突。 git-rebase [1] 的--no-autostash和--autostash选项可以覆盖此选项。默认为 false。

 rebase.missingCommitsCheck

如果设置为“warn”，git rebase -i 将在删除某些提交时打印警告（例如删除了一行），但是 rebase 仍将继续。如果设置为“error”，它将打印上一个警告并停止 rebase，然后可以使用 git rebase --edit-todo 来纠正错误。如果设置为“忽略”，则不进行检查。要在没有警告或错误的情况下删除提交，请使用待办事项列表中的drop命令。默认为“忽略”。

 rebase.instructionFormat

git-log [1] 中指定的格式字符串，用于交互式 rebase 期间的待办事项列表。格式将自动在格式之前添加长提交哈希。

 rebase.abbreviateCommands

如果设置为 true，git rebase将在待办事项列表中使用缩写的命令名称，结果如下：

	p deadbee The oneline of the commit
	p fa1afe1 The oneline of the next commit
	...

代替：

	pick deadbee The oneline of the commit
	pick fa1afe1 The oneline of the next commit
	...

默认为 false。

 rebase.rescheduleFailedExec

自动重新安排失败的exec命令。这仅在交互模式下（或提供--exec选项时）才有意义。这与指定--reschedule-failed-exec选项相同。

OPTIONS

 --onto <newbase>

创建新提交的起点。如果未指定–onto 选项，则起点为< upstream>。可以是任何有效的提交，而不仅仅是现有的分支名称。

作为特殊情况，如果只有一个合并库，则可以使用“A … B”作为 A 和 B 的合并基础的快捷方式。您最多可以省略 A 和 B 中的一个，在这种情况下，它默认为 HEAD。

 <upstream>

上游分支进行比较。可以是任何有效的提交，而不仅仅是现有的分支名称。默认为当前分支的已配置上游。

 <branch>

工作分支;默认为 HEAD。

 --continue

解决合并冲突后重新启动重定位过程。

 --abort

中止 rebase 操作并将 HEAD 重置为原始分支。如果< branch>在 rebase 操作开始时提供，然后 HEAD 将重置为< branch>。否则，HEAD 将重置为启动 rebase 操作时的位置。

 --quit

中止 rebase 操作但 HEAD 不会重置回原始分支。结果，索引和工作树也保持不变。

 --keep-empty

在结果中保留不改变其父项的任何提交。

另见下面的不兼容的选项。

 --allow-empty-message

默认情况下，使用空消息进行的 rebasing 提交将失败。此选项会覆盖该行为，允许对具有空消息的提交进行重新定位。

另见下面的不兼容的选项。

 --skip

跳过当前修补程序重新启动重定位过程。

 --edit-todo

在交互式 rebase 期间编辑待办事项列表。

 --show-current-patch

在交互式 rebase 中显示当前补丁，或者由于冲突而停止 rebase。这相当于git show REBASE_HEAD。

-m

 --merge

使用合并策略进行 rebase。当使用递归（默认）合并策略时，这允许 rebase 知道上游侧的重命名。

请注意，通过从< upstream>顶部的工作分支重放每个提交来进行 rebase 合并。科。因此，当合并冲突发生时，报告为 _ 我们的 _ 的那一方是迄今为止重新命名的系列，从< upstream>开始，而 _ 他们的 _ 是工作分支。换句话说，双方交换。

另见下面的不兼容的选项。

 -s <strategy>

 --strategy=<strategy>

使用给定的合并策略。如果没有-s选项 ，则使用 git merge-recursive 。这意味着–merge。

因为 git rebase 重放来自< upstream>顶部的工作分支的每个提交。使用给定策略的分支，使用 _ 我们的 _ 策略简单地清空< branch>中的所有补丁，这没有多大意义。

另见下面的不兼容的选项。

 -X <strategy-option>

 --strategy-option=<strategy-option>

通过< strategy-option>通过合并策略。这意味着--merge，如果没有指定策略，则-s recursive。注意 _ 我们的 _ 和的逆转，如上所述-m选项。

另见下面的不兼容的选项。

 -S[<keyid>]

 --gpg-sign[=<keyid>]

GPG 签名提交。 keyid参数是可选的，默认为提交者标识;如果指定，它必须粘在没有空格的选项上。

-q

 --quiet

安静。意味着–no-stat。

-v

 --verbose

要冗长。意味着 - 停止。

 --stat

显示自上次 rebase 以来上游更改的差异。 diffstat 也由配置选项 rebase.stat 控制。

-n

 --no-stat

不要将 diffstat 显示为 rebase 过程的一部分。

 --no-verify

此选项绕过 pre-rebase 挂钩。另见 githooks [5] 。

 --verify

允许运行 pre-rebase 挂钩，这是默认值。此选项可用于覆盖–no-verify。另见 githooks [5] 。

 -C<n>

确保至少< n>周围环境的线在每次更改之前和之后匹配。当存在较少的周围环境线时，它们都必须匹配。默认情况下，不会忽略任何上下文。

另见下面的不兼容的选项。

 --no-ff

 --force-rebase

-f

单独重放所有重新提交的提交，而不是快速转发未更改的提交。这可以确保重新分支的整个历史记录由新提交组成。

在恢复主题分支合并之后，您可能会发现这很有用，因为此选项使用新提交重新创建主题分支，因此可以成功重新合并而无需“恢复恢复”（请参阅 revert-a-faulty-merge 如何 - 详情请）。

 --fork-point

 --no-fork-point

使用 reflog 在< upstream>之间找到更好的共同祖先。和< branch>在计算由< branch>引入的提交时。

当–fork-point 激活时，将使用 fork_point 代替< upstream>计算 rebase 的提交集，其中 fork_point 是git merge-base --fork-point <upstream> <branch>命令的结果（参见 git-merge-base [1] ）。如果 fork_point 最终为空，则< upstream>将被用作后备。

如果是< upstream>或–root 在命令行中给出，则默认为--no-fork-point，否则默认为--fork-point。

 --ignore-whitespace

 --whitespace=<option>

这些标志被传递给应用补丁的 git apply 程序（参见 git-apply [1] ）。

另见下面的不兼容的选项。

 --committer-date-is-author-date

 --ignore-date

这些标志传递给 git am 以轻松更改重新提交的提交日期（参见 git-am [1] ）。

另见下面的不兼容的选项。

 --signoff

添加 Signed-off-by：预告片到所有重新提交的提交。请注意，如果给出了--interactive，那么只有标记为要挑选，编辑或重新编号的提交才会添加预告片。

另见下面的不兼容的选项。

-i

 --interactive

列出即将重新定位的提交。让用户在变基之前编辑该列表。此模式也可用于拆分提交（请参阅下面的 SPLITTING COMMITS）。

可以通过设置配置选项 rebase.instructionFormat 来更改提交列表格式。自定义指令格式将自动将长提交哈希添加到格式之前。

另见下面的不兼容的选项。

-r

 --rebase-merges[=(rebase-cousins|no-rebase-cousins)]

默认情况下，rebase 将简单地从 todo 列表中删除合并提交，并将重新提交的提交放入单个线性分支中。使用--rebase-merges，rebase 将通过重新创建合并提交来尝试保留要重新提交的提交中的分支结构。必须手动解决/重新应用这些合并提交中的任何已解决的合并冲突或手动修改。

默认情况下，或者当指定no-rebase-cousins时，没有<upstream>作为直接祖先的提交将保留其原始分支点，即 git 1 的--ancestry-path选项将被排除的提交默认情况下会保留原始血统。如果打开rebase-cousins模式，则此类提交将改为<upstream>（或<onto>，如果指定）。

--rebase-merges模式在精神上与--preserve-merges类似，但与此选项相反，在交互式 rebase 中效果很好：可以随意重新排序，插入和删除提交。

目前只能使用recursive合并策略重新创建合并提交;只能通过显式exec git merge -s <strategy> [...]命令使用不同的合并策略。

另请参见下面的“重新合并和不兼容的选项”。

-p

 --preserve-merges

通过重放合并提交引入的提交来重新创建合并提交，而不是展平历史记录。不保留合并冲突解决方案或手动修改合并提交。

这在内部使用--interactive机器，但明确地将它与--interactive选项结合使用通常不是一个好主意，除非你知道你在做什么（参见下面的 BUGS）。

另见下面的不兼容的选项。

 -x <cmd>

 --exec <cmd>

附加“exec< cmd>”在每行创建最终历史记录中的提交之后。 < CMD>将被解释为一个或多个 shell 命令。任何失败的命令都会中断 rebase，退出代码为 1。

您可以通过使用--exec的一个实例和几个命令来执行多个命令：

git rebase -i --exec "cmd1 && cmd2 && ..."

或者通过提供多个--exec：

git rebase -i --exec "cmd1" --exec "cmd2" --exec ...

如果使用--autosquash，则不会为中间提交附加“exec”行，并且只会出现在每个 squash / fixup 系列的末尾。

这在内部使用--interactive机器，但可以在没有显式--interactive的情况下运行。

另见下面的不兼容的选项。

 --root

重新引用从< branch>可到达的所有提交，而不是用< upstream>来限制它们。这允许您在树枝上重新定义根提交。与–onto 一起使用时，它将跳过< newbase>中已包含的更改（而不是< upstream>）而没有–onto 它将在每次变化时运行。当与–onto 和–preserve-merges 一起使用时，_ 所有 _ 根提交将被重写为< newbase>作为父母代替。

另见下面的不兼容的选项。

 --autosquash

 --no-autosquash

当提交日志消息以“squash！…”（或“fixup！…”）开头，并且 todo 列表中已经存在与相同...匹配的提交时，自动修改 rebase -i 的待办事项列表因此，标记为压缩的提交在修改提交之后立即生效，并将移动的提交的操作从pick更改为squash（或fixup）。如果提交主题匹配，或者...引用提交的哈希，则提交与...匹配。作为后备，提交主题的部分匹配也起作用。创建 fixup / squash 提交的推荐方法是使用 git-commit [1] 的--fixup / --squash选项。

如果使用配置变量rebase.autoSquash默认启用--autosquash选项，则此选项可用于覆盖和禁用此设置。

另见下面的不兼容的选项。

 --autostash

 --no-autostash

在操作开始之前自动创建临时存储条目，并在操作结束后应用它。这意味着您可以在脏工作树上运行 rebase。但是，谨慎使用：成功重组后的最终存储应用程序可能会导致非平凡的冲突。

 --reschedule-failed-exec

 --no-reschedule-failed-exec

自动重新安排失败的exec命令。这仅在交互模式下（或提供--exec选项时）才有意义。

不兼容的选择

以下选项：

–committer-日期是执笔者最新
- 忽略日期
–whitespace
- 忽略空白
-C

与以下选项不兼容：

- 合并
- 战略
–strategy 选项
–allow 空消息
- [无糖] autosquash
–rebase，合并
–preserve-合并
- 互动
–exec
–keep 空
–edit-待办事项
- 与–onto 组合使用时

此外，以下两对选项不兼容：

–preserve-merges 和–interactive
–preserve-merges 和–signoff
–preserve-merges 和–rebase-merges
–rebase-merges 和–strategy
–rebase-merges 和–strategy-option

行为差异

后端的行为有一些微妙的差异。

空提交

无论提交是否为空（没有相对于其父开始的更改）或结束为空（所有更改已在其他提交中上游应用），am 后端将丢弃任何“空”提交。

默认情况下，交互式后端会丢弃提交，该提交开始为空，如果命中达到空的提交，则会暂停。交互式后端存在--keep-empty选项，允许它保持空的提交。

目录重命名检测

在合并和交互式后端中启用了目录重命名启发式扫描。由于缺少准确的树信息，在后端禁用目录重命名检测。

合并战略

合并机制（git merge和git pull命令）允许使用-s选项选择后端 _ 合并策略 _。一些策略也可以采用自己的选项，可以通过向git merge和/或git pull提供-X<option>参数来传递。

 resolve

这只能使用 3 向合并算法解析两个头（即当前分支和您从中拉出的另一个分支）。它试图仔细检测纵横交错的合并模糊，并且通常被认为是安全和快速的。

 recursive

这只能使用 3 向合并算法解析两个磁头。当有多个可用于 3 向合并的共同祖先时，它会创建共同祖先的合并树，并将其用作 3 向合并的参考树。据报道，这会导致更少的合并冲突，而不会因为从 Linux 2.6 内核开发历史记录中进行的实际合并提交所做的测试而导致错误。此外，这可以检测和处理涉及重命名的合并，但目前无法使用检测到的副本。这是拉动或合并一个分支时的默认合并策略。

_ 递归 _ 策略可以采用以下选项：

 ours

这个选项通过支持 _ 我们的 _ 版本来强制冲突的帅哥干净地自动解决。来自与我们方不冲突的其他树的更改将反映到合并结果中。对于二进制文件，整个内容都来自我们这边。

这不应该与 _ 我们的 _ 合并策略混淆，后者甚至不会查看其他树包含的内容。它丢弃了另一棵树所做的一切，声明 _ 我们的 _ 历史记录中包含了所有发生的事情。

 theirs

这与 _ 我们的 _ 相反;请注意，与 _ 我们的 _ 不同，没有 _ 他们的 _ 合并策略来混淆这个合并选项。

 patience

使用此选项， merge-recursive 花费一点额外的时间来避免由于不重要的匹配行（例如，来自不同函数的大括号）而有时发生的错误。当要合并的分支发生疯狂分歧时使用此选项。另见 git-diff [1] --patience。

 diff-algorithm=[patience|minimal|histogram|myers]

告诉 merge-recursive 使用不同的 diff 算法，这有助于避免由于不重要的匹配行（例如来自不同函数的大括号）而发生的错误。另见 git-diff [1] --diff-algorithm。

 ignore-space-change

 ignore-all-space

 ignore-space-at-eol

 ignore-cr-at-eol

为了进行三向合并，将具有指示类型的空白的行更改为未更改。与空行的其他更改混合的空白更改不会被忽略。另见 git-diff [1] -b，-w，--ignore-space-at-eol和--ignore-cr-at-eol。

如果 _ 他们的 _ 版本只将空格更改引入一行，_ 我们的 _ 版本被使用;
如果 _ 我们的 _ 版本引入了空格更改，但 _ 他们的 _ 版本包含了实质性更改，_ 使用了他们的 _ 版本;
否则，合并以通常的方式进行。

 renormalize

在解析三向合并时，这将运行虚拟签出并检入文件的所有三个阶段。此选项适用于将分支与不同的清除过滤器或行尾规范化规则合并时使用。有关详细信息，请参阅 gitattributes [5] 中的“合并具有不同签入/签出属性的分支”。

 no-renormalize

禁用renormalize选项。这会覆盖merge.renormalize配置变量。

 no-renames

关闭重命名检测。这会覆盖merge.renames配置变量。另见 git-diff [1] --no-renames。

 find-renames[=<n>]

打开重命名检测，可选择设置相似性阈值。这是默认值。这会覆盖 merge.renames 配置变量。另见 git-diff [1] --find-renames。

 rename-threshold=<n>

已弃用find-renames=<n>的同义词。

 subtree[=<path>]

此选项是 _ 子树 _ 策略的更高级形式，其中策略猜测两个树在合并时必须如何移位以相互匹配。相反，指定的路径是前缀（或从头开始剥离），以使两个树的形状匹配。

 octopus

这解决了具有两个以上磁头的情况，但拒绝执行需要手动解决的复杂合并。它主要用于将主题分支头捆绑在一起。这是拉动或合并多个分支时的默认合并策略。

 ours

这会解析任意数量的头，但合并的结果树始终是当前分支头的树，实际上忽略了所有其他分支的所有更改。它旨在用于取代侧枝的旧发展历史。请注意，这与 _ 递归 _ 合并策略的-Xours 选项不同。

 subtree

这是一种修改后的递归策略。当合并树 A 和 B 时，如果 B 对应于 A 的子树，则首先调整 B 以匹配 A 的树结构，而不是读取相同级别的树。这种调整也是对共同的祖先树进行的。

使用三向合并的策略（包括默认的 _ 递归 _），如果在两个分支上进行了更改，但稍后在其中一个分支上进行了更改，则该更改将出现在合并结果中;有些人发现这种行为令人困惑。之所以会发生这种情况，是因为在执行合并时只考虑头和合并基础，而不是单个提交。因此，合并算法将恢复的更改视为完全没有更改，而是替换更改的版本。

笔记

您应该了解在共享的存储库中使用 git rebase 的含义。另请参阅下面的从上游回收中恢复。

当运行 git-rebase 命令时，它将首先执行“pre-rebase”挂钩（如果存在）。您可以使用此挂钩进行健全性检查，如果不合适则拒绝该挂钩。有关示例，请参阅模板 pre-rebase hook 脚本。

完成后，< branch>将是现在的分支。

交互模式

以交互方式重新绑定意味着您有机会编辑已重新生成的提交。您可以重新排序提交，并可以删除它们（清除坏的或其他不需要的补丁）。

交互模式适用于此类工作流程：

有个好主意
破解代码
准备一系列提交
提交

其中第 2 点由几个实例组成

a）经常使用

完成值得承诺的事情
承诺

b）独立修正

意识到某些东西不起作用
修复它
提交它

有时在 b.2 中修复了这个问题。不能修改为它修复的不太完美的提交，因为该提交深深埋藏在补丁系列中。这正是交互式 rebase 的用途：在大量的“a”和“b”之后使用它，通过重新排列和编辑提交，并将多个提交压缩成一个。

使用您要保留的最后一次提交启动它：

git rebase -i <after-this-commit>

编辑器将被激活当前分支中的所有提交（忽略合并提交），这些提交在给定的提交之后。您可以将此列表中的提交重新排序到您的内容，然后您可以删除它们。该列表看起来或多或少像这样：

pick deadbee The oneline of this commit
pick fa1afe1 The oneline of the next commit
...

在线描述纯粹是为了您的乐趣; git rebase 不会查看它们但是在提交名称（本例中为“deadbee”和“fa1afe1”），所以不要删除或编辑名称。

通过使用命令“edit”替换命令“pick”，您可以告诉 git rebase 在应用该提交后停止，以便您可以编辑文件和/或提交消息，修改提交，并继续变基。

要中断 rebase（就像“编辑”命令一样，但不首先选择任何提交），使用“break”命令。

如果您只想编辑提交的提交消息，请使用命令“reword”替换命令“pick”。

要删除提交，请将命令“pick”替换为“drop”，或者只删除匹配的行。

如果要将两个或多个提交折叠成一个，请使用“squash”或“fixup”替换第二个和后续提交的命令“pick”。如果提交具有不同的作者，则折叠的提交将归因于第一次提交的作者。折叠提交的建议提交消息是第一次提交的提交消息和具有“squash”命令的提交消息的串联，但是省略了使用“fixup”命令提交的提交消息。

git rebase 将在“pick”替换为“edit”或命令由于合并错误而失败时停止。完成编辑和/或解决冲突后，您可以继续git rebase --continue。

例如，如果要重新排序最后 5 次提交，那么 HEAD~4 的内容将成为新的 HEAD。要实现这一点，你可以像这样调用 git rebase ：

$ git rebase -i HEAD~5

并将第一个补丁移动到列表的末尾。

如果您有这样的历史记录，您可能希望保留合并：

           X
            \
         A---M---B
        /
---o---O---P---Q

假设您要将从“A”开始到“Q”的侧分支重新绑定。确保当前 HEAD 为“B”，然后调用

$ git rebase -i -p --onto Q O

重新排序和编辑提交通常会创建未经测试的中间步骤。您可能希望通过运行测试来检查历史编辑没有破坏任何内容，或者至少使用“exec”命令（快捷键“x”）在历史记录的中间点重新编译。您可以通过创建像这样的待办事项列表来实现：

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
...

当命令失败时（即退出非 0 状态），交互式 rebase 将停止，以便您有机会解决问题。您可以继续git rebase --continue。

“exec”命令在 shell 中启动命令（在SHELL中指定的命令，或者如果未设置SHELL则在默认 shell 中启动），因此您可以使用 shell 功能（如“cd”，“>”， “;”…）。该命令从工作树的根目录运行。

$ git rebase -i --exec "make test"

此命令允许您检查中间提交是否可编译。待办事项清单变得像这样：

pick 5928aea one
exec make test
pick 04d0fda two
exec make test
pick ba46169 three
exec make test
pick f4593f9 four
exec make test

分裂委员会

在交互模式下，您可以使用“编辑”操作标记提交。但是，这并不一定意味着 git rebase 希望此编辑的结果恰好是一次提交。实际上，您可以撤消提交，也可以添加其他提交。这可以用于将提交拆分为两个：

使用git rebase -i <commit>^启动交互式 rebase，其中< commit>是您要拆分的提交。实际上，只要包含该提交，任何提交范围都可以。
使用“编辑”操作标记要拆分的提交。
编辑提交时，执行git reset HEAD^。结果是 HEAD 被一个重绕，索引也随之而来。但是，工作树保持不变。
现在将更改添加到您希望在第一次提交中拥有的索引。您可以使用git add（可能是交互式）或 git gui （或两者）来做到这一点。
使用现在适当的提交消息提交 now-current 索引。
重复最后两步，直到工作树干净。
使用git rebase --continue继续变基。

如果您不完全确定中间修订版是否一致（它们是编译的，通过测试套件等），您应该使用 git stash 来隐藏每次提交，测试后尚未提交的更改，如果需要修复，则修改提交。

从 UPSTREAM REBASE 恢复

重新定位（或任何其他形式的重写）其他人基于其工作的分支是一个坏主意：它下游的任何人都被迫手动修复其历史记录。本节介绍如何从下游的角度进行修复。然而，真正的解决方法是首先避免重新定位上游。

为了说明，假设您处于某人开发 _ 子系统 _ 分支的情况，并且您正在处理依赖于此 _ 子系统 _ 的 _ 主题 _。您最终可能会得到如下历史记录：

    o---o---o---o---o---o---o---o  master
	 \
	  o---o---o---o---o  subsystem
			   \
			    *---*---*  topic

如果 _ 子系统 _ 针对 master 进行了重新设置，则会发生以下情况：

    o---o---o---o---o---o---o---o  master
	 \			 \
	  o---o---o---o---o	  o'--o'--o'--o'--o'  subsystem
			   \
			    *---*---*  topic

如果你现在像往常一样继续开发，并最终将 _ 主题 _ 合并到 _ 子系统 _，那么来自 _ 子系统 _ 的提交将永远保持重复：

    o---o---o---o---o---o---o---o  master
	 \			 \
	  o---o---o---o---o	  o'--o'--o'--o'--o'--M	 subsystem
			   \			     /
			    *---*---*-..........-*--*  topic

这样的副本通常是不受欢迎的，因为它们使历史变得混乱，使得更难以遵循。为了清理，您需要将 _ 主题 _ 上的提交移植到新的 _ 子系统 _ 提示，即 rebase _ 主题 。这会产生涟漪效应： 主题 _ 下游的任何人也被迫改变，依此类推！

有两种修复方法，将在以下小节中讨论：

 Easy case: The changes are literally the same.

如果 _ 子系统 _ rebase 是一个简单的 rebase 并且没有冲突，就会发生这种情况。

 Hard case: The changes are not the same.

如果 _ 子系统 _ rebase 发生冲突，或使用--interactive省略，编辑，压缩或修复提交，则会发生这种情况;或者如果上游使用commit --amend，reset或filter-branch中的一个。

容易的情况

仅在 _ 子系统 _ 上的更改（基于差异内容的修补程序 ID）在 rebase _ 子系统 _ 之前和之后的字面上相同时才有效。

在这种情况下，修复很容易，因为 git rebase 知道跳过已经存在于新上游的更改。所以，如果你说（假设你在 _ 话题 _）

    $ git rebase subsystem

你将最终得到固定的历史

    o---o---o---o---o---o---o---o  master
				 \
				  o'--o'--o'--o'--o'  subsystem
						   \
						    *---*---*  topic

艰难的案例

如果 _ 子系统 _ 更改与 rebase 之前的更改不完全相符，事情会变得更复杂。

| 注意 | 虽然即使在困难的情况下，“简单案件恢复”有时似乎也是成功的，但它可能会产生意想不到的后果。例如，通过git rebase --interactive删除的提交将复活！ |

我的想法是手动告诉 git rebase “旧的 _ 子系统 _ 结束，你的 _ 主题 _ 开始了”，也就是说，他们之间的旧合并基础是什么。您必须找到一种方法来命名旧 _ 子系统 _ 的最后一次提交，例如：

使用 _ 子系统 _ reflog：在 git fetch 之后，_ 子系统 _ 的旧提示位于subsystem@{1}。随后的提取将增加数量。（参见 git-reflog [1] 。）
相对于 _ 主题 _ 的提示：知道你的 _ 主题 _ 有三次提交，_ 子系统 _ 的旧提示必须是topic~3。

然后，您可以通过说（对于 reflog 案例，假设您已经在 _ 主题 _ 上）将旧的subsystem..topic移植到新的提示：

    $ git rebase --onto subsystem subsystem@{1}

“硬案例”恢复的连锁反应特别糟糕： __ 主题 _ 下游的所有人 _ 现在也必须执行“硬案例”恢复！

重新合并

交互式 rebase 命令最初设计用于处理单个补丁系列。因此，从 todo 列表中排除合并提交是有意义的，因为开发人员可能在处理分支时合并当时的master，只是最终将所有提交重新绑定到master上（跳过合并提交））。

但是，开发人员可能想要重新创建合并提交的正当理由是：在处理多个相互关联的分支时保留分支结构（或“提交拓扑”）。

在下面的示例中，开发人员处理主题分支，该分支重构按钮的定义方式，以及使用该重构实现“报告错误”按钮的另一个主题分支。 git log --graph --format=%s -5的输出可能如下所示：

*   Merge branch 'report-a-bug'
|\
| * Add the feedback button
* | Merge branch 'refactor-button'
|\ \
| |/
| * Use the Button class for all buttons
| * Extract a generic Button class from the DownloadButton one

开发人员可能希望在保留分支拓扑的同时将这些提交重新绑定到较新的master，例如，当第一个主题分支预期比第二个主题分支更早地集成到master中时，比如解决与更改为使其成为master的 DownloadButton 类。

可以使用--rebase-merges选项执行此 rebase。它将生成一个如下所示的待办事项列表：

label onto

# 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

# Branch: report-a-bug
reset refactor-button # Use the Button class for all buttons
pick abcdef Add the feedback button
label report-a-bug

reset onto
merge -C a1b2c3 refactor-button # Merge 'refactor-button'
merge -C 6f5e4d report-a-bug # Merge 'report-a-bug'

与常规交互式 rebase 相比，除pick之外还有label，reset和merge命令。

执行该命令时，label命令将标签与当前 HEAD 相关联。这些标签创建为 worktree-local refs（refs/rewritten/<label>），将在 rebase 完成时删除。这样，链接到同一存储库的多个工作树中的 rebase 操作不会相互干扰。如果label命令失败，则立即重新安排，并提供有用的消息如何继续。

reset命令将 HEAD，索引和工作树重置为指定的修订版。它类似于exec git reset --hard <label>，但拒绝覆盖未跟踪的文件。如果reset命令失败，则会立即重新安排，并提供一条有用的消息，说明如何编辑待办事项列表（这通常在手动将reset命令插入待办事项列表并包含拼写错误时发生）。

merge命令会将指定的修订版合并到当时的 HEAD 中。使用-C <original-commit>，将使用指定合并提交的提交消息。当-C更改为小写-c时，成功合并后将在编辑器中打开该消息，以便用户可以编辑该消息。

如果merge命令因合并冲突以外的任何原因而失败（即合并操作甚至没有开始），则立即重新安排。

此时，merge命令将始终使用recursive合并策略进行常规合并，而octopus用于章鱼合并，无法选择不同的合并策略。要解决这个问题，可以使用exec命令显式调用git merge，使用标签是 worktree-local refs 的事实（例如，ref refs/rewritten/onto将对应于标签onto）。

注意：第一个命令（label onto）标记提交重新定位的修订版本;名称onto只是一个约定，作为--onto选项的点头。

也可以通过添加merge <merge-head>形式的命令从头开始引入全新的合并提交。此表单将生成暂定的提交消息，并始终打开编辑器以允许用户编辑它。这可能是有用的，例如当一个主题分支最终解决一个以上的问题，并希望分成两个甚至更多的主题分支。考虑这个待办事项列表：

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

此列表中与 CMake 无关的一个提交很可能是通过修复切换到 CMake 引入的所有错误来实现的，但它解决了一个不同的问题。要将此分支拆分为两个主题分支，可以像下面这样编辑待办事项列表：

label onto

pick afbecd http: add support for TLS v1.3
label tlsv1.3

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

reset onto
merge tlsv1.3
merge cmake