git project size optimization notes, delete large files in history submissions

Preface

Unconsciously, the project has been commit more than 1,000 times and has become 107M.

This is because all submitted data in the project's.git\objects\pack*.pack file is retained and will not be deleted as the file is deleted.

Projects will grow larger and larger over time.

The best way is to delete the remote warehouse and delete the.git folder under the local project, then push it back to the new warehouse after executing the git init.

However, this will result in the deletion of all the historical commit records, which is not possible if you want to roll back to a commit in the future, nor will the company allow it to do so.

So this side dish is also going to learn how to optimize the size of the git warehouse.

1. Sort history submission file size

Executing the following command in the git bash window will sort the file sizes in the history submission in turn

git rev-list --objects --all \
| git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' \
| sed -n 's/^blob //p' \
| sort --numeric-sort --key=2 \
| cut -c 1-12,41- \
| $(command -v gnumfmt || echo numfmt) --field=2 --to=iec-i --suffix=B --padding=7 --round=nearest

Sorting historical submissions shows that most of the time the items get larger because of the files in both folders.

report/app/public/pdf/and report/app/publish/font/

2. See if the file exists

To delete large files, you first need to determine if they can be deleted.

Go to the directory report/app/public/pdf/and report/app/publish/font/below and find that the file has been deleted.

Prove that all file references below these two folders in the history submission can be deleted.

3. Remove a reference to a file in commit

This command only removes the reference to a file in commit. If a commit submits both the file to be deleted and the file to be retained, it only removes the reference to the file to be deleted, not the file to be retained and the current commit record, so there is no need to worry about deleting the file that should not be deleted.

Remove references to a file individually

git filter-branch --force --prune-empty --index-filter 'git rm -rf --cached --ignore-unmatch File Path/file name' --tag-name-filter cat -- --all

Remove references to all files under a folder. I want to remove references to all files under the report/app/public/pdf/folder, so I wrote report/app/public/pdf/*.

git filter-branch --force --prune-empty --index-filter 'git rm -rf --cached --ignore-unmatch report/app/public/pdf/*.*' --tag-name-filter cat -- --all

Start executing commands

Command Execution Completed

Remove Continue Removing References to All Files Below report/app/public/font/Folder

git filter-branch --force --prune-empty --index-filter 'git rm -rf --cached --ignore-unmatch report/app/public/font/*.*' --tag-name-filter cat -- --all

4. Delete pointers to old submissions

rm -rf .git/refs/original/

5. Expire the entire history

Set all unassociated objects to expire now, defaulting to 90 days.

The goal is to discard the possibility of restoring all unassociated objects, since reflog s are the last way to find their trail.

git reflog expire --expire=now --all

6. Repackaging

When this command is executed, a new package file will be generated in the.git\objects\pack directory, and the garbage file will remain in the upper directory of the package.

git repack -A -d

7. gc operations on warehouses

After executing this command, the garbage file you just repack will be deleted, at which point you can see that the warehouse size has been significantly optimized.

git gc --aggressive --prune=now

8. Force push to remote branch

git push --force

9. Think it's over?

You also need to tell your development partners to pull the replacement codes again in a clone fashion and submit the changes.

If someone modifies commit from pre-optimized code, all of the above operations are useless.

10. Re-check project size from remote warehouse clone code