[GIT] Git 기초

   참고

• https://git-scm.com/book/ko/v2/
• https://backlog.com/git-tutorial/kr/stepup/stepup2_3.html
• http://dogfeet.github.io/articles/2012/git-delta.html

아래의 글은 위의 포스터를 참조하여 정리, 재가공한 글입니다.

   버전 관리란?

VCS(Version Control System)

버전 관리 시스템은 파일 변화를 시간에 따라 기록했다가 나중에 특정 시점의 버전을 다시 꺼내올 수 있는 시스템이다.

로컬 버전 관리

아주 간단한 데이터베이스를 사용해서 파일의 변경 정보를 관리한다.

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

프로젝트를 진행하는 도중 다른 개발자와 함께 작업을 해야할 경우, 변경 사항을 적절히 관리하여 충돌과 같은 다양한 문제를 방지하는 것이 중요하다. 이런 문제를 해결하기 위해 CVCS가 개발됐는데 CVS, Subversion, Perforce 같은 시스템이 중앙집중식 버전관리에 해당된다.

중앙집중식 버전관리는 파일을 관리하는 서버가 별도로 존재하고 파일을 수정 및 업데이트하는 개발자가 클라이언트가 되어 중앙 서버에서 파일을 받아서 사용(checkout)한다. (이 때, 받아서 사용하는 것을 checkout이라고 하는데, 여기나 여기나 여기를 보면 서버에서 클라이언트로 원본 파일과 버전관리를 위한 파일들을 받아오는 행위를 말하는 것 같다.)

중앙 서버에서 프로젝트를 모두 관리할 수 있기 때문에 서버의 관리자와 서버와 연결된 클라이언트들은 모두 누가 무엇을 하고 있는지 알 수 있고, 관리자는 중앙 서버의 파일만 관리하면 되기 때문에 더 잘 관리할 수 있는 장점이 있다.

하지만, 서버에 문제가 생기면 클라이언트들은 서로 다른 클라이언트와 협업할 수 있고, 클라이언트에서 했던 작업을 백업할 방법도 없다. 또한, 서버의 하드디스크에 문제가 생기면 프로젝트의 모든 히스토리를 잃는다. (클라이언트가 가진 스냅샷은 괜찮다.) 로컬 VCS 시스템도 비슷한 결점이 존재한다. (스냅샷이란, 여기를 보면 특정 시간에 저장 장치의 상태를 나타낸다고 말한다. 이 글에서는 checkout할 때 프로젝트의 모든 파일을 말하는 것 같다.)

분산 버전 관리 시스템(DVCS)

Git, Mecurial, Bazaar, Darcs와 같은 시스템이 DVCS에 해당된다. 이와 같은 분산 버전 관리 시스템은 중앙 서버의 기능적 구분이 거의 없다. CVCS에서 클라이언트는 중앙 서버의 파일의 마지막 스냅샷을 checkout한다. 하지만, DVCS는 저장소에서 클라이언트로 가져올 때, 파일 뿐만 아니라 히스토리까지 복제한다.

이런 특징은 CVCS의 단점을 보완할 수 있어서 서버에 문제가 생겨도 복제물로 버전 관리 기능을 완전히 사용할 수 있다. 클라이언트를 통해 서버를 복원할 수 있다는 것이다.

이런 복제행위를 clone이라고 하며 모든 데이터를 가진 진정한 백업이라고 볼 수 있다.

그리고 대부분의 DVCS는 리모트 저장소가 존재한다. (리모트 저장소는 인터넷이나 네트워크 어딘가에 있는 저장소를 말한다. remote는 멀리 떨어진이라는 뜻으로, 먼 곳에 존재하는 저장소를 말한다.) 리모트 저장소가 많을 수도 있어서 동시에 다양한 그룹과 다양한 방법으로 협업할 수 있다.

   Git의 기초

Git의 탄생 목표

• 빠른 속도
• 단순한 구조
• 비선형적인 개발(수천 개의 동시 다발적인 브랜치)
• 완벽한 분산
• Linux 커널 같은 대형 프로젝트에도 유용할 것(속도나 데이터 크기 면에서)

스냅샷(SnapShot)

Subversion과 같은 시스템과 Git의 가장 큰 차이점은 데이터를 어떻게 다루는지이다. 크게 봤을 때 VCS 시스템 대부분은 관리하는 대상이 파일들의 목록이다. CVS, Subversion 등의 시스템은 각 파일의 변화를 시간순으로 관리하면서 파일들의 집합을 관리한다(보통 이를 델타 기반 버전관리 시스템이라 함. 아마 Subversion과 같은 시스템은 버전을 저장할 때 스냅샷 자체를 버전으로 저장하는 것 같다.).

Git은 이런 식으로 데이터를 저장하거나 취급하지 않는다. 데이터를 파일 시스템 스냅샷의 연속으로 취급하여 크기가 아주 작다. 파일이 달라지지 않았으면 Git은 성능을 위해 파일을 새로 저장하지 않고 이전 상태의 파일에 대한 링크만 저장한다.

깃의 히스토리는 개념적으로 스냅샷의 연속이자 델타의 연속이기도 하다. Git은 각 시점의 스냅샷을 저장하기도 하지만 그 스냅샷 사이의 델타를 저장하기도 한다.

커밋을 하면 그 시점의 스냅샷이 저장되는데, 커밋은 영구적으로 저장하는 것이기 때문에 델타도 저장되는 것이라 할 수 있다. 필요하면 과거에 저장된 스냅샷들의 델타를 바로 구할 수 있기 때문이다.

Git은 처음에는 이런방식으로 스냅샷들을 저장하고 적절한 시점이 되면 GC(Garbage Collection)이 실행된다. 그러면 마지막 버전의 스냅샷의 파일만 통째로 저장하고 이전 버전들은 델타만 저장한다. 또한, GC는 델타로 저장한 것을 gzip으로 압축하기 때문에 실제로 저장하는 용량이 더욱 작아진다.

세 가지 상태

• Committed, 데이터가 로컬 데이터베이스에 안전하게 저장됐다.
• Modified, 수정한 파일을 아직 로컬 데이터베이스에 커밋하지 않았다.
• Staged, 현재 수정한 파일을 곧 커밋할 것이라고 표시했다.

이 세 가지 상태는 Git 프로젝트의 세 가지 단계와 연결돼 있다. Git 디렉토리, 워킹 트리, Staging Area 세 단계이다.

Git directory는 Git이 프로젝트의 메타 데이터와 객체 데이터베이스를 저장하는 곳을 말한다. 이것이 Git의 핵심이다. 저장소를 clone할 때 만들어진다.

워킹 트리는 프로젝트의 특정 버전을 Checkout 한 것이다. Git 디렉토리는 지금 작업하는 디스크에 있고 그 디렉토리 안에 압축된 데이터베이스에서 파일을 가져와서 워킹 트리를 만든다.

Staging Area는 Git 디렉토리에 있다. 단순한 파일이고 곧 커밋할 파일에 대한 정보를 저장한다. Git에서는 기술용어로는 “Index” 라고 하지만, “Staging Area” 라는 용어를 써도 상관 없다. (아마 git add를 한 후의 상태인 것 같다.)

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

1. 워킹 트리에서 파일을 수정한다.
   
2. Staging Area에 파일을 Stage 해서 커밋할 스냅샷을 만든다. 모든 파일을 추가할 수도 있고 선택하여 추가할 수도 있다. (git add)
   
3. Staging Area에 있는 파일들을 커밋해서 Git 디렉토리에 영구적인 스냅샷으로 저장한다. (git commit)
   

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

   Git 설치

설치 명령어는 무의미한 받아쓰기가 될 것 같아 링크로 대체한다.

Git 설치