Git 내부 동작 파헤치기 - Part 1

들어가며

안녕하세요. 신입으로 원더월 모바일팀에서 앱 개발을 맡고 있는 이하연입니다.

Git은 소프트웨어 개발에서 필수적이고 강력한 도구 중 하나입니다. 이를 활용하면 여러 명의 개발자가 협업하는 프로젝트에서 코드의 변경 사항을 추적하고, 코드 버전 관리를 효과적으로 수행할 수 있다는 큰 장점이 있습니다.

현재 모바일팀 역시 이 Git을 활용하면서 개발을 진행하고 있는데요, 개발하던 도중 Git의 reset의 원리를 정확히 모른채 잘못 사용하여 데이터가 손실되고 프로젝트가 꼬인 일이 발생하였습니다. 그래서 Git 실습과 함께 내부를 파헤치며 배운 내용을 바탕으로 다양한 명령어들이 Git 내부에서 어떻게 동작하는지를 Part1, Part2로 나누어 소개하려고 합니다.

이번 포스트 Part 1에서는 기본 명령어들을 통해 Git의 내부 동작 원리 및 핵심 개념들을 낱낱이 파헤쳐 보겠습니다.

0) .Git 디렉토리

git을 통해 버전 관리를 하게 되면 여러 정보들이 생성되는데, 그 생성된 정보들은 .git 디렉토리에 저장이 됩니다.

ls -al 명령어를 통해 .git 디렉토리를 자세히 살펴보면 동작 원리를 이해하는데 핵심적인 요소들을 발견할 수 있습니다.

1) Git의 원리

저는 .git 디렉토리 안의 핵심적인 요소들의 변화를 gistory라는 분석 도구를 이용하여 보여드리려고 합니다.

gistory란 명령어에 따라 Git 내부에 존재하는 파일들이 어떠한 영향을 받는지 git 저장소의 커밋 로그를 시각화해서 보여주는 분석 도구입니다. 이 도구는 .git 디렉토리 안에 있는 내용들을 리스트로 보여주고, 새로 추가된 파일 혹은 변경된 파일의 내용들을 상세하게 확인 및 추적할 수 있습니다.

1-1 ) git init

아래의 사진은 git init을 한 직후의 내부 모습입니다.

1-2) git add

이 상태에서 f1.text라는 새 파일을 생성하게 되면 git 내부에 변화가 생길까요?

아니요. 파일을 생성하는데에 git이 관여하지 않기 때문에 변화하지 않습니다.

이번엔 파일을 생성 후에 명령어 “add”를 사용하게 되면 어떤일이 생길까요?

위와 같이 git 내부의 index 파일, objects 디렉토리에 있는 78/981… 파일에 변화가 생긴 것을 확인할 수 있습니다. 그 안을 자세히 살펴보면 objects 디렉토리 안에 있는 78/981… 파일은 제가 작성한 f1.text 내용이 blob 파일 형태로 저장되어 있고, index 적혀 있는 파일 이름은 f1.text이 아닌 7898…로 시작하는 어떠한 정보에 담겨져있습니다. 이 둘의 관계를 자세히 들여다보니, ”index의 7898…85 숫자” 는 “object의 78번째 디렉토리 + 9819..85” 임을 알 수 있었습니다.

1-3) blob

제가 blob 형태로 저장된다고 했는데, blob이 무엇일까요?

git에서는 파일이나 디렉토리를 저장할 때 내용을 직접 저장하지 않고, sha1란 해시 알고리즘을 통해 blob 파일 이름을 도출합니다. 이 blob 객체는 같은 내용의 파일이 여러개 있을 경우, 하나의 “blob” 객체만 저장하고 이를 여러 파일이 참조하는 방식으로 처리하여 중복 파일을 효율적으로 관리할 수 있습니다.

그렇다면 이를 확인하기 위해 f1.text를 copy 해보겠습니다.

.git 디렉토리 내부에서는 index와 objects/78/98..85 두 파일에 변화가 생긴 것 확인할 수 있습니다.

먼저 index 파일을 보면 f1.text와 f3.text 모두 같은 파일 이름이 적혀있었고 이는 곧 같은 오브젝트를 가리키고 있음을 알 수 있었습니다. 그 다음 objects/78/98..85는 기존 f1.text의 내용을 담고 있던 파일로 현재 f1.text와 f3.text 모두 같은 오브젝트를 가리킨다는 것을 알 수 있었습니다.

즉, git은 어떠한 파일을 저장할 때 index에는 파일명과 blob 파일주소를 가지고 있는데 파일 내용이 같다면 같은 blob 파일 주소( object 파일 )를 가리키게 되어 중복을 방지할 수 있게 됩니다. 그래서 내용이 동일하면서 용량이 크고 이름이 다른 여러개의 파일이 존재하더라도 하나의 blob을 참조하고 있어 효율적으로 관리할 수 있다는 장점이 있습니다.

1-4) commit

이번엔 add한 파일들을 commit를 해보았습니다.

가장 먼저 objects의 18/1031..78 파일을 열어보면 commit 메시지 정보가 저장되었음을 확인할 수 있습니다.

commit 안에는 작성자, 커밋 내용, tree가 있습니다. 이 tree도 sha1으로 만들어진 해시값이며, 이 값을 추적하면 커밋한 각각의 파일들의 이름과 내용을 담고 있는 blob 파일 이름에 관한 정보를 가지고 있음을 알 수 있었습니다. 이를 통해 commit을 하게 되면, commit 결과는 오브젝트 파일로 저장이 되고, 이 파일에 존재하는 tree의 값은 현재 우리가 작성한 버전에 해당되는 파일의 이름과 내용이 링크되어 있음을 알 수 있습니다.

이 상태에서 f2.text 내용을 수정 후 add, commit 할 때는 어떠한 변화가 생길까요?

먼저 add를 하게 되면 index파일의 f2.text 해시값이 변경되고 수정된 내용을 담고 있는 새 objects가 생성되었음을 알 수 있습니다.

다음으로 commit을 하게 되면 어떻게 될까요?

새로운 Parent라는 정보가 추가되었고, 이를 추적해보면 직전 커밋의 정보를 확인할 수 있습니다. 즉, tree는 현재 커밋한 오브젝트를 가리키는 해시값을, parent는 직전 커밋한 오브젝트를 가리키는 해시값을 가지고 있다는 것을 알 수 있습니다.

종합해보면 commit은 아래와 같은 정보를 가지고 있습니다.

1. commit은 변경 사항을 기록하는 메타데이터의 모음으로, 그 안에 작성자, 작성 일자, 커밋 메시지, tree를 가지고 있다.
2. commit은 변경 사항 자체를 저장하는 대신 이를 포함하는 파일의 스냅샷을 찍고, 해당 스냅샷에 대한 참조를 tree라는 정보 구조에 저장한다.
3. tree에는 commit이 일어난 시점에 우리의 작업 디렉토리에 있는 파일명과 내용을 담고 있는 Blob 파일주소가 담겨있고 이를 통해 프로젝트 폴더에 대한 상태를 얻어 낼 수 있다.
4. 각 commit(버전)마다 서로 다른 트리를 가리키고 있다.
5. parent 값을 통해 이전 커밋(직전 버전)이 누구인지 알 수 있다.

1-5) object 파일

또한 objects 디렉토리 안에 들어있는 object 파일은 크게 3가지로 정의할 수 있습니다.

1. 파일의 내용을 담고 있는 Blob 형태의 파일
2. 작업 디렉토리에 있는 파일명과 파일 내용에 해당되는 Blob 정보를 담고 있는 tree 파일
3. 변경 사항을 기록하는 메타데이터( 작성자, 작성일자, 커밋 메시지, tree)를 담고 있는 commit 파일

Git의 핵심 개념 3가지

앞서 설명드린 Git의 원리에 이어서 working directory, staging area, repository에 대해서 얘기해보겠습니다. 각 개념은 무엇을 의미하고 서로 어떤 연관 관계가 있는지 순서대로 전달드리겠습니다.

• Working directory(workspace)는 .git 바깥쪽에 있는 현재 프로젝트 폴더에 존재하는 파일들 자체를 의미하며 새로운 파일을 생성하거나 기존 파일을 수정하는 등의 작업을 이 디렉토리에서 수행합니다.
  • 위치 : 각자 프로젝트 폴더
• Staging Area(Index)는 Git이 추적하고 있는 변경 사항 중 어떤 것을 다음 버전의 커밋에 포함시킬지 선택하는 단계이며 커밋 하기 전 변경 사항을 검토하고 적절한 상태로 준비합니다. 이 곳은 내부적으로 Index 파일이며, 사용자의 입장에서 index라는 표현이 와닿지 않을 수 있어 Commit 대기 상태라는 의미에서 Staging area라고 부릅니다.
  • 위치 : 프로젝트 폴더 하위 .git/index 파일
• Repository는 모든 커밋과 해당 커밋의 메타데이터를 저장하는 Git의 데이터베이스입니다.
  • 위치 : 프로젝트 폴더 하위 .git/objects/ …

먼저 우리는 각 Working Directory에서 새로운 파일을 생성하거나 수정하는 등의 작업을 수행합니다. 이후 변경 사항은 Staging area로 이동하여 준비된 후, 커밋을 수행하여 repository에 저장됩니다. 변경 사항을 커밋할 때, Git은 staging area에서 변경 사항의 스냅샷을 캡처하여 새로운 커밋을 만듭니다. 커밋을 만들면 repository에서 해당 커밋의 메타데이터가 저장됩니다.

따라서, Git에서 working directory, staging area, repository는 각각 파일을 수정하고 준비하는 공간, 변경 사항을 커밋하기 위해 준비하는 공간, 그리고 모든 커밋과 해당 메타데이터를 저장하는 Git의 데이터베이스로 말할 수 있겠네요.

아래 사진은 Git의 내부 동작 원리 살펴보며 이를 도식화한 모습입니다.

글을 마무리하며

이번 포스트에서는 Git의 기본 원리와 init, add, commit 명령어들에 따라 핵심적인 요소들이 내부적으로 어떻게 동작하는지를 살펴보았는데요. Git을 잘 활용하기 위해서는 명령어들의 사용법과 동작 원리를 잘 이해하고 상황에 맞춰 적절히 이용해야함을 많이 느꼈습니다.

저와 같이 Git의 내부 동작을 잘 모르셨던 분들이 계신다면 이 글을 보고 도움을 받으셨으면 좋겠습니다!

다음 Part2에서는 Git에서 중요한 역할을 담당하는 명령어들에 대해서 더 자세히 살펴보겠습니다. 끝까지 읽어주셔서 감사합니다.