자식은 파일을 어떻게 저장합니까?

225

나는 git을 배우기 시작했고 Git Community Book을 읽기 시작 했다.이 책에서 그들은 SVN과 CVS가 파일의 차이점을 저장하고 git은 모든 파일의 스냅 샷을 저장한다고 말합니다.

그러나 나는 그들이 스냅 샷의 의미를 실제로 얻지 못했습니다. git은 각 커밋의 모든 파일을 실제로 복사합니까?

추신 : git을 배울 수있는 더 좋은 소스가 있다면 감사하겠습니다.

git

— mteffaha
소스

다음은 git 작동 방식을 자세히 설명 하는 훌륭한 게시물 입니다. 당신이 찾고있는 것은 아마도 객체 데이터베이스에 관한 것입니다.

— greg0ire

다른 훌륭한 자료에 대한 링크가 포함 된 훌륭한 기사. 나는 몇 시간 동안 이것들과 재미있었습니다.

— mihai

나는 정말로 내부에서 git을 설명하는이 멋진 기사를 발견했다 : maryrosecook.com/blog/post/git-from-the-inside-out

— Sumudu

답변:

275

Git은 각 커밋마다 모든 파일의 전체 사본을 포함합니다. 단, Git 저장소에 이미 존재하는 컨텐츠의 경우 스냅 샷이 단순히 컨텐츠를 복제하지 않고 단순히 가리 킵니다.
또한 동일한 내용의 여러 파일이 한 번만 저장됨을 의미합니다.

따라서 스냅 샷은 기본적으로 디렉토리 구조 의 내용 을 참조하는 커밋 입니다.

좋은 참고 자료는 다음과 같습니다.

git.github.io/git-reference

Git에게 git commit 명령으로 프로젝트의 스냅 샷을 저장하고 싶다고 말하면 기본적으로 프로젝트의 모든 파일이 그 시점에서 어떻게 보이는지 기록합니다.

자식 침수

실습 12 에서는 이전 스냅 샷을 얻는 방법을 보여줍니다.

progit 책은 스냅 샷의보다 포괄적 인 설명이 :

Git과 다른 VCS (Subversion 및 친구들 포함)의 주요 차이점은 Git이 데이터에 대해 생각하는 방식입니다.
개념적으로 대부분의 다른 시스템은 정보를 파일 기반 변경 목록으로 저장합니다. 이러한 시스템 (CVS, Subversion, Perforce, Bazaar 등)은 파일 세트로 유지하는 정보와 시간이 지남에 따라 각 파일의 변경 사항을 생각합니다.

델타 기반 VCS

Git은 이런 식으로 데이터를 생각하거나 저장하지 않습니다. 대신, Git은 데이터를 미니 파일 시스템의 스냅 샷 세트처럼 생각합니다.
Git에서 프로젝트 상태를 커밋하거나 저장할 때마다 기본적으로 해당 시점의 모든 파일 모양을 캡처하고 해당 스냅 샷에 대한 참조를 저장합니다.
효율적으로 파일이 변경되지 않은 경우 Git은 파일을 다시 저장하지 않습니다. 이미 저장된 이전의 동일한 파일에 대한 링크 일뿐입니다.
Git은 다음과 같이 데이터에 대해 더 많이 생각합니다.

스냅 샷 기반 VCS

이것은 Git과 거의 모든 다른 VCS의 중요한 차이점입니다. Git은 대부분의 다른 시스템이 이전 세대에서 복사 한 버전 제어의 거의 모든 측면을 재고합니다. 이를 통해 Git은 단순한 VCS가 아닌 그 위에 강력한 도구가 내장 된 미니 파일 시스템처럼 보입니다.

Jan Hudec 은이 중요한 의견을 다음과 같이 덧붙입니다 .

개념 수준에서는 이것이 중요하지만 저장소 수준에서는 그렇지 않습니다.
Git은 저장을 위해 델타를 사용합니다 .
뿐만 아니라 다른 시스템보다 효율적입니다. 파일 별 히스토리를 유지하지 않기 때문에 델타 압축을 원할 때, 각 블로 브를 사용하고 유사 할 가능성이있는 일부 블로 브 (이전 버전과 가장 가까운 근사치를 포함한 휴리스틱 사용)를 선택하고 델타를 생성하고 가장 작은 블로 브를 선택합니다. 이 방법으로 (종종 휴리스틱에 따라 다름) 다른 유사한 파일이나 이전 버전과 유사한 이전 버전을 활용할 수 있습니다. "pack window"매개 변수는 델타 압축 품질에 대한 거래 성능을 허용합니다. 기본값 (10)은 일반적으로 적절한 결과를 제공하지만 공간이 제한되거나 네트워크 전송 속도를 높이는 git gc --aggressive경우 값 250을 사용하여 매우 느리게 실행되지만 기록 데이터에 대한 추가 압축을 제공합니다.

— VonC
소스

@JanHudec 좋은 지적. 더 많은 가시성을 제공하기 위해 귀하의 의견을 답변에 포함 시켰습니다.

— VonC

누구나 해시 기반의 가치 저장소라고 불리는 Git과 같은 스토리지 패턴에 대한 컴퓨터 과학 용어를 알고 있습니까? (또는 뭔가 유사한)

— JOANNES Vermorel

OP의 실제 질문과 관련하여 첫 번째 단락은 실제로 오도 된 것처럼 보입니다. 마지막 단락에 도달하기 전까지는 안된다. 사실 Git 이 파일들 사이에 "[...] 차이점을 저장 한다는 사실을 알게된다 . 정보가 맨 위에 표시되어 너무 깊게 묻히지 않기를 바란다"고 말했다. 적어도 당신의 대답에 실제 이야기를 포함;)

— Josh O'Brien

트윗 담아 가기 그 답변이 더 많은 청중을 찾는 것이 기쁘다.

— VonC

또 다른 좋은 책 : Git From The Bottom Up : ftp.newartisans.com/pub/git.from.bottom.up.pdf

— Jonas Berlin

Git은 각 파일을 논리적으로 SHA1에 저장합니다. 이것은 저장소에 정확히 동일한 내용을 가진 두 개의 파일이 있거나 파일 이름을 바꾸는 경우 하나의 사본 만 저장된다는 것을 의미합니다.

그러나 이것은 또한 파일의 작은 부분을 수정하고 커밋 할 때 파일의 다른 사본이 저장됨을 의미합니다. git이 이것을 해결하는 방법은 팩 파일을 사용하는 것입니다. 가끔, 저장소에서 모든“느슨한”파일 (실제로는 파일뿐만 아니라 커밋 및 디렉토리 정보를 포함하는 객체도)이 수집되어 팩 파일로 압축됩니다. 팩 파일은 zlib을 사용하여 압축됩니다. 비슷한 파일도 델타 압축됩니다.

(적어도 일부 프로토콜에서는) 당기거나 밀 때 동일한 형식이 사용되므로 해당 파일을 다시 압축 할 필요가 없습니다.

그 결과 전체 압축되지 않은 작업 복사본, 압축되지 않은 최근 파일 및 압축 된 오래된 파일을 포함하는 git 저장소는 일반적으로 작업 사본의 크기보다 두 배 작습니다. 이것은 SVN이 히스토리를 로컬로 저장하지 않더라도 동일한 파일을 가진 SVN repo보다 작다는 것을 의미합니다.

— 스빅
소스

아 너무 수은은 더 공간

— Ben