[Git] Git이란?
IT 현업에서 협업은 절대 빼놓을 수 없는 업무요소 중 하나이다. 협업은 현재 문서, 이미지, 소스코드 등 다양한 요소들에 접목되어 이루어지고 있으며, 형상관리라는 개념 아래에서 체계적으로 관리된다. 형상관리는 현시점에서 개발자, 엔지니어등 IT에 종사하는 많은 분들에게 불가피한 요소로 자리잡고 있으며, 때문에 개발자들의 생산성이 나날이 높아지고 있다.
그럼 형상관리라는 것은 어떻게 무엇으로 이루어지고 있는걸까? 현재 IT업계에서 형상관리는 SVN, Git, ClearCase 등 다양한 툴들이 활용되고 있으며, 우리는 이번 포스팅에서 전세계적으로 가장 많이 활용되고 있는 git이라는 형상관리도구를 알아보고자 한다.
Git의 탄생배경
형상관리라는 개념이 없던 시절, 과거 개발자들은 소스코드를 어떻게 관리하였을까? 그렇다. 특정 개발자가 생산된 소스코드들을 일일이 모아 합쳐야만했다. 물론 프로젝트가 소규모라고 가정하면 뭐 감당할 수 있을듯하다. 하지만 대규모 프로젝트라면 정말 끔찍하지 않을 수 없다. 이러한 악조건 속에서 개발자들은 하루하루 지옥을 맛보며 개발을 하던 중 어느날, 버전관리시스템(VCS)이라는 개념이 생겨나며, SVN이나 CVS같은 버전관리시스템이 개발자들의 봄비로 자리잡게 된다.
혹시 독자들은 리눅스를 개발한 리누스 토발즈라고 들어보셨는가? 리누스 토발즈는 IT발전에 막대한 영향을 끼친 인물로서, OS인 리눅스와 형상관리도구 Git을 개발한것으로 유명하다.
리누스 토발즈는 리눅스 커널 소스 코드를 관리할 때 SVN이나 CVS같은 버전관리시스템을 사용하지않았다. 그 이유로는 정확하진 않지만 기능이 마음에 들지않는다는 정설이 있다고한다. 때문에 버전관리시스템이 등장했음에도 불구하고 리누스 토발즈는 원시적으로 파일을 관리하던 중 결국 버티지 못하고 VCS를 채택하여 사용하게된다. 리누스 토발즈가 사용한 VCS는 BitKeeper라는 제품이며 분산 처리 기능과 비교적 빠른 성능 덕분에 사용했다고 한다.
그러다가 BitKeeper 쪽에서 리버스 엔지니어링을 문제로 일부 리눅스 개발자들을 제한하는 일이 발생했다. 때문에 리누스 토발즈는 BitKeeper를 계속 사용해야할지 아니면 다른 버전 관리 시스템을 사용해야할지 결정해야 했는데, 리누스 토발즈는 전자도 후자도 아닌 직접 VCS를 개발하겠다고 결정했으며, 그렇게 탄생한 VCS가 바로 Git이다.
오픈소스 Git(GPL License)
오픈소스를 이용해서 개발하는 경우 코드를 무료로 보고 사용할 수 있어 개발하기 편리하다는 장점이 있으나 사용하고 있는 오픈소스가 어떤 라이센스를 가지느냐에 따라서 상업적인 이용이 제한될 수도 있고 내가 만든 코드를 공개해야 할 의무까지 생길 수 있다.
그렇다면 Git은 어떤 라이선스를 가지고 있을까? 바로 리누스 토발즈가 설립한 재단인 GNU가 만든 GPL라이선스(GNU 일반 공중 사용 허가서)이다. GPL의 의무는 다음과 같다.
- 컴퓨터 프로그램을 어떠한 목적으로든지 사용할 수 있다. 다만 법으로 제한하는 행위는 할 수 없다.
- 컴퓨터 프로그램의 실행 복사본은 언제나 프로그램의 소스 코드와 함께 판매하거나 소스코드를 무료로 배포해야 한다.
- 컴퓨터 프로그램의 소스 코드를 용도에 따라 변경할 수 있다.
- 변경된 컴퓨터 프로그램 역시 프로그램의 소스 코드를 반드시 공개 배포해야 한다.
- 변경된 컴퓨터 프로그램 역시 반드시 똑같은 라이선스를 취해야 한다. 즉 GPL 라이선스를 적용해야 한다.
DVCS Git
VCS의 종류는 크게 Local VCS, CVCS, DVCS 3가지가 있다. 그 중 Git은 DVCS에 해당하며 분산 버전관리 시스템이라고 한다. DVCS에는 Git 이외에 Mecurial, Bazaar, Darcs 등이 있으며, 특징은 다음과 같다.
- 중앙서버의 문제가 있어도 클라이어트 PC의 소스를 통한 원상 복구가 가능합니다.
- 여러명이 동시에 작업하는 병렬 개발이 가능합니다.
- 프로젝트를 모두 복사해와 로컬 환경에서 마음것 테스트 할 수 있습니다.
Git 구조
Git의 장단점
DVCS의 특징을 바탕으로한 Git의 장단점은 다음과 같다.
장점
- 오프라인 작업이 가능하다. TFS 등의 기존 중앙집중형 형상관리 툴은 오프라인 작업을 아예 지원하지 않거나, 매우 제한적으로만 지원하였다. 본인이 특정 파일을 체크아웃했다는 사실이 실시간으로 서버에 드러나야 하기 때문이다. 온라인 상태에서 체크아웃한 파일은 오프라인 상태에서도 계속 작업할 수 있는 경우도 있으나, 이 경우에는 추가적인 형상관리가 되지않는다. Git은 저장소를 일단 로컬에 복제하고, 로컬 저장소에 있는 히스토리도 그대로 유지되므로, 서버에서 새 자료를 받아올 수 없을 뿐이지 이외에는 오프라인 상태에서도 대부분의 형상관리 기능을 이용할 수 있다. 일종의 로컬 서버로 작용하는 것이다.
- 속도가 빠르다. 각각의 개발자들이 모두 분산처리 서버의 주인이 된다고 볼 수 있기에 서버가 직접 해야 될 일들이 많이 줄어든다.
- 로컬 저장소가 있기 때문에 일시적인 서버 장애가 있어도 개발을 계속할 수 있다.
- 서버와 클라이언트 뿐인 기존 형상관리에 비해 분산처리 구조를 유연하게 세울 수 있다. 중간 서버를 구성하거나, 부서별로 따로 서버를 구성하는 등 자유롭게 구축 가능하다.
- 가지치기(branch)가 비교적 가볍다. 가지치기 자체를 it의 장점으로 꼽기도 하지만 이는 현존하는 대부분의 형상관리 도구가 지원하는 기능이다. 실질적인 차이는 그 구현 방법에 있다고 봐야 한다. Git는 브랜칭이 매우 쉽고 가벼워 원하는 만큼 별 제약 없이 생성하고 삭제할 수가 있다. git만 사용해오던 사람은 당연하게 느껴질 것이고 이게 왜 장점인지조차 모를 수 있겠지만, 기존 형상관리 도구를 사용하던 사람들은 브랜칭 하나 하려고 수 시간의 미팅을 해야 하던 때도 있었다.
- 병합(merge)에서 타 VCS제품보다 이슈가 적다. 서버의 자료를 가져와(fetch) 로컬에서 병합하고 이를 다시 올리는 형태이기 때문인데, 물론 아예 문제가 발생하지 않을 수는 없으나, 이러한 구조 덕분에 예기치 못하게 발생하는 병합 문제 발생 빈도가 낮아진다.
- 스테이징을 지원한다. 단순히 커밋되지 않은 로컬 변동사항을 얘기하는 것이 아니고, 아예 커밋하기 전에 사용해야 하는 스테이징 단계가 따로 있다. 물론 이를 사용하지 않고 다른 형상관리 도구처럼 바로 커밋하는 식으로 사용할 수도 있다.
- 직접 호스팅을 할 경우 상업용 용도로도 무료로 이용 가능한 방법이 존재한다.
- 수많은 개발자용 툴이 Git을 자체 지원하거나, Git용 플러그인이 있다. 또한 관련 툴킷 범위도 넓어, 초보자를 위한 GUI부터 전문자용 Diff툴까지 Git사용에 도움이 되는 툴이 많다. 또한 libgit2 등을 이용하면 원하는 언어로 Git을 활용하는 프로그램을 직접 만들 수도 있다.
단점
- 기존 형상관리 도구에 비해 덜 직관적이고 배우기 어렵다. 특히 중앙 집중형 형상관리 도구에 익숙한 사람일수록 귀찮고 어려워지는데, 용어도 컨셉트도 처리과정도 전혀 다르기 때문이다. 체크아웃 후 파일을 수정하고 다시 커밋하기만 하면 되는 중앙집중형 도구에 비해 git는 커밋, 푸시, 풀, 머지, 페치 등 수많은 용어들이 존재하며 기존의 지식이 이 새로운 컨셉트를 이용하는 데에 크게 방해가 된다. 또한 처음 배우는 경우 어디까지가 서버에 영향을 미치는 행위이고 어디까지가 로컬에서 안전하게 할 수 있는 일인지 명확하게 이해하기가 어렵다. 한 번 익숙해지면 별 것 아니기는 하지만, 바로 이 문제 때문에 기존 형상관리 도구를 계속 사용하는 경우도 많다.
- 한 번에 여러 브랜치나 여러 태그에 걸쳐서 커밋을 할 수 없다. 내가 만든 사소한 변동사항이 다른 브랜치에 자동적으로 알려지지 않고, 나중에 취합하는 시점이 돼서야 반영된다. 때에 따라선 이후 다른 브랜치와 병합하려 할 때 충돌의 원인이 될 수도 있다.
- 하나의 저장소가 하나의 프로젝트 전체를 의미하는 것으로 강제되어 있어 일부만 브랜칭을 한다든지 클론을 한다든지 하는 일을 할 수 없다. 정책적인 부분이라 관점에 따라 장점이 될 수도 있겠지만, 해당 기능이 꼭 필요한 사람이라면 단점이 될 수 있다.
- push를 했다 해서 커밋 히스토리가 영원히 안전하게 저장된다고 장담할 수 없다. 중앙 집중형 형상관리에서는 일단 체크인을 하고 나면 서버에 문제가 생기지 않는 한에는 항상 안전하고 언제든 과거 기록을 볼 수 있으나, git에서는 push를 한 내용이라 하더라도 해당 브랜치가 다른 브랜치에 병합되기 전에 삭제돼버리면 나중에 해당 내용에 접근할 수 없다.
읽어주셔서 감사합니다. 😊
Reference
Git - namuwiki
GNU 일반 공중 사용 허가서 - wikipedia