이것은 git에 대한 일반적인 오해입니다. git 초보자의 경우 Git은 커밋을 diff로 최종 사용자에게 노출하므로 아래 이미지와 같이 변경 사항을 쉽게 식별할 수 있으므로 그렇게 가정하는 것이 합리적입니다.



그러나 Git은 각 커밋에 대한 diff를 내부적으로 저장하지 않고 각 커밋 동안 파일의 스냅샷을 생성합니다.
즉, 한 커밋에서 파일을 만들고 두 번째 커밋에서 동일한 파일을 수정하면 Git은 동일한 파일에 대해 2개의 스냅샷을 갖게 됩니다.

git이 내부적으로 이러한 파일을 저장하는 방법을 보여주기 위해 .git/ 폴더를 파헤쳐 보겠습니다. git이 파일을 처리하는 방법을 이해하면 더 나은 그림을 얻을 수 있습니다. 동일한 내용에 대해서는 내 블로그를 확인하십시오.
TLDR: git 저장소에 추가하는 모든 파일은 저장소.git/objects/에 객체로 추가됩니다.

(스냅샷과 diff를 사용하는 이유는 마지막에 있는 왜? 섹션으로 건너뛰세요)

이것을 실제로 보자

$ mkdir gitinternals && cd gitinternals # create and cd into a dir
$ git init # initialize git
Initialized empty Git repository in /Users/home/gitinternals/.git/

이제 새로운 git 저장소가 있으므로 파일을 만들고 커밋할 수 있습니다.

$ echo "# Hello world" > README.md
$ git add README.md
$ git commit -m "Add readme file"
[master (root-commit) 0948529] Add readme file
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

git 객체 디렉토리를 살펴보겠습니다. readme 파일이 저장되어 있을 것입니다.

$  tree -a .git/objects/
.git/objects/
├── 09
│   └── 4852928af802dfe0f463359c7ade3f7a21fffa
├── 71
│   └── 6ed1421c738a75abe6e0c4812ad4aacee0e11a
├── a5
│   └── ef91ee14be786131cbecfd2eb8c7fef8a2510d
├── info
└── pack

객체 디렉토리에는 세 개의 객체가 있으며 cat-file -t plumbing 명령을 사용하여 객체 파일의 유형을 확인할 수 있습니다.
이를 통해 716e가 Blob 파일임을 알 수 있습니다. 리포지토리에는 하나의 Blob 파일만 있기 때문에 이 파일은 README.md 파일이어야 합니다. cat-file -p를 사용하여 개체 파일의 내용을 볼 수 있습니다.
Git 객체에 대해 더 알고 싶다면 언제든지 를 참조하십시오.

$  git cat-file -t 716e
blob

$ git cat-file -p 716e
# Hello world

readme를 수정하여 파일 끝에 .를 추가하고 커밋을 다시 생성해 보겠습니다.

$ echo "." >> README.md
$ git add README.md
$ git commit -m "Update readme"
[master ccab425] Update readme
 1 file changed, 1 insertion(+)

객체 디렉토리 확인

$ tree -a .git/objects/
.git/objects/
├── 09
│   └── 4852928af802dfe0f463359c7ade3f7a21fffa
├── 28
│   └── af00ee0e3e44d7806dc1c2d7f1a9c9d75cfd8e
├── 5f
│   └── a99c8ea90f41ae4601f92ea7475832e6fb773d
├── 71
│   └── 6ed1421c738a75abe6e0c4812ad4aacee0e11a
├── a5
│   └── ef91ee14be786131cbecfd2eb8c7fef8a2510d
├── cc
│   └── ab425bf34937b0e02ed807724af39812e8988b
├── info
└── pack

디렉터리에 개체가 몇 개 더 있습니다. blob 파일을 얻기 위해 각 파일의 유형을 확인하고 어떤 파일이 README.md의 새 버전인지 알아낼 수 있지만 더 나은 방법론적 접근 방식이 있습니다.

우리는 현재 커밋 해시를 가져오고 트리 해시에 대한 포인트가 있는 트리를 확인할 수 있으며 blob 해시를 얻을 수 있어야 합니다. 커밋 및 트리 개체에 익숙하지 않은 경우 참조하십시오.

# get hash of current commit
$ git rev-parse --short HEAD
ccab425

# check content of the commit to get tree hash
$ git cat-file -p ccab425
tree 28af00ee0e3e44d7806dc1c2d7f1a9c9d75cfd8e
parent 094852928af802dfe0f463359c7ade3f7a21fffa
author root <[email protected]> 1601836557 +0530
committer root <[email protected]> 1601836557 +0530

Update readme

# check content of tree `28af00`
$ git cat-file -p 28af00
100644 blob 5fa99c8ea90f41ae4601f92ea7475832e6fb773d    README.md

새README.md 스냅샷의 해시는 5fa99c입니다. 이전 및 새 스냅샷 콘텐츠를 검사할 수 있습니다.

# New snapshot hash
$ git cat-file -p 5fa99c
# Hello world
.

# Old snapshot hash
git cat-file -p 716ed1
# Hello world

왜요 ?

diff만 저장하는 것이 저장소를 가장 효율적으로 사용하므로 파일의 각 버전을 스냅샷으로 저장하는 것은 비효율적으로 보일 수 있습니다. 그래서 이유를 묻는 것이 자연스럽습니까?

기본 파일 버전 위에 diff를 저장하고 적용하는 것은 수천 또는 수백만 개의 파일이 있는 대규모 프로젝트에 있을 때 계산 비용이 상당히 많이 들 수 있습니다.
diff 기반 접근 방식은 SVN에서 사용되며 CPU 및 IO가 이러한 diff를 적용하는 데 병목 현상이 발생하기 때문에 체크아웃하는 데 몇 시간이 걸리는 대규모 프로젝트에는 일반적인 문제가 있습니다.

SVN은 스토리지가 컴퓨팅보다 비용이 더 많이 들었을 때 인기가 있었지만 지금은 테이블이 변경되었습니다. 스토리지는 오늘날 훨씬 더 저렴하므로 Git은 버전 제어를 위한 완벽한 선택입니다.

Git에는 개체를 압축하기 위한 최적화 기능이 내장되어 있어 디스크에서 더 적은 저장 공간을 차지합니다. 이에 대해서는 다음 블로그에서 다룰 예정입니다 :).