핵심 정리

# 1. 파일 수정 (작업 트리에서만 변경된 상태)
# 2. 다음 커밋에 포함할 변경을 선택
git add app.js

# 3. 스테이징된 내용을 커밋으로 확정
git commit -m "Refine search input behavior"

# 현재 세 영역의 상태를 확인
git status

구조 이해

어떤 Git 영역을 먼저 떠올리면 되나

스테이징 영역이 존재하는 이유 — 커밋 단위를 논리적으로 제어하기 위해서다

파일을 수정하면 작업 트리에 변경이 생긴다. 그런데 수정한 파일이 여러 개이고 서로 다른 목적의 변경이 섞여 있을 수 있다. 스테이징 영역(index)은 "다음 커밋에 무엇을 포함할지"를 고르는 중간 지점이다. git add로 선택한 변경만 스테이징되고, 나머지는 작업 트리에 남는다. 이 덕분에 하나의 파일 안에서도 git add -p로 hunk 단위로 선택해 서로 다른 커밋으로 분리할 수 있다. 커밋 단위가 논리적으로 명확할수록 git bisect, git revert, 코드 리뷰가 모두 쉬워진다.

커밋은 스냅샷이지 차이(diff)가 아니다 — Git 객체 모델의 핵심

git commit을 실행하면 Git은 스테이징된 파일들을 blob 객체로 저장하고, 디렉터리 구조를 tree 객체로 만들고, 이를 가리키는 commit 객체를 생성한다. 커밋 객체에는 부모 커밋 해시, 작성자, 타임스탬프, 커밋 메시지가 포함된다. 중요한 점은 Git이 저장하는 것이 이전 상태와의 차이가 아니라 그 시점의 전체 스냅샷이라는 것이다. diff는 두 커밋의 스냅샷을 비교해서 계산하는 것이지 저장된 형태가 아니다. 이 구조 덕분에 어떤 시점으로든 빠르게 복원할 수 있다.

git status가 항상 첫 번째 판단 도구다 — 세 영역의 현재 상태를 알려준다

git status는 작업 트리, 스테이징 영역, HEAD 커밋 세 가지를 비교해 현재 상태를 알려 준다. "Changes not staged for commit"은 작업 트리에 변경이 있지만 스테이징되지 않은 것, "Changes to be committed"는 스테이징 영역에 올라간 것, "Untracked files"는 Git이 추적하지 않는 새 파일이다. git add와 git commit 사이에 무슨 일이 일어나고 있는지 모를 때 항상 git status를 먼저 실행하는 습관이 혼란을 줄인다.

add --patch로 파일 일부만 스테이징할 수 있다 — 커밋 품질이 올라가는 핵심 기능이다

git add -p(또는 --patch)를 실행하면 변경된 각 hunk를 하나씩 보여 주면서 "이 부분을 스테이징할지(y/n)"를 선택할 수 있다. 하나의 파일에 버그 수정과 리팩터링이 함께 있을 때, 이 기능으로 두 변경을 서로 다른 커밋으로 분리할 수 있다. 커밋 단위가 작고 명확할수록 나중에 특정 변경을 git revert하거나 git bisect로 버그 도입 시점을 찾는 작업이 훨씬 정확해진다.

git add만 하고 git commit을 안 하면 히스토리는 바뀌지 않는다

스테이징을 "저장"으로 오해하면 Git 흐름이 계속 꼬입니다. git add는 다음 커밋 후보를 고르는 단계일 뿐이고, 히스토리를 실제로 바꾸는 것은 git commit입니다. add까지만 하고 브랜치를 바꾸거나 터미널을 닫아도, 커밋 기록은 늘어나지 않습니다.

echo "new line" >> app.js
git add app.js
git status
# Changes to be committed: app.js

git log --oneline -1
# 아직 새 commit은 없음

git commit -m "Update app behavior"
# 이 시점에야 히스토리가 늘어남

체크포인트

주의할 점