분산 버전 관리 시스템
Git은 DVCS(분산 버전 관리 시스템)입니다. DVCS에서의 클라이언트는 단순히 파일의 마지막 스냅샷을 Checkout1 하지 않고 그냥 저장소를 히스토리와 더불어 전부 Clone 합니다. 서버에 문제가 생기면 이 복제물로 다시 작업을 시작할 수 있습니다. 클라이언트 중에서 아무거나 골라도 서버를 복원할 수 있다. Clone은 모든 데이터를 가진 진정한 백업입니다.
- 스냅샷 : 컴퓨터 파일 시스템에서 스냅샷(snapshot)은 과거의 한 때 존재하고 유지시킨 컴퓨터 파일과 디렉터리의 모임.
그림 1. 분산 버전 관리 시스템(DVCS).
게다가 대부분의 DVCS 환경에서는 리모트 저장소가 존재합니다.
리모트 저장소가 많을 수도 있습니다. 그래서 사람들은 동시에 다양한 그룹과 다양한 방법으로 협업할 수 있습니다.
계층 모델 같은 중앙집중식 시스템으로는 할 수 없는 워크플로를 다양하게 사용할 수 있습니다.
Git 기초
스냅샷
Git은 원래 Linux 소스코드를 관리할 목적으로 리누스 토발즈가 개발하였습니다.
Git을 배울 때 CVS나 Subversion 같은 VCS를 사용하던 경험은 도움이 되질 않습니다.
VCS[CVS, Subversion] 시스템 대부분은 각 파일의 변화를 시간순으로 관리하면서 파일들의 집합을 관리하는 반면,
Git[DVCS]는 데이터를 파일 시스템 스냅샷의 연속으로 취급하고 크기가 아주 작습니다. Git은 커밋하거나 프로젝트의 상태를 저장할 때마다 파일이 존재하는 그 순간을 중요하게 여깁니다. 파일이 달라지지 않았으면 Git은 성능을 위해서 파일을 새로 저장하지 않습니다.
단지 이전 상태의 파일에 대한 링크만 저장합니다. Git은 데이터를 스냅샷의 스트림처럼 취급합니다. 즉 Git이 관리하는 파일이 변경 이력 별로 구분되어 저장됩니다.
로컬에서 실행
VCS와 다르게 Git이 관리하는 프로젝트의 모든 히스토리가 로컬 디스크에 있기 때문에 모든 명령이 순식간에 실행됩니다. 예를 들어 Git은 프로젝트의 히스토리를 조회할 때 서버 없이 조회합니다. 그냥 로컬 데이터베이스에서 히스토리를 읽어서 보여 줍니다. 그래서 눈 깜짝할 사이에 히스토리를 조회할 수 있습니다.
무결성
Git으로 무얼 하든 Git 데이터베이스에 데이터가 추가 됩니다. Git은 데이터를 저장하기 전에 항상 체크섬을 구하고 그 체크섬으로 데이터를 관리한다. 체크섬은 Git에서 사용하는 가장 기본적인(Atomic) 데이터 단위이자 Git의 기본 철학입니다. Git은 SHA-1 해시를 사용하여 체크섬을 만듭니다. Git이 생성한 체크섬은 40자 길이의 16진수 문자열입니다. 파일의 내용이나 디렉토리 구조를 이용하여 체크섬을 구합니다.
이력을 관리하는 저장소
저장소(Git repository)란 말그대로 파일이나 폴더를 저장해 두는 곳입니다.
원격 저장소와 로컬 저장소
Git은 원격 저장소와 로컬 저장소 두 종류의 저장소를 제공합니다.
-
원격 저장소(Remote Repository): 파일이 원격 저장소 전용 서버에서 관리되며 여러 사람이 함께 공유하기 위한 저장소입니다.
-
로컬 저장소(Local Repository): 내 PC에 파일이 저장되는 개인 전용 저장소입니다.
평소에는 내 PC의 로컬 저장소에서 작업하다가 작업한 내용을 공개하고 싶을 때에 원격 저장소에 업로드 합니다. 물론 원격 저장소에서 다른 사람이 작업한 파일을 로컬 저장소로 가져올 수도 있습니다.
그림 2. Git DVCS
세 가지 상태
Git은 파일을 Committed, Modified, Staged 이렇게 세 가지 상태로 관리합니다.
-
Modified는 수정한 파일을 아직 로컬 데이터베이스에 커밋하지 않은 것을 말한다.
-
Staged란 현재 수정한 파일을 곧 커밋할 것이라고 표시한 상태를 의미한다.
-
Committed란 데이터가 로컬 데이터베이스에 안전하게 저장됐다는 것을 의미한다.
이 세 가지 상태는 Git 프로젝트의 세 가지 단계[Working Tree, Index, Repository]와 연결되어 있습니다.
그림 3. Git 세 가지 단계
| Step | Description | remark |
|---|---|---|
| Working Tree | 프로젝트의 특정 버전을 Checkout1 한 것 | git 디렉토리안에 압축된 데이터베이스에서 파일을 가져와서 워킹 트리를 만든다. |
| Index(Staging Area) | 단순한 파일이고 곧 커밋할 파일에 대한 정보를 저장 | Git에서는 기술용어로는 Index'' 라고 하지만, "Staging Area'' 라는 용어를 써도 상관 없다. |
| Repository(.git) | Git이 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳 | .git 디렉토리가 Git의 핵심이다. 다른 컴퓨터에 있는 저장소를 Clone 할 때 .git 디렉토리가 만들어진다. |
Git으로 하는 일은 기본적으로 아래와 같다.
-
워킹 트리에서 파일을 수정한다.
-
Index[Staging Area]에 파일을 Stage 해서 커밋할 스냅샷을 만든다. 모든 파일을 추가할 수도 있고 선택하여 추가할 수도 있다.
-
Index[Staging Area]에 있는 파일들을 커밋해서 .git 디렉토리에 영구적인 스냅샷으로 저장한다.
- Checkout1 하고 나서 수정했지만, 아직 Index[Staging Area]에 추가하지 않았으면 Modified 상태입니다. 파일을 수정하고 Index[Staging Area]에 추가했다면 Staged 상태입니다. .git 디렉토리에 있는 파일들은 Committed 상태입니다.
Index 필요성
Git의 '커밋' 작업은 '워킹 트리'에 있는 변경 내용을 저장소에 바로 기록하는 것이 아니라 그 사이 공간인 '인덱스'에 파일 상태를 기록(stage - 스테이징 한다고 표현하기도 합니다)하게 되어 있습니다. 따라서 저장소에 변경 사항을 기록하기 위해서는, 기록하고자 하는 모든 변경 사항들이 '인덱스'에 존재해야 합니다.
예를 들어, 10개의 파일을 수정했지만 그 중에 7개만 저장소에 공개하고 싶을 때를 생각해 보세요. 변경한 10개의 파일 중 7개를 선택하는 작업이 바로 '인덱스에 등록' 또는 '스테이징(stage)'이라 표현하는 작업 입니다.
이렇게 인덱스란 가상 공간이 중간에 있는 덕분에 워킹 트리안에 있는 커밋이 필요 없는 파일들을 커밋에 포함하지 않을 수 있고, 파일에서 내가 원하는 일부 변경 사항만 인덱스에 등록해 커밋할 수 있습니다.
지정된 트리 또는 인덱스의 버전을 일치시키기 위해서 워킹 트리의 파일들을 업데이트한다.
<출처>
