init부터 merge까지 Git의 내부에서 일어나는 일

💡 지금껏 git init부터 브랜치 간의 merge까지 수백 번 넘게 경험하면서 단 한 번도 Git의 내부 동작이나 원리에 대해 궁금함을 가져본 적이 없었습니다. 이번 기회에 그 내부를 샅샅이 살펴보면서 Git에 대해 제대로 이해해보려고 합니다. 

📌 Git의 일반적인 사용법 정도를 알고 있어야 합니다.

 

🥸 선수 지식

• Git 내부의 동작 방식을 이해하기 위해 필수적으로 알아야 할 용어 및 개념입니다.
• 아래 내용은 가볍게 읽어보시고, 실습 부분에서 이해가 안되시면 돌아와 해당 개념을 다시 읽으시면 보다 수월하게 이해하실 수 있으리라 생각됩니다.

 

✍🏻 용어 정리

🔸 HEAD

• Git에서 HEAD는 현재 작업 중인 "브랜치의 마지막 커밋을 가리키는 포인터"를 말한다.
  • 가장 최신 커밋을 가리키고 있는 포인터인 것이다.

 

🔸 Git의 저장 단위 : Object

• Git은 내부적으로 객체(Object)라는 이름의 저장 단위를 사용하여 데이터를 저장한다.
• 이 객체들은 Git의 모든 동작의 기반이 되며, 버전 관리가 가능한 구조를 제공한다.
• Object에는 blob, commit, tree, tag가 있다.
• 모든 객체는 기본적으로 SHA-1 해시를 사용한다.
  • Git 2.29 이상에서는 core.objectFormat=sha256 설정을 통해 SHA-256을 사용할 수 있다고 한다.

 

🔘 Blob(Binary Large Object)

• git add 명령어를 통해 추가되는 객체이다.
  • git add 시 blob 객체가 생성된다.
• git add로 추가된 개별 파일의 내용만 저장하는 객체이다.
  • 파일 이름이나 위치 정보는 없고 오직 내용만을 담는다.
• 동일한 내용이면 언제나 동일한 SHA-1 해시값을 가지므로 중복 저장이 되지 않아 공간을 절약한다.
• 파일이 수정되지 않았다면 커밋을 여러 번 해도 동일한 blob이 재사용된다.

 

🔘 Commit

• commit은 Git에서 하나의 스냅샷(버전)을 의미하며, 이는 프로젝트의 특정 시점을 가리킨다.
• git commit 명령어를 통해 추가되는 객체이다.
  • 말그대로 git commit을 통해 저장된 스냅샷(버전)을 저장하는 객체인 것이다.
• 하나의 commit 객체는 하나의 tree 객체(파일 구조 전체)를 가리킨다.
• 다음과 같은 메타데이터를 포함한다.
  • tree 해시값
  • 부모 커밋 해시값(parent로 표시되며, 첫 커밋이라면 당연하게도 존재하지 않는다.)
  • 작성자(author) / 커밋터(committer)
  • 커밋 메시지

 

🔘 Tree

• git commit 명령어를 통해 추가되는 객체이다.
  • 위에서 설명했듯이 Git에서 commit을 한다는 건 해당 시점의 스냅샷(버전)을 저장한다는 뜻이다.
  • tree는 commit 시의 특정 시점에 대한 디렉터리(폴더) 구조와 그 안의 파일들을 나타내는 객체이다.
• 이 객체는 해당 디렉터리에 포함된 파일과 하위 디렉터리(tree 또는 blob 객체들)의 목록을 트래킹하고, 각각의 이름, 권한, 그리고 해당 객체의 해시를 가지고 있다.
• 좀 더 정확히 설명하면 해당 디렉터리 내의 파일 목록, 이름, 권한(100644, 100755), 타입(blob/tree), 해시값(blob 또는 tree의 SHA-1 해시)을 가진다.
  • 권한이란?
    • 권한에서 6자리 숫자는 파일의 모드를 의미한다. 
    • ex) 100644에서 앞에 두 자리는 파일의 타입이다.
      • 10은 일반 파일, 12는 심볼릭 링크, 04는 디렉터리이다.
    • 뒤 네자리는 권한 비트(8진수)를 의미한다.
• 한마디로 정리하면, tree 객체는 commit 시의 특정 시점에 대한 blob 객체(파일)나 다른 tree 객체(하위 폴더)를 포함한다.

 

🔘 Tag

• 특정 commit에 이름표(label) 를 붙이는 역할을 한다.
• git tag로 생성한다.
• 버전을 명확하게 구분하고, 릴리스를 표시할 때 자주 사용된다.
  • Lightweight tag : 단순히 커밋의 해시를 가리키는 포인터이며 객체는 아니다.
  • Annotated tag : 메시지, 작성자 정보를 포함하며 별도의 객체로 저장된다.

 

👀 Git 내부 구조 한눈에 보기

HEAD
 └─▶ Commit
       ├─▶ Tree
       │    ├─▶ Blob (hello.txt)
       │    └─▶ Tree (src/) ─▶ Blob (main.java)
       └─▶ Parent Commit (이전 스냅샷)

• 위의 Git 객체에 대한 설명을 토대로 Git 내부 구조를 하나씩 다시 살펴보자.
  • 이 예시는 커밋이 여러 번 일어난 특정 브랜치의 내부 구조를 나타낸 것이다.
• Head는 현재 브랜치의 마지막(가장 최신) commit을 가리키고 있다.
• 하나의 comitt 객체에는 하나의 tree 객체를 가지고 있다.
• 하나의 tree 객체는 Git에 의해 Commit한 시점에서의 하위 디렉터리나, 개별 파일을 저장한다.
• Head가 가리키는 commit 객체가 최초의 commit이 아닌 경우, parent commit(부모 커밋 객체)를 가지고 있다.
  • 즉, 하나의 commit은 부모 commit(바로 직전의 commit)을 가지고 있기 때문에 커밋 취소와 같은 롤백이 가능한 것이다.

 

🚀 Git의 세 가지 주요 영역

구분	설명	확인 위치
Working Directory	Git에서 작업 중인 로컬 폴더를 말한다.(폴더, 파일 등)	프로젝트 루트 폴더
Staging Area(Index)	커밋할 준비가 된 파일들의 정보를 저장하는 곳이다.	.git/index
Repository(Git Directory)	Git의 객체가 저장되는 곳이다.	.git/objects

 

🛸 Git state 명칭과 설명

🔘 Untracked

• Git이 아직 추적하지 않는 새 파일을 의미한다.
• git add 명령어를 이용하여 Git이 해당 파일을 추적(관리)하도록 준비 상태로 만들 수 있다.
• 한 번 추적되기 시작하면 unmodified나 modified와 같이 트래킹 되면서 변경 감지가 되는 것이다.

 

☑️ Unmodified

• 이미 Tracked 되고 있는 상태이다.(이미 Git이 관리하고 있는 파일)
• Working Directory의 파일이 마지막(가장 최신) 커밋과 동일하다는 의미로, 파일이 변경되지 않았음을 의미한다.
• 내부적으로는 Working Directory 내 파일의 해시값과, HEAD commit의 blob 해시값이 동일하다는 뜻이다.

 

☑️ Modified

• 이미 Tracked 되고 있는 상태이다.(이미 Git이 관리하고 있는 파일)
  • unmodified와의 차이점은 기존 파일과의 변경 여부이다.
• 추적 중인 파일이 변경되었음을 Git이 인지하고 있는 것이다.
• 아직 staging area에는 올리지 않은 상태이다.
• 내부적으로는 Working Directory 내 변경된 파일의 해시값과, HEAD commit의 blob 해시값이 다르다는 뜻이다.

 

🔘 Staged

• 변경된 파일을 git add 명령어를 사용하여 staging area에 올릴 수 있다.
• 다음 커밋에 포함될 준비가 된 상태이다.
• 내부적으로는 .git/index에 변경된 파일의 blob 객체가 새로 저장된다.

 

🔘 Committed

• staging area의 내용이 실제로 커밋된 상태이다.
• Git이 완전히 추적한다는 의미이다.
• 내부적으로는 .git/objects에 Tree 객체와 Commit 객체가 새로 저장된다.
  • tree 객체를 기반으로 한 새로운 Commit 객체가 생성되는 것이다.

 

🎨 그림으로 Git state와 Git 내부 변화 이해하기

• git 명령어에 의해 객체가 물리적으로 생성되며, 이는 .git 폴더 내에서 일어난다.
• Working Directory는 Git이 관리하는 로컬 시스템 상의 실제 파일 경로를 의미한다.
  • 사용자가 Git에 의해 관리되는 파일을 편집, 생성, 삭제하는 공간이다.
• Staging Area는 .git/index에, Git Repository는 .git/object 내부에 객체로 기록된다.

 

🔸 새로 만든 파일: Untracked -> Staged -> Committed

• 처음 파일을 생성하면 Git은 이 파일의 존재만을 감지할 뿐이다. 어떠한 변경 사항 등의 추적을 진행하지 않는다. 이것이 Untracked 상태이다.
• git add를 하게 되면 Staging area로 들어가 Git의 추적을 받을 준비를 하게 된다.
  • 이때, 해당 파일의 내용을 기반으로 blob 객체가 생성되어 .git/objects/에 저장된다.
    • 이미 동일한 내용이 있는 경우는 재사용한다.
  • 또한, .git/index에 있는 스테이징 영역 정보에 저장된다.
• 이후 commit을 하게 되면 Git에 의해 객체로서 추적 및 관리가 되기 시작한다.
  • 이때, 해당 파일의 tree 객체와 commit 객체가 .git/objects/에 생성된다.

 

🔸 기존 파일 수정: (Unmodified → Modified) → Staged → Committed

• 기존 파일은 이미 Git에 의해 추적되어지고 있다. 따라서 Git은 해당 파일이 수정되었는지 아닌지를 항상 체크한다.
• 파일이 수정되면 Unmodified에서 modified로 상태가 변경된다.
  • Git이 변경 감지를 한 것이다.
• 이후 git add를 하게 되면 Staging area로 이동하여 다음 커밋을 준비하게 된다.
  • 이 과정에서 해당 변경 사항이 반영된 새 blob 객체가 생성된다.
    • 이미 동일한 내용이 있는 경우는 재사용한다.
• 이후 commit을 하게 되면  Git은 이 파일을 정식으로 저장소에 기록한다.
  • 이때, 해당 변경 사항이 반영된 새 tree과 commit 객체가 생성된다.

 

🤧 관련 명령어

# 스테이징 영역 정보 확인
$ git ls-files --stage

# 현재 커밋 해시 확인
$ git rev-parse HEAD

# 객체 타입 확인
$ git cat-file -t <해시>

# 객체 내용 보기
$ git cat-file -p <해시>

# tree 내부 구조 보기
$ git ls-tree <tree해시>

• 아래 실습 때 사용할 명령어이다.
• Git의 내부 객체는 바이너리 데이터로 저장되기 때문에 읽을 수 있게 별도의 명령어를 통해 변환해야 한다.

 

👨🏻‍🔬 init부터 merge까지 Git의 내부의 변화 살펴보기

# 1 단계: Commit 해보기
git init
git add
git commit

# 2 단계: 브랜치를 나누고 merge 해보기
git checkout -b feature/test1
git merge

• 위 선수 지식 내용을 어느정도 이해한 상태에서 위 명령어를 이용해 Git 내부의 변화를 자세히 살펴보자.

 

☝🏻 1 단계: Commit 해보기

🖋️ 시퀀스 다이어그램으로 살펴보기(init -> commit)

• 흐름 순으로 그려보았다.
• 크게 새 파일 생성과 기존 파일 변경을 기준으로 그렸다.
• 자세한 설명은 아래를 참고하자.

 

👉🏻 git init

$ mkdir git-internal-test
$ cd git-internal-test 
$ ls -al

# 출력(git 생성 전)
total 0
drwxr-xr-x  2 root  staff   64  4 26 02:07 .
drwxr-xr-x  8 root  staff  256  4 26 02:07 ..

$ git init

# 출력(git 생성 후)
Initialized empty Git repository in /경로/git-internal-test/.git/

$ ls -al
total 0
drwxr-xr-x  3 root  staff   96  4 26 02:07 .
drwxr-xr-x  8 root  staff  256  4 26 02:07 ..
drwxr-xr-x  9 root  staff  288  4 26 02:07 .git

• git init 명령어 실행 시 해당 루트 폴더에 .git 폴더가 생성된다.
• 이제 해당 폴더는 working directory가 되며 Git에 의해 관리된다.

 

📌 .git 폴더 내부 자세히 살펴보기

/.git$ ll

# 출력
total 24
-rw-r--r--   1 root  staff  137  4 26 02:07 config
-rw-r--r--   1 root  staff   73  4 26 02:07 description
-rw-r--r--   1 root  staff   21  4 26 02:07 HEAD
drwxr-xr-x  15 root  staff  480  4 26 02:07 hooks
drwxr-xr-x   3 root  staff   96  4 26 02:07 info
drwxr-xr-x   4 root  staff  128  4 26 02:07 objects
drwxr-xr-x   4 root  staff  128  4 26 02:07 refs

• .git 내부에는 꽤나 많은 파일과 폴더가 존재한다. 하나하나 다 뜯어보자.
• Git의 객체 이해에 초점을 두고 싶다면 이 부분은 건너뛰어도 무방하다.

 

💼  파일

🔵 config 파일

$ cat config 

# 출력
[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
	ignorecase = true
	precomposeunicode = true

• Git Repository의 기본 동작을 제어하는 설정 파일이다.
• 가볍게 넘어가자.

🔸 repositoryformatversion

• Repository의 포맷 버전을 뜻하며, 초기 포맷은 0이다.
• Git에 의해 자동으로 관리된다.

🔸 filemode

• true일 시 git이 파일의 chmod 실행 권한 변경을 추적한다.
• false일 경우 권한은 무시하고 내용 변경만 추적한다.

🔸 bare

• bare repository인지의 여부를 나타낸다.
• true일 경우 bare repository라는 뜻이다.
  • .git 폴더만 저장하는데, 말 그대로 파일 내용(Working Directory) 없이 git의 데이터 구조만을 저장한다.
    • 예를 들어, 코드 파일이 존재할 경우 파일 꼬임 문제가 발생할 수 있기 때문에 .git 폴더만을 관리하며 내부 변경 사항(커밋, 브랜치 등)만 기록하는 것이다.
    • 따라서 bare repository는 버전(commit 기록)만을 저장하기 때문에 이를 활용해 여러 사람이 저장소를 공유하고 협업할 수 있다.
  • GitHub는 이 bare repository를 서버에 저장하고, 이를 사용자가 웹상에서 코드 파일처럼 쉽게 볼 수 있도록 시각화해주는 서비스다.
    • GitHub 화면에서 우리가 코드 파일을 보는 것처럼 보이는 이유는 bare repository에 저장된 Git 객체들(blob, tree 등)을 파일 형태로 변환해서 보여주기 때문이다.
• false일 경우 working directory가 존재하는, 우리가 아는 일반 깃 저장소이다.

🔸 logallrefupdates

• 브랜치가 업데이트될 때마다 로그를 남길지 여부이다.
• true일 경우 브랜치가 옮겨갈 때마다 .git/logs/ 밑에 기록이 쌓인다.

🔸 ignorecase

• 파일 이름 대소문자 구분 여부이다.

🔸 precomposeunicode

• 유니코드 정규화 관련 설정 여부이다.
  • MacOS에서는 파일 이름에 유니코드를 저장할 때 조합형(normalization)으로 저장하는 경우가 있다.
  • true일 경우 이를 감안해서 이름을 맞춰서 저장하고 비교한다.

 

🔵 description 파일

$ cat description 

# 출력
Unnamed repository; edit this file 'description' to name the repository.

• 리포지터리에 대한 간단한 설명을 제공한다.

 

🔵 HEAD 파일

$ cat HEAD

# 출력
ref: refs/heads/main

• Git에서 현재 체크아웃한 브랜치의 폴더 경로를 담고 있다.

 

💼 디렉터리

🟢 hooks/

/hooks$ ll

# 출력
total 120
-rwxr-xr-x  1 root  staff   478  4 26 02:07 applypatch-msg.sample
-rwxr-xr-x  1 root  staff   896  4 26 02:07 commit-msg.sample
-rwxr-xr-x  1 root  staff  4726  4 26 02:07 fsmonitor-watchman.sample
-rwxr-xr-x  1 root  staff   189  4 26 02:07 post-update.sample
-rwxr-xr-x  1 root  staff   424  4 26 02:07 pre-applypatch.sample
-rwxr-xr-x  1 root  staff  1643  4 26 02:07 pre-commit.sample
-rwxr-xr-x  1 root  staff   416  4 26 02:07 pre-merge-commit.sample
-rwxr-xr-x  1 root  staff  1374  4 26 02:07 pre-push.sample
-rwxr-xr-x  1 root  staff  4898  4 26 02:07 pre-rebase.sample
-rwxr-xr-x  1 root  staff   544  4 26 02:07 pre-receive.sample
-rwxr-xr-x  1 root  staff  1492  4 26 02:07 prepare-commit-msg.sample
-rwxr-xr-x  1 root  staff  2783  4 26 02:07 push-to-checkout.sample
-rwxr-xr-x  1 root  staff  3650  4 26 02:07 update.sample

• git의 이벤트 자동화 폴더이다.
• 예를 들어 commit이나 push를 할 때 자동으로 실행되는 스크립트가 포함되어 있다.

 

🟢 info/

/info$ ll

# 출력
total 8
-rw-r--r--  1 root  staff  240  4 26 02:07 exclude

• 추가 정보를 저장하는 폴더이다.
• 일반적인 설정 외에 exclude(특정 파일만 무시하는 설정) 파일 등이 들어가 있다.

 

🟢 object/

/objects$ ll

# 출력
total 0
drwxr-xr-x  2 root  staff  64  4 26 02:07 info
drwxr-xr-x  2 root  staff  64  4 26 02:07 pack

/objects/info$ls -al

# 출력
total 0
drwxr-xr-x  2 root  staff   64  4 26 02:07 .
drwxr-xr-x  4 root  staff  128  4 26 02:07 ..

/objects/pack$ls -al

# 출력
total 0
drwxr-xr-x  2 root  staff   64  4 26 02:07 .
drwxr-xr-x  4 root  staff  128  4 26 02:07 ..

• git의 핵심 폴더이다.
• 사용자가 만든 커밋, 파일, 폴더 등 진짜 데이터가 모두 여기에 저장된다.
• 압축된 형태로 저장되기 때문에 특정 명령어나 외부 parser를 사용하여 해독할 수 있다.

 

🟢 refs/

/refs$ ll

# 출력
total 0
drwxr-xr-x  2 root  staff  64  4 26 02:07 heads
drwxr-xr-x  2 root  staff  64  4 26 02:07 tags

/refs/heads$ ls -al

# 출력
total 0
drwxr-xr-x  2 root  staff   64  4 26 02:07 .
drwxr-xr-x  4 root  staff  128  4 26 02:07 ..

• 브랜치랑 태그 정보를 저장한다.
• git init으로 어떠한 커밋작업도 없을 때에는 heads, tags 폴더가 비어있다.
  • 나중에 commit을 하게 되면 heads에 브랜치 명의 파일 생성된다.
  • 혹은 브랜치를 생성하면 해당 브랜치 명의 파일이 추가된다.
  • 이 파일에 해당 브랜치가 가리키는 커밋의 SHA-1 해시가 저장된다.

 

👨🏻‍🔬 본격적인 실습 시작

👉🏻 git add

🔸 git 폴더 내 새로운 파일 생성

# git init을 한 최초 폴더 내부에서 fitst.text 파일에 i am iron man. 입력 후 저장
$ echo "i am iron man." > first.text

$ ll

# 출력
total 8
-rw-r--r--  1 root  staff  15  4 28 01:39 first.text

• 우선 새로운 파일을 생성한다.
• 최초 생성하게 되면 Git에 의해 추적되지 않고 있는 untracked 파일이 추가된다.

 

🔸 git add - 스테이징 영역에 새로운 파일 추가하기

# git add 하기 전
$ git status # 상태 확인 명령어

# 출력
On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	first.text

nothing added to commit but untracked files present (use "git add" to track)

# git add 한 후
$ git add first.text
$ git status  

# 출력
On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   first.text

• git add 명령어를 하기 전과 후 git status를 확인해 보면 Git이 first.text 파일을 추적하고 있지 않다가, 추적하는 것을 확인할 수 있다.
• 이는 git add로 인해 first.text 파일이 스테이징 영역(Index)으로 들어갔음을 의미한다.
  • 아직 커밋하지 않았지만, 커밋할 준비를 끝냈다고 볼 수 있다.

 

🔸 Git 내부에서는?

# 스테이징 영역 정보 확인 명령어
$ git ls-files --stage

# 출력
100644 8e21e230620d2380b2fee92cf506ea4e4dc3363a 0	first.text

# objects 폴더 내 blob 객체 생성 확인해보기
/.git/objects$ ll

# 출력
total 0
drwxr-xr-x  3 root  staff  96  4 28 01:43 8e
drwxr-xr-x  2 root  staff  64  4 26 02:07 info
drwxr-xr-x  2 root  staff  64  4 26 02:07 pack

/.git/object$ cd 8e 
/.git/objects/8e$ ll

# 출력
total 8
-r--r--r--  1 root  staff  31  4 28 01:43 21e230620d2380b2fee92cf506ea4e4dc3363a

# blob 객체 내용 확인 해보기
$ git cat-file -p 8e21e230620d2380b2fee92cf506ea4e4dc3363a

# 출력
i am iron man.

• git add 명령어를 사용하면 first.text 파일의 내용을 읽고 SHA-1 해시를 생성(다른 객체도 마찬가지)한다.
• 이 내용을 blob 객체로 만들어 .git/object 폴더 안에 저장하는데 해시값의 앞 두 글자를 폴더명으로 하고 나머지 글자를 내부 파일명으로 한다.
  • 위에서 확인할 수 있듯이 만들어진 blob 객체는 파일의 내용을 저장하고 있다.

 

🔸 .git/index

/.git$ ll 

# 출력
total 40
-rw-r--r--   1 root  staff  137  4 26 02:07 config
-rw-r--r--   1 root  staff   73  4 26 02:07 description
-rw-r--r--   1 root  staff   21  4 26 02:07 HEAD
drwxr-xr-x  15 root  staff  480  4 26 02:07 hooks
-rw-r--r--   1 root  staff  145  4 28 02:10 index # 새로 생성
drwxr-xr-x   3 root  staff   96  4 26 02:07 info
drwxr-xr-x   4 root  staff  128  4 28 02:10 logs
drwxr-xr-x   7 root  staff  224  4 28 02:10 objects
drwxr-xr-x   4 root  staff  128  4 26 02:07 refs

# cat 명령어로 내부 내용 확인하기(실패)
/.git$ cat index 

# 출력
#????,??NM?6:?'za?
first.textTREE1 0
#??t"/?R?? ?nSz?q?H?9x???ߣ8???@??%

# 별도의 명령어로 내부 내용 확인하기(성공)
/.git$ git ls-files --stage

# 출력
100644 8e21e230620d2380b2fee92cf506ea4e4dc3363a 0	first.text

• .git/index가 새로 생성되었다. 이는 Git의 스테이징 영역을 구현하는 바이너리 파일이다.  
  
  • 이 파일에는 git add를 통해 추가된 파일들의 blob 해시와 메타 정보가 저장된다. 
  • .git/index는 바이너리 포맷이므로 cat 같은 명령어로 보면 깨진다. 
  • git ls-files --stage와 같은 별도의 명령어를 사용하면 각 파일의 blob 해시와 스테이징 정보를 확인할 수 있다.

 

👉🏻 git commit

$ git commit -m "first commit"

# 출력
[main (root-commit) b19a9f1] first commit
 1 file changed, 1 insertion(+)
 create mode 100644 first.text

• 첫 번째 commit이 실행됨으로써 Git은 first.text라는 파일을 관리하며, 첫번째 버전을 기억하고 있게 되었다.

 

🔸 Git 내부에서는?

/.git$ cd objects 
/.git/objects$ll

# 출력
total 0
drwxr-xr-x  3 root  staff  96  4 28 02:10 82 # 새로 생성
drwxr-xr-x  3 root  staff  96  4 28 01:43 8e
drwxr-xr-x  3 root  staff  96  4 28 02:10 b1 # 새로 생성
drwxr-xr-x  2 root  staff  64  4 26 02:07 info
drwxr-xr-x  2 root  staff  64  4 26 02:07 pack

# 현재 HEAD가 바라보는 커밋 해시 조회
/.git$ git rev-parse HEAD

# 출력
b19a9f14568ce6ed7b22f02f2cecdd6aeff6929e

• .git/objects/에 tree, commit 객체가 추가됨을 확인할 수 있다.
• 참고로, 현재 HEAD에 커밋 해시를 확인하는 명령어를 입력하면 commit 객체의 해시값이 나온다.

 

🔸 refs/heads

/.git/$ cd refs
/.git/refs$ cd heads 
/.git/refs/heads$ ll

# 출력
total 8
-rw-r--r--  1 root  staff  41  4 28 02:10 main

# main 출력
/.git/refs/heads$ cat main 
b19a9f14568ce6ed7b22f02f2cecdd6aeff6929e

• 또한, .git/refs/heads/main에 이 커밋 객체의 해시값이 기록된다.

 

🔸 commit 객체로 tree, blob 해시값 찾아보기

# 객체 타입 확인
/.git$ git cat-file -t b19a9f14568ce6ed7b22f02f2cecdd6aeff6929e

# 출력
commit

# 객체 정보 확인
/.git$ git cat-file -p b19a9f14568ce6ed7b22f02f2cecdd6aeff6929e

# 출력
tree 82a374221b7e2f8252a0f020c56e53167aab71b0
author root <111210881+xxxxxx@users.noreply.github.com> 1745773845 +0900
committer root <111210881+xxxxxx@users.noreply.github.com> 1745773845 +0900

# 객체 정보 확인
/.git$ git cat-file -p 82a374221b7e2f8252a0f020c56e53167aab71b0

# 출력
100644 blob 8e21e230620d2380b2fee92cf506ea4e4dc3363a	first.text

• git cat-file -t의 경우 객체의 타입을 출력한다.
• git cat-file -p의 경우 객체의 정보를 출력한다.
• 이를 이용하여 commit객체를 가지고 tree와 blob 객체까지 해시를 찾을 수 있다.

 

🫥 중간 정리

• Git은 add와 commit 과정을 통해 내부적으로 blob, tree, commit 객체를 생성하고, 이를 통해 파일과 디렉터리의 변경 내역을 추적하고 관리한다는 것을 확인할 수 있었다.

 

✌🏻 2 단계: 브랜치를 나누고 merge 해보기

• 이제 브랜치를 나누고 merge 하는 과정을 가볍게 알아보자. Git 내부적인 객체의 변화는 위에 충분히 설명했으므로 상당 부분 생략한다.

 

👉🏻  git checkout -b feature/test1

# feature/test1 브랜치로 변경
$ git checkout -b feature/test1

# 출력
Switched to a new branch 'feature/test1'

# HEAD의 브랜치 조회하여 브랜치 변경 확인
/.git $cat HEAD
ref: refs/heads/feature/test1

# 실제 폴더 경로 들어가서 새로 생성됨을 확인해보기
/.git$ cd refs/heads 
/.git/refs/heads$ ll

# 출력
total 8
drwxr-xr-x  3 root  staff  96  4 29 02:32 feature # 새로 생성
-rw-r--r--  1 root  staff  41  4 28 02:10 main

/feature$ ll

# 출력
total 8
-rw-r--r--  1 wonyong  staff  41  4 29 02:32 test1

• 새로운 브랜치를 만들고 HEAD 브랜치를 조회하면 변경된 브랜치임을 확인할 수 있다.
• 또한, 해당 경로로 들어가 보면 feature/test1이라는 새로운 브랜치 폴더 및 파일이 생성되어 있음을 알 수 있다.

 

🔸 파일 변경해 보기

# 파일 변경 전
/git-internal-test$ git status                        

# 출력
On branch feature/test1
nothing to commit, working tree clean

# 파일 변경
/git-internal-test$ echo "i am not iron man." > first.text # ">"는 파일 덮어쓰기임
/git-internal-test$ git status

# 출력
On branch feature/test1
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   first.text

no changes added to commit (use "git add" and/or "git commit -a")

• 위의 설명에 이어 feature/test1에서 진행 중이다.
• 파일이 변경사항이 없는 unmodified였다가, 파일을 수정하여 modified로 변경되었다.

 

🔸 blob 객체 추가 확인하기

/git-internal-test$ git add first.text 
/git-internal-test$ cd .git/objects 
/.git/objects$ ll

# 출력
total 0
drwxr-xr-x  3 root  staff  96  4 28 02:10 82
drwxr-xr-x  3 root  staff  96  4 28 01:43 8e # 첫번째 blob 객체
drwxr-xr-x  3 root  staff  96  4 29 02:47 9f # 새로 추가된 blob 객체
drwxr-xr-x  3 root  staff  96  4 28 02:10 b1
drwxr-xr-x  2 root  staff  64  4 26 02:07 info
drwxr-xr-x  2 root  staff  64  4 26 02:07 pack

# 스테이징 영역 정보 확인하기
$ git ls-files --stage

# 출력(first.text에 해당하는 blob 객체의 해시값이 변경됨)
100644 9fe8f948e6de78c9f7627aba2632e6b0c80c6fb7 0	first.text

• 위의 설명에 이어 feature/test1에서 진행 중이다.
• git add 명령어로 first.text의 변경 사항을 스테이징 영역으로 올렸다.
• 변경된 새로운 blob 객체가 생성되었음을 확인할 수 있다.
• 또한 스테이징 영역 정보를 출력해 보면 새로 추가된 blob 객체로 해시값이 변경되었음을 확인할 수 있다.

 

👉🏻  git commit

# 두번째 커밋하기
$ git commit -m "second commit"
 
 # 출력
[feature/test1 8ed69f8] second commit
 1 file changed, 1 insertion(+), 1 deletion(-)
 
# 커밋 정보 확인하기
$ git rev-parse HEAD
8ed69f812495b68a4bafb47074f8efa7e9a0e845

# object에 두번째 커밋에 의해 추가된 tree, commit 객체 확인해보기
/.git$ cd objects 
/.git/objects$ ll

# 출력
total 0
drwxr-xr-x  3 root  staff   96  4 29 02:50 76 # 두번째 tree 객체
drwxr-xr-x  3 root  staff   96  4 28 02:10 82 # 첫번째 tree 객체
drwxr-xr-x  4 root  staff  128  4 29 02:50 8e # 두번째 commit 객체, 첫번째 blob 객체(두 객체의 해시값 첫 두자리가 같아서 같은 폴더에 들어감)
drwxr-xr-x  3 root  staff   96  4 29 02:47 9f # 두번째 blob 객체
drwxr-xr-x  3 root  staff   96  4 28 02:10 b1 # 첫번째 commit 객체
drwxr-xr-x  2 root  staff   64  4 26 02:07 info
drwxr-xr-x  2 root  staff   64  4 26 02:07 pack

# commit 객체 정보 출력
$ git cat-file -p 8ed69f812495b68a4bafb47074f8efa7e9a0e845
tree 766ad35e3fee28e3b41e90d64ee650546fa88383
parent b19a9f14568ce6ed7b22f02f2cecdd6aeff6929e # 부모 tree 객체 추가
author root <111210881+xxxxxx@users.noreply.github.com> 1745862647 +0900
committer root <111210881+xxxxxx@users.noreply.github.com> 1745862647 +0900

second commit

# 깃 커밋 그래프 출력
$ git log --oneline --graph --all

* 8ed69f8 (HEAD -> feature/test1) second commit
* b19a9f1 (main) first commit

• 위의 설명에 이어 feature/test1에서 진행 중이다.
• commit을 완료하면 새로운 tree 객체가 생성된다.
• commit을 완료하면 commit 객체가 새로 만들어진다.
• 또한, 두 번째 commit 객체 정보를 출력하면 부모 tree 객체가 무엇인지 추가로 표시된다.
• 커밋 이력을 그래프 형식으로 출력하면 feature/test1 브랜치에서 second commit 기록이 추가되었음을 확인할 수 있다.

 

🔸 main 브랜치로 돌아오기

$ git checkout main

# 출력
Switched to branch 'main'

# main 브랜치로 돌아와 스테이징 영역 정보 출력하기
$ git ls-files --stage
100644 8e21e230620d2380b2fee92cf506ea4e4dc3363a 0	first.text

# main 브랜치로 돌아와 HEAD의 커밋 객체 해시값 출력하기
$ git rev-parse HEAD

# 출력
b19a9f14568ce6ed7b22f02f2cecdd6aeff6929e

• main 브랜치로 돌아오면 기존에 있던 그대로 첫 번째 스테이징 영역의 blob 객체와, 첫번째 commit 객체 해시값이 출력됨을 확인할 수 있다.
  • main 브랜치로 돌아오면 HEAD가 다시 main 브랜치의 마지막 커밋을 가리키고, .git/index도 해당 커밋에 맞게 복원되기 때문이다.
  • 따라서 이전에 main 브랜치에서 스테이징 된 상태와 commit 내용이 그대로 출력되는 것이다.
  • 브랜치마다 HEAD 포인터가 가리키고 있는 commit 객체가 다르기 때문에 위와 같이 브랜치 별 작업이 가능한 것이다.

 

👉🏻  git merge

• 우선 main 브랜치와 feature/test1을 merge 해보자.

# main 브랜치에서 first.txt 출력
$ cat first.text 

# 출력
i am iron man. # 맨 처음 main 브랜치의 내용

# main 브랜치에서 깃 커밋 그래프 출력
$ git log --oneline --graph --all

# 출력
* 8ed69f8 (feature/test1) second commit
* b19a9f1 (HEAD -> main) first commit # HEAD가 main으로 나옴

# main 브랜치에서 새로운 파일 추가
$ echo "i am thanos." >> second.txt 

# git add & git commit
$ git add second.txt 
$ git commit -m "second commit in main" 

# 출력
[main 0a4bb61] second commit in main
 1 file changed, 1 insertion(+)
 create mode 100644 second.txt
 
# main 브랜치에서 깃 커밋 그래프 다시 출력
# A : 현재 main 브랜치(first commit 대비 변경사항 : second.txt "i am thanos.")
# B : feature/test1 브랜치(first commit 대비 변경사항 : first.text "i am not iron man.")
$ git log --oneline --graph --all
* 0a4bb61 (HEAD -> main) second commit in main # A
| * 8ed69f8 (feature/test1) second commit # B
|/  
* b19a9f1 first commit

# feature/test1 브랜치와 merge 해보기
$ git merge feature/test1

# 출력
Merge made by the 'ort' strategy.
 first.text | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

# first.txt 변경사항 확인
$ cat first.text 

# 출력
i am not iron man.

# merge 후 main 브랜치에서 깃 커밋 그래프 출력하기
$ git log --oneline --graph --all

# 출력
# merge(first.text "i am not iron man., second.txt "i am thanos.")
*   283c20c (HEAD -> main) Merge branch 'feature/test1'
|\  
| * 8ed69f8 (feature/test1) second commit
* | 0a4bb61 second commit in main
|/  
* b19a9f1 first commit

# merge commit 객체 정보 조회하기
/.git/objects/28$ git cat-file -p 283c20c2160c49dcade03214b6755cea8c370833

# 출력(현재 브랜치와 병합 대상 브랜치의 커밋 해시가 parent commit 해시로 두 개 나온다.)
tree 39b858e782d8e744d823614963c8b20b685730f2
parent 0a4bb610d806d091823ffed17f3add24bd859e3f
parent 8ed69f812495b68a4bafb47074f8efa7e9a0e845
author root <111210881+xxxxxx@users.noreply.github.com> 1745866013 +0900
committer root <111210881+xxxxxx@users.noreply.github.com> 1745866013 +0900

• merge에 성공하면 feature/test1 브랜치의 변경 내용이 main 브랜치에 반영되고, 두 브랜치의 기록을 연결하는 새로운 merge commit이 생성된다.
  • 위의 예시를 보면 main 브랜치의 second.txt 파일("i am thanos.")와 feature/test1 브랜치의 first.text 파일("i am not iron man.")이 모두 반영된 새로운 merge commit이 생성되는 것이다.
  • 해당 merge commit 객체는 parent가 두 개(현재 브랜치, 병합 대상 브랜치의 commit 객체)이다.
• 이 과정에서 병합된 파일 구조를 나타내는 tree 객체가 새로 만들어지며, 파일 내용이 추가로 변경된 경우에는 blob 객체도 함께 생성된다.

 

🔸  고의로 충돌 내보기

# main 브랜치에서 feature/test2 브랜치 생성
/git-internal-test$ git checkout -b feature/test2

# 출력
Switched to a new branch 'feature/test2'

# second.txt에 문장 추가
$ echo "i am thor" >> second.txt

# feature/test2의 second.txt 출력해보기 
$ cat second.txt 

# 출력
i am thanos.
i am thor

# main 브랜치로 돌아오기
$ git switch main

# 출력
Switched to branch 'main'

# second.txt에 다른 문장 추가
$ echo "i am captain america" >> second.txt

# main의 second.txt 출력해보기 
$ cat second.txt 

# 출력
i am thanos.
i am captain america

# 깃 커밋 그래프 출력해보기
$ git log --oneline --graph --all   

# 출력
# main 브랜치는 "i am captain america"
# test2 브랜치는 "i am thor"
* 41b266d (HEAD -> main) feature/test2 - captain america
| * 4b19a0f (feature/test2) feature/test2 - thor 
|/  
*   283c20c Merge branch 'feature/test1'
|\  
| * 8ed69f8 (feature/test1) second commit
* | 0a4bb61 second commit in main
|/  
* b19a9f1 first commit

# merge 해보기
$ git merge feature/test2

# 출력(second.txt에 내용이 달라 충돌 발생)
Auto-merging second.txt
CONFLICT (content): Merge conflict in second.txt
Automatic merge failed; fix conflicts and then commit the result.

# main의 second.txt 다시 출력해보기 
$ cat second.txt 

# 출력(Git에서 친절히 충돌 지점을 표시해줌)
i am thanos.
# <<<<<<< HEAD
i am captain america
=======
i am thor
>>>>>>> feature/test2

# 직접 수정 하든, 아래 명령어로 수정하든 main의 변경사항을 기준으로 하기
$ git checkout --ours second.txt

# main의 second.txt 다시 출력해보기 
$ cat second.txt 

# 출력(main의 변경 사항을 기준으로 하여 충돌 해결 함.)
i am thanos.
i am captain america

# git add & commit 통해 merge commit 생성하여 충돌 해결
$ git add second.txt
$ git commit -m "merge conflict solved"

# 출력
[main 3e7e5ea] merge conflict solved

# 깃 커밋 그래프 다시 출력해보기
# A : merge 충돌을 해결한 새로운 merge 커밋이 생성 됨
# B : 충돌 커밋("i am thor")
# C : 충돌 커밋("i am captain america")
$ git log --oneline --graph --all 
*   3e7e5ea (HEAD -> main) merge conflict solved # A 
|\  
| * 4b19a0f (feature/test2) feature/test2 - thor # B
* | 41b266d feature/test2 - captain america # C
|/  
*   283c20c Merge branch 'feature/test1'
|\  
| * 8ed69f8 (feature/test1) second commit
* | 0a4bb61 second commit in main
|/  
* b19a9f1 first commit

• 충돌이 발생한 후 git checkout --ours 명령어를 사용해 현재(main) 브랜치의 내용을 선택했다.
  • Auto로 충돌을 해결할 수 없어 수동으로 직접 충돌을 해결한 것이다.
• 이후 git add로 변경 사항(merge 충돌 해결한 부분)을 스테이징 영역에 올렸다.
• 이 과정에서 변경된 내용에 따라 새로운 blob 객체가 생성될 수도 있다.
  • 예를 들어, 지금과 같이 현재(main) 브랜치의 내용을 그대로 따르면 기존 blob 객체를 그대로 참조하여 새로운 blob 객체가 생성되지 않을 것이다.
  • 만약, "i am antman."과 같은 전혀 다른 새로운 내용으로 수정하여 충돌을 해결하면 새로운 blob 객체가 생성된다.
• 마지막으로 git commit을 실행하면 변경 내용을 반영한 tree 객체와 두 부모를 가진 merge commit 객체가 생성되며, 병합 결과가 Git에 최종적으로 기록된다.

 

 

 

참고

Chat GPT

2025 오픈소스 컨트리뷰션 아카데미 Git & Redis 수업 자료