[Pro Git] ch01 - Git의 기초

 

출처 : Pro Git

- 저자 : Scott Chacon, Ben Straub

 

버전 관리란?

버전 관리는 무엇이고 우리는 왜 이것을 알아야 할까? 버전 관리 시스템은 파일 변화를 시간에 따라 기록했다가 나중에 특정 시점의 버전을 다시 꺼내올 수 있는 시스템이다

 

로컬 버전 관리

많은 사람은 버전을 관리하기 위해 디렉토리로 파일을 복사하는 방법을 쓴 다(똑똑한 사람이라면 디렉토리 이름에 시간을 넣을 거다). 이 방법은 간단하 므로 자주 사용한다. 그렇지만, 정말 뭔가 잘못되기 쉽다. 작업하던 디렉토리 를 지워버리거나, 실수로 파일을 잘못 고칠 수도 있고, 잘못 복사할 수도 있다.

중앙집중식 버전 관리(CVCS)

프로젝트를 진행하다 보면 다른 개발자와 함께 작업해야 하는 경우가 많 다. 이럴 때 생기는 문제를 해결하기 위해 CVCS(중앙집중식 VCS)가 개발됐다. CVS, Subversion, Perforce 같은 시스템은 파일을 관리하는 서버가 별도로 있고 클라이언트가 중앙 서버에서 파일을 받아서 사용(Checkout)한다.

 

CVCS 환경은 로컬 VCS에 비해 장점이 많다. 모두 누가 무엇을 하고 있는지 알 수 있다. 관리자는 누가 무엇을 할지 꼼꼼하게 관리할 수 있다. 모든 클라이 언트의 로컬 데이터베이스를 관리하는 것보다 VCS 하나를 관리하기가 훨씬 쉽다. 그러나 이 CVCS 환경은 몇 가지 치명적인 결점이 있다. 가장 대표적인 것이 중앙 서버에 발생한 문제다. 만약 서버가 한 시간 동안 다운되면 그동안 아무 도 다른 사람과 협업할 수 없고 사람들이 하는 일을 백업할 방법도 없다. 그리 고 중앙 데이터베이스가 있는 하드디스크에 문제가 생기면 프로젝트의 모든 히스토리를 잃는다. 물론 사람마다 하나씩 가진 스냅샷은 괜찮다. 로컬 VCS 시 스템도 이와 비슷한 결점이 있고 이런 문제가 발생하면 모든 것을 잃는다.

 

 

분산 버전 관리 시스템

DVCS(분산 버전 관리 시스템)을 설명할 차례다. Git, Mecurial, Bazaar, Darcs 같은 DVCS에서의 클라이언트는 단순히 파일의 마지막 스냅샷을 Checkout 하 지 않는다. 그냥 저장소를 전부 복제한다. 서버에 문제가 생기면 이 복제물로 다시 작업을 시작할 수 있다. 클라이언트 중에서 아무거나 골라도 서버를 복 원할 수 있다. 모든 Checkout은 모든 데이터를 가진 진정한 백업이다.

 

게다가 대부분의 DVCS 환경에서는 리모트 저장소가 존재한다. 리모트 저 장소가 많을 수도 있다. 그래서 사람들은 동시에 다양한 그룹과 다양한 방법 으로 협업할 수 있다. 계층 모델 같은 중앙집중식 시스템으로는 할 수 없는 Workflow를 다양하게 사용할 수 있다.

 

 

짧게 보는 Git의 역사

Git은 2005년 탄생하고 나서 아직도 초기 목표를 그대로 유지하고 있다. 그 러면서도 사용하기 쉽게 진화하고 성숙했다. Git은 미친 듯이 빨라서 대형 프 로젝트에 사용하기도 좋다. Git은 동시다발적인 브랜치에도 끄떡없는 슈퍼 울 트라 브랜칭 시스템이다

 

git 의 초기목표

 

• 빠른 속도

• 단순한 구조

• 비선형적인 개발(수천 개의 동시 다발적인 브랜치)

• 완벽한 분산

• Linux 커널 같은 대형 프로젝트에도 유용할 것(속도나 데이터 크기 면에 서)

 

차이가 아니라 스냅샷

Git의 핵심은 뭘까? Git이 무엇 이고 어떻게 동작하는지 이해한다면 쉽게 Git을 효과적으로 사용할 수 있다.

 

Git은 데 이터를 파일 시스템 스냅샷으로 취급하고 크기가 아주 작다. Git은 커밋하거 나 프로젝트의 상태를 저장할 때마다 파일이 존재하는 그 순간을 중요하게 여 긴다. 파일이 달라지지 않았으면 Git은 성능을 위해서 파일을 새로 저장하지 않는다. 단지 이전 상태의 파일에 대한 링크만 저장한다. Git은 데이터를 스냅 샷의 스트림처럼 취급한다.

좌 각 파일에 대한 변화를 저장하는 시스템들. 우 시간순으로 프로젝트의 스냅샷을 저장하는 git

이것이 Git이 다른 VCS와 구분되는 점이다. 이점 때문에 Git은 다른 시스템 들이 과거로부터 답습해왔던 버전 컨트롤의 개념과 다르다는 것이고 많은 부 분을 새로운 관점에서 바라본다. Git은 강력한 도구를 지원하는 작은 파일시 스템이다. Git은 단순한 VCS가 아니다.

 

 

 

거의 모든 명령을 로컬에서 실행

거의 모든 명령이 로컬 파일과 데이터만 사용하기 때문에 네트워크에 있는 다 른 컴퓨터는 필요 없다. 대부분의 명령어가 네트워크의 속도에 영향을 받는 CVCS에 익숙하다면 Git이 매우 놀라울 것이다. 

 

프로젝트의 모든 히스토리가 로컬 디스크에 있기 때문에 모든 명령을 순식간에 실행된다. 예를 들어 Git은 프로젝트의 히스토리를 조회할 때 서버 없이 조회한다. 그 냥 로컬 데이터베이스에서 히스토리를 읽어서 보여 준다. 그래서 눈 깜짝할 사이에 히스토리를 조회할 수 있다. 어떤 파일의 현재 버전과 한 달 전의 상태 를 비교해보고 싶을 때도 Git은 그냥 한 달 전의 파일과 지금의 파일을 로컬에 서 찾는다. 파일을 비교하기 위해 리모트에 있는 서버에 접근하고 나서 예전 버전을 가져올 필요가 없다.

 

Git의 무결성

Git은 데이터를 저장하기 전에 항상 체크섬을 구하고 그 체크섬으로 데이터를 관리한다. 그래서 체크섬 이해하는 Git 없이는 어떠한 파일이나 디렉토리도 변경할 수 없다. 체크섬은 Git에서 사용하는 가장 기본적인(Atomic) 데이터 단 위이자 Git의 기본 철학이다. Git 없이는 체크섬을 다룰 수 없어서 파일의 상태 도 알 수 없고 심지어 데이터를 잃어버릴 수도 없다. Git은 SHA-1 해시를 사용하여 체크섬을 만든다. 만든 체크섬은 40자 길이의 16진수 문자열이다. 파일의 내용이나 디렉토리 구조를 이용하여 체크섬을 구 한다. SHA-1은 아래처럼 생겼다. 24b9da6552252987aa493b52f8696cd6d3b00373 Git은 모든 것을 해시로 식별하기 때문에 이런 값은 여기저기서 보인다. 실 제로 Git은 파일을 이름으로 저장하지 않고 해당 파일의 해시로 저장한다.

 

Git은 데이터를 추가할 뿐

Git으로 무얼 하든 Git 데이터베이스에 데이터가 추가된다. 되돌리거나 데이 터를 삭제할 방법이 없다. 다른 VCS처럼 Git도 커밋하지 않으면 변경사항을 잃 Git 기초 29 FIGURE 1-6 워킹 디렉토리, Staging Area, Git 디 렉토리. 어버릴 수 있다. 하지만, 일단 스냅샷을 커밋하고 나면 데이터를 잃어버리기 어렵다.

 

세 가지 상태

이 부분은 중요하기에 집중해서 읽어야 한다. Git을 공부하기 위해 반드시 짚 고 넘어가야 할 부분이다. Git은 파일을 Committed, Modified, Staged 이렇게 세 가지 상태로 관리한다. Committed란 데이터가 로컬 데이터베이스에 안전 하게 저장됐다는 것을 의미한다. Modified는 수정한 파일을 아직 로컬 데이터 베이스에 커밋하지 않은 것을 말한다. Staged란 현재 수정한 파일을 곧 커밋 할 것이라고 표시한 상태를 의미한다

 

워킹 디렉토리, Staging Area, Git 디 렉토리.

Git 디렉토리는 Git이 프로젝트의 메타데이터와 객체 데이터베이스를 저장 하는 곳을 말한다. 이 Git 디렉토리가 Git의 핵심이다. 다른 컴퓨터에 있는 저장 소를 Clone 할 때 Git 디렉토리가 만들어진다. 워킹 디렉토리는 프로젝트의 특정 버전을 Checkout 한 것이다. Git 디렉토 리는 지금 작업하는 디스크에 있고 그 디렉토리 안에 압축된 데이터베이스에 서 파일을 가져와서 워킹 디렉토리를 만든다.

Staging Area는 Git 디렉토리에 있다. 단순한 파일이고 곧 커밋할 파일에 대 한 정보를 저장한다. 종종 ``Index``라고 불리기도 하지만, Staging Area라는 명칭이 표준이 되어가고 있다.

 

Git으로 하는 일은 기본적으로 아래와 같다.

 

1. 워킹 디렉토리에서 파일을 수정한다.

2. Staging Area에 파일을 Stage 해서 커밋할 스냅샷을 만든다.

3. Staging Area에 있는 파일들을 커밋해서 Git 디렉토리에 영구적인 스냅 샷으로 저장한다.

 

Git 디렉토리에 있는 파일들은 Committed 상태이다. 파일을 수정하고 Staging Area에 추가했다면 Staged이다. 그리고 Checkout 하고 나서 수정했지 만, 아직 Staging Area에 추가하지 않았으면 Modified이다.

 

CLI

Git을 사용하는 방법은 많다. CLI로 사용할수도 있고 GUI를 사용할 수도 있다. 이 책에서는 Git CLI 사용법을 설명한다. Git의 모든 기능을 지원하는 것은 CLI 뿐이다. GUI 프로그램의 대부분은 Git 기능을 전부 구현하지 않아서 비교적 단 순하다. CLI를 사용할 줄 알면 GUI도 사용할 수 있지만 반대는 성립하지 않는 다. GUI를 선호하는 사람이 있다고 하더라도, CLI는 모든 사람 컴퓨터에 설치 돼 있어서 바로 사용할 수 있을 것이다.

 

도움말은 언제 어디서나 볼 수 있다. 오프라인으로도 볼 수 있다. 도움말과 이 책으로 부족하면 다른 사람의 도움을 받는 것이 필요하다. Freenode IRC 서 버(irc.freenode.net)에 있는 #git이나 #github 채널로 찾아가라. 이 채널에는 보통 수백 명의 사람이 접속해 있다. 모두 Git에 대해 잘 알고 있다. 기꺼이 도 와줄 것이다.