<4> 생활코딩 - GIT

commit메세지가 길지도 않은데 파일이 수정될 때마다 add 하고 editor를 띄어서 거기서 commit메세지를 작성하는 과정이 귀찮은 일이다.

이런 경우에는 어떻게 하면 되는가?

우리가 메뉴얼을 찾아서 알아낼 수 있는 것인데

git commit --help 라고 하면 커밋 메세지에 대한 도움말을 볼 수가 있다.

옵션들에 따라 commit하는 방법을 우리가 원하는대로 달리 줄 수 있다.

options

-a 와 -all은 똑같이 사용된다. 이것은 우리가 수정이나 삭제한 파일들을 자동적으로 stage에 올린다라는 뜻.

예를 들어, vim f1.txt 입력하여 '4'라는 내용을 입력하고 나와서 파일을 add해주고 commit을 하여 commit 메세지를 입력하였는데

git commit -a를 하면 바로 commit 메세지를 입력하는 단계가 실행된다.

 

이제는 이렇게 이디터를 키는 것도 귀찮을 수가 있다. 이럴때는 다시 git commit --help를 들어가서 찾아본다.

-m 뒤에 적혀있는 어떠한 텍스트를 commit 메세지로 사요하겠다라는 뜻.

f1.txt에 내용을 입력하고 git commit -a는 바로 commit 에디터로 가는 것인데, git commit -am 은 에디터를 띄우지 않고 메세지를 바로 여기서 작성하겠다는 뜻.

---

git의 원리 소개

'git의 명령어들을 실행했을 때 그것이 어떤 메커니즘에 의해서 동작하는가' 라고 하는 git의 원리에 대해서 알아보자.

 

원리 - 분석도구 gistory 소개

.git 디렉토리에 어떠한 변화가 생기는가 살펴보자. git의 내부가 어떻게 구성되어 있는가를 보자. 

그걸 하기 위해서 여려가지 방법이 있지만 조금 더 편하게 하기 위해 생활코딩님이 서비스 소프트웨어 gistory라는 것을 만드심.

 

.git 이라는 디렉토리에 있는 내용들을 리스트로 보여줌. 그리고 파일이 변경되면 변경되거나 추가된 파일이 제일 위쪽으로 올라온다.

그걸 보면 방금 내가 내린 명령이 어떤 파일에 영향을 주었는지 알 수 있고 그 각각의 파일의 내용이 무엇인지를 클릭해서 알아 볼 수 있다.

 

 

---

원리

1. git은 어떤 파일을 저장할때 파일의 이름이 달라도 파일의 내용이 같으면 같은 오브젝트 파일을 가르킨다.

예를들어 10000개의 파일이 각각 10기가의 아주 큰 파일이더라고 그 내용이 같다면 그 만개의 파일은 인덱스에는 각각의 파일명만 적혀있고 만개의 파일이 똑같은 오브젝트 파일을 가르키기 때문에 이런 경우에 생길 수 있는 어마어마한 중복을 제거한다.

 

우리가 만든 파일의 내용이 'a'라면 그 파일이 저장되어 있는 오브젝트의 이름도 78디렉토리에 98로 시작하는 파일명에 담겨있게 된다.

내용이 같다면 내가 작성한 것이건 다른 모든 사람이 작성한 것이건 반드시 이름이 7898~~이 된다.

 

내용이 같으면 파일의 이름이 같다.

즉, 내용을 기반으로 해서 파일의 이름이 결정되는 메커니즘이 무엇을 사용하고 있는지 알아보자.

 

http://www.sha1-online.com/

위의 링크에서 

'hi'라고 입력하면 c22b5f9178342609428d6f51b2c5af4c0bde6a42 라는 정보가 나올 것이다. 이것은 세계 모든 사람들이 적어도 똑같은 정보를 얻게 된다.

'hi'라는 정보는 hash라고 하는 어떤 메커니즘을 통과하면 c22b5f9178342609428d6f51b2c5af4c0bde6a42 라고 하는 어떠한 일정한 길이의 텍스트를 얻어낼 수 있다라는 것이다.

즉, 깃은 우리가 저장한 파일의 내용을 sha1이라는 hash알고리즘을 통과시켜서 그 파일의 이름을 도출한 다음에 이 파일의 이름, 해쉬 값이라고 하는 정보에서 앞의 두글자를 떼서 오브젝트 디렉토리 밑에다가 c2라는 디렉토리를 만들고 그리고 그 밑에 2b로 시작하는 파일을 만들어서 그 안에다 hi라는 정보를 저장하는 것이다.

 

 

2. 각각의 버전마다 서로 다른 트리를 가르키고 있고 그 트리에는 파일의 이름과 그 파일에 담겨있는 내용이 각각 링크로 되어있기 떄문에 

우리는 이 버전의 적혀있는 트리를 통해서 그 버전이 만들어진 시점에 우리의 프로젝트 폴더에 대한 상태를 얻어낼 수 있다.

그런걸 뭐라고 표현하냐면 '스냅샷'이라 표현한다. 즉 각각의 버전은 그 버전이 만들어진 시점에 스냅샷을 트리라고 하는 정보 구조를 통해서 가지고 있다는 것이다.

 

 

오브젝트라는 디렉토리 안에 들어가는 파일은 오브젝트 파일이고 오브젝트 파일은 크게 세가지 중에 하나이다.

      1) 파일의 내용을 담고 있는 것. (blob이라는 것. 파일의 내용을 담는 것.)

      2) 어떤 디렉토리에 파일명과 그 파일명의 해당되는 내용에 해당되는 blob에 대한 정보를 담고 있는 것, 트리이다.

     3) 커밋이다. 각각의 커밋은 밑의 사진처럼 오브젝트 id를 갖고 있다.

 

 인덱스라는 파일이 무엇인가? & status라는 명령이 어떻게 동작하는가?

 

git status를 입력하면 이때 깃이 커밋 할 것이 없다 라고 하는 것은 어떻게 깃은 이것을 알 수 있을까..

정확한 처리 방법을 모르겠지만 우리가 봤던 파일들 중에는 인덱스라는 파일이 있다. (굉장히 중요한 파일)

그리고 또 하나는 현재 우리의 가장 최신 커밋. 이 두개 사이의 차이를 비교하면 커밋할게 있는지 없는지 알 수 있다.

ex) f2.txt 수정하

깃은 인덱스의 내용과 최신 커밋의 마지막 커밋 트리가 가리키고 있는 f2.txt 파일의 내용이 다르다면 현재 f2.txt는 인덱스에 add가 되어서 커밋 대기상태에 있다는 것을 알 수가 있다.

* 프로젝트 폴더를 이제부터 워킹 카피로 부르겠다.

저장소와 인덱스와 워킹카피 이 세가지가 정확하게 일치하기 때문에 깃은 git status를 했을 때 더이상 커밋할 것이 없다고 라고 우리에게 알려주는 것이다.

 

workspace : .git 디렉토리 바깥쪽에 있는 워킹디렉토리(프로젝트 폴더)에서 add를 하면 그 내용들이 인덱스파일에 등록이 됨. commit을 하면 인덱스 파일에 등록된 내용들이 레파지토리에 오브젝트로 저장이 되는데 커밋 오브텍트가 저장이 되고 트리가 저장이 되고 그리고 파일이 저장이 되는 것이다.

working derectory  -  index or staging area or cache  -   repository