[ Web Basics ] Git - Blog Full of Desire

들어가면서#

이번에 새로운 부트캠프에 들어가게 되면서 오전에는 강의, 오후에는 자유롭게 작업을 하게 되었다. 가장 첫 강의가 git과 github이었는데, git/github가 무엇인지 이미 알고 있어 그렇게 달가운 강의는 아니었다. 하지만, 혼자 생각하다 내가 완벽하게 이해하고 있는지 의문이 들기 시작하면서 “왜 git을 사용하지?” 라는 질문에 스스로 답을 하지 못한다는 것을 알게 되었다. 그래서 이번 기회에 git을 한 번 정리해보려 한다. 왜 git을 사용하게 되었는지, git은 어떤 구조로 되어 있는지 알아보자.

2000년대의 형상관리 시스템, SVN#

git 이전에 여러 형상관리 시스템들(RCS, CVS)이 있었고, 기존 시스템의 문제점을 해결하기 위해 SVN이라는 형상관리 시스템이 개발되었다. SVN은 기존 CVS의 문제인 원자적 커밋이 안되는 문제를 해결하면서 CVS의 한계를 극복하였다.

SVN의 특징#

중앙 집중식#

SVN 중앙 집중식 구조

SVN(Subversion)은 전형적인 중앙집중식 버전 관리 시스템으로, 모든 프로젝트 파일과 그 변경 이력이 단일 중앙 서버에 저장된다. 개발자들은 이 중앙 저장소에서 작업 복사본을 체크아웃하여 로컬에서 작업하지만, 전체 이력 정보는 서버에만 존재한다. 변경사항을 적용하려면 반드시 서버에 연결하여 커밋해야 하며, 이력을 조회하거나 이전 버전으로 되돌리는 작업도 서버 연결이 필수적이다.

저장 방식(delta)#

SVN Delta 저장 방식

SVN의 델타(delta) 방식은 최초 버전을 기준점으로 저장한 후 이후로는 변경된 부분만 기록하는 방식이다. 각 커밋에서는 이전 버전에서 무엇이 추가되었고, 삭제되었으며, 수정되었는지에 대한 차이점만 저장한다.

기준 버전(r1): A, B, C를 기록
r2의 델타: A, C의 변경점만을 기록
r3의 델타: C의 변경점만을 기록

이 방식의 장점은 저장 공간을 효율적으로 사용한다는 점이며, 특히 큰 바이너리 파일을 다룰 때 유리하다. 또한 특정 파일의 변경 이력을 쉽게 추적할 수 있다. 하지만 단점도 존재한다. 특정 버전의 파일을 보기 위해서는 기준 버전부터 해당 버전까지의 모든 델타를 순차적으로 적용해야 했다. 따라서 파일 기록이 길어질수록 파일 조회 시간이 길어진다는 문제가 있다.

git#

Git은 2005년 리눅스 커널을 개발하는 과정에서 리누스 토르발스가 개발한 분산형 버전 관리 시스템이다. SVN과 같은 중앙 집중식 시스템의 한계를 극복하기 위해 만들어졌다.

분산버젼 관리 시스템#

Git 분산 버전 관리 시스템

Git은 분산형 버전 관리 시스템으로, 모든 개발자가 전체 저장소의 완전한 복사본을 로컬에 가지고 있다. 이는 중앙 서버에 의존하지 않고도 로컬에서 대부분의 작업(커밋, 브랜치 생성, 이력 조회 등)을 수행할 수 있다는 것을 의미한다. 오프라인 상태에서도 작업이 가능하며, 변경 사항은 나중에 원격 저장소와 동기화할 수 있다.

저장 방식(snapshot)#

Git Snapshot 저장 방식

Git은 SVN의 델타 방식과 달리 스냅샷(snapshot) 방식을 사용한다. 각 커밋은 프로젝트의 특정 시점에 대한 전체 파일 상태의 스냅샷을 저장한다. 파일이 변경되지 않았다면 Git은 해당 파일에 대한 링크만 저장한다.

커밋 1: 모든 파일(A, B, C)의 전체 스냅샷 저장
커밋 2: 변경된 파일(A, C)의 새 스냅샷 저장, 변경되지 않은 파일(B)은 이전 스냅샷에 대한 링크만 저장

이런 snapshot 방식은 특정 버전의 파일을 조회할 때 이전 델타를 모두 적용할 필요 없이 해당 스냅샷에서 바로 파일 상태를 확인할 수 있다. 이는 파일 조회 속도를 크게 향상시킨다. 이런 이점으로, 특정 회사를 제외한 많은 회사들은 git을 사용한다.

Git의 주요 영역과 상태#

Git 주요 영역과 상태

git의 영역과 상태는 크게 3가지로 나뉘어진다. 수정되었지만 스테이징 영역에 포함되지 않는 modified, 스테이징 영역에 올라간 수정한 파일을 곧 커밋할 것이라고 표시한 상태인 staged, 데이터가 로컬 데이터베이스에 안전하게 저장된 상태인 committed 이다.

위 다이어그램에서 볼 수 있듯이, git의 작업 흐름은 간단히 다음과 같다.

Working Directory에서 파일을 수정한다.
git add 명령어를 사용하여 변경사항을 Staging Area로 이동시킨다.
git commit 명령어를 사용하여 Staging Area의 스냅샷을 Repository에 영구적으로 저장한다.
Repository에서 git checkout, git pull 등의 명령어를 통해 변경사항을 다시 Working Directory로 가져올 수 있다.

이렇게 git은 파일의 상태 변화를 추적하면서 프로젝트의 변경 이력을 관리한다.

정리하면서#

이후 브랜치에 대한 개념도 있지만, 이미 알고 내가 궁금했던 내용이 아니었기 때문에 이쯤에서 마무리하려 한다. 어쩌다보니 2025년 첫 글이 이 글이다.(기존에 쓰던 글이 개발 이슈로 늦어지고 있다…c 메모리도 글 써야하는데…) 좀 늦었지만, 올해에는 이 블로그에 질 좋은 포스트를 올리려고 노력하는 한 해가 되었으면 한다.