Git 기초
Git은 기존 VCS에서 사용하던 Subversion이나 Perforce같은 것과 다르기 때문에 같은 개념으로 이해하려고 하면 헷갈릴 수 있다. Git과 기존 VCS는 사용자 인터페이스가 유사하지만, 정보를 다루는 방식이 다르다. 이런 차이점을 이해하면 Git을 이용하는 것이 어렵지 않을 것이다.
Difference vs. Snapshot
Subversion과 Git의 가장 큰 차이점은 데이터를 다루는 방법에 있다. 큰 틀에서 봤을 때 VCS 대부분은 관리하는 정보가 파일들의 목록이다. CVS, Subversion, Perforce, Bazaar 등의 시스템은 각 파일의 변화를 시간순으로 관리하면서 파일들의 집합을 관리한다. 이러한 것들을 델타 기반 VCS이라고 한다.
위는 VCS에서 데이터를 저장하고 다루는 방식이다. Git은 위와 같이 데이터를 저장하지도 취급하지도 않는다. 대신 데이터를 파일 시스템 스냅샷의 연속으로 취급하며, 그 크기가 매우 작다. Git은 커밋하거나 프로젝트의 상태를 저장할 때마다 파일이 존재하는 그 순간을 중요하게 여긴다. 파일이 달라지지 않았으면, Git은 성능을 위해서 파일을 새로 저장하지 않는다. 단지 이전 상태의 파일에 대한 링크만 저장한다. Git은 데이터를 스냅샷의 스트림처럼 취급한다.
이것이 Git이 다른 VCS와 구분되는 점이다. Git은 강력한 도구를 지원하는 작은 파일시스템이다. Git은 단순한 VCS가 아니다. Git 브랜치를 사용하면 여러가지 이점이 있다. 브랜치에 대해서는 다른 아티클에 포스팅 하도록 하겠다.
로컬에서 대부분의 명령을 실행
거의 모든 명령이 로컬 파일과 데이터만 사용하기 때문에 네트워크에 있는 다른 컴퓨터는 필요 없다. 이러한 점은 대부분의 명령어가 네트워크의 속도에 영향을 받는 CVCS에 비해 큰 장점이다. 즉, 프로젝트의 모든 히스토리가 로컬 디스크에 있기 때문에 기존 VCS에 비해 명령이 매우 빠르게 실행된다.
Git은 히스토리를 조회할 때 서버 없이 로컬 데이터베이스에서 조회한다. 즉, 오프라인 상태거나 VPN에 연결하지 못해도 막힘없이 작업을 할 수 있다. 이는 다른 VCS 시스템에서는 불가능하다. Perforce는 서버가 없을 때 할 수 있는 작업이 거의 없고, Subversion이나 CVS에서도 마찬가지로 데이터베이스에 접근할 수 없어서 파일을 편집할 수 있으나 커밋이 불가능하다.
Git의 무결성
Git은 데이터를 저장하기 전에 항상 체크섬을 구분하고 그 체크섬으로 데이터를 관리한다. 그래서 체크섬을 이해하는 Git 없이는 어떠한 파일이나 디렉토리도 변경할 수 없다. 체크섬은 Git에서 사용하는 가장 기본적인(Atomic) 데이터 단위이자 Git의 기본 철학이다. Git 없이는 체크섬을 다룰 수 없어서 파일의 상태도 알 수 없고 심지어 데이터를 잃어버릴 수도 없다.
Git은 SHA-1 해시를 사용하여 체크섬을 만든다. 만든 체크섬은 40자 길이의 16진수 문자열이다. 파일의 내용이나 디렉토리 구조를 이용하여 체크섬을 구한다. SHA-1은 아래와 같이 생겼다.
24b9da6552252987aa493b52f8696cd6d3b00373Git은 모든 것을 해시로 식별하기 때문에 이런 값은 여기저기서 보인다. 실제로 Git은 파일을 이름으로 저장하지 않고 해당 파일의 해시로 저장한다.
Git은 데이터를 추가할 뿐
Git으로 무얼 하든 Git 데이터베이스에 데이터가 추가되고, 이후 되돌리거나 데이터를 삭제할 수 없다. 물론 다른 VCS 처럼 Git도 커밋하지 않으면 변경사항을 잃어버릴 수 있다. 하지만, 일단 스냅샷을 커밋하고 나면 데이터를 잃어버리기 어렵다.
Git을 사용하면 언제든 되돌릴 수 있기 때문에 프로젝트가 심하게 망가질 걱정이 없어 다양한 시도를 해볼 수 있다. 되돌리는 방법에 대해서는 다른 아티클에 포스팅하도록 하겠다.
세 가지 상태
Git은 Committed, Modified, Staged 이렇게 세 가지 상태로 관리한다.
- Committed는 데이터가 로컬 데이터베이스에 안전하게
저장되었다는 것을 의미한다. - Modified는 수정한 파일을 아직 로컬 데이터베이스에
커밋하지 않은 것을 말한다. - Staged는 현재 수정한 파일을 곧
커밋할 것이라고 표시한 상태를 의미한다.
이 세 상태는 Git 프로젝트에서 Git 디렉토리, 워킹 트리, Staging Area의 세 단계와 연결되어 있다.
Git 디렉토리는 Git이 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳을 말한다. 다른 컴퓨너테 있는 저장소를 Clone 할 때 Git 디렉토리가 만들어진다.
워킹 트리는 프로젝트의 특정 버전을 Checkout 한 것이다. Git 디렉토리는 지금 작업하는 디스크에 있고 그 디렉토리 안에 압축된 데이터베이스에서 파일을 가져와서 워킹 드리를 만든다.
Staging Area는 Git 디렉토리에 있다. 단순한 파일이고 곧 커밋할 파일에 대한 정보를 저장한다. Git에서는 기술용어로는 Index라고 하지만, Staging Area라는 용어를 써도 상관 없다.
Git의 흐름은 다음과 같다.
- 워킹 트리에서 파일을 수정한다.
- Staging Area에 파일을 Stage 해서 커밋할 스냅샷을 만든다. 모든 파일을 추가할 수도 있고 선택하여 추가할 수도 있다.
- Staging Area에 있는 파일들을 커밋해서 Git 디렉토리에 영구적인 스냅샷으로 저장한다.
Git 디렉토리에 있는 파일들은 Committed 상태이다. 파일을 수정하고 Staging Area에 추가했다면 Staged이다. 그리고 Checkout 하고 나서 수정했지만, 아직 Staging Area에 추가하지 않았으면 Modified 이다. Staging Area를 이용하는 방법 혹은 생략하는 방법은 추후 아티클에서 포스팅하도록 하겠다.
