10

我的 Git 存储库有数百 GB 的数据，比如数据库备份，所以我正在尝试删除旧的、过时的备份，因为它们使一切变得更大、更慢。所以我自然需要快速的东西；越快越好。

我如何压缩（或只是简单地删除）除了最近的提交之外的所有提交，并且不必在交互式 rebase中手动压缩每个提交？具体来说，我不想使用

git rebase -i --root

例如，我有这些提交：

A .. B .. C ... ... H .. I .. J .. K .. L

我想要的是这个（将所有内容压缩到之间A）：HA

A .. H .. I .. J .. K .. L

甚至这也可以正常工作：

H .. I .. J .. K .. L

有一个关于如何压缩所有提交的答案，但我想保留一些最近的提交。我也不想压缩最近的提交。（特别是我需要保持前两个提交从顶部开始计数。）

（编辑，几年后。这个问题的正确答案是使用正确的工具来完成这项工作。Git 不是存储备份的好工具，无论它多么方便。有更好的工具。）

4

3 回答 3

3

原海报评论：

如果我们拍摄提交 10004 的快照，删除之前的所有提交，并将提交 10004 设为根提交，我会没事的

一种方法是在这里，假设您当前的工作被称为branchname. 每当我进行大型变基时，我都喜欢使用临时标签来仔细检查是否没有更改，并在出现问题时标记我可以reset返回的点（不确定这是否是标准程序，但它适用于我):

git tag temp

git checkout 10004
git checkout --orphan new_root
git commit -m "set new root 10004"

git rebase --onto new_root 10004 branchname

git diff temp   # verification that it worked with no changes
git tag -d temp
git branch -D new_root

要摆脱旧分支，您需要删除其上的所有标签和分支标签；然后

git prune
git gc

将从您的回购中清除它。

请注意，您将暂时拥有所有内容的两份副本，直到您拥有gc'd，但这是不可避免的；即使你做了一个标准的 squash 和 rebase，你仍然有两个副本，直到 rebase 完成。

于 2014-06-11T02:27:23.500 回答
2

最快的计数实现时间几乎肯定会使用嫁接和filter-branch，尽管您可以使用手动提交树序列处理rev-list输出来获得更快的执行速度。

Rebase 旨在将更改应用于不同的内容。你在这里所做的是保留内容并故意丢失产生它们的更改历史，因此几乎所有 rebase 最乏味和缓慢的工作都被浪费了。

这里的有效载荷是，根据你的图片工作，

echo `git rev-parse H; git rev-parse A` > .git/info/grafts  
git filter-branch -- --all

git rev-parse和的文档git filter-branch。

Filter-branch 非常小心地在任何时候发生故障后可以恢复，这当然是最安全的....但是只有在通过简单地重做恢复时它才真正有帮助，如果事情不顺利的话，它不会更快更容易。故障很少见，重新启动通常很便宜，要做的是做一个不“安全”但非常快速的操作，几乎肯定会工作。为此，最好的选择是在 tmpfs 上进行（我在 Windows 上知道的最接近的等价物是ImDisk之类的 ramdisk ），这将非常快，并且在您确定之前不会触及您的主仓库已经得到了你想要的结果。

所以在 Windows 上，比如说T:\wip是在一个 ramdisk 上，并注意这里的克隆不会复制任何东西。除了阅读git clone's --sharedoption 上的文档外，请检查克隆的内部结构以查看真实效果，这非常简单。

# switch to a lightweight wip clone on a tmpfs
git clone --shared --no-checkout . /t/wip/filterwork
cd !$

# graft out the unwanted commits
echo `git rev-parse $L; git rev-parse $A` >.git/info/grafts
git filter-branch -- --all

# check that the repo history looks right
git log --graph --decorate --oneline --all

# all done with the splicing, filter-branch has integrated it
rm .git/info/grafts

# push the rewritten histories back
git push origin --all --force

您可能想要做的事情以及您的存储库中可能存在的内容有足够多的可能变化，因此这些命令上的几乎所有选项都可能有用。上面的内容已经过测试，并且会按照它所说的去做，但这可能不是你想要的。

于 2014-07-23T18:46:58.903 回答
1

XY 问题

请注意，原始发布者有一个XY 问题，他试图弄清楚如何压缩他的旧提交（Y 问题），而他真正的问题实际上是试图减小他的 Git 存储库的大小（X 问题），如我在评论中提到过：

有很多提交不一定会使 Git 存储库的大小膨胀。Git 在压缩基于文本的文件方面非常有效。您确定提交的数量是导致您的大型 repo 大小的实际问题吗？一个更有可能的候选者是你有太多的二进制资产版本，与纯文本文件相比，Git 没有压缩（或根本没有）。

尽管如此，为了完整起见，我还将为Matt McNabb对 Y 问题的回答添加一个替代解决方案。

压缩（数百或数千）旧提交

正如原始海报已经指出的那样，--root当有许多提交（数量为数百或数千）时，使用带有标志的交互式 rebase 可能是不切实际的，特别是因为交互式 rebase 不会在如此大量的提交上有效运行。

正如马特麦克纳布在他的回答中指出的那样，一种解决方案是使用孤立分支作为新的（压扁的）根，然后在此基础上重新设置基础。另一种解决方案是使用几个不同的分支重置来达到相同的效果：

# Save the current state of the branch in a couple of other branches
git branch beforeReset
git branch verification

# Also mark where we want to start squashing commits
git branch oldBase <most_recent_commit_to_squash>

# Temporarily remove the most recent commits from the current branch,
# because we don't want to squash those:
git reset --hard oldBase

# Using a soft reset to the root commit will keep all of the changes
# staged in the index, so you just need to amend those changes to the
# root commit:
git reset --soft <root_commit>
git commit --amend

# Rebase onto the new amended root,
# starting from oldBase and going up to beforeReset
git rebase --onto master oldBase beforeReset

# Switch back to master and (fast-forward) merge it with beforeReset
git checkout master
git merge beforeReset

# Verify that master still contains the same state as before all of the resets
git diff verification

# Cleanup
git branch -D beforeReset oldBase verification

# As part of cleanup, since the original poster mentioned that
# he has a lot of commits that he wants to remove to reduce
# the size of his repo, garbage collect the old, dangling commits too
git gc --prune=all

--prune=all选项将git gc确保所有悬空提交都被垃圾收集，而不仅仅是那些超过 2 周的提交，这是git gc.

于 2014-06-11T15:02:27.253 回答