쓰고 있는 git 저장소 데이터 크기가 점점 커지고 있다면, 저장소의 데이터 크기를 줄여서 git이 매끄럽게 잘 작동하도록 합시다. bitbucket 같은 경우, 한 저장소에 2GB까지 허용해줍니다. 2GB의 저장소 용량은 파일 크기뿐만 아니라 git 히스토리를 포함한 용량입니다.
git은 커밋을 기반으로 합니다. 한 저장소에 몇 번이든 커밋을 할 수 있습니다. 커밋을 사용하는 것의 장점은 커밋을 통해 소스 코드를 재생성할 수 있습니다. 커밋 한 번으로 코드의 변화를 포함한 소스코드 전체를 재생성한다는 거죠. 그것이 버전 관리의 힘입니다. 멋지죠?
우리는 git의 부작용(side effect)를 이해하고 있어야 한다는 것 명심하세요. 우리가 적절한 방법으로 git을 사용한다면 부작용이라고 부를 순 없겠죠. 말씀드렸듯이 git은 당신이 변경한 코드를 한 줄 한 줄 다 보관합니다, 거대하겠죠. 그러나 git은 강력한 압축 메커니즘을 통해 당신의 코드를 아주 조그만 청크로 만들어버립니다. 그리고 코드의 변화 전후 차이만을 보관하여 용량을 줄입니다.
저장소를 클론 하는 것은 깃 히스토리를 포함한 저장소 전체를 복사합니다. 만약 JAR 파일 같은 거대한 파일을 커밋하면 그 이후의 모든 클론은 그 파일을 포함하게 됩니다. 심지어 결국 프로젝트에서 그 파일을 삭제하여 커밋하더라도 git 히스토리에 파일은 여전히 남아있습니다.
git 내용물은 실제 소스 코드의 크기보다 작을 것입니다. 그러나 그런 경우에도, 크기가 큰 파일을 계속해서 커밋하면 저장소 크기는 버전 히스토리를 관리하느라 계속 늘어날겁니다. git이 매끄럽게 잘 작동하게 하기 위해선 저장소 크기를 줄여줄 필요가 있어요.
git 저장소 크기를 100MB에서 300MB 사이로 관리하는 것이 이상적입니다. 몇가지 예를 들자면 git 자체는 222MB, Mercurial은 64MB, Apache는 225MB입니다.*
bitbucket에는 Soft limit과 Hard limit, 두 가지의 저장소 용량제한이 있습니다.
Soft Limit (1GB) : 저장소 용량이 1GB에 도달하면 당신은 소프트 리밋에 도달한 겁니다. bitbucket은 사용자에게 용량 제한에 대한 알림을 줍니다. 사용자는 여전히 커밋과 푸시를 계속할 수 있어요. 그렇지만 그 이후로는 하드리밋에 도달할 때까지 지속적인 관리를 해줘야 합니다.
Hard limit (2 GB) : 저장소가 멈추는 용량 제한입니다. 용량을 줄이기 전까진 추가적인 행동을 할 수 없습니다.
git 저장소의 용량을 줄이는 것은 몇가지 방법이 있습니다. 가장 먼저 알아야 할 것은 저장소의 실제 사이즈를 파악하는 것입니다.
git count-objects -v이 명령어로 저장소의 용량 전체를 볼 수 있습니다.
저장 공간을 줄이기기 위해선 git 히스토리를 새로 써야합니다. git 히스토리를 새로 쓰는 건 아주 중요한 작업이고 한 번 히스토리를 새로 쓰면 과거 버전의 커밋으로 되돌아갈 수 없다는 걸 절대 잊지 마세요! 그러니 히스토리를 새로 쓰기전에 깃 저장소를 백업해두는게 좋겠죠?
git을 백업하는 방법은 몇가지가 있습니다.
-
zip 파일로 git 소스 코드를 다운로드 받으세요. 코드 재사용을 위해 안정적이고(stable) 업데이트된 브랜치에서 다운 받았는지 확인하세요. Bitbucket과 깃헙은 특정 브랜치를 선택해서 다운로드 받을 수 있게 옵션을 제공하고 있습니다. 로그인해서 옵션을 찾아보세요.
-
로컬에 저장소를 클론해서 어딘가 보관하세요. 위에서 언급했듯이 저장소를 클론하는 것은 git 히스토리를 다 포함하고 있기때문에 저장소 크기가 리모트랑 완전히 같습니다.
git clone repo_name.git
-
git bare 명령어로 저장소를 클론하세요. bare 저장소로 클론할 수 있습니다. 리모트 저장소와 완전 같은 저장소를 로컬에 가질 수 있다는 말인데요, 로컬에 일반 클론도 할 수 있다는 것을 의미합니다. bare 저장소는 리모트에 저장하는 방식대로 되어있는 코드로 구성되어있습니다.
git clone repo_name.git — bare
백업 한 뒤에는 저장소 정리를 시작할 수 있습니다. 크기가 큰 파일을 커밋했었고 git 히스토리에서 완전히 지워버리길 원한다면
- 프로젝트의 현재 파일 트리에서 파일을 지우세요.
- 저장소 히스토리에서 파일을 지우세요. (git 히스토리를 재작성하고 파일 정보가 포함된 모든 커밋 삭제)
- 오래된 git 히스토리에 적용되어있는 모든 reflog 히스토리를 모두 제거합니다.
- repack the repository, garbage-collecting the now-unused data using git gc
git gc명령어로 현재 사용되지 않는 데이터들을 가비지 콜렉팅으로 저장소를 repack하세요.
또 다른 방법으로는, git에게 현재의 커밋이 초기 커밋이라고 말해주는 것입니다. 그러기 위해선 먼저 초기 커밋으로 만들고 싶은 커밋을 체크아웃 한 뒤, 다음 명령어들을 실행시키세요:
git checkout — orphan latest_branch
git add -A
git commit -am “초기 커밋 메세지” #변경내용 커밋
git branch -D master #마스터 브랜치 삭제
git branch -m master #브랜치 이름을 마스터로 변경
git push -f origin master #마스터 브랜치로 푸시
git gc — aggressive — prune=all #오래된 파일 삭제위의 명령어들은 강제로 현재의 소스 코드를 마스터 브랜치에 푸시합니다.
기억할 것: 다른 모든 브랜치와 태그를 삭제해야 합니다. 오래된 히스토리를 여전히 가지고 있을 가능성이 있거든요.
참고:
- https://confluence.atlassian.com/bitbucket/reduce-repository-size-321848262.html
- https://stackoverflow.com/questions/13716658/how-to-delete-all-commit-history-in-github/26000395#26000395
- https://www.atlassian.com/git/tutorials/rewriting-history
To give you some examples: Git itself is 222MB, Mercurial itself is 64MB, and Apache is 225MB.
*Mercurial은 git 과 같은 버전 관리 시스템이라는 것을 알게 되었습니다. 그 다음 문장의 각각의 용량은 정확하게 어떤 의미인지 파악하지 못 했습니다.
repack 이란 git 명령어에 대해서 알게 되었습니다. 잘 공부해서 저장소의 용량이 많이 커졌을때, 가비지 컬렉팅과 함께 잘 활용해보면 좋을 것 같습니다.
