Git 입문: 커밋할 때 프로젝트를 스냅샷으로 기록하는 법

한 문장으로 이해하기

Git은 커밋(commit)이라는 저장 시점마다 프로젝트 파일 전체의 상태를 순간 사진, 즉 스냅샷으로 기록하는 도구다.

이 강좌의 학습 목표는 세 가지다. 첫째, Git이 커밋할 때 스냅샷 방식으로 데이터를 다룬다는 점을 설명할 수 있다. 둘째, 수정됨·스테이징됨·커밋됨 세 가지 파일 상태를 구분할 수 있다. 셋째, 작업 트리·스테이징 영역·Git 디렉터리라는 세 공간의 역할을 말할 수 있다. 여러 사람이 함께 쓰는 협업 방법은 이 로컬 원리를 익힌 다음 단계에서 배우게 되며, 이 강좌의 범위에는 포함하지 않는다.

사전지식은 파일을 만들고 저장하는 기본 컴퓨터 조작이면 충분하다. 프로그래밍 경험이 없어도 된다.

왜 필요한가

Git을 쓰면 저장하고 싶은 시점마다 커밋을 만들어 그때의 프로젝트 상태를 스냅샷으로 기록해 둘 수 있다. 한번 커밋한 스냅샷은 잃기 매우 어렵기 때문에, 커밋은 ‘이 상태는 지키고 싶다’는 확실한 표시가 된다.

Git의 또 다른 특징은 프로젝트 이력을 내 컴퓨터의 로컬 데이터베이스에 둔다는 점이다. 그래서 대부분의 작업을 네트워크 연결 없이 로컬 파일과 자원만으로 수행할 수 있고, 프로젝트 이력도 내 컴퓨터에서 바로 확인할 수 있다.

어떻게 이루어지는가

다른 여러 버전 관리 시스템은 데이터를 파일별 변경 목록으로 다룬다. 반면 Git은 커밋할 때 그 시점의 프로젝트 상태를 스냅샷으로 다루며, 변경되지 않은 파일은 새로 저장하지 않고 이미 저장된 동일 파일을 참조한다.

Git은 데이터를 저장하기 전에 체크섬(내용으로부터 계산한 검사 값)을 구하고, 그 값으로 데이터를 참조한다. 이때 쓰이는 것이 SHA-1 해시로, 16진수 문자로 표현되는 40자 해시 값이다. 내용이 바뀌면 해시 값도 달라지므로, 저장된 내용의 변경이나 손상을 Git이 감지할 수 있다.

Git 프로젝트에는 세 공간이 있다. 작업 트리(working tree)는 프로젝트의 한 버전을 꺼내 놓고 실제로 파일을 고치는 공간이다. 스테이징 영역(staging area)은 다음 커밋에 들어갈 정보를 담는 곳이다. Git 디렉터리(Git directory)는 프로젝트에 관한 관리 정보(메타데이터)와 실제 저장된 데이터 묶음(객체 데이터베이스)을 보관하는 곳이다.

한편 파일은 세 가지 상태 중 하나에 있다. 수정됨(modified)은 파일을 바꿨지만 아직 커밋으로 기록하지 않은 상태, 스테이징됨(staged)은 수정한 파일을 다음 커밋에 포함하도록 표시해 둔 상태, 커밋됨(committed)은 데이터가 로컬 데이터베이스에 안전하게 저장된 상태다.

기본 작업 흐름은 다음 순서로 이루어진다.

1. 작업 트리에서 파일을 수정한다.
2. 다음 커밋에 포함하고 싶은 변경을 골라 스테이징 영역에 올린다.
3. 커밋을 실행해 스테이징 영역의 파일 상태를 Git 디렉터리에 스냅샷으로 저장한다.

하나의 예시로 따라가기

(아래는 원리를 설명하기 위한 가상 예시다.)

민준은 hello.py라는 파일을 작성하고 있다.

1단계, 민준이 작업 트리에서 hello.py를 고친다. 이 시점의 파일은 ‘수정됨’ 상태이며, 아직 이력에는 기록되지 않았다.

2단계, 민준은 이 변경을 다음 커밋에 포함하도록 선택해 스테이징 영역에 올린다. 파일은 ‘스테이징됨’ 상태가 된다. 여러 파일을 고쳤더라도 원하는 변경만 골라 올릴 수 있다.

3단계, 민준이 커밋을 실행하면 스테이징 영역에 있던 파일 상태가 스냅샷으로 Git 디렉터리에 저장되고, 파일은 ‘커밋됨’ 상태가 된다. 이렇게 커밋한 스냅샷은 잃기 매우 어렵고, 다른 저장소로 정기적으로 보내 두면 보존에 더 도움이 된다.

다음 날 민준이 다시 파일을 고치면, 그 파일은 다시 ‘수정됨’ 상태가 되어 같은 흐름을 반복한다.

언제 쓰고 언제 쓰지 않는가

Git은 프로젝트 이력이 로컬 데이터베이스에 있으므로, 인터넷이 없는 환경에서도 대부분의 작업을 이어갈 수 있다. 저장하고 싶은 시점마다 커밋을 만들어 두면, 그 스냅샷들은 잃기 매우 어렵게 보관된다.

다만 다음을 주의해야 한다.

• 커밋하지 않은 변경은 잃거나 망가뜨릴 수 있다. 커밋은 자동으로 생기지 않으므로, 지키고 싶은 상태는 직접 스테이징하고 커밋해야 한다.
• 파일을 편집기에서 저장하는 것과 Git에 기록하는 것은 다르다. 저장만 해서는 스냅샷이 만들어지지 않는다.
• ‘대부분의 작업이 로컬’이라는 말은 모든 작업이 그렇다는 뜻은 아니다. 이 강좌는 로컬에서의 기본 흐름까지만 다루며, 협업 방법은 별도의 학습이 필요하다.
• 수정됨 → 스테이징됨 → 커밋됨의 흐름을 기준으로 삼으면, 이후 Git의 다른 기능도 이 틀 위에서 이해할 수 있다.

핵심 정리와 확인문제

Git은 커밋할 때 프로젝트 상태를 스냅샷으로 기록하고, 변경되지 않은 파일은 기존에 저장된 데이터를 참조한다. 파일은 수정됨 → 스테이징됨 → 커밋됨 순서로 이동하며, 데이터는 체크섬으로 저장·참조되므로 내용 변경이나 손상을 Git이 감지할 수 있다.

확인문제

1. Git이 데이터를 다루는 방식으로 올바른 것은?

   • A) 각 파일의 변경된 부분만 목록으로 기록한다.
   • B) 커밋할 때 프로젝트 상태를 스냅샷으로 다룬다.
   • C) 파일을 편집기에서 저장할 때마다 자동으로 이력이 기록된다.

2. 수정한 파일을 다음 커밋에 포함하도록 선택해 둔 상태를 무엇이라고 하는가?

   • A) 수정됨(modified)
   • B) 스테이징됨(staged)
   • C) 커밋됨(committed)

3. Git 디렉터리의 역할로 올바른 것은?

   • A) 프로젝트의 한 버전을 꺼내 놓고 파일을 고치는 공간이다.
   • B) 다음 커밋에 들어갈 정보를 담는 공간이다.
   • C) 프로젝트의 관리 정보(메타데이터)와 저장된 데이터 묶음(객체 데이터베이스)을 보관한다.

정답과 해설

1. 정답: B — Git은 커밋할 때 프로젝트 상태를 스냅샷으로 다룬다. 다만 변경되지 않은 파일까지 매번 다시 저장하는 것은 아니며, 이미 저장된 동일 파일을 참조해 공간을 아낀다. 파일별 변경 목록 방식(A)은 다른 여러 버전 관리 시스템의 방식이고, 편집기 저장만으로는(C) 스냅샷이 만들어지지 않는다.

2. 정답: B — 다음 커밋에 포함하도록 표시해 둔 상태가 ‘스테이징됨’이다. 아직 커밋 전이므로 ‘커밋됨’이 아니며, 커밋을 실행해야 로컬 데이터베이스에 저장된다.

3. 정답: C — Git 디렉터리는 프로젝트의 관리 정보와 저장된 데이터 묶음을 보관한다. 파일을 고치는 공간(A)은 작업 트리, 다음 커밋 정보를 담는 공간(B)은 스테이징 영역이다.

참고자료

• Git 입문 참고자료