GitLab에서 Git 오브젝트 중복 제거가 작동하는 방식

GitLab에서 포크 시 Git 오브젝트 중복 제거를 구현하는 방법과 풀 리포지터리, SQL 모델, Gitaly 일관성, Geo 연동에 대해 설명합니다.

GitLab 사용자가 프로젝트를 포크 하면, GitLab은 포크 시점의 원본 프로젝트 복사본인 Git 리포지터리가 연결된 새 프로젝트를 생성합니다. 대규모 프로젝트가 자주 포크될 경우, Git 리포지터리 스토리지 디스크 사용량이 빠르게 증가할 수 있습니다. 이 문제를 해결하기 위해 GitLab에 포크를 위한 Git 오브젝트 중복 제거 기능을 추가하고 있습니다. 이 문서에서는 GitLab이 Git 오브젝트 중복 제거를 어떻게 구현하는지 설명합니다. 풀 리포지터리 # Git alternates 이해하기 # Git 수준에서는 Git alternates 를 사용하여 중복 제거를 달성합니다. Git alternates는 리포지터리가 동일 머신의 다른 리포지터리에서 오브젝트를 빌려올 수 있게 해주는 메커니즘입니다. 리포지터리 A가 리포지터리 B에서 빌려오도록 만들려면 다음을 수행합니다: 특수 파일 A.git/objects/info/alternates 에 B.git/objects 로 해석되는 경로를 작성하여 alternates 링크를 설정합니다. 리포지터리 A에서 git repack 을 실행하여 리포지터리 B에도 존재하는 모든 오브젝트를 A에서 제거합니다. repack 후, 리포지터리 A는 더 이상 자급자족하지 않지만 자체 refs와 설정은 유지됩니다. B에 없는 A의 오브젝트는 A에 남아 있습니다. 이 구성이 제대로 작동하려면 리포지터리 B에서 오브젝트를 삭제하면 안 됩니다 . 리포지터리 A가 해당 오브젝트를 필요로 할 수 있기 때문입니다. @pools 디렉터리에 저장된 오브젝트 풀 리포지터리에서는 git prune 또는 git gc 를 실행하지 마십시오. 이는 오브젝트 풀에 의존하는 일반 리포지터리에서 데이터 손실을 일으킬 수 있습니다. 위험은 git prune 에 있으며, git gc 는 git prune 을 호출합니다. 풀 리포지터리에서 실행될 때 git prune 은 오브젝트가 더 이상 필요하지 않은지 신뢰할 수 있게 판단하지 못하는 문제가 있습니다. GitLab에서의 Git alternates: 풀 리포지터리 # GitLab은 사용자에게 숨겨진 특수 풀 리포지터리 를 생성 하여 이 오브젝트 빌려오기를 체계적으로 관리합니다. 그런 다음 Git alternates를 사용하여 프로젝트 리포지터리 컬렉션이 단일 풀 리포지터리에서 빌려오도록 합니다. 이러한 프로젝트 리포지터리 컬렉션을 풀이라고 부릅니다. 풀은 단일 풀에서 빌려오는 리포지터리의 별 모양 네트워크를 형성하며, 이는 사용자가 프로젝트를 포크할 때 형성되는 포크 네트워크와 유사하지만(완전히 동일하지는 않습니다). Git 수준에서 풀 리포지터리는 Gitaly RPC 호출을 사용하여 생성 및 관리됩니다. 일반 리포지터리와 마찬가지로, 어떤 풀 리포지터리가 존재하는지와 어떤 리포지터리가 풀에서 빌려오는지에 대한 권한은 SQL의 Rails 애플리케이션 수준에 있습니다. 결론적으로, Git 수준에서 GitLab 프로젝트 리포지터리 컬렉션 전체에 걸쳐 효과적인 오브젝트 중복 제거를 위해서는 세 가지