英语 ▾ 主题 ▾ 最新版本 ▾ git-filter-branch 上次更新于 2.44.0

名称

git-filter-branch - 重写分支

概要

git filter-branch [--setup <command>] [--subdirectory-filter <directory>]
	[--env-filter <command>] [--tree-filter <command>]
	[--index-filter <command>] [--parent-filter <command>]
	[--msg-filter <command>] [--commit-filter <command>]
	[--tag-name-filter <command>] [--prune-empty]
	[--original <namespace>] [-d <directory>] [-f | --force]
	[--state-branch <branch>] [--] [<rev-list-options>…​]

警告

git filter-branch 有许多缺陷，可能导致对预期历史记录重写的非显式损坏（并且由于其糟糕的性能，您可能没有时间调查这些问题）。 这些安全和性能问题无法向后兼容地修复，因此不建议使用。 请使用替代的历史记录过滤工具，例如 git filter-repo。 如果您仍然需要使用 git filter-branch，请仔细阅读 SAFETY（和 PERFORMANCE）以了解 filter-branch 的地雷，然后尽量避免其中列出的尽可能多的危害。

描述

允许您通过重写 <rev-list-options> 中提到的分支来重写 Git 修订历史记录，对每个修订应用自定义过滤器。 这些过滤器可以修改每个树（例如，删除文件或在所有文件上运行 perl 重写）或有关每个提交的信息。 否则，所有信息（包括原始提交时间或合并信息）都将被保留。

该命令将仅重写命令行中提到的正引用（例如，如果您传递 a..b，则仅 b 将被重写）。 如果您不指定任何过滤器，则提交将被重新提交而没有任何更改，这通常不会产生任何影响。 然而，这可能在将来用于补偿某些 Git 错误或类似情况，因此允许这种用法。

注意：此命令遵循 .git/info/grafts 文件和 refs/replace/ 命名空间中的引用。 如果您有任何 graft 或替换引用定义，运行此命令将使其永久生效。

警告！ 重写的历史记录将为所有对象使用不同的对象名称，并且不会与原始分支收敛。 您将无法轻松地在原始分支之上推送和分发重写的分支。 如果您不了解全部含义，请不要使用此命令，并且如果简单的单次提交足以解决您的问题，请避免使用它。（有关重写已发布历史记录的更多信息，请参见 git-rebase[1] 中的“从上游变基恢复”部分。）

始终验证重写的版本是否正确：如果与重写的版本不同，原始引用将存储在命名空间 refs/original/ 中。

请注意，由于此操作非常占用 I/O，因此最好使用 -d 选项将临时目录重定向到磁盘外，例如在 tmpfs 上。 据报道，速度提升非常明显。

过滤器

过滤器按下面列出的顺序应用。 <command> 参数始终在 shell 上下文中通过 eval 命令进行评估（除了提交过滤器，由于技术原因，这是一个值得注意的例外）。 在此之前，$GIT_COMMIT 环境变量将被设置为包含正在重写的提交的 id。 此外，GIT_AUTHOR_NAME、GIT_AUTHOR_EMAIL、GIT_AUTHOR_DATE、GIT_COMMITTER_NAME、GIT_COMMITTER_EMAIL 和 GIT_COMMITTER_DATE 取自当前提交并导出到环境中，以便影响由 git-commit-tree[1] 在过滤器运行后创建的替换提交的作者和提交者身份。

如果任何 <command> 的评估返回非零退出状态，则整个操作将被中止。

有一个 map 函数可用，它接受一个“原始 sha1 id”参数，如果提交已被重写，则输出一个“重写的 sha1 id”，否则输出“原始 sha1 id”； 如果您的提交过滤器发出了多个提交，则 map 函数可以在单独的行上返回多个 id。

选项

--setup <command>

这不是为每个提交执行的真实过滤器，而是在循环之前的一次性设置。 因此，尚未定义任何特定于提交的变量。 在这里定义的函数或变量可以在以下过滤器步骤中使用或修改，除了提交过滤器，由于技术原因。

--subdirectory-filter <directory>

仅查看涉及给定子目录的历史记录。 结果将包含该目录（并且仅包含该目录）作为其项目根目录。 意味着 重映射到祖先。

--env-filter <command>

如果您只需要修改将执行提交的环境，则可以使用此过滤器。 具体来说，您可能想要重写作者/提交者名称/电子邮件/时间环境变量（有关详细信息，请参见 git-commit-tree[1]）。

--tree-filter <command>

这是用于重写树及其内容的过滤器。 参数在 shell 中进行评估，工作目录设置为检出树的根目录。 然后按原样使用新树（新文件会自动添加，消失的文件会自动删除 - .gitignore 文件和任何其他忽略规则没有任何效果！）。

--index-filter <command>

这是用于重写索引的过滤器。 它类似于树过滤器，但不检查树，这使其速度更快。 经常与 git rm --cached --ignore-unmatch ... 一起使用，请参见下面的示例。 对于复杂的情况，请参见 git-update-index[1]。

--parent-filter <command>

这是用于重写提交的父列表的过滤器。 它将在 stdin 上接收父字符串，并在 stdout 上输出新的父字符串。 父字符串的格式如 git-commit-tree[1] 中所述：对于初始提交为空，对于普通提交为 "-p parent"，对于合并提交为 "-p parent1 -p parent2 -p parent3 …​"。

--msg-filter <command>

这是用于重写提交消息的过滤器。 参数在 shell 中进行评估，原始提交消息在标准输入上； 其标准输出用作新的提交消息。

--commit-filter <command>

这是用于执行提交的过滤器。 如果指定了此过滤器，则将调用它来代替 git commit-tree 命令，参数形式为“<TREE_ID> [(-p <PARENT_COMMIT_ID>)…​]”，日志消息在 stdin 上。 提交 id 应在 stdout 上。

作为一种特殊扩展，提交过滤器可以发出多个提交 id； 在这种情况下，原始提交的重写子项将把它们全部作为父项。

您可以在此过滤器中使用 map 便捷函数，以及其他便捷函数。 例如，调用 skip_commit "$@" 将省略当前提交（但不是其更改！如果您想要这样做，请改用 git rebase）。

如果您不希望保留具有单个父项且未对树进行任何更改的提交，您也可以使用 git_commit_non_empty_tree "$@" 而不是 git commit-tree "$@"。

--tag-name-filter <command>

这是用于重写标签名称的过滤器。 传递后，将为指向重写对象（或指向指向重写对象的标签对象）的每个标签引用调用它。 原始标签名称通过标准输入传递，新的标签名称应在标准输出上。

原始标签不会被删除，但可以被覆盖； 使用 "--tag-name-filter cat" 只是为了更新标签。 在这种情况下，请非常小心，并确保您已备份旧标签，以防转换出现问题。

支持几乎正确的标签对象重写。 如果标签附加了消息，则将使用相同的消息、作者和时间戳创建一个新的标签对象。 如果标签附加了签名，则该签名将被删除。 根据定义，不可能保留签名。之所以说它是“几乎”正确的，是因为理想情况下，如果标签没有更改（指向同一对象、具有相同的名称等），它应该保留任何签名。 事实并非如此，签名将始终被删除，请购买者注意。 也不支持更改作者或时间戳（或标签消息）。 指向其他标签的标签将被重写为指向底层提交。

--prune-empty

一些过滤器会生成空的提交，不会改变树的状态。这个选项指示 git-filter-branch 移除这些提交，如果它们只有一个或零个未修剪的父提交；合并提交将会保持不变。这个选项不能和 --commit-filter 一起使用，尽管可以通过在提交过滤器中使用提供的 git_commit_non_empty_tree 函数来实现同样的效果。

--original <namespace>

使用此选项设置原始提交将被存储的命名空间。默认值是 refs/original。

-d <directory>

使用此选项设置用于重写的临时目录的路径。当应用树过滤器时，该命令需要临时检出树到某个目录，这在大型项目中可能会消耗相当多的空间。默认情况下，它在 .git-rewrite/ 目录中执行此操作，但您可以通过此参数覆盖该选择。

-f
--force

除非强制执行，否则 git filter-branch 拒绝使用现有的临时目录或当已经存在以 refs/original/ 开头的引用时启动。

--state-branch <branch>

此选项将导致从指定分支加载旧对象到新对象的映射，并在退出时保存为该分支上的新提交，从而实现大型树的增量处理。如果 <branch> 不存在，它将被创建。

<rev-list options>…​

git rev-list 的参数。所有通过这些选项包含的正引用都会被重写。您也可以指定诸如 --all 之类的选项，但您必须使用 -- 将它们与 git filter-branch 选项分开。暗示 重映射到祖先。

重映射到祖先

通过使用 git-rev-list[1] 参数，例如路径限制器，您可以限制被重写的修订集的范围。但是，命令行上的正引用是不同的：我们不允许它们被这些限制器排除。为此，它们会被重写为指向最近的未被排除的祖先。

退出状态

如果成功，退出状态是 0。如果过滤器找不到任何要重写的提交，退出状态是 2。在任何其他错误时，退出状态可能是任何其他非零值。

示例

假设您想从所有提交中删除一个文件（包含机密信息或版权侵犯）

git filter-branch --tree-filter 'rm filename' HEAD

但是，如果该文件在某些提交的树中不存在，则简单的 rm filename 将在该树和提交中失败。因此，您可能想改用 rm -f filename 作为脚本。

使用 --index-filter 与 git rm 结合使用会产生一个明显更快的版本。与使用 rm filename 类似，如果该文件在提交的树中不存在，git rm --cached filename 将会失败。如果您想“完全忘记”一个文件，它何时进入历史并不重要，所以我们还添加 --ignore-unmatch

git filter-branch --index-filter 'git rm --cached --ignore-unmatch filename' HEAD

现在，您将获得保存在 HEAD 中的重写历史记录。

要重写存储库，使其看起来好像 foodir/ 是它的项目根目录，并丢弃所有其他历史记录

git filter-branch --subdirectory-filter foodir -- --all

因此，您可以将例如库子目录转换为它自己的存储库。请注意分隔 filter-branch 选项与修订选项的 --，以及重写所有分支和标签的 --all。

要设置一个提交（通常位于另一个历史记录的顶端）作为当前初始提交的父提交，以便将另一个历史记录粘贴到当前历史记录之后

git filter-branch --parent-filter 'sed "s/^\$/-p <graft-id>/"' HEAD

（如果父字符串为空 - 当我们处理初始提交时会发生这种情况 - 则添加 graftcommit 作为父提交）。请注意，这假设历史记录具有单个根（即，没有发生没有共同祖先的合并）。如果不是这种情况，请使用

git filter-branch --parent-filter \
	'test $GIT_COMMIT = <commit-id> && echo "-p <graft-id>" || cat' HEAD

或者更简单

git replace --graft $commit-id $graft-id
git filter-branch $graft-id..HEAD

要从历史记录中删除由 "Darl McBribe" 提交的提交

git filter-branch --commit-filter '
	if [ "$GIT_AUTHOR_NAME" = "Darl McBribe" ];
	then
		skip_commit "$@";
	else
		git commit-tree "$@";
	fi' HEAD

函数 skip_commit 定义如下

skip_commit()
{
	shift;
	while [ -n "$1" ];
	do
		shift;
		map "$1";
		shift;
	done;
}

shift magic 首先丢弃树 id，然后丢弃 -p 参数。请注意，这会正确处理合并！如果 Darl 提交了 P1 和 P2 之间的合并，它将正确传播，并且合并的所有子提交都将成为以 P1,P2 作为其父提交而不是合并提交的合并提交。

注意 提交引入的更改，以及未被后续提交恢复的更改，仍将存在于重写的分支中。如果您想同时丢弃 更改 以及提交，您应该使用 git rebase 的交互模式。

您可以使用 --msg-filter 重写提交日志消息。例如，可以通过这种方式删除由 git svn 创建的存储库中的 git svn-id 字符串

git filter-branch --msg-filter '
	sed -e "/^git-svn-id:/d"
'

如果您需要向例如最近 10 个提交（没有一个是合并）添加 Acked-by 行，请使用此命令

git filter-branch --msg-filter '
	cat &&
	echo "Acked-by: Bugs Bunny <bunny@bugzilla.org>"
' HEAD~10..HEAD

--env-filter 选项可用于修改提交者和/或作者身份。例如，如果您发现由于错误配置的 user.email 导致您的提交具有错误的身份，您可以在发布项目之前进行更正，如下所示

git filter-branch --env-filter '
	if test "$GIT_AUTHOR_EMAIL" = "root@localhost"
	then
		GIT_AUTHOR_EMAIL=john@example.com
	fi
	if test "$GIT_COMMITTER_EMAIL" = "root@localhost"
	then
		GIT_COMMITTER_EMAIL=john@example.com
	fi
' -- --all

要限制重写仅限于历史记录的一部分，除了新分支名称之外，还需要指定一个修订范围。新的分支名称将指向此范围的 git rev-list 将打印的最顶层修订。

考虑一下这个历史

     D--E--F--G--H
    /     /
A--B-----C

要仅重写提交 D,E,F,G,H，但保持 A、B 和 C 不变，请使用

git filter-branch ... C..H

要重写提交 E,F,G,H，请使用以下方式之一

git filter-branch ... C..H --not D
git filter-branch ... D..H --not C

要将整个树移动到子目录中，或从中删除它

git filter-branch --index-filter \
	'git ls-files -s | sed "s-\t\"*-&newsubdir/-" |
		GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
			git update-index --index-info &&
	 mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"' HEAD

缩小存储库的清单

git-filter-branch 可以用于摆脱文件的一个子集，通常与 --index-filter 和 --subdirectory-filter 的某种组合一起使用。人们期望生成的存储库小于原始存储库，但您需要更多步骤才能实际使其更小，因为 Git 会尽力不丢失您的对象，直到您告诉它这样做。首先确保

  • 您确实删除了文件名的所有变体，如果一个 blob 在其生命周期内被移动过。git log --name-only --follow --all -- filename 可以帮助您找到重命名。

  • 您确实过滤了所有引用：调用 git-filter-branch 时使用 --tag-name-filter cat -- --all。

然后有两种方法可以获得更小的存储库。更安全的方法是克隆，它可以使您的原始存储库保持不变。

  • 使用 git clone file:///path/to/repo 克隆它。克隆将不包含删除的对象。请参见 git-clone[1]。（请注意，使用纯路径克隆只会硬链接所有内容！）

如果您真的不想克隆它，无论出于何种原因，请检查以下几点（按此顺序）。这是一种非常具有破坏性的方法，因此进行备份或返回到克隆它。您已被警告。

  • 删除 git-filter-branch 备份的原始引用：例如 git for-each-ref --format="%(refname)" refs/original/ | xargs -n 1 git update-ref -d。

  • 使用 git reflog expire --expire=now --all 使所有 reflog 过期。

  • 使用 git gc --prune=now 垃圾回收所有未引用的对象（或者如果您的 git-gc 不够新，无法支持 --prune 的参数，请改用 git repack -ad; git prune）。

性能

git-filter-branch 的性能非常慢；它的设计使得一个向后兼容的实现永远不可能快速

  • 在编辑文件时，git-filter-branch 通过设计会检出原始存储库中存在的每个提交。如果您的存储库有 10^5 个文件和 10^5 个提交，但每个提交只修改五个文件，那么 git-filter-branch 会让您执行 10^10 个修改，尽管只有（最多）5*10^5 个唯一 blob。

  • 如果您试图作弊并尝试使 git-filter-branch 仅适用于在提交中修改的文件，那么会发生两件事

    • 当用户只是试图重命名文件时，您会遇到删除问题（因为尝试删除不存在的文件看起来像一个空操作；当重命名通过任意用户提供的 shell 发生时，需要一些诡计来跨文件重命名映射删除）

    • 即使您成功地实现了 map-deletes-for-renames 诡计，您仍然在技术上违反了向后兼容性，因为允许用户以依赖于提交拓扑的方式过滤文件，而不是仅仅基于文件内容或名称进行过滤（尽管这在野外没有观察到）。

  • 即使您不需要编辑文件，而只想例如重命名或删除一些文件，因此可以避免检出每个文件（即，您可以使用 --index-filter），您仍然传递 shell 代码段以进行过滤。这意味着对于每个提交，您都必须准备一个 git 存储库，以便可以在其中运行这些过滤器。这是一个重要的设置。

  • 此外，git-filter-branch 还会为每个提交创建或更新几个附加文件。其中一些文件用于支持 git-filter-branch 提供的便利函数（例如 map()），而另一些文件用于跟踪内部状态（但也可能被用户过滤器访问；git-filter-branch 的一个回归测试就是这样做的）。这实际上相当于使用文件系统作为 git-filter-branch 和用户提供的过滤器之间的 IPC 机制。磁盘往往是一种缓慢的 IPC 机制，并且写入这些文件也有效地表示我们在每个提交中都命中的独立进程之间的强制同步点。

  • 用户提供的 shell 命令很可能涉及命令管道，从而导致每个提交创建许多进程。在操作系统之间，创建和运行另一个进程所花费的时间差异很大，但在任何平台上，相对于调用函数而言，它都非常慢。

  • git-filter-branch 本身是用 shell 编写的，速度较慢。这是唯一可以向后兼容地修复的性能问题，但与 git-filter-branch 设计中固有的上述问题相比，工具本身的语言是一个相对较小的问题。

    • 题外话：不幸的是，人们往往专注于用 shell 编写的方面，并经常询问是否可以用另一种语言重写 git-filter-branch 以解决性能问题。这不仅忽略了设计中更大的内在问题，而且帮助会比你想象的要少：如果 git-filter-branch 本身不是 shell，那么便利函数（map()、skip_commit() 等）和 --setup 参数将不能再在程序开始时执行一次，而是需要添加到每个用户过滤器的前面（因此每次提交时重新执行）。

git filter-repo 工具是 git-filter-branch 的替代方案，它不会受到这些性能问题或安全问题（如下所述）的影响。对于那些依赖 git-filter-branch 的现有工具，git filter-repo 还提供了 filter-lamely，一个即插即用的 git-filter-branch 替代品（有一些注意事项）。虽然 filter-lamely 遭受与 git-filter-branch 相同的所有安全问题，但它至少可以稍微缓解性能问题。

安全

git-filter-branch 充满了陷阱，导致各种容易损坏仓库或最终得到比你开始时更糟糕的混乱的方法

  • 有人可能有一组“工作和测试过的过滤器”，他们记录或提供给同事，然后同事在不同的操作系统上运行它们，而相同的命令无法工作/测试（git-filter-branch 手册页中的一些示例也受到此影响）。BSD 与 GNU 用户空间的差异可能会带来麻烦。如果幸运的话，会喷出错误消息。但同样有可能的是，命令要么不执行所请求的过滤，要么通过进行一些不希望的更改来静默地损坏。不希望的更改可能只会影响少数提交，因此也不一定很明显。（问题不一定很明显这一事实意味着它们很可能在重写后的历史记录使用很长一段时间后才会被注意到，到那时，很难证明为了另一次重写而进行另一个标记日是合理的。）

  • 带有空格的文件名经常被 shell 片段错误处理，因为它们会给 shell 管道带来问题。并非每个人都熟悉 find -print0、xargs -0、git-ls-files -z 等。即使是那些熟悉这些的人也可能认为这些标志不相关，因为在进行过滤的人加入项目之前，其他人已经重命名了他们仓库中的任何此类文件。而且，通常，即使是那些熟悉处理带有空格的参数的人也可能不会这样做，只是因为他们没有考虑到所有可能出错的事情。

  • 非 ASCII 文件名可能会被静默删除，即使它们位于所需的目录中。通常使用诸如 git ls-files | grep -v ^WANTED_DIR/ | xargs git rm 之类的管道来仅保留想要的路径。ls-files 仅在需要时才引用文件名，因此人们可能不会注意到其中一个文件与正则表达式不匹配（至少在为时已晚之前）。是的，知道 core.quotePath 的人可以避免这种情况（除非他们有其他特殊字符，例如 \t、\n 或 "），并且使用 ls-files -z 和 grep 以外的其他东西的人可以避免这种情况，但这并不意味着他们会这样做。

  • 同样，在移动文件时，人们会发现带有非 ASCII 或特殊字符的文件名最终会出现在不同的目录中，该目录包含双引号字符。（这在技术上与上面的引用问题相同，但可能是一个有趣的不同方式，它可以并且已经表现为问题。）

  • 很容易意外地混合新旧历史。使用任何工具仍然是可能的，但 git-filter-branch 几乎邀请它。如果幸运的话，唯一的缺点是用户感到沮丧，因为他们不知道如何缩小他们的仓库并删除旧内容。如果不幸的是，他们合并了新旧历史记录，最终得到了每个提交的多个“副本”，其中一些副本具有不希望的或敏感的文件，而另一些副本则没有。这以多种不同的方式发生

    • 默认只进行部分历史重写（--all 不是默认值，很少有示例显示它）

    • 事实上，没有自动的运行后清理

    • --tag-name-filter（用于重命名标签时）的事实是它不会删除旧标签，而是只添加带有新名称的新标签

    • 事实上，没有提供多少教育信息来告知用户重写的后果以及如何避免混合新旧历史记录。例如，此手册页讨论了用户需要理解他们需要将所有分支上的更改变基到新历史记录之上（或删除并重新克隆），但这只是需要考虑的多个问题之一。有关更多详细信息，请参见 git filter-repo 手册页的“讨论”部分。

  • 由于以下两个问题中的任何一个，带注释的标签可能会意外地转换为轻量级标签

    • 有人可以进行历史重写，意识到他们搞砸了，从 refs/original/ 中的备份恢复，然后重新执行他们的 git-filter-branch 命令。（refs/original/ 中的备份不是真正的备份；它首先取消引用标签。）

    • 在你的 <rev-list-options> 中使用 --tags 或 --all 运行 git-filter-branch。为了将带注释的标签保留为带注释的标签，你必须使用 --tag-name-filter（并且必须没有在先前搞砸的重写中从 refs/original/ 恢复）。

  • 任何指定编码的提交消息都将被重写损坏；git-filter-branch 忽略编码，获取原始字节，并将其提供给 commit-tree，而不告诉它正确的编码。（无论是否使用 --msg-filter，都会发生这种情况。）

  • 提交消息（即使它们都是 UTF-8）默认情况下会被损坏，因为它们没有更新 — 提交消息中对其他提交哈希的任何引用现在都将引用不再存在的提交。

  • 没有设施来帮助用户找到他们应该删除的哪些不需要的垃圾，这意味着他们更有可能进行不完整或部分清理，这有时会导致混乱，人们浪费时间试图理解。（例如，人们倾向于只寻找要删除的大文件，而不是大目录或扩展名，一旦他们这样做，那么以后使用新存储库的人，他们正在浏览历史记录时会注意到一个构建工件目录，其中包含一些文件但没有其他文件，或者一个依赖项缓存（node_modules 或类似物），它可能永远无法运行，因为它缺少一些文件。）

  • 如果未指定 --prune-empty，那么过滤过程可能会创建大量令人困惑的空提交

  • 如果指定了 --prune-empty，那么在过滤操作之前有意放置的空提交也会被修剪掉，而不仅仅是修剪由于过滤规则而变为空的提交。

  • 如果指定了 --prune-empty，有时会错过空提交并将其遗留下来（一个有点罕见的错误，但它确实会发生…​）

  • 一个小问题，但目标是更新存储库中所有名称和电子邮件的用户可能会被引导到 --env-filter，它只会更新作者和提交者，而遗漏了标记者。

  • 如果用户提供了一个 --tag-name-filter，该过滤器将多个标签映射到同一名称，则不会提供任何警告或错误；git-filter-branch 只是以某种未记录的预定义顺序覆盖每个标签，最终只留下一个标签。（git-filter-branch 回归测试需要这种令人惊讶的行为。）

此外，git-filter-branch 的性能不佳通常会导致安全问题

  • 想出正确的 shell 片段来执行你想要的过滤有时很困难，除非你只是做一些简单的修改，例如删除几个文件。不幸的是，人们通常通过试用来了解片段是否正确，但正确与否可能因特殊情况而异（文件名中的空格、非 ASCII 文件名、有趣的作者姓名或电子邮件、无效的时区、grafts 或 replace 对象的存在等），这意味着他们可能必须等待很长时间，遇到错误，然后重新启动。git-filter-branch 的性能非常糟糕，以至于这个周期令人痛苦，减少了仔细重新检查的可用时间（更不用说它对正在进行重写的人的耐心所做的一切，即使他们从技术上讲有更多可用时间）。这个问题更加复杂，因为来自损坏过滤器的错误可能很长时间都无法显示和/或迷失在大量输出中。更糟糕的是，损坏的过滤器通常只会导致静默的错误重写。

  • 最重要的是，即使当用户最终找到可用的命令时，他们自然也想分享它们。但他们可能不知道他们的仓库没有其他人的仓库中的一些特殊情况。因此，当具有不同存储库的其他人运行相同的命令时，他们会受到上述问题的困扰。或者，用户只是运行了经过特殊情况审查的命令，但他们在不同的操作系统上运行它，如上所述，它不起作用。

GIT

是 git[1] 套件的一部分

scroll-to-top