많은 개발자들이 사용하고 있는 VCS 인 git 에 대해 제대로 이해하기 위해,
Scott Chacon 과 Ben Straub 이 쓰고 Apress 이 발간한, Pro Git book 을 포함한 다양한 자료들을 참고하여 공부한 포스팅입니다. 더 많은 자료를 얻고 싶으신 분들은 이 곳을 참고하시기 바랍니다.
또한, 이 포스팅은 한번에 끝나는 포스팅이 아니며, 공부를 할 때마다 조금씩 추가되고 수정되는 포스팅일 것입니다.
VCS(Version Control System)
프로젝트 버전관리를 위한 시스템
버전관리 시스템?
파일 변화를 시간에 따라 기록했다가 나중에 특정 시점의 버전을 다시 꺼내올 수 있는 시스템
CVCS(중앙집중VCS) 와 DVCS(분산VCS)
협업시에 생기는 문제를 해결하기위해 CVCS 방식이 고안되었는데,
관리자는 이를 통해서 쉽게 VCS 를 관리할 수 있게 되었지만 중앙 서버에 문제가 생기면 해결할 동안 협업이 불가능해지고, 서버쪽의 하드에 문제가 생기면 프로젝트의 히스토리를 잃어버리게 된다.
DVCS 의 경우 CVCS 와 달리 클라이언트가 사용할 파일의 마지막 스냅샷만 checkout 하는게 아니라 모든 히스토리를 복제하여 가져옴으로 서버에 문제가 생긴다면 여러 클라이언트 중 하나로 복윈이 가능하다.
CVCS
DVCS
==> 참고로 git 은 DVCS 방식을 사용하고 있다.
Git 기초
git 과 git 이 아닌 다른 vcs 들은 데이터를 다루는 방법에 있어서 큰 차이가 있다.
git 이 아닌 것들이 사용하는 방법..
위 그림에서 A, B, C 파일을 가진 프로젝트를 만들었고, Version1 이라고 가정하였다. 그리고 A 와 C 파일에 코드를 추가해 새로운 기능을 구현하였고 Version2 를 만들었다.
이 때 A와 C의 변경사항은 A-델타1, C-델타1 에 저장되고, Version2 는 변경사항인
A-델타1, C-델타1을 가지고 있게 된다.
예를들어 version4 를 checkout 하면
A 에 A-델타1 을 적용하고, A-델타2 를 적용시킨 A-델타2 파일과
B 에 B-델타1 을 적용해, B-델타1 파일
C 에 C-델타1 을 적용하고, C-델타2 를 적용시켜 C-델타2 파일을
보여주게 된다.
이렇게, 프로젝트 내의 각 파일의 변화를 시간순으로 관리하면서 파일들의 집합을 관리하는 방식을 델타 기반 버전관리 시스템 이라고 한다.
하지만, 이런 방식을 사용하면 버전을 가져올 때, 변경사항들을 계산해가며 가져와야하기 때문에 시간이 걸릴 수 밖에 없다.
git 은 그렇다면?
반면에 git 은 파일을 개별로 보면서 차이점만 따로 관리하는게 아니라 프로젝트 전체를 스냅샷 형태로 관리하는 방법을 사용한다.
위 그림을 보며 생각해보자.
Version1 은 A,B,C 파일로 구성되었고 이 구조를 하나의 스냅샷 으로 저장한다.
Version2 는 A1, B, C1 파일로 구성되어 있고 이 구조를 하나의 스냅샷 으로 저장한다.
만약 여기서 Version4 를 가져온다면 그냥 A2, B1, C2 파일을 가져오면 되기 때문에, 훨씬 빠른 속도와 안전성을 가질 수 있을 것이다.
그렇지만 여기에도 문제점은 Version1 과 Version2 의 B 파일은 동일한데, 스냅샷을 찍어두면 중복으로 저장될 수 도 있지 않냐는 문제가 있다.
이를 해결하기 위해 동일한 파일의 경우 새로 저장하는게 아니라, 기존 파일의 링크를 저장해둠으로써 문제를 해결하고 있다.
git 은 DVCS 이다.
깃은 DVCS 방식을 채택하였다. 버전관리를 할 때 서버에 연결이 되지않더라도 문제가 되지 않는다. 프로젝트 히스토리가 모두 .git 폴더 안에 넣어두기 때문이다. (물론, 다른 개발자들이 origin 에 새로 추가한 것들이 있다면 그것들을 fetch 할 때는 서버와 연결이 필요하겠지만)
여하튼, 이렇게 로컬에 모든 히스토리가 저장되어 있음으로 이전 프로젝트의 작업물이 필요할 경우 서버에 접속해서 가져오지 않고 로컬에서 바로 가져오면 됨으로 빠른 작업이 가능하다. 또 한, 서버가 터진다거나 물리적으로 서버 컴퓨터에 불이나 데이터가 사라져버려도 각각의 로컬에 모든 히스토리가 남아있기 때문에 대부분의 복구가 가능하다.
