Git 中文参考（三）（5）https://developer.aliyun.com/article/1565824
REFS
在多个工作树中，一些参考树可以在所有工作树之间共享，一些参考树是本地的。一个例子是 HEAD 对于所有工作树都是不同的。本节介绍共享规则以及如何从另一个工作树访问 refs。
通常，所有伪引用都是每个工作树，并且所有以“refs /”开头的引用都是共享的。伪引用类似 HEAD，直接在 GIT_DIR 下而不是在 GIT_DIR / refs 内。这有一个例外：refs / bisect 中的 refs 和不共享 refs / worktree。
仍然可以通过两个特殊路径（main-worktree 和 worktree）从另一个工作树访问每个工作树的引用。前者允许访问主工作树的每个工作树参考，而后者访问所有链接的工作树。
例如，main-worktree / HEAD 或 main-worktree / refs / bisect / good 分别解析为与主工作树的 HEAD 和 refs / bisect / good 相同的值。类似地，worktrees / foo / HEAD 或 worktrees / bar / refs / bisect / bad 与 GIT_COMMON_DIR / worktrees / foo / HEAD 和 GIT_COMMON_DIR / worktrees / bar / refs / bisect / bad 相同。
要访问 refs，最好不要直接查看 GIT_DIR。而是使用诸如 git-rev-parse [1] 或 git-update-ref [1] 之类的命令，它们将正确处理 refs。
配置文件
默认情况下，存储库“config”文件在所有工作树之间共享。如果配置变量core.bare或core.worktree已经存在于配置文件中，它们将仅应用于主工作树。
为了具有特定于工作树的配置，您可以打开“worktreeConfig”扩展名，例如：
$ git config extensions.worktreeConfig true
在此模式下，特定配置保留在git rev-parse --git-path config.worktree指向的路径中。您可以使用git config --worktree在此文件中添加或更新配置。较旧的 Git 版本将拒绝使用此扩展名访问存储库。
请注意，在此文件中，core.bare和core.worktree的例外消失了。如果您之前在$ GIT_DIR / config 中有它们，则必须将它们移动到主工作树的config.worktree。您也可以借此机会查看并移动您不想共享的其他配置到所有工作树：
- 永远不要共享
core.worktree和core.bare - 除非您确定始终对所有工作树使用稀疏检出，否则建议每个工作树使用
core.sparseCheckout。
细节
每个链接的工作树在存储库的$ GIT_DIR / worktrees 目录中都有一个私有子目录。私有子目录的名称通常是链接工作树路径的基本名称，可能附加一个数字以使其唯一。例如，当$GIT_DIR=/path/main/.git命令git worktree add /path/other/test-next next在/path/other/test-next中创建链接的工作树时，还会创建$GIT_DIR/worktrees/test-next目录（如果已经test-next，则创建$GIT_DIR/worktrees/test-next1）。
在链接的工作树中，$ GIT_DIR 设置为指向此私有目录（例如示例中的/path/main/.git/worktrees/test-next），并且GITCOMMONDIR设置为指向主工作树的GITCOMMONDIR设置为指向主工作树的 GIT_COMMON_DIR 设置为指向主工作树的 GIT_DIR（例如/path/main/.git）。这些设置在位于链接工作树顶部目录的.git文件中进行。
通过git rev-parse --git-path的路径分辨率使用GITDIR或GITDIR或 GIT_DIR 或 GIT_COMMON_DIR，具体取决于路径。例如，在链接的工作树git rev-parse --git-path HEAD中返回/path/main/.git/worktrees/test-next/HEAD（不是/path/other/test-next/.git/HEAD或/path/main/.git/HEAD），而git rev-parse --git-path refs/heads/master使用$ GIT_COMMON_DIR 并返回/path/main/.git/refs/heads/master，因为 refs 在所有工作树之间共享，refs /除外平分和参考/工作树。
有关详细信息，请参阅 gitrepository-layout [5] 。经验法则是，当您需要直接访问GITDIR内的某些内容时，不要对路径是属于GITDIR内的某些内容时，不要对路径是属于 GIT_DIR 内的某些内容时，不要对路径是属于 GIT_DIR 还是$ GIT_COMMON_DIR 做出任何假设。使用git rev-parse --git-path获取最终路径。
如果手动移动链接的工作树，则需要更新条目目录中的 gitdir 文件。例如，如果链接的工作树移动到/newpath/test-next并且其.git文件指向/path/main/.git/worktrees/test-next，则将/path/main/.git/worktrees/test-next/gitdir更新为引用/newpath/test-next。
要防止$ GIT_DIR / worktrees 条目被修剪（这在某些情况下很有用，例如当条目的工作树存储在便携式设备上时），请使用git worktree lock命令，该命令添加名为 _ 的文件锁定 _ 到条目的目录。该文件包含纯文本的原因。例如，如果链接的工作树的.git文件指向/path/main/.git/worktrees/test-next，则名为/path/main/.git/worktrees/test-next/locked的文件将阻止test-next条目被修剪。有关详细信息，请参阅 gitrepository-layout [5] 。
启用 extensions.worktreeConfig 时，在.git/config之后读取配置文件.git/worktrees//config.worktree。
列表输出格式
worktree list 命令有两种输出格式。默认格式显示包含列的单行详细信息。例如：
$ git worktree list /path/to/bare-source (bare) /path/to/linked-worktree abcd1234 [master] /path/to/other-linked-worktree 1234abc (detached HEAD)
瓷器格式
瓷器格式每个属性都有一行。列出的属性标签和值由单个空格分隔。布尔属性（如 _ 裸 _ 和 _ 分离 _）仅作为标签列出，仅当值为真时才存在。工作树的第一个属性始终是worktree，空行表示记录的结尾。例如：
$ git worktree list --porcelain worktree /path/to/bare-source bare worktree /path/to/linked-worktree HEAD abcd1234abcd1234abcd1234abcd1234abcd1234 branch refs/heads/master worktree /path/to/other-linked-worktree HEAD 1234abc1234abc1234abc1234abc1234abc1234a detached
例子
您正处于重构阶段，您的老板进来并要求您立即修复。您通常可以使用 git-stash [1] 临时存储您的更改，但是，您的工作树处于混乱状态（使用新的，移动的和删除的文件以及其他零碎的部分）散落在你周围，你不想冒任何干扰它的风险。相反，您创建一个临时链接工作树来进行紧急修复，完成后将其删除，然后恢复您之前的重构会话。
$ git worktree add -b emergency-fix ../temp master $ pushd ../temp # ... hack hack hack ... $ git commit -a -m 'emergency fix for boss' $ popd $ git worktree remove ../temp
BUGS
一般的多次检出仍然是实验性的，对子模块的支持是不完整的。建议不要对超级项目进行多次检出。
GIT
部分 git [1] 套件
git-fetch
名称
git-fetch - 从另一个存储库下载对象和引用
概要
git fetch [<options>] [<repository> [<refspec>…]] git fetch [<options>] <group> git fetch --multiple [<options>] [(<repository> | <group>)…] git fetch --all [<options>]
描述
从一个或多个其他存储库中获取分支和/或标记（统称为“refs”），以及完成其历史记录所需的对象。远程跟踪分支已更新（有关控制此行为的方法，请参阅下面< refspec>的说明）。
默认情况下，还会获取指向要获取的历史记录的任何标记;效果是获取指向您感兴趣的分支的标记。可以使用–tags 或–no-tags 选项或配置远程来更改此默认行为。< name> .tagOpt。通过使用明确获取标记的 refspec，您可以获取不指向您感兴趣的分支的标记。
git fetch 可以从单个命名的存储库或 URL 获取，或者如果< group>则从一个存储库获取。给出并且有一个遥控器。< group>配置文件中的条目。 （参见 git-config [1] ）。
如果未指定远程，则默认情况下将使用origin远程，除非为当前分支配置了上游分支。
获取的引用名称及其指向的对象名称将写入.git/FETCH_HEAD。脚本或其他 git 命令可以使用此信息，例如 git-pull [1] 。
OPTIONS
--all
获取所有遥控器。
-a
--append
将获取的引用的引用名称和对象名称附加到.git/FETCH_HEAD的现有内容。如果没有此选项，.git/FETCH_HEAD中的旧数据将被覆盖。
--depth=<depth>
从每个远程分支历史记录的提示限制提取到指定的提交数。如果使用--depth=选项（参见 git-clone [1] ）获取git clone创建的 _ 浅 _ 存储库，请将历史记录加深或缩短到指定的提交数。不提取深化提交的标记。
--deepen=<depth>
与–depth 类似，不同之处在于它指定了当前浅边界而不是每个远程分支历史记录的提交数。
--shallow-since=<date>
深化或缩短浅存储库的历史记录，以包括< date>之后的所有可访问提交。
--shallow-exclude=<revision>
深化或缩短浅存储库的历史记录，以排除从指定的远程分支或标记可到达的提交。可以多次指定此选项。
--unshallow
如果源存储库已完成，请将浅存储库转换为完整存储库，从而消除浅存储库所施加的所有限制。
如果源存储库很浅，则尽可能多地获取，以便当前存储库与源存储库具有相同的历史记录。
--update-shallow
默认情况下，从浅存储库中获取时，git fetch拒绝需要更新.git / shallow 的引用。此选项更新.git / shallow 并接受此类引用。
--negotiation-tip=<commit|glob>
默认情况下，Git 将向服务器报告可从所有本地引用访问的提交，以查找公共提交以尝试减少要接收的包文件的大小。如果指定，Git 将仅报告从给定提示可到达的提交。当用户知道哪个本地 ref 可能与正在获取的上游引用有共同提交时，这对于加速提取是有用的。
可以多次指定此选项;如果是这样，Git 将报告从任何给定提交可到达的提交。
此选项的参数可以是 ref 的名称，ref 或者提交的（可能缩写的）SHA-1 上的 glob。指定 glob 等效于多次指定此选项，每个匹配的 ref 名称一个。
另请参见 git-config [1] 中记录的fetch.negotiationAlgorithm配置变量。
--dry-run
显示将要完成的任务，而不进行任何更改。
-f
--force
当 git fetch 与: refspec 一起使用时，它可能会拒绝更新本地分支，如下面部分所述。此选项会覆盖该检查。
-k
--keep
保持下载的包。
--multiple
允许多个< repository>和< group>要指定的参数。不能指定< refspec> s。
-p
--prune
在获取之前，删除远程不再存在的任何远程跟踪引用。如果仅由于默认标记自动跟踪或由于–tags 选项而提取标记，则不对其进行修剪。但是，如果由于显式 refspec（在命令行或远程配置中，例如，如果使用–mirror 选项克隆远程），则会提取标记，那么它们也会受到修剪。提供--prune-tags是提供标签 refspec 的简写。
有关详细信息，请参阅下面的 PRUNING 部分。
-P
--prune-tags
在获取之前，如果启用了--prune，则删除遥控器上不再存在的任何本地标签。应该更仔细地使用此选项，与--prune不同，它将删除已创建的任何本地引用（本地标记）。此选项是提供显式标记 refspec 和--prune的简写，请参阅其文档中有关该标记的讨论。
有关详细信息，请参阅下面的 PRUNING 部分。
-n
--no-tags
默认情况下，指向从远程存储库下载的对象的标记将被提取并存储在本地。此选项会禁用此自动标记。可以使用远程。< name> .tagOpt 设置指定远程的默认行为。见 git-config [1] 。
--refmap=<refspec>
在获取命令行中列出的引用时，使用指定的 refspec（可以多次给出）将 refs 映射到远程跟踪分支，而不是远程存储库的remote.*.fetch配置变量的值。有关详细信息，请参阅“已配置的远程跟踪分支”部分。
-t
--tags
从远程获取所有标记（即，将远程标记refs/tags/*提取到具有相同名称的本地标记），以及否则将获取的任何其他标记。即使使用了–prune，单独使用此选项也不会对标记进行修剪（尽管如果它们也是显式 refspec 的目标，则无论如何都可以修剪标记;请参阅--prune）。
--recurse-submodules[=yes|on-demand|no]
此选项控制是否以及在何种条件下应该提取已填充的子模块的新提交。当设置为 no 时，它可以用作布尔选项来完全禁用递归，或者当设置为 yes 时无条件地递归到所有填充的子模块，这是使用此选项时的默认值没有任何价值。当超级项目检索到更新子模块对尚未在本地子模块克隆中的提交的引用的提交时，使用 _ 按需 _ 仅递归到填充的子模块。
-j
--jobs=<n>
用于获取子模块的并行子节点数。每个都将从不同的子模块中获取，这样获取许多子模块的速度会更快。默认情况下，将一次提取一个子模块。
--no-recurse-submodules
禁用递归获取子模块（这与使用--recurse-submodules=no选项具有相同的效果）。
--submodule-prefix=<path>
前置<路径>在信息性消息中打印的路径，例如“获取子模块 foo”。在子模块上递归时，此选项在内部使用。
--recurse-submodules-default=[yes|on-demand]
此选项在内部用于临时为–recurse-submodules 选项提供非负默认值。所有其他配置 fetch 子模块递归的方法（例如 gitmodules [5] 和 git-config [1] 中的设置）都会覆盖此选项，指定 - [no-] recurse-submodules 直接。
-u
--update-head-ok
默认情况下 git fetch 拒绝更新与当前分支对应的头部。此标志禁用检查。这纯粹是为 git pull 内部使用与 git fetch 进行通信，除非你实现自己的瓷器，否则你不应该使用它。
--upload-pack <upload-pack>
当给定，并且要获取的存储库由 git fetch-pack 处理时，--exec=被传递给命令以指定另一端运行的命令的非默认路径。
-q
--quiet
将–quiet 转换为 git-fetch-pack 并使任何其他内部使用的 git 命令静音。未向标准错误流报告进度。
-v
--verbose
要冗长。
--progress
除非指定了-q，否则在将标准错误流附加到终端时，默认情况下会报告进度状态。即使标准错误流未定向到终端，此标志也会强制进度状态。
-o <option>
--server-option=<option>
使用协议版本 2 进行通信时，将给定的字符串传输到服务器。给定的字符串不得包含 NUL 或 LF 字符。当给出多个--server-option=时，它们都按照命令行中列出的顺序发送到另一侧。
-4
--ipv4
仅使用 IPv4 地址，忽略 IPv6 地址。
-6
--ipv6
仅使用 IPv6 地址，忽略 IPv4 地址。
<repository>
“远程”存储库，它是获取或拉取操作的源。该参数可以是 URL（参见下面的 GIT URL 部分）或遥控器的名称（参见下面的 REMOTES 部分）。
<group>
一个名称，指的是存储库列表作为遥控器的值。< group>在配置文件中。 （参见 git-config [1] ）。
<refspec>
指定要获取的引用和要更新的本地引用。如果命令行中没有< refspec> s，则从remote..fetch变量中读取要获取的引用（参见下面的配置的远程跟踪分支）。
< refspec>的格式参数是可选加+，后跟源< src>，后跟冒号:，后跟目标 ref< dst>。当< dst>时，可以省略冒号。是空的。 < SRC>通常是 ref，但它也可以是完全拼写的十六进制对象名称。
tag 表示与refs/tags/:refs/tags/相同;它请求获取给定标记的所有内容。
匹配< src>的远程引用取出，如果< dst>不是空字符串，尝试更新与其匹配的本地引用。
在没有--force的情况下是否允许更新取决于它被提取到的 ref 命名空间，被提取的对象的类型，以及更新是否被认为是快进。通常，相同的规则适用于推送时的提取，请参阅 git-push [1] 的...部分。 git fetch 特有的那些规则的例外情况如下所述。
直到 Git 版本 2.20，并且与使用 git-push [1] 推送时不同，对refs/tags/*的任何更新都将在 refspec（或--force）中没有+的情况下被接受。在获取时，我们会混淆地将远程的所有标记更新视为强制提取。从 Git 版本 2.20 开始，获取更新refs/tags/*的方式与推送时相同。即如果没有 refspec（或--force）中的+，任何更新都将被拒绝。
与使用 git-push [1] 进行推送时不同，[refdpec（或--force）中的+将接受refs/{tags,heads}/*以外的任何更新，无论是否交换，例如一个 blob 的树对象，或另一个提交的提交，它没有先前的提交作为祖先等。
与使用 git-push [1] 进行推送不同，没有任何配置可以修改这些规则，也没有类似于pre-receive挂钩的pre-fetch挂钩。
与使用 git-push [1] 推送一样，可以通过向 refspec 添加可选的前导+（或使用--force来覆盖上面描述的关于不允许作为更新的所有规则。 ]命令行选项）。唯一的例外是没有任何强制将使refs/heads/*命名空间接受非提交对象。
| 注意 | 当你想要获取的远程分支被认为是经常倒带和重新定位时，预计它的新提示将不会是其上一个提示的后代（如上次提取时存储在远程跟踪分支中）。您可能希望使用+符号来指示此类分支将需要非快进更新。无法确定或声明具有此行为的存储库中的分支可用;拉动用户只需知道这是分支的预期使用模式。 |
GIT 网址
通常，URL 包含有关传输协议，远程服务器的地址以及存储库路径的信息。根据传输协议，可能缺少某些信息。
Git 支持 ssh，git，http 和 https 协议（此外，ftp 和 ftps 可用于获取，但这是低效的并且已弃用;请勿使用它）。
本机传输（即 git：// URL）不进行身份验证，应在不安全的网络上谨慎使用。
可以使用以下语法：
- SSH：// [用户@] host.xz [：端口] /path/to/repo.git/
- GIT 中：//host.xz [：端口] /path/to/repo.git/
- HTTP [S]：//host.xz [：端口] /path/to/repo.git/
- FTP [S]：//host.xz [：端口] /path/to/repo.git/
另一种类似 scp 的语法也可以与 ssh 协议一起使用：
- [用户@] host.xz：路径/到/ repo.git /
只有在第一个冒号之前没有斜杠时才会识别此语法。这有助于区分包含冒号的本地路径。例如，本地路径foo:bar可以指定为绝对路径或./foo:bar，以避免被误解为 ssh url。
ssh 和 git 协议还支持〜用户名扩展：
- SSH：// [用户@] host.xz [：端口] /〜[用户] /path/to/repo.git/
- GIT 中：//host.xz [：端口] /〜[用户] /path/to/repo.git/
- [用户@] host.xz：/〜[用户] /path/to/repo.git/
对于本地也受 Git 支持的本地存储库，可以使用以下语法：
- /path/to/repo.git/
- 文件：///path/to/repo.git/
这两种语法大多是等价的，除了克隆时，前者暗示–local 选项。有关详细信息，请参阅 git-clone [1] 。
当 Git 不知道如何处理某种传输协议时，它会尝试使用 remote-< transport> 远程助手，如果存在的话。要显式请求远程帮助程序，可以使用以下语法：
- <运输> ::<地址>
其中<地址>可以是路径，服务器和路径，或者由被调用的特定远程助手识别的任意类似 URL 的字符串。有关详细信息，请参阅 gitremote-helpers [1] 。
如果存在大量具有相似名称的远程存储库，并且您希望为它们使用不同的格式（以便将您使用的 URL 重写为有效的 URL），则可以创建表单的配置部分：
[url "<actual url base>"] insteadOf = <other url base>
例如，有了这个：
[url "git://git.host.xz/"] insteadOf = host.xz:/path/to/ insteadOf = work:
像“work：repo.git”这样的 URL 或类似“host.xz：/path/to/repo.git”的 URL 将在任何带有 URL 的上下文中被重写为“git：//git.host.xz/repo” git 的”。
如果要为仅推送重写 URL，可以创建表单的配置部分：
[url "<actual url base>"] pushInsteadOf = <other url base>
例如，有了这个：
[url "ssh://example.org/"] pushInsteadOf = git://example.org/
像“git：//example.org/path/to/repo.git”这样的网址将被重写为“ssh：//example.org/path/to/repo.git”以进行推送，但是 pull 仍会使用原始网址。
Git 中文参考（三）（7）https://developer.aliyun.com/article/1565826
