【问题标题】:Clean up large files on git server清理 git 服务器上的大文件
【发布时间】:2015-11-03 03:15:35
【问题描述】:

有人不小心将一些大型(多 GB)二进制文件提交到我的自托管 gitlab 存储库中,现在每次有人尝试从存储库中提取时,服务器都会受到严重打击。

我尝试通过强制推送删除对文件的任何引用,但它似乎仍然会影响服务器。有没有办法强制gitlab服务器摆脱它?

我阅读了一些诸如 filter-branch 之类的东西,但我不确定这会对裸仓库产生什么影响,或者我什至如何在我不再引用的提交中使用它。

更新:作为参考,这些类型的消息出现在 gitlab VM 的控制台上:

[ 5099.922896] Out of memory: kill process 6200 (git-upload-pack) score 1053982 or a child
[ 5099.922908] Killed process 6202 (git)
[ 5099.930796] Out of memory: kill process 6200 (git-upload-pack) score 360394 or a child
[ 5099.930807] Killed process 6203 (git)
[ 5099.938875] Out of memory: kill process 6200 (git-upload-pack) score 360394 or a child
[ 5099.938886] Killed process 6203 (git)
[ 5099.951163] Out of memory: kill process 6139 (git-upload-pack) score 324327 or a child
[ 5099.951174] Killed process 6151 (git)

【问题讨论】:

  • 您是如何尝试删除文件的?
  • @Tim - 我创建了一个提交来还原不需要的文件,然后将其压缩到原始提交中,因此就分支历史而言,它不再存在,但它仍然在 Git 的内部浮动某处。
  • @VonC - 看起来它可能有潜力。如果我运行 BFG、gc 和其他东西然后推送到远程,它会在远程中引起相同的变化吗?还是应该直接在服务器上运行这些工具?
  • @Karl 我也会在服务器上运行这些命令。

标签: git gitlab


【解决方案1】:

正如OP Karl 确认in the comments,在服务器端(直接在裸存储库中)运行BFG repo cleaner 足以删除大型二进制文件。

如果您遵循(如“Git - Delete a Blob”中所述):

rm -rf .git/refs/original/
git reflog expire --expire=now --all
git gc --prune=now
git gc --aggressive --prune=now

还有(“git gc --aggressive vs git repack”):

git gc
git repack -Ad      # kills in-pack garbage
git prune           # kills loose garbage

你最终应该得到一个更苗条更小的裸仓库。

【讨论】:

    【解决方案2】:

    为此,您将打破从该提交推送的任何人的存储库的历史记录。你必须告诉他们。

    您需要对远程存储库进行 rebase 并删除此提交。

    首先,在你的仓库中变基。

    git rebase -i problematicCommit~1
    

    这将打开您的默认编辑器。删除提交有问题的提交的行。保存文件并关闭它。

    删除远程存储库中的分支。

    git push origin :nameOfTheBranch
    

    查看分支名称前的点。

    最后,在远程再次创建分支。

    git push origin nameOfTheBranch
    

    这会在没有冲突提交的情况下在远程重新生成分支,并且新的克隆将再次快速。

    现在,如果您仍然注意到您的存储库运行缓慢。您可以删除它拥有的未跟踪对象(例如具有此大文件的对象)。

    首先,删除所有可能指向旧提交的标签和分支。这很重要,因为要能够擦除旧的提交,它们必须不被跟踪。

    然后,按照 VonC 评论 stackoverflow.com/a/28720432/6309 - 在您的存储库和远程执行:

    git gc
    git repack -Ad
    git prune
    

    【讨论】:

    • 这大约是我已经尝试过的,唯一的区别是我使用git push -f 而不是删除并重新创建分支。我不认为会有什么不同,因为历史已经过去了。服务器仍然有不稳定的内存使用,这让我相信有问题的对象仍在被反弹。
    • 这是不同的,因为在变基之后,在分支中有问题的对象永远消失了。但是,您可以通过 VonC 的链接删除这些未跟踪的对象。我把方法写在我的答案中。
    【解决方案3】:

    遇到同样的问题,解决问题的过程非常复杂。

    我们在 Docker 容器中运行社区维护的 sameersbn/gitlab11.4.5。我不想在那里安装bfg,但选择在本地执行更改。

    # Install the bfg tool, ex. on MacOS via homebrew
    brew install bfg
    
    # Clone repo locally
    cd ~/Development
    git clone --mirror ssh://git@server.com:22/some/dir/myrepo.git
    
    # Clean the repo
    bfg --delete-files \*.pdf myrepo.git
    cd myrepo.git
    rm -rf .git/refs/original/
    git reflog expire --expire=now --all
    git gc --prune=now
    git gc --aggressive --prune=now
    
    # Upload to container-host, e.g. via FileZilla
    
    # Connect to the container-host via ssh
    
    # Rename the original directory in the container, to have a backup
    docker exec -it gitlab /bin/bash
    mv /home/git/data/repositories/some/dir/myrepo.git /home/git/data/repositories/some/dir/myrepo.git.mybackup
    exit
    
    # Copy from container-host into container
    docker cp /root/Documents/myrepo.git gitlab:/home/git/data/repositories/some/dir/myrepo.git
    
    # Fix permissions in container
    docker exec -it gitlab /bin/bash
    cd /home/git/data/repositories/some/dir/myrepo.git
    find . -type f -print0 | xargs -0 chown git:git
    chown -R git:git /home/git/data/repositories/some/dir/myrepo.git
    chmod 770 /home/git/data/repositories/some/dir/myrepo.git
    
    # Re-create the "hooks" subdir with some symlinks in the repo
    cd /home/git/gitlab/bin
    ./rake gitlab:shell:create_hooks
    
    # Clear Redis cache (unclear if needed)
    ./rake cache:clear
    exit
    
    # Clone the changed repo locally again, also tell everyone who got a copy to clone again (history is broken now)
    
    # Then do a commit to the repo, to hit the hook and trigger a size recheck
    

    【讨论】:

    • 有趣的替代过程。 +1
    猜你喜欢
    • 2012-03-09
    • 2012-04-25
    • 2015-02-27
    • 1970-01-01
    • 1970-01-01
    • 2019-03-23
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多