在运行git log --graph --oneline时，我只看到与某些分支(本地和源)或标签关联的提交(以及父提交和父提交等)。
也就是说，如果我在分支上重置为以前的提交并进行新的提交，则会创建一个新的历史记录行。现在，如果我将新的本地历史记录行与原点合并，我会看到旧的历史记录行不再显示在图形中(除非标记了旧的历史提示)。
即使在查询整个存储库日志似乎也没有帮助git log --graph --oneline -all
所以，想知道 git 日志/图形拾取(显示)是否仅与某些分支或标签相关联的提交？有人可以确认或纠正。
编辑- 根据罗曼瓦莱里的回答
来自 git 文档：
git-log - 显示提交日志
从实际观察和回答来自 - 罗曼瓦莱里
git log --graph --oneline --all
输出所有分支/标记历史记录
那么有没有办法使用 git log 或任何其他备用命令/工具查看每个提交的日志(包括悬空提交，即与任何分支/标签无关的提交)。
是的，默认情况下需要HEAD，但您可以给它提供任何 ref ：
git log --graph --oneline
# outputs history backwards from HEAD
git log --graph --oneline branch-1
# outputs only branch-1 history
git log --graph --oneline --all
# outputs all branch histories
为了解决您在下面的评论：对于--all的情况，这并不意味着它需要所有提交，而是所有引用。因此，将探索所有refs/目录(以及HEAD)
在新范围后编辑：
要查找丢失(悬空)提交，请使用fsck
git fsck --lost-found
最后，要将两者链接起来，您可以嵌套命令。
git log --graph --oneline $(git fsck --lost-found | sed -E 's/dangling (tree|commit|blob|tag) //')
这有点不清楚，但是在更新后，您的主要问题似乎是：
那么有没有办法使用 git log 或任何其他备用命令/工具查看每个提交的日志(包括悬空提交，即与任何分支/标签无关的提交)。
简短的(但仍然大部分准确)的答案是：不是真的。
如果您签出了悬空提交(即HEAD与所有引用分离并发散)，那么您可以看到该历史记录。 可以查看reflogs的历史记录(存储库的分支和HEAD过去指向的位置的本地记录)，以查看可能无法从任何当前引用访问的历史记录。 还有其他类似的例外。 您甚至可以为 git 提供一个特定的提交 ID 以查看导致该提交的历史记录。
但无论如何，你必须告诉git log从哪里开始行走;它不是为了寻找悬空的提交并在那里开始行走而设计的。
在我得出结论之前 - 以及"不是真的"的原因只是大部分正确 - 我想指出，如果你有一个--all无法到达的提交，那么gc从该提交下拉出地毯只是时间问题 - 因为据它所知， 此类提交未使用。 大多数git命令都做出了与日志相同的假设：有用的提交可以从 refs(分支、标签等)访问，所以即使你禁用了gc以避免此类提交被删除(不是一个好主意)，你仍然会永远试图说服 git 使用它们。
因此，唯一合理的建议是，在编写要保留的代码时，不要养成在分离的头状态工作的习惯;如果你正在编写想要保留的新更改，然后意识到你处于分离的头中，请创建一个分支。
但是对于技术上更完整的答案，我会注意到 git 有一个命令，其工作是找到悬而未决的提交。 您可以使用git fsck找到无法访问的对象(假设它们尚未被gc清理)，然后将生成的 SHA ID 值提供给log。 您甚至可以安装一个脚本来执行此操作。
恐怕在这一点上这有点漫无边际，因为问题本身有点没有重点。 你从git log开始，徘徊在git gc领域。:-)
Git 具有可见的引用，例如HEAD、分支名称和标记名称。 但 Git 也有不太明显的引用，例如 reflogs 和不可见的引用。 最后一个特别棘手：
-
暂时忽略
git worktree add，让我们看看不可见的参考。 这些是索引中的条目！ 它们直接引用 Blob 对象(仅)，但出于git gc目的，它们使这些 Blob 保持活动状态。 -
现在让我们加入
git worktree add. 添加工作树时，添加的工作树将获得自己的索引、HEAD和一组特定于工作树的特殊引用(ORIG_HEAD、git bisect引用等)。git gc和git fsck命令必须检查所有这些引用。 在 Git 2.5 中，当git worktree第一次进入时，他们没有！ 直到 Git 2.15 之前，这个问题才得到解决。 这样做的结果是，当git gc运行时，它可能会丢弃某些添加的工作树中使用的数据：仅存储在添加的工作树索引中的对象，或只能从添加的工作树的分离 HEAD 访问的提交被遗漏，并且可以在修剪到期后进行 GCed(默认值 = 14 天)。
你可以git log-g遍历 reflog，也可以让它用--all遍历所有正常的引用。 但是，--all标志仅查看此工作树的特定于工作树的引用。 同时，git fsck和git gc必须查看所有引用，包括 reflogs 以及不可见和每工作树引用。 如果你的 Git 在 2.5 到 2.15 之间，这是坏的，所以要小心使用添加的工作树太久。 (我自己也被这个特殊的错误咬了。 幸运的是，添加的工作树中没有任何重要内容。
锻炼(无需偷看源头即可发现)：refs/stash是每个工作树，还是全局的？ (我自己也不知道答案。
有没有办法查看每个提交的日志(包括悬空提交，即那些与任何分支/标签无关的提交)
通常，向命令中添加--reflog就足以查看您在上个月左右所做的或放弃的每个提交，无论它是否在任何当前历史记录中。
可以在不创建 reflog 条目的情况下生成和放弃提交，但很难想象为什么要寻找这些。 找到所有幽灵提示的方法，--reflogs无法到达的，因为它们很久以前就被遗弃了，或者是由认为自己不需要臭味的 reflogs 的本土工作流程/脚本生成的
git fsck --connectivity-only --unreachable --no-dangling