我几乎可以获得深度优先排序，git rev-list --in-commit-order --objects --reverse HEAD这给了我类似的东西

当我想要

首先将列表后处理到深度并不简单，因为两棵共同祖先的树可能共享同一个孩子

我最近开始使用 git 树和临时索引文件来构建提交，而无需修改我的工作目录，以实现某些任务的自动化。最终目标是有效地变基一些分支（例如feature/x_y_z，在 之上main），但不修改工作目录来完成它。显然我仍然想检测冲突，并且绝对不会破坏更改main（因为可以使用git commit-tree）。我通读了本书的“Git Internals”一章，它对树、blob、索引等很有教育意义——但没有明确解释变基是如何工作的。

（旁白：这样做的动机是 1）它更快，以及 2）我想让开发人员能够快速启动一些提交/分支的测试，使用最新的规范更改，而不会破坏他们的工作目录。）

为此，如何git rebase在引擎盖下工作？它使用什么管道命令？它如何分析树以检测冲突？指向有用资源的链接和/或对这些内容的直接解释将非常有帮助。

这是一个非常小的可访问性问题，但我想知道是否有人解决了它：

每当我这样做git status时，文件都会按字母顺序显示（应该如此）：

但是，我希望我的标题出现在我的实现文件之前。一个原因是，每当我完成一堆工作时，我都喜欢git add -p添加阶段性的相关文件。如果我可以先添加标题，这样我可以在之后跟进实现，那就更好了。

有什么方法可以自定义 git 以便我可以定义自己的文件顺序？类似于“句点之前的所有内容的字母数字，然后h优先于文件扩展名中的所有其他内容”。

我想使用管道命令访问 reflog 主题。我期望：

给我我想要的，但这只是给我输出如下：

奥托：

给了我我所期望的。

背景

我正在将 VCS 迁移到 git。这是通过从旧的 VCS (TFSVC) 中签出并通过脚本签入 git 存储库来完成的。

基本上在这样一个循环中：

问题

旧的 VCS 包含一个.gitignore，作为迁移过程的一部分，我不希望应用这些模式。这可以很容易地使用git add . --force. 问题是我可能仍然想忽略一些事情。

我试过的

我希望.git/info/exclude用于此目的，但git-add --force显然除了.gitignore规则之外还忽略了这一点。似乎也一样core.excludesFile。

理想的解决方案

• 排除规则.gitignore
• .git/info/exclude在或其他一些排除文件或模式中使用规则
• 有点性能，这个过程足够慢
• 不依赖于修改工作树

一个选项当然是git restore --staged $EXCLUDE_PATH_SPEC在将所有内容添加到索引之后，但我想知道是否没有更好的解决方案。

我似乎记得看到一个用于指定忽略/排除 glob 的选项，但我似乎无法找到它。

也许有一种方法可以使用管道命令来实现这一点，比如git update-index？

我已经添加说明，我不想依赖修改工作树的解决方案（即：移动/修改.gitignore），因为它已被多次建议。主要是因为这些原因：

1. 有嵌套.gitignore文件
2. 它们的存在和内容依赖于其他 VCS 的状态，我想完全控制
3. 有另一个 VCS 跟踪文件，所以任何修改工作树的东西，除了从其他 VCS 增量获取使事情复杂化
4. 它很可能更慢（尽管可能还不足以成为主要问题）

例如，我有以下分支：

• 主 -> 跟踪原点/主
• 特征/f1 -> 跟踪原点/特征/f1
• feature/f2 -> 跟踪 origin/feature/f2 和 .gitconfig

现在我只想查看功能分支，因此将 .gitconfig 更新为：

有没有办法删除本地存储的主分支，而不在远程服务器上删除它？

--contains选项有什么作用git for-each-ref？

如果它的 revlist--contains在命令行上的选项之后指定了提交，它是否只返回一个引用？（例如，是否git for-each-ref refs/heads --contains feature/test只返回那些在其修订列表中包含提交feature/test的头部？（即它们与第一次提交之间的提交列表，即git rev-list <ref>））？

Git 文档（v. 2.31.1；见这里）实际上已经过时了：Notes底部的部分声明您可以一起使用--mergedand--no-merged选项，但这与此提交不兼容。

文档中提供的定义是模棱两可的：它重用了“包含”这个词，但没有澄清它的含义。引用是仅指向一个 SHA 的名称。“包含”的概念表明引用是指多次提交，这仅在其git rev-list.

提交可以在另一个提交之后或之前（仅通过提交时间），但如果从该提交无法访问（即，如果提交未合并到其分支中），则提交不知道它，因此它可以不要说“包含”它。

这就是为什么--mergedand --no-mergedtogether 是有意义的：它将返回可从（至少一个）到达的提交，--merged而没有一个--no-merged.

“包含”是什么意思？...“有直接父 X”？“有祖先X”？“有表弟X”吗？

更新：

看来我使用的是旧版本的 Git。在 v2.28.1 中同时使用两者--merged和--no-merged一起使用是不兼容的，但现在在 v2.31.1 中是兼容的。因此，Git 文档并没有过时。

似乎此提交是在 2017 年 3 月 21 日进行的，比 v2.31.1 早得多（不确定它到底是用哪个版本提交的）。

其次，@LeGEC 的回答似乎是有道理的（相对于--contains/的--no-contains意思是“给我在他们之后有这个提交的裁判”和--merged/--no-merged意味着“给我在他们之前有这个提交的裁判”。

不过，如果能进一步澄清 Git 文档，那就太好了。像他们所做的那样使用定义中的词是非常模糊的。

因为 Git 是一个有向无环图 (DAG)，所以提交指向一个方向的链表形式的其他提交：时间倒退到它们的祖先。因此，名称--merged/--no-merged及其在“可达性”方面的描述是有意义的。

“包含”是指“之后且可到达”（即孩子），还是简单地“之后”（即稍后做出的提交）？

由于这是一个管道命令（在自定义脚本中使用），我需要确切地知道它的作用以及它是如何工作的，这样我的脚本就不会产生任何意外的副作用。

git 中有多种类型的 ref，其中最常见的一些是分支（存储在 中.git/refs/heads）、远程跟踪分支（.git/refs/remotes）和标签（.git/refs/tags）。

但是也可以创建和使用任意的非标准 refs，这些 refs 存在于.git/refs. 这对于将自定义元数据存储在您不希望用户直接与之交互的存储库中很有用。例如，GitHub 使用这些类型的 refs 来公开对 pull request 分支的引用，并且 Emacs git 客户端Magit在启用适当的设置时使用它们定期保存未提交的更改。此类引用通常需要使用 git 的所谓“管道”命令进行操作，因为面向用户的“瓷器”命令不了解或不支持它们。

我正在使用管道命令玩非标准参考，git update-ref并发现了一些奇怪的行为：

当我创建 refrefs/foo/bar/baz时，git update-ref创建了必要的父目录。当我删除 ref 时，它很聪明地删除了 parent directory bar，该目录现在已变为空。但是，删除“祖父母”目录还不够聪明，删除后该目录foo现在也是空bar的。

这是一个错误吗？