• git의 원리에 대한 공부
  • 주요 키워드: .git , local repo, remote repo, working tree, stage(=index), origin, blob, tree객체, 체크썸
  • 진짜 객체는 blob, tree, commit 뿐이고, 나머지(branch, HEAD 같은 것)는 모두 참조일 뿐이다.
    • commit객체 —— tree객체 — 또다른 tree객체 + blob객체
  • file id는 파일내용을 SHA-1 Hash (체크썸) 하여 얻어짐. => 파일이 달라도 내용이 같으면 같은 id를 얻는다.
  • git state 했을 때 clean한 상태 ==> working tree와 stage가 동일한 상태 ( stage가 비워져있다는 뜻이 아니다! )
  • git add 시 ==> working tree에서 stage로 파일이 blob(binary large object)형태로 바뀌어 저장됨.
    • 파일 내용이 바뀌면, 체크썸도 바뀌기 때문에 내용을 일일히 diff하지 않아도, 체크썸만 비교하여 stage로 올릴 파일(변경사항이 있는 파일)을 찾을 수 있다.
    • git hash-object a.txt // 선택한 파일의 내용을 체크썸(SHA-1)한 id값 리턴. blob의 id로 쓰인다.
    • git cat-file -t ${id} // 해당id가 가리키는 type 리턴 (type종류: blob , tree, commit, tag)
    • git ls-tree –stage // stage에 올라가있는 객체 정보 확인
  • git commit 시 ==> stage에 올라간 blob들을 한덩어리로 묶은 tree객체나 또 다른 tree객체들에 대한 정보가 들어간 commit객체가 만들어짐
    • git ls-tree ${tree id} // tree에 포함된 blob객체 정보 확인 가능 (blob id, file name 등)
    • git cat-file commit ${commit id} // tree id, parent id, author 정보등이 들어간 commit객체를 확인 가능.
  • 커밋이 참조되는 구조 : HEAD(참조) ==> * branch name(참조) ==> commit “객체”
    • commit은 항상 이전 부모를 참조함. (like 링크드 리스트). 마지막으로 커밋된 객체(최신커밋)을 HEAD가 가리킴
    • HEAD는 branch를 거쳐서 commit을 참조하지만, git checkout “${commit id}”를 할 경우 HEAD가 직접 commit 객체를 참조하게 되는 현상 => Detached HEAD (안좋은 현상. HEAD가 다른 커밋으로 인해 이동할 경우 branch참조를 하지 않으므로 트리에서 사라져버림. 어딘가에 객체로 남아있지만.. GC의 대상이 될 뿐)
  • svn은 diff로 일일히 변경사항을 확인하고 그 내용을 저장하여 올렸으므로 느리고 성능도 떨어졌지만, git은 체크썸으로 변경파일을 확인하고 해당파일 전체를 저장해버리므로 성능 향상 도모. (update가 아닌 항상 create만 함). 현대사회(?)에서는 저장용량에 대한 기술이 발전하고 저렴한 가격으로 사용할 수 있어서 용량에 관대하므로 성능이 빠른게 더 좋다.
  • 이 외에.. reset, rebase, checkout, cherry-pick, merge가 어떤 식으로 이루어지고 장단점이 무엇인지 알기
    • git branch를 시각적으로 실습하기 좋은 사이트 : 링크
  • 앞으로는 ~
    • git을 사용하다 문제가 일어났을 경우, 이런 구조와 원리를 떠올리면서 해결방법을 모색해 볼 것 (예전처럼 스택오버플로우에 나온 answer 적용해보고 되면 땡 하지말고)
    • 내가 git같은 시스템을 만든다면 자료의 구조는 어떻게 하고, 주요 명령어(add, commit, push, pull같은) 처리는 어떻게 할지 떠올려 보는 것도 좋음