Github
왜 선형으로 관리 안하고, 그래프로 관리하냐
깃 내부 구조에 대해 알아보자.
Git은 애플리케이션이다.
+—————————+
| application |
+—————————+
| .git(폴더) 저장소 |
+—————————+
Key, value 저장소 이다.
Value => Blob, Tree Commit
Git의 3대 자료구조
Blob
Git commit 시 commit 될 때 파일 내용은 Hashing, 되어 Blob으로 저장 됨.
저장 위치
.git/objects
예를 들어
Tree
파일 A가 Hello world로 저장되어 있는데
파일 B도 Hello world로 저장하면
해시 값이 동일하다..
파일간의 관계를 Tree 형태로 저장한다.
Commit
작성자
Message
Parent commit
Add 된 파일들
40글자의 해시값으로 나온다.
SHA-1 로 저장하면 40 글자가 나온다.
그래프
방향성 비순환 그래프
Reset –HARD => 파일 시스템도 바꾼다
Reset –soft => 개념상으로만 변경
Branch
.git/refs에 저장된 파일 1개 이다.
요 파일안에는 해시값이 들어 있다.
Merge 커밋
두개의 commit 해시를 가지고 있는 구조이다.
**Rebase **
현재 커밋 내용을 다른 커밋 그래프로 이동시키는 것
B A
ㅇ ㅇ
ㅇ ㅇ
\ /
| ㅇ |
A를 B로 Rebase를 하겠다는 것은
B를 Base로 삼아서 생성됨으로
A와 B의 공통 부모 위치에서
A커밋이 추가된다.
A2
A1
b2
b1
o
B를 A로 Rebase로 하겠다는 것은
A와 B의 공통부모 위치에서
A의 브런치에서 B의 커밋이 추가된다.
b2
b1
A2
A1
o
Git은 Time Machine, Space Ship 이다.
rebase를 잘 다루면 앞서 진행된 커밋 내용도 수정되어 반영할 수 있다.
Git에서는 Insert, select만 존재한다.
흔히, 알고 있는 git commit –amend 는 수정이 아닌 생성이다.
자세히보면 아래와 같다고 한다.
abf
**O ** <—— commit - -ammend
O
o
abf 76c <— 변경됨
O O
| \ |
O | O
역사가 간단해야 유지보수가 편하다.
유지 보수 관점에서는 로그 그래프는 간편해야 한다.