Is there a way to reduce the size of the git folder?

Question

Seems like my project is getting bigger and bigger with every git commit/push. Is there a way to clean up my git folder?

score 235 · Accepted Answer · edited Oct 29 '15 at 01:44

235

I'm not sure what you want. First of all, of course each time you commit/push the directory is going to get a little larger, since it has to store each of those additional commits.

However, probably you want git gc which will "cleanup unnecessary files and optimize the local repository" (manual page).

Another possibly relevant command is git clean which will delete untracked files from your tree (manual page).

edited Oct 29 '15 at 01:44

Aequitas

2,205
1
25
51

answered Jun 25 '10 at 16:58

houbysoft

32,532
24
103
156

31

git clean -d -f -x deletes files listed in .gitignore and such. E.g. workspaces that don't belong in git, Pods folder, etc. – Kalle Jun 14 '13 at 20:02
124

**`WARNING`** The command as written above by @Kalle will remove **EVERY _>UNTRACKED< FILE AND DIRECTORY_ WITHIN YOUR GIT ROOT**, _not_ just "files listed in .gitignore". Anything that is not being tracked by Git, regardless of whether or not it is listed in `.gitignore` will be wiped. `git clean -dfX` (note the case on the `X`) will only remove items which have an applicable rule in `.gitignore`. **Please heed this warning:** _Never run `git clean` without either running it in interactive mode, with `-i` instead of `-f`, or at least doing a dry run first — `-n` and then again with `-f`._ – Adrian Günter Aug 27 '15 at 21:59
6

Or making a backup :-) – Mateen Ulhaq May 04 '17 at 16:20
And making a backup – Lee Goddard Feb 07 '23 at 08:25

score 75 · Answer 2 · edited Mar 25 '14 at 11:33

75

Run:

git remote prune origin

Deletes all stale tracking branches which have already been removed at origin but are still locally available in remotes/origin.

git gc --auto

'G arbage C ollection' - runs housekeeping tasks (compresses revisions, removes loose/inaccessible objects). The --auto flag first determines whether any work is required, and exits without doing anything if not.

edited Mar 25 '14 at 11:33

nimasmi

3,978
1
25
41

answered Feb 25 '13 at 22:26

phamductri

1,351
2
14
18

5

Some explanation of what those do? I know that we can Google them and search for their documentation, but it is a common practice to provide short description of your answer when it involves just code or commands. – Dzhuneyt Mar 04 '14 at 08:18

VonC · Answer 3 · 2019-12-11T17:53:17.667

One scenario where your git repo will get seriously bigger with each commit is one where you are committing binary files that you generate regularly. Their storage won't be as efficient than text file.

Another is one where you have a huge number of files within one repo (which is a limit of git) instead of several subrepos (managed as submodules).

In this article on git space, AlBlue mentions:

Note that Git (and Hg, and other DVCSs) do suffer from a problem where (large) binaries are checked in, then deleted, as they'll still show up in the repository and take up space, even if they're not current.

If you have large binaries stored in your git repo, you may consider:

managing those binaries in an external repository.
manage your .git repo size
try and remove those binaries from your history with git filter-branch (warning: this will rewrite the history, which is bad if you have already pushed your repo and if other have pulled from it)

As I mentioned in "What are the file limits in Git (number and size)?", the more recent (2015, 5 years after this answer) Git LFS from GitHub is a way to manage those large files (by storing them outside the Git repository).

git large file support is helpful if you have large binary files (like images) routinely being added / updated. See https://git-lfs.github.com/. Super easy to implement, supported by github. All team members need to install it to make use of it collaboratively. — Eric Woods, Dec 11 '19 at 17:31
@EricWoods True. I mentioned Git-LFS before (64 times: https://stackoverflow.com/search?tab=newest&q=user%3a6309%20git-lfs). I have edited this old answer accordingly. — VonC, Dec 11 '19 at 17:53
Ha, indeed! Funny how a 9+ year old answer is still relevant (and now even more so with the LFS info). — Eric Woods, Dec 12 '19 at 16:14

score 28 · Answer 4 · edited Jun 20 '20 at 09:12

yes yes, git gc is the solution, naturally,

and locally - you can just delete the local repository and clone it again,

but there is something more important here...

the seconds you wait for that huge git & externals to process are collected to long minutes in which are collected to hours of inefficient time spent,

Create a new (entirely, not just a branch) repository from scratch, including the only recent version of files, naturally you'll loose all the history,

but when in code-world it is not time to get sentimental, there is no point dragging along the entire 5 years of code every commit or diff, you can still store the old git & externals somewhere, if you get nostalgic :]

but, at some point you really have to move along :]

your team will thank you!

Completely agree, we recently took this approach with an old repository and haven't looked back; well, mainly because we can't, but you know what I mean :) — WhatIsHeDoing, Aug 04 '17 at 09:43

Evandro Coan · Answer 5 · 2018-12-04T14:12:56.977

20

Running this command is extremely dangerous, but will shrink your repository by erasing all your git recovery/backup files:

git reflog expire --expire=now --all && git gc --prune=now --aggressive

It will erase all files git uses to recover your repository from some bad command, for example, if you did git reset --hard, you can usually recover the files lost. But if you do git reset --hard before the git reflog expire... command, then you lost everything. Now, your only hope is to use some tool which analyses your file system and try to recover the erased files, if they were not overridden.

edited Dec 04 '18 at 14:12

answered Sep 07 '18 at 21:52

Evandro Coan

8,560
11
83
144

4

I really wouldn’t call this *extremely dangerous*. I’d just label it something you have to be *careful* with. In my experience, very few indeed ever touch the reflog or unreachable objects—most don’t even know they’re there or how to interact with them, and so get stuck in situations where they’d be useful, or do things a terribly inefficient way. I’d go so far as to say that if you don’t know and can’t figure out what these commands will do, then you can safely run them! – Chris Morgan Jan 09 '19 at 02:01

score 12 · Answer 6 · edited Jun 19 '14 at 07:25

12

git clean -d -f -i is the best way to do it.

This will help to clean in a more controlled manner.

-i stands for interactive.

edited Jun 19 '14 at 07:25

brasofilo

25,496
15
91
179

answered Jun 19 '14 at 05:55

anandharshan

5,817
4
34
33

5

While the OP's question is vague, and this is a good answer in that respect, I do want to point out that `git clean` is not for cleaning up the repo so much as cleaning up the directory. For users who blindly copy/paste, beware; this removes untracked files/dirs you might actually want locally. – sraboy Feb 01 '18 at 14:46
git clean -d -x -f works nicely if you want to deep clean – Rishabh Jain Mar 20 '19 at 09:38

score 1 · Answer 7 · edited Feb 26 '19 at 01:31

1

Don't know if it will shrink it, but after I run git clean, I often do git repack -ad as well, which reduces the number of pack files.

edited Feb 26 '19 at 01:31

Corey

1,217
3
22
39

answered May 14 '15 at 02:09

Damien Sawyer

5,323
3
44
56

6

repack is a part of `git gc` process, so no need to run it separately – artkoshelev Aug 25 '16 at 21:02

Is there a way to reduce the size of the git folder?

7 Answers7

but there is something more important here...

Linked