问题标签 [git-history-graph]

从 master 分支有两个分支：develop 和 foo。develop 和 foo 都与 master 发生了几次提交不同。

foo 已合并到开发中。现在 foo 和 develop 指向同一个合并提交，即提交的两个“流”在这个合并提交中相遇（对于近似词汇表示歉意）。

此合并提交中的代码与应有的完全一致。没有什么是应该撤消的。

现在假设没有人会想要检查 foo 的任何先前提交。所以，我们想“删除”这些提交（即不撤消这些提交带来的修改，只是没有它们在历史记录中。事实上，查看历史记录，它看起来好像 foo 从未存在过，并且合并提交不再是两个“提交流”的交汇点）。

当然，如果 foo 在合并到 develop 之前被压扁会更好，但这并没有发生。

在合并后尝试 rebase/squash foo 以解决一些冲突。由于代码与合并提交中的代码完全相同，因此不需要解决冲突（免责声明：可能是未以正确的方式尝试此变基）。

有没有办法做到这一点 ？

在此SO 问题中，提供了有关使用开箱即用 vscode“时间轴视图”体验的详细信息，作为从文件范围角度查看提交历史记录和差异的一种方式。

是否存在开箱即用的 vscode 支持，用于对提交历史进行 gui 审查，即git log，然后区分它的内容，即git show <commit id>，从提交范围而不是时间线文件按文件范围或扩展市场提供，例如GitLens、Git History或吉特图？

我在 git 中有以下历史记录：

现在我在 b2 上，我想明白 b2 分支的地方（7be9db9）。算法如下：

1. 获得下一次提交
2. 检查提交所属的分支
3. 如果只有当前分支，则继续 1. step else 4.step
4. 提交属于多个分支，这一定是我们分支的点

但是，如果我想对 b1 做同样的事情，我最终会在同一个位置 - 7be9db9。但我预计最终会在 22601c0，因为这是 b1 分支的点。历史就是这样创造的。

来自 master (b1) 的初始提交分支和提交来自 b1 (b2) 的 file1 分支和提交 file2 checkout b1 并提交 search.py

恐怕git的设计方式，无法区分，commit 7be9db9(file1)是b1还是b2创建的，对吗？所以不能说b1的父母是master还是b2？

感谢您的确认。

feature/XY是功能分支的名称，当前已签出。feature/XY-refactor是另一个分支的名称，它从feature/XY.

当我运行时git log --oneline，我得到下面的输出。这两个在日志输出的最顶部一个接一个是什么意思？我在 Windows 上使用 git bash。

在处理补丁时，我希望提供一组干净的提交。因此，我经常发现自己在提交集干净并准备好合并之前反复重写历史记录。
在这个过程中，在收到审稿人的意见后，我会回去rebase -i修复我的代码，修复提交消息等。每次创建一个新的修订提交来替换之前的提交。先前的提交仍然存在，但不再是修订历史的一部分。

经过几次历史重写迭代后，我终于得到了一个干净的修订提交集，我可以推送或转换为补丁集。但现在我有时喜欢回顾一下我对一个或一组提交所做的更改历史，看看我在这个历史重写过程中做了什么。
我可以手动跟踪它——在某个地方写下我正在编辑的每个提交的提交哈希，然后再重写它。这样我可以回顾历史重写的历史，但这很乏味且容易出错。

有没有办法自动化这个，让 git 自己跟踪“二阶”历史——历史重写的历史？获取一个git log'提交，以显示历史上为生成该提交而执行的所有“修改”操作？