Git 中文参考（五）（6）https://developer.aliyun.com/article/1565850
gitignore
名称
gitignore - 指定要忽略的故意未跟踪文件
概要
，XDGCONFIGHOME/git/ignore， XDG_CONFIG_HOME / git / ignore， GIT_DIR / info / exclude，.gitignore
描述
gitignore文件指定 Git 应忽略的故意未跟踪文件。 Git 已经跟踪的文件不受影响;有关详细信息，请参阅下面的注释。
gitignore文件中的每一行都指定一个模式。在决定是否忽略路径时，Git 通常会检查来自多个源的gitignore模式，具有以下优先顺序，从最高到最低（在一个优先级内，最后一个匹配模式决定结果）：
- 从命令行读取的模式用于支持它们的那些命令。
- 从与路径相同的目录中的
.gitignore文件读取的模式，或在任何父目录中读取的模式，其中较高级别文件中的模式（直到工作树的顶层）被较低级别文件中的模式覆盖到包含该文件的目录。这些模式相对于.gitignore文件的位置匹配。项目通常在其存储库中包含此类.gitignore文件，其中包含作为项目构建的一部分生成的文件的模式。 - 从
$GIT_DIR/info/exclude读取的模式。 - 模式从配置变量
core.excludesFile指定的文件中读取。
放置模式的文件取决于模式的使用方式。
- 应该通过克隆进行版本控制并分发到其他存储库的模式（即所有开发人员都希望忽略的文件）应该进入
.gitignore文件。 - 特定于特定存储库但不需要与其他相关存储库共享的模式（例如，存储在存储库中但特定于一个用户工作流的辅助文件）应该进入
$GIT_DIR/info/exclude文件。 - 用户希望 Git 在所有情况下忽略的模式（例如，由用户选择的编辑器生成的备份或临时文件）通常会进入用户
~/.gitconfig中core.excludesFile指定的文件。其默认值为。如果XDGCONFIGHOME/git/ignore。如果 XDG_CONFIG_HOME / git / ignore。如果 XDG_CONFIG_HOME 未设置或为空，则使用$ HOME / .config / git / ignore。
底层的 Git 管道工具，如 git ls-files 和 git read-tree ，读取命令行选项指定的gitignore模式，或者命令行指定的文件选项。更高级别的 Git 工具，例如 git status 和 git add ，使用上面指定的来源的模式。
模式格式
- 空行不匹配任何文件，因此它可以作为可读性的分隔符。
- 以＃开头的行作为注释。对于以哈希开头的模式，在第一个哈希值前加一个反斜杠（“
\”）。 - 除非用反斜杠（“
\”）引用尾随空格，否则将忽略尾随空格。 - 可选的前缀“
!”否定模式;之前模式排除的任何匹配文件将再次包含在内。如果排除该文件的父目录，则无法重新包含文件。出于性能原因，Git 不会列出排除的目录，因此无论在何处定义，所包含文件的任何模式都不起作用。对于以文字“!”开头的模式，在第一个“!”前放置一个反斜杠（“\”），例如“\!important!.txt”。 - 如果模式以斜杠结尾，则为了以下描述的目的将其删除，但它只会找到与目录的匹配项。换句话说，
foo/将匹配目录foo和它下面的路径，但不匹配常规文件或符号链接foo（这与在 Git 中一般使用 pathspec 的方式一致）。 - 如果模式不包含斜杠 / ，Git 会将其视为 shell glob 模式，并检查相对于
.gitignore文件位置的路径名匹配（相对于工作的顶层）树，如果不是来自.gitignore文件）。 - 否则，Git 将模式视为 shell glob：“
*”匹配除“/”之外的任何内容，“?”匹配除“/”之外的任何一个字符，并且“[]”匹配一个字符选定的范围。有关更详细的说明，请参阅 fnmatch（3）和 FNM_PATHNAME 标志。 - 前导斜杠与路径名的开头匹配。例如，“/ *。c”匹配“cat-file.c”但不匹配“mozilla-sha1 / sha1.c”。
与完整路径名匹配的两个连续星号（“**”）可能具有特殊含义：
- 前导“
**”后跟斜杠表示在所有目录中匹配。例如，“**/foo”在任何地方匹配文件或目录“foo”，与模式“foo”相同。 “**/foo/bar”将文件或目录“bar”匹配在“foo”目录下的任何位置。 - 尾随“
/**”匹配内部的所有内容。例如，“abc/**”匹配目录“abc”内的所有文件，相对于.gitignore文件的位置，具有无限深度。 - 斜杠后跟两个连续的星号，然后斜杠匹配零个或多个目录。例如，“
a/**/b”匹配“a/b”，“a/x/b”，“a/x/y/b”等。 - 其他连续的星号被认为是常规星号，并且将根据先前的规则匹配。
笔记
gitignore 文件的目的是确保 Git 未跟踪的某些文件保持未跟踪。
要停止跟踪当前跟踪的文件，请使用 git rm --cached 。
例子
$ git status [...] # Untracked files: [...] # Documentation/foo.html # Documentation/gitignore.html # file.o # lib.a # src/internal.o [...] $ cat .git/info/exclude # ignore objects and archives, anywhere in the tree. *.[oa] $ cat Documentation/.gitignore # ignore generated html files, *.html # except foo.html which is maintained by hand !foo.html $ git status [...] # Untracked files: [...] # Documentation/foo.html [...]
另一个例子：
$ cat .gitignore vmlinux* $ ls arch/foo/kernel/vm* arch/foo/kernel/vmlinux.lds.S $ echo '!/vmlinux*' >arch/foo/kernel/.gitignore
第二个.gitignore 阻止 Git 忽略arch/foo/kernel/vmlinux.lds.S。
排除除特定目录foo/bar以外的所有内容的示例（注意/* - 没有斜杠，通配符也会排除foo/bar中的所有内容）：
$ cat .gitignore # exclude everything except directory foo/bar /* !/foo /foo/* !/foo/bar
也可以看看
git-rm [1] ， gitrepository-layout [5] ， git-check-ignore [1]
GIT
部分 git [1] 套件
gitmodules
名称
gitmodules - 定义子模块属性
概要
$ GIT_WORK_DIR / .gitmodules
描述
.gitmodules文件位于 Git 工作树的顶级目录中，是一个文本文件，其语法与 git-config [1] 的要求相匹配。
该文件包含每个子模块的一个子部分，子部分值是子模块的名称。该名称设置为添加子模块的路径，除非使用 _git 子模块添加 _ 的--name选项进行自定义。每个子模块部分还包含以下必需的键：
submodule.<name>.path
定义相对于 Git 工作树的顶级目录的路径，其中预期子模块将被检出。路径名称不得以/结尾。所有子模块路径在.gitmodules 文件中必须是唯一的。
submodule.<name>.url
定义可以从中克隆子模块存储库的 URL。这可以是准备传递给 git-clone [1] 的绝对 URL，或者（如果它以./或…/开头）相对于超级项目的原始存储库的位置。
此外，还有许多可选键：
submodule.<name>.update
定义命名子模块的默认更新过程，即超级项目中“git submodule update”命令如何更新子模块。这仅由git submodule init用于初始化同名的配置变量。这里允许的值是 _ 检出 ， rebase ， 合并 _ 或 _ 无 _。有关其含义，请参阅 git-submodule [1] 中 update 命令的说明。请注意，出于安全原因，此处有意忽略 _！命令 _ 表单。
submodule.<name>.branch
用于跟踪上游子模块中的更新的远程分支名称。如果未指定该选项，则默认为 master 。 .的特殊值用于指示子模块中分支的名称应与当前存储库中当前分支的名称相同。有关详细信息，请参阅 git-submodule [1] 中的--remote文档。
submodule.<name>.fetchRecurseSubmodules
此选项可用于控制此子模块的递归获取。如果此选项也存在于超级项目的.git / config 中的子模块条目中，则该设置将覆盖.gitmodules 中的设置。通过使用“git fetch”和“git pull”的“ - [no-] recurse-submodules”选项，可以在命令行上覆盖这两个设置。
submodule.<name>.ignore
定义在什么情况下“git status”和 diff 系列将子模块显示为已修改。支持以下值：
all
子模块永远不会被视为已修改（但仍将显示在状态输出中并在提交时提交）。
dirty
将忽略对子模块工作树的所有更改，仅考虑子模块的 HEAD 与其在超级项目中的记录状态之间的已提交差异。
untracked
只有子模块中未跟踪的文件才会被忽略。将显示对跟踪文件的承诺差异和修改。
none
不会忽略对子模块的修改，显示所有已提交的差异以及对已跟踪和未跟踪文件的修改。这是默认选项。
如果此选项也存在于超级项目的.git / config 中的子模块条目中，则该设置将覆盖.gitmodules 中的设置。
可以使用“–ignore-submodule”选项在命令行上覆盖这两个设置。 _git 子模块 _ 命令不受此设置的影响。
submodule.<name>.shallow
设置为 true 时，除非用户明确要求非浅层克隆，否则此子模块的克隆将作为浅层克隆（历史深度为 1）执行。
例子
请考虑以下.gitmodules 文件：
[submodule "libfoo"] path = include/foo url = git://foo.com/git/lib.git
[submodule "libbar"] path = include/bar url = git://bar.com/git/lib.git
这定义了两个子模块，libfoo和libbar。这些预期将在路径 include / foo 和 include / bar 中检出，并且对于这两个子模块，指定了可用于克隆子模块的 URL。
也可以看看
git-submodule [1] git-config [1]
GIT
部分 git [1] 套件
gitrevisions
名称
gitrevisions - 为 Git 指定修订版和范围
概要
gitrevisions
描述
许多 Git 命令将修订参数作为参数。根据命令，它们表示特定的提交，或者对于遍历修订图的命令（例如 git-log [1] ），表示可以从该提交到达的所有提交。对于遍历修订图的命令，还可以明确指定一系列修订。
另外，一些 Git 命令（例如 git-show [1] 和 git-push [1] ）也可以采用表示除提交之外的其他对象的修订参数，例如： blob（“文件”）或树（“文件目录”）。
指定修订
修订参数 < rev> 通常（但不一定）命名提交对象。它使用所谓的 _ 扩展 SHA-1_ 语法。以下是拼写对象名称的各种方法。列表末尾附近列出的名称包含提交中包含的树和 blob。
| 注意 | 本文档显示了 git 看到的“原始”语法。 shell 和其他 UI 可能需要额外的引用来保护特殊字符并避免单词拆分。 |
<sha1>, e.g. dae86e1950b1277e545cee180551750029cfe735, dae86e
完整的 SHA-1 对象名称（40 字节十六进制字符串），或存储库中唯一的前导子字符串。例如。如果存储库中没有其他对象以 dae86e 开头的对象，则 dae86e1950b1277e545cee180551750029cfe735 和 dae86e 都命名相同的提交对象。
<describeOutput>, e.g. v1.7.4.2-679-g3bee7fb
git describe的输出;即，最接近的标签，可选地后跟破折号和多次提交，然后是破折号， g 和缩写的对象名称。
<refname>, e.g. master, heads/master, refs/heads/master
一个象征性的引用名称。例如。 master 通常表示 refs / heads / master 引用的提交对象。如果您碰巧同时拥有 _ 磁头/主控 _ 和 _ 标签/主控 ，您可以明确地说 _ 磁头/主控 _ 告诉 Git 您的意思。当含糊不清时，< refname>_ 通过以下规则中的第一场比赛消除歧义：
- 如果 $ GIT_DIR /< refname> 存在，这就是你的意思（这通常只适用于
HEAD，FETCH_HEAD，ORIG_HEAD，MERGE_HEAD和CHERRY_PICK_HEAD）; - 否则， refs /< refname> 如果存在;
- 否则， refs / tags /< refname> 如果存在;
- 否则， refs / heads /< refname> 如果存在;
- 否则， refs / remotes /< refname> 如果存在;
- 否则， refs / remotes /< refname> / HEAD （如果存在）。
HEAD命名您基于工作树中的更改的提交。FETCH_HEAD记录您使用上次git fetch调用从远程存储库中获取的分支。ORIG_HEAD是由以大刀阔斧的方式移动HEAD的命令创建的，用于在操作之前记录HEAD的位置，以便您可以轻松地将分支的尖端更改回运行它们之前的状态。MERGE_HEAD在运行git merge时记录您要合并到分支中的提交。当您运行git cherry-pick时，CHERRY_PICK_HEAD会记录您正在挑选的提交。
请注意，上述任何 refs / * 情况可能来自 $ GIT_DIR / refs 目录或来自 $ GIT_DIR / packed-refs 文件。虽然未指定引用名称编码，但首选 UTF-8，因为某些输出处理可能会假定使用 UTF-8 中的引用名称。
@
单独 @ 是HEAD的捷径。
<refname>@{<date>}, e.g. master@{yesterday}, HEAD@{5 minutes ago}
引用后跟 @ 后缀为日期规格括号对（例如 {昨天} ， {1 个月 2 周 3 天 1 小时 1 秒前} 或 {1979-02-26 18:30:00} ）指定先前时间点的 ref 值。此后缀只能在引用名称后立即使用，并且引用必须具有现有日志（ $ GIT_DIR / logs /< ref> ）。请注意，这会在给定时间查找本地 ref 的状态;例如，上周本地 _ 主 _ 分支机构的内容。如果要查看在特定时间内提交的提交，请参阅--since和--until。
<refname>@{<n>}, e.g. master@{1}
后缀为 @ 的后缀为括号对中的序数规范（例如 {1} ， {15} ）指定第 n 个先验那个参考的价值。例如 master @ {1} 是 master 的前一个值，而 master @ {5} 是 master 的第 5 个先前值]。此后缀只能在引用名称后立即使用，并且引用必须具有现有日志（ $ GIT_DIR / logs /< refname> ）。
@{<n>}, e.g. @{1}
您可以使用带有空参考部分的 @ 构造来获取当前分支的 reflog 条目。例如，如果你在分支 blabla ，那么 @ {1} 意味着与 blabla @ {1} 相同。
@{-<n>}, e.g. @{-1}
构造 @ { - < n>} 表示在当前分支/提交之前检出的第 n 个分支/提交。
<branchname>@{upstream}, e.g. master@{upstream}, @{u}
后缀 @ {upstream} 到分支机构（简称 < branchname> @ {u} ）指的是由 branchname 指定的分支设置为在其上构建的分支（配置为branch.<name>.remote和branch.<name>.merge）。缺少的 branchname 默认为当前的。当拼写为大写时，这些后缀也被接受，无论如何它们都意味着相同的东西。
<branchname>@{push}, e.g. master@{push}, @{push}
后缀 @ {push} 报告分支“我们将推送到哪里”如果branchname在branchname被检出时运行（或者当前HEAD如果没有指定分支机构）。由于我们的推送目的地位于远程存储库中，当然，我们报告与该分支对应的本地跟踪分支（即 refs / remotes / 中的内容）。
这是一个让它更清晰的例子：
$ git config push.default current $ git config remote.pushdefault myfork $ git checkout -b mybranch origin/master $ git rev-parse --symbolic-full-name @{upstream} refs/remotes/origin/master $ git rev-parse --symbolic-full-name @{push} refs/remotes/myfork/mybranch
请注意，在我们设置三角形工作流程的示例中，我们从一个位置拉出并推送到另一个位置。在非三角形工作流程中， @ {push} 与 @ {upstream} 相同，并且不需要它。
拼写为大写时也接受此后缀，无论情况如何都是相同的。
<rev>^, e.g. HEAD^, v1.5.1⁰
修订参数的后缀 ^ 表示该提交对象的第一个父级。 ^< n> 表示第 n 个亲本（即 < rev> ^ 等同于 < rev> ^ ）。作为特殊规则，< rev> ^ 0 表示提交本身并且在 < rev>时使用。 是引用提交对象的标记对象的对象名称。
<rev>~<n>, e.g. master~3
后缀 〜< n> 到版本参数意味着提交对象是指定提交对象的第 n 代祖先，仅跟随第一个父对象。即 < rev>〜 相当于 < rev> ^^^ ，其相当于 < rev> ^ 1 ^ 1 ^ 。请参阅下文，了解此表单的用法。
<rev>^{<type>}, e.g. v0.99.8^{commit}
后缀 ^ 后跟括号对中包含的对象类型名称意味着在 < rev>处取消引用对象。 递归地直到 < type>类型的对象为止。找到 _ 或者不再解除引用对象（在这种情况下，barf）。例如，如果 < rev> 是 commit-ish，< rev> ^ {commit}_ 描述了相应的提交对象。类似地，如果 < rev> 是树，< rev> ^ {tree} 描述了相应的树对象。 < rev> ^ 0 是 < rev> ^ {commit} 的简写。
rev ^ {object} 可以用来确保 rev 命名一个存在的对象，而不需要 rev 作为标签，并且不需要解除引用 rev ;因为标签已经是一个对象，所以即使一次到达一个对象也不需要解除引用。
rev ^ {tag} 可用于确保 rev 标识现有标记对象。
<rev>^{}, e.g. v0.99.8^{}
后缀 ^ 后跟空括号对意味着该对象可以是标记，并递归取消引用标记，直到找到非标记对象。
<rev>^{/<text>}, e.g. HEAD^{/fix nasty bug}
后缀 ^ 到一个修订参数，后跟一个括号对，其中包含一个由斜杠引导的文本，与下面的 _：/ fix 讨厌错误 _ 语法相同，只是它返回可以从 _< rev>到达的最年轻的匹配提交 ^ 之前的 _。
:/<text>, e.g. :/fix nasty bug
冒号后跟一个斜杠，后跟一个文本，命名一个提交，其提交消息与指定的正则表达式匹配。此名称返回可从任何 ref 访问的最新匹配提交，包括 HEAD。正则表达式可以匹配提交消息的任何部分。为了匹配以字符串开头的消息，可以使用例如 ：/ ^ foo 。特殊序列 ：/！ 保留用于匹配的修饰符。 ：/！ - foo 执行负匹配，而 ：/ !! foo 匹配文字 ！ 字符，然后是 foo 。以 _ 开头的任何其他序列：/！_ 暂时保留。根据给定的文本，shell 的单词拆分规则可能需要额外的引用。
<rev>:<path>, e.g. HEAD:README, :README, master:./README
后缀 ： 后跟一个路径，命名由冒号前部分命名的树形对象中给定路径上的 blob 或树。 ：path （在冒号前面有空部分）是下面描述的语法的特例：在给定路径的索引中记录的内容。以 ./ 或 …/ 开头的路径是相对于当前工作目录的。给定路径将转换为相对于工作树的根目录。这对于从具有与工作树具有相同树结构的提交或树来解决 blob 或树最有用。
:<n>:<path>, e.g. :0:README, :README
冒号，可选地后跟一个阶段号（0 到 3）和一个冒号，后跟一个路径，在给定路径的索引中命名一个 blob 对象。缺少的阶段编号（以及其后面的冒号）命名阶段 0 条目。在合并期间，阶段 1 是共同的祖先，阶段 2 是目标分支的版本（通常是当前分支），阶段 3 是正在合并的分支的版本。
以下是 Jon Loeliger 的插图。提交节点 B 和 C 都是提交节点 A 的父节点。父提交从左到右排序。
G H I J \ / \ / D E F \ | / \ \ | / | \|/ | B C \ / \ / A
A = = A⁰ B = A^ = A¹ = A~1 C = A² = A² D = A^^ = A¹¹ = A~2 E = B² = A^² F = B³ = A^³ G = A^^^ = A¹¹¹ = A~3 H = D² = B^² = A^^² = A~2² I = F^ = B³^ = A^³^ J = F² = B³² = A^³²
指定范围
遍历诸如git log之类的命令的历史操作在一组提交上，而不仅仅是单个提交。
对于这些命令，使用上一节中描述的表示法指定单个修订版意味着来自给定提交的提交reachable集。
提交的可达集是提交本身和其祖先链中的提交。
提交排除
^<rev> (caret) Notation
要排除从提交可到达的提交，使用前缀 ^ 表示法。例如。 ^ r1 r2 表示从 r2 可到达的提交，但排除可从 r1 （即 r1 及其祖先）到达的提交。
虚线范围符号
The .. (two-dot) Range Notation
^ r1 r2 设置操作经常出现，因此有一个简写。如果你有两个提交 r1 和 r2 （根据上面的 SPECIFYING REVISIONS 中解释的语法命名），你可以要求从 r2 可以访问的提交，不包括那些可以从 r1 到达的提交 ^ r1 r2 可以写成 r1…r2 。
The … (three-dot) Symmetric Difference Notation
类似的符号 r1 … r2 称为 r1 和 r2 的对称差异，定义为 r1 r2 - not $（git merge） -base --all r1 r2）。它是可以从 r1 （左侧）或 r2 （右侧）中的任何一个到达的提交集，但不是两者都可以。
在这两个简写符号中，您可以省略一端并将其默认为 HEAD。例如，_ 原点…_ 是 origin…HEAD 的简写并询问“自从我从原点分支分叉后我做了什么？”同样， .origin 是 HEAD…origin 的简写，并询问“自从我从它们分叉后，起源做了什么？”注意 … 将意味着 HEAD…HEAD ，这是一个空的范围，既可以从 HEAD 到达又无法到达。
其他< rev> ^父简写符号
存在三个其他的缩写，对于合并提交特别有用，用于命名由提交及其父提交形成的集合。
r1 ^ @ 符号表示 r1 的所有亲本。
r1 ^！ 表示法包含 commit r1 但不包括其所有父母。这个符号本身表示单个提交 r1 。
< rev> ^ - < n> 符号包括 < rev> 但不包括第 n 个亲本（即 < rev> ^< n> …< rev> 的简写），< n>如果没有给出， = 1。这通常对于合并提交很有用，您可以通过 < commit> ^ - 来获取合并提交中合并的分支中的所有提交 < commit> （包括 < commit> 本身）。
虽然 < rev> ^< n> 是关于指定单个提交父级，这三个符号也考虑其父级。例如你可以说 HEAD ^ 2 ^ @ ，但你不能说 HEAD ^ @ ^ 2 。
Git 中文参考（五）（8）https://developer.aliyun.com/article/1565852
