몰랐던 Git에 관한 이야기

대학교 처음 들어와서 동아리에서 게임개발을 배우고 함께 배웠던 것이 Git 사용법이다. 깃은 버전 관리 툴로 개발 할 때 협업이나 프로젝트 관리 면에서 도움을 주는 도구다. 게임 개발 뿐만아니라 웹 프로젝트, 알고리즘 문제 기록 등 여러 방면으로 써왔고 사용법이 익숙하지 않을 때 빨간 줄로 이유를 알 수 없는 오류가 뜨면 파일을 지우고 깃을 다시 clone 해오거나 했었는데 이제는 능숙하게 merge 할 수 있다. 그래서 나는 내가 git을 잘 활용 하고 있는줄 알았다. 어떤 강의를 듣기 전까지

 

Git 객체에 해당하는 것들을 고르시오.

라는 간단한 퀴즈였고 나는 처음 들어보는 용어였다. Git에 객체라는게 있었나? 놀랍게도 있다.

https://git-scm.com/book/ko/v2/Git%EC%9D%98-%EB%82%B4%EB%B6%80-Git-%EA%B0%9C%EC%B2%B4

Git - Git 개체

심지어 Git을 다운로드 받을때 외에는 들어가지 않았던 Git공식 홈페이지 문서다.

 

Git에는 4개의 객체가있다.

Blob

Tree

Commit

Tag

 

그리고 이 4개가 몰랐던 깃에 대한 전부이다.

우선 간단하게만 보면

Blob : Binary Large Object로 파일이다.

Tree : blob을 묶어서 관리한다.

Commit : Tree + Blob + 메타정보

Tag : Commit에대한 참조지만 설명이 추가된다.

 

그 와중에 우리가 자주 깃에서 보던 그 녀석이 없다.

Branch ? 

브랜치는 단순히 포인터 같은 것이다. Commit을 참조하고 있다.

git reset --hard HEAD^

이런 명령어를 본적 이 있을것이다. 적어도 난 많이 썼다.

여기서 HEAD가 의미하는 것은 HEAD branch이고 이 역시도 commit에대한 참조인 것이다.

 

이해를 쉽게하자면 우리가 자주 쓰는 명령어를 보면

git add .
git commit -m "asdf"

커밋을 하는 순간 이전 커밋을 가리키는 노드가 생겨나고

이는 링크드 리스트 형식으로 생각할 수 있다. 이것이 우리가 아는 branch와 commit의 정체이다.

 

Blob같은 경우에 일반적으로 파일을 SHA1 hash 로 이름이 지어진다. 같은 내용의 파일의 경우에 같은 hashcode를 볼 수 있다. 일반적으로 Git에 커밋을 한다면 공간효율을 위해 변경사항만 저장할 것 같지만 ( 나도 그런줄 알았다. ) 실제로는 전체를 저장한다.

 

이유 역시 합리적이다. 변경사항만 저장한다면 역추적하기가 어렵다.

예시를 들어보자 100번째 커밋에서 20000번째 커밋으로 변경하려고 할때 변경사항만 저장한다면 100..101..102..20000까지 가야되는 반면 전체를 저장하고 있으면 바로 변경이 가능하다.

 

 

git status

이 명령어는 그럼 무엇을 하는 명령어 인가?

stage, Head 커밋, 작업디렉토리 를 비교하는 명령어이다.

 

여기서 Stage란? 커밋을 만들기 위한 임시 공간이다. 우리가 git add . 하면 추가된 파일들이 Stage로 올라간다는 것은 알것이다. log에 staged, unstaged와 같은 명칭들을 봤다면 말이다.

여기서 git commit을 하면 Stage가 비워지는 모습을 볼 수 있다. 이 말은 틀린 말이다. abc.text를 stage에 올리고 커밋한다음 수정해보자. 빨간색으로 modified라고 뜨는 모습을 볼수 있다.

그렇다 commit을 하면 Stage가 비워지는것이 아니라 우리눈에 안보이는것이지 이는 Unmodified 형태로 계속 추적 되고 있는 것이다.

 

후기

Git을 정말 많이 쓰고 많이 안다고 생각했지만 실제로 Git이 어떻게 동작하는가에대해서는 하나도 알지 못했던 것 같다. 이와 같이 어떤 도구를 잘 쓰는것도 중요하지만 이러한 도구들이 왜 쓰게 됐는지 어떻게 동작하는지 아는 것 역시 중요하다고 생각 되는 강의 였던 것 같다.