git는 파일을 어떻게 저장합니까?

git는 파일을 어떻게 저장합니까?

저는 이제 막 Git를 배우기 시작했고 그렇게 Git 커뮤니티 북을 읽기 시작했습니다. 이 책에서 SVN과 CVS는 파일 간의 차이를 저장하고 Git은 모든 파일의 스냅샷을 저장한다고 합니다.

하지만 저는 스냅샷이 의미하는 바를 잘 이해하지 못했습니다.Git이 정말로 각 커밋의 모든 파일의 복사본을 만드나요? 그것이 제가 그들의 설명에서 이해한 것이기 때문입니다.

PS: 기트를 배울 수 있는 더 좋은 자료를 가진 사람이 있다면 감사합니다.

Gitrepo에 이미 있는 콘텐츠의 경우 스냅샷이 복제하는 대신 해당 콘텐츠를 가리키기만 한다는 점을 제외하고 각 커밋에 모든 파일의 전체 복사본이 포함됩니다.
이는 동일한 콘텐츠를 가진 여러 파일이 한 번만 저장된다는 의미이기도 합니다.

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

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

• git.github.io/git-reference

Git에게 git commit 명령을 사용하여 프로젝트의 스냅샷을 저장하고 싶다고 말하면 기본적으로 프로젝트의 모든 파일이 해당 시점에서 어떻게 보이는지에 대한 매니페스트가 기록됩니다.

• 2020: "A commit in Git: 스냅샷/상태/이미지입니까, 아니면 변경/diff/patch/delta입니까?"
• 기트 몰입

연구소 12에서는 이전 스냅샷을 가져오는 방법을 설명합니다.

• "당신은 깃을 발명할 수 있었을 것입니다. (아마도 이미 발명했을 것입니다!)"

• 깃 "스냅샷"이란 무엇입니까?

• 깃허브 배우기

---

Progit Book에는 스냅샷에 대한 보다 포괄적인 설명이 나와 있습니다.

Git와 다른 VCS(버전 및 친구 포함)의 주요 차이점은 Git의 데이터에 대한 생각입니다.
개념적으로 대부분의 다른 시스템은 정보를 파일 기반 변경 목록으로 저장합니다. 시스템와 시간 에 따른 각 사항을 합니다.

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

이는 Git와 거의 모든 다른 VCS 간의 중요한 차이점입니다.Git는 대부분의 다른 시스템이 이전 세대에서 복사한 버전 제어의 거의 모든 측면을 재고하게 됩니다.따라서 Git는 단순한 VCS가 아닌 매우 강력한 툴이 내장된 미니 파일 시스템에 가깝습니다.

참고 항목:

• "파일의 스냅샷에서 Git가 작동한다면 시간이 지나도 크기가 커지지 않는 이유는 무엇입니까?"
• "각 git commit의 트리 개체 콘텐츠로 저장되는 정보

---

Jan Hudec은 다음과 같은 중요한 논평을 덧붙입니다.

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

Git는 각 파일을 SHA1 아래에 논리적으로 저장합니다.즉, 저장소에 내용이 완전히 동일한 두 개의 파일이 있는 경우(또는 파일 이름을 변경한 경우) 복사본이 하나만 저장됩니다.

그러나 파일의 작은 부분을 수정하고 커밋하면 파일의 다른 복사본이 저장됩니다.git이 이 문제를 해결하는 방법은 팩 파일을 사용하는 것입니다.때때로 레포의 모든 "느슨한" 파일(실제로 파일뿐만 아니라 커밋 및 디렉터리 정보를 포함하는 개체)이 수집되어 팩 파일로 압축됩니다.팩 파일은 zlib를 사용하여 압축됩니다.유사한 파일도 델타 압축됩니다.

또한 일부 프로토콜을 사용하여 풀 또는 푸시할 때도 동일한 형식이 사용되므로 이러한 파일을 다시 압축할 필요가 없습니다.

그 결과 압축되지 않은 전체 작업 복사본, 압축되지 않은 최근 파일 및 압축된 이전 파일을 포함하는 Git 저장소는 일반적으로 작업 복사본 크기보다 2배 더 작습니다.이는 SVN이 기록을 로컬로 저장하지 않더라도 동일한 파일을 사용하는 SVN repo보다 작다는 것을 의미합니다.

OP: Git의 스냅샷은 무엇을 의미합니까?Git가 각 커밋에 있는 모든 파일의 복사본을 만든다는 것이 사실입니까?

Git의 스냅샷은 무엇을 의미합니까?

Git에서 모든 커밋은 특정 시점에 프로젝트의 불변 스냅샷(무시 파일 제외)입니다.즉, 각 커밋에는 커밋 시 수정되거나 추가된 파일(델타)뿐만 아니라 전체 프로젝트의 고유한 표현이 포함됩니다.실제 파일에 대한 참조 외에도 각 커밋에는 커밋 메시지, 작성자(타임 스탬프 포함), 커밋(타임 스탬프 포함) 및 상위 커밋에 대한 참조와 같은 관련 메타데이터도 포함됩니다. 이 모든 것은 불변입니다!

커밋(또는 공식적으로 커밋 개체라고 함)은 전체적으로 불변하기 때문에 내용을 수정할 수 없습니다.커밋은 생성된 후에는 절대로 조작하거나 수정할 수 없습니다!

Git가 파일을 내부적으로 저장하는 방법

Pro Git 책에서 우리는 다음을 배웁니다.

Git는 콘텐츠 주소 지정이 가능한 파일 시스템입니다.좋습니다. 그게 무슨 뜻이죠?즉, Git의 핵심에는 간단한 키 값 데이터 저장소가 있습니다.즉, 모든 종류의 콘텐츠를 Git 저장소에 삽입할 수 있습니다. Git는 나중에 해당 콘텐츠를 검색하는 데 사용할 수 있는 고유한 키를 반환합니다.

이제 위의 설명이 실제로 무엇을 의미하는지, Git가 데이터(특히 파일)를 내부적으로 저장하는 방법을 알아보기 위해 아래 그림을 살펴보겠습니다.

실제 데이터(파일 및 디렉터리)가 Git 내부에 저장되는 방법에 대한 개요를 포함하여 세 가지 커밋이 포함된 간단한 커밋 기록.왼쪽에는 실제 스냅샷이 표시되고 이전 커밋과 비교한 "델타 변경"이 녹색으로 강조 표시됩니다.맨 오른쪽에는 저장에 사용되는 내부 개체가 있습니다.

Git는 내부 스토리지에서 세 가지 주요 객체를 사용합니다.

• 커밋 개체(고급 스냅샷 컨테이너)
• 트리 개체(낮은 수준의 파일 이름/디렉토리 컨테이너)
• Blob 개체(낮은 수준의 파일 내용 컨테이너)

일반적인 의미(예: 내용 + 파일 이름/디렉토리)로 Git 내부에 파일을 저장하려면 하나의 블롭과 트리가 필요합니다. 파일 내용만 저장할 블롭과 블롭을 참조하는 파일 이름/디렉토리를 저장할 트리가 필요합니다.중첩된 디렉토리를 구성하기 위해 여러 트리가 사용되므로 트리는 블롭과 트리를 모두 참조할 수 있습니다.높은 수준의 관점에서 보면 Git이 커밋 프로세스의 일부로 자동으로 생성하기 때문에 방울과 나무에 대해 걱정할 필요가 없습니다.

참고: Git는 모든 해시(키)를 상향식으로 계산합니다. BLOB부터 시작하여 모든 하위 트리를 이동하여 최종적으로 루트 트리에 도달합니다. 즉, 키를 직접 부모에게 입력으로 제공합니다.이 프로세스는 수학 및 컴퓨터 과학에서 DAG(Directed Asyclic Graph)로 알려진 위에서 시각화된 구조를 생성합니다. 예를 들어 모든 참조는 순환 의존성 없이 한 방향으로만 이동합니다.

시각화된 예제를 조금 더 분석합니다.

위의 내역을 자세히 조사하면 초기 C0 커밋에 대해 두 개의 빈 파일이 추가되었음을 알 수 있습니다.src/index.js그리고..gitignore하지만 단 하나의 블롭만 생성되었습니다!이는 Git가 고유한 콘텐츠만 저장하고 빈 두 파일의 콘텐츠는 분명히 동일한 해시를 생성했기 때문입니다.e69de하나의 항목만 필요했습니다.그러나 파일 이름과 경로가 다르기 때문에 이를 추적하기 위해 두 개의 트리가 만들어졌습니다.각 트리는 참조 중인 경로 및 블롭을 기반으로 계산된 고유 해시(키)를 반환합니다.

두 번째 커밋 C1까지 위쪽으로 계속하면, 우리는 오직.gitignore파일이 업데이트되어 새로운 블롭이 생성되었습니다(e51ac 해당 해당 데이터를 포함합니다. 트리 합니다.src/index.js는 단순히 일파 에 새 . 그러나 루트 트리는 단순히 기반이 되는 것 때문에 새로운 해시(키)를 가진 완전히 새로운 개체이기도 합니다..gitignore참조가 변경되었습니다.

최종 C2에서 커밋은 오직src/index.js블롭)이 했습니다.257cc가 나타나서 새로운 트리로 생성했습니다.5de32트리(), 그고리궁로새루트트리운로으극적▁(),▁),().07eff).

요약하면

새 커밋이 생성될 때마다 DAG 데이터 구조에 따라 전체 프로젝트의 스냅샷이 기록되고 내부 데이터베이스에 저장됩니다.커밋이 체크아웃될 때마다 기본 스냅샷이 루트 트리를 통해 참조하는 것과 동일한 상태를 반영하도록 작업 트리가 재구성됩니다.

출처: 위의 발췌문은 이 주제에 대한 전체 길이의 게시물에서 발췌한 것입니다.불변 스냅샷 - Git의 핵심 개념 중 하나

언급URL : https://stackoverflow.com/questions/8198105/how-does-git-store-files