DVCS에서는 클라이언트가 파일들의 마지막 스냅샷을 가져오는 대신 저장소(Repository)를 통째로 복제한다. 따라서 서버에 문제가 생겨도 어느 클라이언트든 복제된 저장소를 다시 서버로 복사하면 서버가 복구도니다. 체크아웃(checkout)을 할 때마다 전체 백업이 일어나는 셈이다. 게다가 대부분의 DVCS에서는 다수의 원격 저장소(Remote Repository)를 갖는 것이 가능하기 때문에 동시에 여러 그룹과 여러 방법으로 함께 작업할 수 있다. 이로 인해 계층 모델(Hierarchical Model) 등 중앙집중 시스템에서는 할 수 없는 다양한 작업 방식(Workflow)들을 사용해 볼 수 있다.
델타가 아니라 스냅샷
Git은 데이터를 저장하지도 취급하지도 않는다. 대신 Git의 데이터는 파일 시스템의 스냅샷이라 할 수 있으며 크기가 아주 작다. Git은 커밋하거나 프로젝트의 상태를 저장할 때마다 파일이 존재하는 그 순간을 중요하게 여긴다. 파일이 달라지지 않았으면 Git은 성능을 위해서 파일을 저장하지 않는다. 단지 이전 상태의 파일에 대한 링크만 저장한다.
거의 모든 명령을 로컬에서
거의 모든 명령이 로컬 파일과 데이터만 사용하기 때문에 네트워크에 있는 다른 컴퓨터는 필요 없다. 프로젝트의 모든 히스토리가 로컬 디스크에 있기 때문에 모든 명령은 순식간에 실행된다. 예를 들어 Git은 프로젝트의 히스토리를 조회할 때 서버 없이 조회한다. 즉 오프라인 상태에서도 비교할 수 있다.
무결성
Git은 모든 데이터를 저장하기 전에 체크섬(또는 해쉬)을 구하고 그 체크섬으로 데이터를 관리한다. 체크섬 없이 어떠한 파일이나 디렉토리도 변경할 수 없다. 체크섬은 Git에서 사용하는 가장 기본적인(Atomic) 데이터 단위이자 Git의 기본 철학이다.Git 없이는 체크섬을 다룰 수 없어서 파일의 상태도 알 수 없고 심지어 데이터를 잃어버릴 수도 없다. Git은 SHA-1 해쉬를 사용하여 체크섬을 만든다. 만든 체크섬은 40자 길이의 16진수 문자열이다. 파일의 내용이나 디렉토리 구조를 이용하여 체크섬을 구한다.
데이터를 추가할 뿐
Git으로 무얼 하든 데이터를 추가한다. 되돌리거나 데이터를 삭제할 방법이 없다. 다른 VCS처럼 Git도 커밋하지 않으면 변경사항을 잃어버릴 수 있다. 하지만, 스냅샷을 커밋하고 나면 데이터를 잃어버리기 어렵다.
세 가지 상태
Git은 파일을 Committed, Modified, Staged 이렇게 세 가지 상태로 관리한다. Committed란 데이터가 로컬 데이터베이스에 안전하게 저장됐다는 것을 의미한다. Modified는 수정한 파일을 아직 로컬 데이터베이스에 커밋하지 않은 것을 의미한다. Staged란 현재 수정한 파일을 곧 커밋할 것이라고 표시한 상태를 의미한다. 이 세 가지 상태는 Git 프로젝트의 세 가지 단계와 연결돼 있다. Git 디렉토리, 워킹 디렉토리, Staging Area.
-
Git 디렉토리 : Git이 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳을 의미한다. Git 디렉토리가 Git의 홱심이다. 다른 컴퓨터에 있는 저장소를 Clone할 때 Git 디렉토리가 만들어진다.
-
워킹 디렉토리 : 프로젝트의 특정 버전을 Checkout한 것이다. Git 디렉토리는 지금 작업하는 디스크에 있고 그 디렉토리에 압축된 데이터베이스에서 파일을 가져와서 워킹 디렉토리를 만든다.
-
Staging Area : Staging Area는 Git 디렉토리에 있다. 단순한 파일이고 곧 커밋할 파일에 대한 정보를 저장한다.
Git으로 하는 일은 기본적으로 아래와 같다.
- 워킹 렉토리에서 파일을 수정한다.
- Staging Area에 파일을 Stage해서 커밋할 스냅샷을 만든다.
- Staging Area에 있는 파일들을 커밋해서 Git 디렉토리에 영구적인 스냅샷을 저장한다.
Git 디렉토리에 있느 파일들은 Committed 상태이다. 파일을 수정하고 Staging Area에 추가했다면 Staged이다. 그리고 Checkout하고나서 수정했지만, 아직 Staging Area에 추가하지 않았다면 Modified이다.