[Git] 01. Git 소개 — 분산 버전 관리 시스템과 탄생 배경

Git을 처음 접하는 사람이 가장 먼저 마주치는 혼란은 “Git"과 “GitHub"을 같은 것으로 여기는 착각이다. 계정을 만들고 웹사이트에 접속하는 절차부터 시작하다 보니 Git이 특정 웹 서비스의 이름처럼 느껴지기 쉽지만, 실제로는 인터넷 연결 없이 로컬 컴퓨터에서 완결되는 버전 관리 도구가 Git이고, GitHub은 그 Git 저장소를 호스팅하는 여러 서비스 중 하나일 뿐이다. 이 장은 Git이 어떤 문제를 풀기 위해 만들어졌고, 그 배경이 지금의 설계에 어떻게 남아 있는지를 다룬다.

개요

Git은 2005년 리누스 토르발스(Linus Torvalds)가 리눅스 커널 개발을 위해 만든 분산 버전 관리 시스템(Distributed Version Control System, DVCS)이다. 당시 리눅스 커널 프로젝트는 상용 버전 관리 도구인 BitKeeper를 무상으로 이용하고 있었는데, 2005년 라이선스 분쟁으로 더 이상 무료로 쓸 수 없게 되자 토르발스는 대안을 직접 설계하기로 했다. Git 프로젝트 자체가 공개한 개발 배경에 따르면, 그가 세운 설계 목표는 속도, 단순한 설계, 비선형 개발(수천 개의 병렬 브랜치)에 대한 강력한 지원, 완전한 분산 구조, 리눅스 커널처럼 방대한 프로젝트를 대규모 리눅스 스타일 워크플로에서도 효율적으로 다룰 수 있는 능력이었다.

이 표의 차이는 우연이 아니라 설계 목표에서 직접 도출된다. 중앙 서버 없이도 리눅스 커널 기여자 수천 명이 각자 독립적으로 커밋하고 나중에 병합할 수 있어야 한다는 요구가, 모든 clone이 완전한 히스토리를 갖는 분산 구조로 이어졌다.

기본 개념

Git이 파일 변경을 기록하는 방식은 스냅샷(snapshot)이다. CVS·SVN 같은 도구는 파일별로 “이전 버전과 지금 버전의 차이(delta)“를 저장하고, 특정 시점의 파일을 복원하려면 그 델타들을 순서대로 다시 적용해야 한다. 반면 Git은 커밋할 때마다 그 시점의 전체 파일 트리를 통째로 찍어 저장한다. 다만 이전 커밋과 비교해 바뀌지 않은 파일까지 매번 복사하지는 않는다 — 바뀌지 않은 파일은 이전 스냅샷이 가리키던 동일한 저장 객체를 그대로 재사용해 참조하므로, 실제 디스크 사용량은 델타 방식과 크게 다르지 않다.

1
2
3
4
5

CVS/SVN 방식(델타 누적):
v1 --(diff1)--> v2 --(diff2)--> v3   # v3를 보려면 diff1, diff2를 순서대로 적용

Git 방식(스냅샷):
v1[snapshot] --> v2[snapshot] --> v3[snapshot]   # v3는 그 자체로 완전한 트리를 가리킴

이 차이는 실무에서 체감되는 성능으로 이어진다. 특정 커밋으로 되돌아가거나 임의의 두 커밋을 비교하는 연산이, 중간 델타를 누적 계산할 필요 없이 두 스냅샷을 직접 비교하는 것으로 끝난다. Git의 커밋·체크아웃 관련 명령 대부분이 로컬에서 매우 빠르게 동작하는 이유가 여기에 있다.

종류/세부

Git이 아닌 것

Git과 자주 혼동되는 개념을 구분해두면 이후 챕터를 읽을 때 헷갈리지 않는다.

Git 자체는 명령줄 도구(git)이며, 리포지토리를 열람·조작하는 그래픽 클라이언트(GitHub Desktop, GitKraken, VS Code의 소스 제어 패널 등)는 모두 이 명령줄 도구를 내부적으로 호출하는 여러 프런트엔드 중 하나에 불과하다. 이 컬렉션은 명령줄 git을 기준으로 서술한다 — 개념이 명확하면 어떤 그래픽 클라이언트를 쓰든 같은 원리가 적용되기 때문이다.

왜 지금도 유효한가

Git이 처음 설계된 2005년과 비교하면 개발 환경은 크게 달라졌지만, “빠른 로컬 연산”, “저비용 브랜치”, “완전한 분산 히스토리"라는 목표는 오늘날 소프트웨어 개발의 요구와도 정확히 맞아떨어진다. 오픈소스 프로젝트는 수천 명의 기여자가 각자 fork한 저장소에서 독립적으로 작업하다 Pull Request로 병합하는 구조를 취하는데, 이는 리눅스 커널이 애초에 풀어야 했던 문제와 본질적으로 같다. CI/CD 파이프라인이 커밋·태그·브랜치 이벤트를 트리거로 삼는 것도, Git이 이런 이벤트를 로컬에서 빠르고 신뢰성 있게 기록한다는 전제 위에 세워진다.

주의사항·함정

“Git 히스토리를 지우면 안전하게 사라진다"는 오해: Git은 모든 clone이 전체 히스토리를 가지므로, 로컬 저장소에서 커밋을 삭제하거나 강제로 재작성(force push)해도 다른 사람이 이미 pull해간 사본에는 그대로 남아 있을 수 있다. 민감한 정보(비밀번호, API 키 등)를 실수로 커밋했다면 단순히 다음 커밋에서 지우는 것으로는 불충분하며, 히스토리 자체를 재작성하고 관련된 모든 clone에 통보해야 한다.

“버전 관리 시스템은 Git 하나뿐이다"라는 오해: 실무에서는 SVN을 여전히 쓰는 레거시 조직도 있고, Mercurial·Perforce 같은 대안도 특정 업계(게임 개발의 대용량 바이너리 관리 등)에서 쓰인다. Git이 현재 가장 널리 쓰이는 것은 사실이지만, 새로 합류한 조직의 버전 관리 도구를 확인하지 않고 Git 명령을 그대로 시도하면 당연히 동작하지 않는다.

초기 설정 없이 커밋을 시도하면 오류가 난다: Git은 모든 커밋에 작성자 이름과 이메일을 기록하도록 요구한다. 설치 직후 첫 커밋을 시도하면 “Please tell me who you are” 오류를 만나게 되는데, 이 설정 방법은 02장에서 다룬다.

Reference

• A Short History of Git - Git Book
• Git - About Version Control