Git 删除提交会删除对象repo中的更改吗

在git中删除提交真正做什么？我会零钱吗。实际上不应该这样，因为每次提交都会有工作目录的整个快照。这应该不是问题

我正在考虑恢复合并。我发现每个人都在谈论重新合并合并提交时，都不会接受原始合并的更改

编辑

以下是上下文。。

它讨论了丢失99个更改…丢失的原因是什么…每次都是快照…我想问题是，提交中保存了什么，以及在播放时会发生什么（在cherry pick或rebase的情况下）

---

最近的提交还不够。

提交是给定时间内整个存储库的快照。它包括：

• 指向包含repo状态的树对象的指针-其他树、blob（文件）

• 元数据-谁引入了变更等

• 指向父对象的指针

• 识别信息

此提交对象存储在.git/objects中。我强烈建议不要直接修改这个

git revert将引入与给定提交的更改相反的更改（在您的案例中是最后一次合并提交，即HEAD）。现在这实际上是一个新的提交。 我觉得这不是你想要的。相反，听起来您希望从存在中删除合并提交，然后再次合并

你可以做：

git reset HEAD~1

这将使头指针返回到合并前的状态。原始合并提交引入的任何更改仍将位于工作目录中。为了摆脱这些，你可以这样做

git reset --hard

现在，合并提交仍将存在一段时间。如果需要，可以通过遍历ref日志来检索指向它的指针

git log -g 

最终，此提交将被垃圾收集

您实际上无法删除提交。与中一样，您可以“将其重置”，使其不是来自当前分支提示。如果无法从所有外部引用（包括reflog引用）访问它，

git-gc

通常会在此时抛出它

我发现整个事情在Mercurial中更容易解释，在Mercurial中，您运行

hg strip-r

删除修订版

及其所有后代。您必须在Git中执行相同的操作，以使提交变得不可访问，因为每个后代提交（子、孙子、大孙子等等）都将要剥离的提交的哈希ID编码为其组成哈希ID的一部分。因此，必须放弃提交的所有子代。如果您想保留大多数人都会保留的子体，则必须将这些快照及其元数据的新副本“移植”到一个新的子体链中，该子体链是从要“剪断”的提交的父项派生而来的

在Git中实现这一点的主要方法是使用

Git过滤器分支

。

git-filter-branch

命令只是复制每个提交（或者更准确地说，根据引用名称和作为参数提供的其他限制，复制存储库某个受限子集中的每个提交）。要制作副本，请执行以下操作：

摘录原文

按顺序应用每个过滤器；及

提交结果

如果新提交与原始提交完全相同，则它们最终将使用相同的哈希ID。如果任何位发生更改，新提交将具有新的、不同的哈希ID，并且该新ID将作为后续子级的父级的输入

当git filter分支从一个提交移动到另一个提交时，它将构建一个“旧哈希ID”到“最近的适当新哈希ID”的映射。此映射是如何在复制操作期间将要剪切或修改的提交的子级重新设置为父级的映射

--parent filter

允许您对父散列ID进行任意更改，

--commit filter

可以故意跳过提交。有关详细信息，请参阅。但是，请注意，

git filter分支

遵循由

git replace

创建的替换对象，因此您可以使用

git replace

拼接出一些提交，然后如果需要，使用no op

git filter分支

在遵循替换的同时复制所有内容，有效地形成一个新的提交图，它缺少拼接出的提交

完成此操作并指示git filter branch更新适当的外部引用（主要是分支名称和标记）后，您就有了一个新的存储库，该存储库将省略您希望省略的提交

---

git过滤器分支

中存在一个缺陷，它对

git注释

没有任何用处。默认情况下，

git-rebase

命令将复制注释。在某些有限的情况下，可以使用复制提交的交互式rebase删除提交，但由于目标不同，

git rebase

使用

git cherry pick

进行复制，这与

git filter branch

的行为方式不同。

你说的“删除提交”是什么意思？你能告诉我们你所指的确切情况和命令吗？也许通过相关提交的

git log--graph--decoration--oneline

，我已经添加了上下文并在编辑部分进行了更新