Git 2 - 기본 원리 + branch/merge

Git 기본 원리

• workspace : 우리의 프로젝트
• index : stage라고 부르던 공간이다. add된 파일이 올라가있는 공간
• local repository : 해당 프로젝트 .git 디렉토리(로컬) 내 커밋된 파일들이 저장돼있는 공간.
• remote repository : github의 원격 레포지토리이다.

  SHA-1 (선행 지식)
  SHA(Secure Hash Algorithm) : 안전한 해시 알고리즘
  SHA 함수들은 미국 표준 암호학적 해시 함수들의 모음이다.
  SHA-1은 SHA-0, SHA-1, SHA-224, SHA-256 .. 등 SHA 함수들 중 하나이며 가장 널리 쓰이는 SHA함수이다.
  무작위 40자리 암호를 생성하는 함수라고 생각하면 된다.

add, commit, status를 통해 기본 원리를 알아보자

• add
  • 먼저, objects 디렉토리에 add한 파일의 내용이 blob타입으로 저장된다.
  • 해당 파일의 파일명은 실제 파일명이 아닌 SHA-1 값으로 저장된다. 이 때 SHA-1 값에서 제일 앞 두 글자는 hash key이다.

  • index 파일명 예시
    objects/71/630A3A10B172FC6F55B2CFA4C5C9B363D54AF9

  • add한 파일들의 blob 파일명들은 index에 올라와 있다.
  • 이 때, 파일 명이 다르더라도 파일 내용이 동일하면 index에선(실제 파일명으로) 따로 존재하지만 동일한 blob 파일명을 가진다.
• commit
  • 커밋한 파일들도 objects 디렉토리에 commit타입으로 저장된다.
  • commit타입 파일의 파일명도 SHA-1 값으로 저장된다.
  • commit타입 파일은 parent(부모 commit 타입 파일)의 파일명 값을 가지고 있다.
  • commit타입 파일은 저마다 tree 타입 파일의 파일명을 가지고 있다. tree 파일은 해당 커밋의 blob 타입 파일의 파일명들을 가지고 있다. tree 타입 파일의 파일명도 SHA-1 값으로 저장된다.
  • commit타입 파일은 config 정보를 가지고 있다.
  • 즉, 커밋을 하면 해당 커밋 파일은 그 순간의 snapshot 정보들을 가지고 있다는 것이다.(tree, parent, config)
• add, commit
  • 지금까지
    - 실제 파일의 내용이 담긴 blob 타입 파일
    - 해당 커밋의 snapshot 정보를 가지고 있는 commit 타입 파일
    - 해당 커밋된 blob 타입들의 타입명들을 담고 있는 tree 타입 파일
    들이 objects 디렉토리에 sha1 키값으로 저장되는 과정을 살펴봤다.
• status
  • git은 commit할 파일이 없다는 사실을 어떻게 알아채는가?
  • git은 파일 내용의 변화를 관찰하고 있다.
  • index 파일들의 내용과 최신 커밋 파일들의 내용이 동일하다면 커밋할 파일이 없음으로 간주한다.

Branch

git branch exp

"하나의 작업 흐름 단위"이다.

• 프로젝트를 진행함에 따라 새로운 작업 흐름이 생길 수 있는데, 이 때 우리는 new Branch, 즉 새로운 브런치를 만든다.
• 가장 초기에 시작된 기본 작업 흐름. 이미 우린 브런치를 하나 가지고 있어왔다. 이 브런치의 이름은 master이다.
• 새로운 브런치의 이름은 해당 작업의 목적에 따라서 이름을 만들어주는 것이 좋다.
• 위에선 exp라는 브런치를 새로 생성했다.

git checkout OOO

현재 브런치를 빠져나오고 OOO 브런치로 이동한다.
"head가 OOO 브런치를 가르키게 하는 것"과 동일하다.

• 브런치를 이동(check out)하면서 서로 다른 작업 흐름 단위에 대해 작업할 수 있다.
• 갈라져서 작업 후 필요없으면 버리고. 병합해야 하면 merge 처리한다.
• 왜 head는 현재 브런치(master)를 가르키고
  master는 현재 commit버전의 파일명을 가르키는지 이제 이해할 수 있었다.
  head는 branch를 가르키는 파일이고, branch는 커밋을 가르키는 파일이다.

git merge OOO

OOO 브런치를 master 브런치와 병합한다.

• 병합된 커밋은 병합한 두 브런치들의 최신 커밋을 부모로 가진다.

example

1. master : 1, 2 commit
2. master : git checkout -b exp(exp branch 생성 후 checkout)
3. exp : 3, 4 commit
4. exp : git checkout master
5. master : 5 commit
   
6. master : git merge exp
   이 때, exp가 master로 병합된 새로운 커밋이 master의 최신 커밋이 되었다.
   이 master의 최신 커밋은 두 개의 부모 커밋을 가진다.(master의 5, exp의 3, 4)
   하지만 exp의 최신 커밋인 4는 5 commit을 부모로 가지지 못하고 있다.
   완전한 merge가 이뤄지지 않은 것임.
   
7. master : git checkout exp
8. exp : git merge master
   exp가 master와 똑같은 커밋(1f91a45)을 최신 커밋으로 가지고 있다.(최상단)
   exp와 master는 이제 완전히 똑같은 상태가 된 것이다.
   그럼 이제 더 이상 exp branch를 들고 있을 필요가 없다.
   
9. git branch -d exp
   exp 브런치가 흔적도 없이 사라졌다.
   여기서 궁금증 : 6번 직후에 exp branch를 바로 삭제했어도 결과는 같지 않았나?