Git 中文参考（七）（4）https://developer.aliyun.com/article/1565814
git-hash-object
名称
git-hash-object - 计算对象 ID，并可选择从文件创建 blob
概要
git hash-object [-t <type>] [-w] [--path=<file>|--no-filters] [--stdin [--literally]] [--] <file>… git hash-object [-t <type>] [-w] --stdin-paths [--no-filters]
描述
使用指定文件的内容（可以在工作树之外）计算具有指定类型的对象的对象 ID 值，并可选择将结果对象写入对象数据库。将其对象 ID 报告给其标准输出。 git cvsimport 使用它来更新索引而不修改工作树中的文件。当< type>未指定，默认为“blob”。
OPTIONS
-t <type>
指定类型（默认值：“blob”）。
-w
实际上将对象写入对象数据库。
--stdin
从标准输入而不是从文件中读取对象。
--stdin-paths
从标准输入读取文件名，每行一个，而不是从命令行读取。
--path
哈希对象，因为它位于给定的路径。文件的位置不会直接影响哈希值，但路径用于确定在将对象放置到对象数据库之前应该将哪些 Git 过滤器应用于对象，并且，作为应用过滤器的结果，实际的 blob 放置进入对象数据库可能与给定文件不同。此选项主要用于散列位于工作目录外部的临时文件或从 stdin 读取的文件。
--no-filters
按原样哈希内容，忽略属性机制选择的任何输入过滤器，包括行尾转换。如果从标准输入读取文件，则始终隐含，除非给出--path选项。
--literally
允许--stdin将任何垃圾散列到松散的对象中，否则可能无法通过标准对象解析或 git-fsck 检查。用于压力测试 Git 本身或复制野外遇到的腐败或伪造物体的特征。
GIT
部分 git [1] 套件
git-ls-files
名称
git-ls-files - 显示索引和工作树中的文件信息
概要
git ls-files [-z] [-t] [-v] [-f] (--[cached|deleted|others|ignored|stage|unmerged|killed|modified])* (-[c|d|o|i|s|u|k|m])* [--eol] [-x <pattern>|--exclude=<pattern>] [-X <file>|--exclude-from=<file>] [--exclude-per-directory=<file>] [--exclude-standard] [--error-unmatch] [--with-tree=<tree-ish>] [--full-name] [--recurse-submodules] [--abbrev] [--] [<file>…]
描述
这将目录高速缓存索引中的文件列表与实际工作目录列表合并，并显示两者的不同组合。
以下一个或多个选项可用于确定显示的文件：
OPTIONS
-c
--cached
在输出中显示缓存的文件（默认）
-d
--deleted
在输出中显示已删除的文件
-m
--modified
在输出中显示已修改的文件
-o
--others
在输出中显示其他（即未跟踪）文件
-i
--ignored
仅显示输出中的忽略文件。在索引中显示文件时，仅打印与排除模式匹配的文件。显示“其他”文件时，仅显示与排除模式匹配的文件。标准忽略规则不会自动激活，因此至少需要一个--exclude*选项。
-s
--stage
在输出中显示暂存内容的模式位，对象名称和阶段编号。
--directory
如果整个目录被归类为“其他”，则只显示其名称（带斜杠）而不是其全部内容。
--no-empty-directory
不要列出空目录。没有–directory 没有效果。
-u
--unmerged
在输出中显示未合并的文件（强制 - 阶段）
-k
--killed
显示文件系统上由于文件/目录冲突而需要删除的文件，以使 checkout-index 成功。
-z
\ 0 输出行终止，不引用文件名。有关详细信息，请参阅下面的 OUTPUT。
-x <pattern>
--exclude=<pattern>
跳过与图案匹配的未跟踪文件。请注意，pattern 是 shell 通配符模式。有关详细信息，请参阅下面的 EXCLUDE PATTERNS。
-X <file>
--exclude-from=<file>
从< file>中读取排除模式;每行 1 个。
--exclude-per-directory=<file>
阅读仅适用于< file>中的目录及其子目录的其他排除模式。
--exclude-standard
添加标准 Git 排除项：.git / info / exclude，.gitignore 在每个目录中，以及用户的全局排除文件。
--error-unmatch
如果有任何< file>没有出现在索引中，将其视为错误（返回 1）。
--with-tree=<tree-ish>
使用–error-unmatch 扩展用户提供的< file>时（即路径模式）路径的参数，假装自从命名的< tree-ish>以来在索引中删除的路径。仍然存在。将此选项与-s或-u选项一起使用没有任何意义。
-t
此功能已被半弃用。出于脚本目的， git-status [1] --porcelain和 git-diff-files [1] --name-status几乎总是优秀的替代品，用户应该看一下 git-status [1] --short或 git-diff [1] --name-status，用于更加用户友好的替代品。
此选项在每行的开头标识具有以下标记（后跟空格）的文件状态：
H
缓存
S
跳 worktree
M
未合并
R
删除/删除
C
改性的/改变
K
被杀
?
其他
-v
与-t类似，但对于标记为 _ 的文件使用小写字母假设不变 _（参见 git-update-index [1] ）。
-f
与-t类似，但对于标记为 _fsmonitor 有效 _ 的文件使用小写字母（参见 git-update-index [1] ）。
--full-name
从子目录运行时，该命令通常输出相对于当前目录的路径。此选项强制路径相对于项目顶级目录输出。
--recurse-submodules
递归调用存储库中每个子模块上的 ls-files。目前只支持–cached 模式。
--abbrev[=<n>]
不显示完整的 40 字节十六进制对象行，而是仅显示部分前缀。可以使用–abbrev =< n>指定非默认位数。
--debug
在描述文件的每一行之后，添加有关其缓存条目的更多数据。这旨在显示尽可能多的手动检查信息;确切的格式可能随时改变。
--eol
显示< eolinfo>和< eolattr>的文件。 < eolinfo>是当“text”属性为“auto”（或未设置且 core.autocrlf 不为 false）时 Git 使用的文件内容标识。 < eolinfo>是“-text”，“none”，“lf”，“crlf”，“mixed”或“”。
“”表示该文件不是常规文件，它不在索引中或在工作树中不可访问。
< eolattr>是签出或提交时使用的属性，它是“”，“ - text”，“text”，“text = auto”，“text eol = lf”，“text eol = crlf”。由于支持 Git 2.10“text = auto eol = lf”和“text = auto eol = crlf”。
< eolinfo>都是在索引（“i /< eolinfo>”）和工作树（“w /< eolinfo>”）中显示常规文件，然后是（“attr /< eolattr>”）。
--
不要将任何更多的参数解释为选项。
<file>
要显示的文件。如果没有给出文件，则显示与其他指定条件匹配的所有文件。
OUTPUT
git ls-files 只输出文件名，除非指定了--stage，在这种情况下输出：
[<tag> ]<mode> <object> <stage> <file>
git ls-files --ee 将显示 i /< eolinfo>< SPACES> w /< eolinfo>< SPACES> attr /< eolattr>< SPACE *>< TAB> ;<文件>
git ls-files --unmerged 和 git ls-files --stage 可用于检查未合并路径的详细信息。
对于未合并的路径，索引不是记录单个模式/ SHA-1 对，而是记录最多三个这样的对;一个来自阶段 1 中的树 O，阶段 2 中的 A 和阶段 3 中的 B.一个用户（或瓷器）可以使用该信息来查看最终应该在路径上记录的内容。 （有关状态的更多信息，请参见 git-read-tree [1] ）
如果没有-z选项，则会引用具有“异常”字符的路径名，如配置变量core.quotePath所述（参见 git-config [1] ）。使用-z，文件名逐字输出，行以 NUL 字节终止。
排除模式
git ls-files 可以在遍历目录树时使用“排除模式”列表，并查找文件以显示指定标志 - 其他或–ignored 的时间。 gitignore [5] 指定排除模式的格式。
这些排除模式来自这些地方，依次为：
- 命令行标志–exclude =< pattern>指定单个模式。模式的排序顺序与它们在命令行中出现的顺序相同。
- 命令行标志–exclude-from =< file>指定包含模式列表的文件。模式的排序顺序与文件中出现的顺序相同。
- 命令行标志–exclude-per-directory =< name>指定每个目录 git ls-files 检查的文件名，通常是
.gitignore。更深层目录中的文件优先。模式的排序顺序与文件中出现的顺序相同。
在命令行中使用–exclude 或从–exclude-from 指定的文件读取的模式相对于目录树的顶部。从–exclude-per-directory 指定的文件读取的模式是相对于模式文件出现的目录。
也可以看看
git-read-tree [1] ， gitignore [5]
GIT
部分 git [1] 套件
git-merge-base
名称
git-merge-base - 为合并找到尽可能好的共同祖先
概要
git merge-base [-a|--all] <commit> <commit>… git merge-base [-a|--all] --octopus <commit>… git merge-base --is-ancestor <commit> <commit> git merge-base --independent <commit>… git merge-base --fork-point <ref> [<commit>]
描述
git merge-base 找到两个提交之间最好的共同祖先，用于三向合并。如果后者是前者的祖先，一个共同的祖先 _ 比另一个共同的祖先更好 _。没有任何更好的共同祖先的共同祖先是 _ 最佳共同祖先 _，即 _ 合并基 _。请注意，一对提交可以有多个合并基础。
操作模式
作为最常见的特殊情况，在命令行上仅指定两个提交意味着计算给定两个提交之间的合并基础。
更一般地，在计算合并基数的两个提交中，一个由命令行上的第一个提交参数指定;另一个提交是（可能是假设的）提交，它是命令行上所有剩余提交的合并。
因此，如果指定了两个以上的提交，则 _ 合并库 _ 不一定包含在每个提交参数中。当与--merge-base选项一起使用时，这与 git-show-branch [1] 不同。
--octopus
计算所有提供的提交的最佳共同祖先，为 n 路合并做准备。这模仿了 git show-branch --merge-base 的行为。
--independent
不是打印合并库，而是使用相同的祖先打印提供的提交的最小子集。换句话说，在给出的提交中，列出那些不能从任何其他提交的提交。这模仿了 git show-branch --independent 的行为。
--is-ancestor
检查第一个< commit>是第二个< commit>的祖先，如果为 true 则退出，状态为 0，否则退出状态为 1。错误由非零状态发出信号，该状态不为 1。
--fork-point
找到分支（或任何导致< commit>的历史记录）从另一个分支（或任何引用）< ref>分叉的点。这不只是寻找两个提交的共同祖先，而且还考虑了< ref>的 reflog。查看导致< commit>的历史记录分支早期的分支< ref>分叉（见下面关于这种模式的讨论）。
OPTIONS
-a
--all
输出提交的所有合并基础，而不是仅输出一个。
讨论
给定两个提交 A 和 B ，git merge-base A B将通过父关系输出可从 A 和 B 到达的提交。
例如，使用此拓扑：
o---o---o---B / ---o---1---o---o---o---A
A 和 B 之间的合并碱基是 1 。
给定三次提交 A ， B 和 C ，git merge-base A B C将计算 A 和假设提交 _ 之间的合并基数 M_ ，是 B 和 C 之间的合并。例如，使用此拓扑：
o---o---o---o---C / / o---o---o---B / / ---2---1---o---o---o---A
git merge-base A B C的结果是 1 。这是因为 B 和 C 之间具有合并提交 M 的等效拓扑是：
o---o---o---o---o / \ / o---o---o---o---M / / ---2---1---o---o---o---A
git merge-base A M的结果是 1 。提交 2 也是 A 和 M 之间的共同祖先，但 1 是更好的共同祖先，因为 2 是 1 的祖先。因此， 2 不是合并基础。
git merge-base --octopus A B C的结果是 2 ，因为 2 是所有提交的最佳共同祖先。
当历史涉及纵横交错时，两个提交可以有不止一个 _ 最佳 _ 共同祖先。例如，使用此拓扑：
---1---o---A \ / X / \ ---2---o---o---B
1 和 2 都是 A 和 B 的合并碱基。两者都不比另一个好（两者都是 _ 最佳 _ 合并碱基）。如果未给出--all选项，则未指定输出哪一个最佳选项。
在两个提交 A 和 B 之间检查“快进”的常用习惯用法是（或者至少用于）计算 A 和 B 之间的合并基础，并检查它是否与 A 相同，在这种情况下，A 是 B 的祖先。你会看到这个习惯用法经常用在较旧的脚本中。
A=$(git rev-parse --verify A) if test "$A" = "$(git merge-base A B)" then ... A is an ancestor of B ... fi
在现代 git 中，您可以更直接地说出这一点：
if git merge-base --is-ancestor A B then ... A is an ancestor of B ... fi
代替。
关于叉点模式的讨论
处理使用git checkout -b topic origin/master创建的topic分支后，远程跟踪分支origin/master的历史记录可能已经倒回并重建，从而导致此形状的历史记录：
o---B2 / ---o---o---B1--o---o---o---B (origin/master) \ B0 \ D0---D1---D (topic)
其中origin/master用于指向提交 B0，B1，B2，现在它指向 B，当origin/master位于 B0 时，您的topic分支在它上面启动，并且您构建了三个提交，D0， D1 和 D，在它上面。想象一下，您现在想要在更新的 origin / master 之上重新设置您在该主题上所做的工作。
在这种情况下，git merge-base origin/master topic将在上图中返回 B0 的父节点，但是 B0 ^ … D 是而不是你想要在 B 之上重放的提交范围（它包括 B0） ，这不是你写的;它是一个提交，当它从 B0 移动到 B1 时，另一方丢弃了）。
git merge-base --fork-point origin/master topic旨在帮助解决此类问题。它不仅需要 B，还需要 B0，B1 和 B2（即存储库的 reflog 知道的远程跟踪分支的旧技巧），以查看构建主题分支的提交并找到 B0，允许您仅重放对你主题的提交，不包括后来丢弃的提交。
于是
$ fork_point=$(git merge-base --fork-point origin/master topic)
会找到 B0，和
$ git rebase --onto origin/master $fork_point topic
将重放 B 顶部的 D0，D1 和 D 以创建此形状的新历史记录：
o---B2 / ---o---o---B1--o---o---o---B (origin/master) \ \ B0 D0'--D1'--D' (topic - updated) \ D0---D1---D (topic - old)
需要注意的是，您的存储库中较旧的 reflog 条目可能会被git gc过期。如果远程跟踪分支origin/master的 reflog 中不再出现 B0，则--fork-point模式显然无法找到并失败，从而避免给出随机且无用的结果（例如 B0 的父级，就像同一命令一样没有--fork-point选项给出）。
此外，您使用--fork-point模式的远程跟踪分支必须是您的主题从其提示分叉的主题。如果你从一个比提示更早的提交分叉，这个模式将找不到叉点（想象在上面的示例历史 B0 不存在，origin / master 从 B1 开始，移到 B2 然后 B，你分叉你的主题 at origin / master ^当 origin / master 为 B1 时;历史的形状与上面相同，没有 B0，B1 的父级是git merge-base origin/master topic正确找到的，但--fork-point模式不会，因为它不是曾经位于 origin / master 的提交之一。
也可以看看
git-rev-list [1] ， git-show-branch [1] ， git-merge [1]
GIT
部分 git [1] 套件
Git 中文参考（七）（6）https://developer.aliyun.com/article/1565816
