버전관리 도구 Git이란? Git의 내부구조 파헤치기

VSC & Git

https://git-scm.com/book/ko/v2/시작하기-버전-관리란%3F

 

버전 관리 시스템(VCS)은 소스 코드의 변경 이력을 관리하고, 팀원 간의 협업을 용이하게 해주는 도구이다. VCS는 크게 로컬 VCS, 중앙집중식 VCS, 그리고 분산 VCS로 나눌 수 있다. Git은 분산 VCS로서, 각 개발자의 로컬 환경에 모든 프로젝트의 전체 버전과 변경 이력을 복제하여 관리한다.

 

---

Git의 내부 구조

지옥에서 온 GIT : git의 원리 소개

Git - Git 개체

Git의 내부구조

 

Git은 내부적으로 Content-addressable 파일시스템으로 동작한다.

이는 데이터를 Blob(내용)과 Tree(디렉토리 구조) 객체로 저장하며, 커밋(Commit) 객체는 변경 사항과 메타데이터를 포함하게 된다.

각 객체는 SHA-1 해시 값을 사용하여 고유하게 식별되며, .git/objects 디렉토리에 저장된다.

 

 

Blob Object

• 파일에 대응하여 내용이 저장되는 Object
• 파일의 이름이나 형식등은 저장되지 않고 내용만 저장된다.
• 이름이 다른 2개의 파일이 프로젝트 내에 있다해도, 그 내용이 같으면 Git은 Blob을 한 개만 저장함.

 

Tree Object

• Working directory의 디렉토리에 대응하여 git에 저장되는 object.
• tree의 내용은 해당 디렉토리 내부의 파일과 디렉토리 정보(파일명, 형식, SHA-1 등)를 담은 blob과 tree object의 리스트

 

Commit Object

• commit history를 저장하는 object
• author, committer, commit message를 포함하고 있다.

 

Tag Object

 

git의 특정 commit에 tag를 달면 tag object가 생성됨.

• lightweight 태그: 특정 commit에 대한 포인터
• annotated 태그: 태그의 작성자, 이메일, 날짜, 메시지 저장

 

 

다음 그림을 통해서 구조를 쉽게 이해할 수 있었다.

출처: https://cyberx.tistory.com/81

• 첫 번째 커밋 이후 README 파일은 변경되지 않았다. 따라서 두 번째 커밋에서의 최상위 트리(Tree)는 첫 번째 커밋과 동일한 Blob을 가리키고 있다. 그러나 두 번째 커밋에서는 새로운 파일인 dir/test.txt가 추가되었다. 이 두 번째 커밋은 master 브랜치의 레퍼런스(참조)를 가리키며, 이 레퍼런스를 다시 HEAD 레퍼런스가 가리키고 있다.
• 이 상태에서 dir/test.txt가 추가되고, README 파일이 수정된다면 아래와 같은 구조로 변경될 것이다.
• 새로운 커밋(Commit) 객체와 루트 트리(Tree) 객체가 생성되며, 새로운 dir 트리와 수정된 README, 그리고 dir/text Blob 객체들을 가리키게 될 것이다. 각각의 버전은 해당 시점에서의 파일 스냅샷을 트리 구조로 나타낸 것이다. Git은 이러한 방식으로 파일의 변경 이력과 프로젝트의 전체 버전 관리를 효과적으로 수행한다. 이러한 강력한 기능을 통해 여러 사용자가 협업하고, 안정적으로 소스 코드를 관리할 수 있다.

출처: https://cyberx.tistory.com/81

---

Git 파일 관리

저장소 안의 파일들의 상태를 확인해보자 :: git status

Tracked

1. Unmodified: 파일이 수정되지 않은 상태 (= 파일이 최근에 저장한 상태 그대로임)
2. Modified: 파일이 수정된 상태 (= 파일이 최근에 저장한 파일과 달라짐)
3. Staged: 파일을 저장할 예정인 상태 (= 이 파일을 저장할 것이라는 뜻)

---

git add

• git add 명령어를 실행하면, 파일들의 변경 내용이 Git의 Staging Area에 추가된다. Staging Area는 다음 커밋에 포함될 파일들의 목록을 담고 있는 임시 저장소로 볼 수 있다.
• 이렇게 Staging Area에 파일들의 정보가 추가되면, 커밋(commit)을 하게 되면서 현재 Staging Area에 있는 파일들의 스냅샷이 새로운 커밋 개체(Commit Object)를 생성한다. 새로운 커밋 개체에는 해당 버전에서의 파일 구조와 각 파일들의 Blob 개체에 대한 정보가 담겨 있다.

---

git commit

• 커밋 메시지에 해당하는 정보가 objects 안에 저장된다.
• tree에 있는 값은 우리가 작성한 버전에 해당하는 파일 이름과 내용이 링크되어 있다.
• 파일내용을 수정해서 add하고 커밋을 한번 더 하면, parent 라는 곳이 생기는데, 이전 commit을 보여준다. 첫번째 commit의 tree값(아래)과 두번째 commit(위)의 tree값이 다른 것을 알 수 있다.

 

각각의 버전은 그 버전이 만들어질 시점의 snapshot을 tree의 정보구조로 가지고 있다.

정리하자면, object 파일은 세가지 중 하나이다.

1. 파일의 내용을 담고 있음 → blob
2. 어떤 디렉토리의 파일명과 내용에 해당되는 blob에 대한 정보를 담고 있다. → tree
3. object id를 갖고 있다. → commit

 

---

 

git log

• 여러 번의 커밋을 거치면서 각각의 버전은 그 버전이 만들어진 시점의 파일 스냅샷을 Tree의 정보 구조로 가지고 있게 된다. 이를 통해 Git은 프로젝트의 모든 버전을 안전하게 보존하는데 이걸 git log 명령어을 통해 확인할 수 있다.
• git log 명령어를 실행하면 각 커밋의 정보와 변경된 파일들의 목록을 볼 수 있다.

---

 

git remote & git clone

• 원격 저장소(Remote Repository)와의 연결은 git remote 명령어를 통해 관리한다. 원격 저장소는 프로젝트를 다른 사용자와 협업하고, 중앙 저장소로 이용하는 등 다양한 용도로 사용된다.
• git clone 명령어를 사용하면 원격 저장소의 프로젝트를 로컬 환경으로 복제하여 작업할 수 있다.

 

---

SHA256 해시

출처: https://academy.bit2me.com/en/sha256-bitcoin-algorithm/

[Blockchan A-Z] SHA256 - 해시(Hash) 이해하기

디지털 문서에 대한 지문이라고 보면된다.

• 해시의 길이는 언제나 64자이고 숫자뿐만 아니라 문자가 올 수 있다. 왜냐하면, 16진법 해시이기 때문이다.
• 같은 데이터를 입력하면 언제나 같은 해시값을 얻는다.
• 주 작은 심볼을 변경하면 해시값은 완전히 달라진다. 이를 쇄도 효과라고 한다.

여기서 objects 파일명의 원리가 나오는데, sha1 해시값 40자리로 변환시켜서 앞에 두글자는 디렉토리, 나머지는 파일명으로 저장이된다.