섹션1. Git 의 데이터베이스

스

1. Git 의 데이터베이스

• 데이터베이스는 해당 서비스를 이해하는 로드맵 역할을 한다.

• 깃을 사용해오면서 숱하게 사용하는 기능 -> commit

1.1. 커밋은 디비에 어떻게 저장될까?

1.1.1. 커밋의 재료

• 메타 데이터

  • 커밋 메시지

  • 커밋한 사람의 정보(이메일)

  • 커밋 날짜, 시간

• 프로젝트 스냅샷 hash

• 부모 커밋 hash

1.1.2. 손으로 커밋을 만들어보자

1. git add .

   1. 파일 내용 저장 (blob : binary large object)

      1. a.txt 파일 내에 있는 aa 를 해싱 했더니 0a123 이 나왔고, 해당 해시값을 디비에 저장할 때 키 값으로 삼아 저장한다.

      2. b.txt 파일 내에 있는 bb 를 해싱 했더니 17cd6 이 나왔고, 해당 해시값을 디비에 저장할 때 키 값으로 삼아 저장한다.

      3. c.txt 파일 내에 있는 aa 를 해싱 했더니 0a123 이 나왔고, 해당 해시값을 디비에 저자할 때 키 값을 삼아 저장한다?

         1. a.txt 파일 내에 있는 값과 동일하기에 저장하지 않는다..

         2. 디비에 저장되는 파일은 4개?

      4. d.txt 파일 내에 있는 d 를 해싱 했더니 67c12 이 나왔고, 해당 해시값을 디비에 저장할 때 키 값으로 삼아 저장한다.

      5. e.txt 파일 내에 있는 e 를 해싱 했더니 bb234 이 나왔고, 해당 해시값을 디비에 저장할 때 키 값으로 삼아 저장한다.

   2. 파일 [이름 & 경로] 저장 (tree)

      1. 파일 [이름 & 경로] 를 저장할 때는 디렉토리 기반으로 저장하게 되고 파일 이름, 컨텐츠(위에서 각 파일 내용을 해싱한 값) 를 하나의 문자열 구조로 묶는다. -> 위 그림 예시에서는 src 디렉토리에는 3개의 파일 내용(a.txt, b.txt, c.txt)이 저장된다.

      2. 위에서 정리한 하나의 문자열 구조를 해싱하고 해당 해시값을 디비에 저장할 때 키 값을 삼아 저장한다.

      3. 똑같은 방식으로 res 디렉토리도 저장해준다.

   3. 하위 디렉토리 저장 (tree)

      1. 상위 디렉토리(root) 입장에서 하위 디렉토리를 저장할 때는 디렉토리 기반으로 저장하게 되고 디렉토리 이름, 컨텐츠(위에서 각 디렉토리 내 파일을 해싱한 값) 를 하나의 문자열 구조로 묶는다.

      2. 위에서 정리한 하나의 문자열 구조를 해싱하고 해당 해시값을 디비에 저장할 때 키 값을 삼아 저장한다.

2. git commit (commit)

   1. 커밋 메시지, 프로젝트 스냅샷 hash(루트 노드 hash), 부모 커밋 hash(처음 커밋의 경우 빈값) 을 하나의 문자열로 묶어서 해싱하고 해당 해시값을 디비에 저장할 때 키 값을 삼아 저장한다.

   2. 위 과정을 통해 최종적으로 나온 해시값이 커밋의 해시값이라고 부른다.

1.1.3. 커밋을 복원해보자. (중요한 파일을 날렸을 때 ㅠㅠ)

• 우리는 커밋이라는 과정을 통해서 특정 커밋의 해시값을 얻었다. (해당 커밋의 해시값을 통해서 구조를 만들어갈 수 있다.)

• 만약 우리가 저장한 key:value 기반 디비의 내용을 날린다면 복구할 수 없다..

• 때문에, 깃에서 사용하는 디비는 insert, select 만 가능하다. (프로젝트 전체를 복구할 수 있다)

1. git reset --hard [커밋 해시값 : ex, bb178]

   1. 디비에서 커밋 해시값을 조회한다.

   2. 해당 키의 value 값을 타고 들어가면서, 우리가 저장하면서 만들었던 트리 구조를 만들어간다.

      1. tree 구조를 만들고,

      2. 파일 내에 있는 값 또한 해시값으로 조회해 채워주어야 한다.

---

2. Commit 의 구조

---

3. Commit 의 관계

• 실제 커밋에 들어가는 정보는 root 노드의 해시값, 메타데이터, ... 정도 일 것이다.

• 결론적으로, root 노드의 해시값을 추적해서 트리 전체 구조를 만들 수 있을 것이다.

• 해시값의 특징 때문에, 프로젝트의 특정 스냅샷을 해시값이 대표하게 된다.

  • 해시값만 알고 있으면 특정 시점으로 돌아갈 수 있다!

3.1. 특정 파일을 수정하게 되는 경우

• 특정 파일을 수정하게 되면 해당 파일의 해시값이 달라지게 되고, 해당 파일과 관련된 전체 해시값이 달라질 수 밖에 없다.

  • 변경된 파일의 해시값부터 ~ 루트의 해시값 ~커밋 해시값까지 변경된다.

• 최초 커밋 후 특정 파일을 수정하게 되는 경우 부모 커밋과의 관계가 만들어지게 된다.

  • 때문에, 최초 커밋과 달리 커밋을 하는 순간, 커밋 메시지, 프로젝트 스냅샷 hash(루트 노드 hash), 부모 커밋 hash 값이 들어간다.

  • 첫번째 커밋은 두번째 커밋을 알지 못한다. 하지만, 두번째 커밋을 부모 커밋으로 첫번째 커밋을 알고 있다.

3.2. 두 커밋을 비교하기

1. git diff [비교1 커밋 해시값] [비교2 커밋 해시값]

   1. 각각 커밋의 루트 노드 해시값을 비교하고 동일하지 않다면 자식 노드 내용들을 추적한다.

      1. 만약 해시값이 동일하다면 두 커밋이 내용일 동일하다는 것을 의미한다.

      2. 해시값을 사용한 비교는 해시 값이 동일한 부분의 파일을 확인하지 않기 때문에, 높은 효율을 보인다.

      3. 또한, 버전 관리시 변경된 부분만 새롭게 저장하기 때문에, 공간 효율적인 측면이 있다. (실제 깃 이전에 버전관리는 .zip 으로 전체 프로젝트를 압축하는 방식을 사용하기도 했는데, 공간적으로 매우 비효율적이었다)

   2. 추적을 통해 해시값이 다른 부분을 확인해 달라진 부분을 확인한다.

---

4. Commit 생성하기