Quick Flow
파일을 수정하면 worktree가 바뀌고, git add는 실행 시점의 내용을 index에 복사하며, git commit은 index snapshot으로 새 commit을 만듭니다. add 뒤 같은 파일을 다시 수정하면 staged와 unstaged 변경이 동시에 있을 수 있습니다.
HEAD commit --(git diff --staged)--> index --(git diff)--> worktree
git commit git add / git add -p| 목적 | 명령 | 바뀌는 상태 |
|---|---|---|
| 전체 상태 확인 | git status | 변경 없음 |
| unstaged 확인 | git diff | worktree vs index |
| staged 확인 | git diff --staged | index vs HEAD |
| 파일/경로 stage | git add <path> | index |
| hunk만 stage | git add -p <path> | index 일부 |
| staged snapshot 기록 | git commit -m "..." | HEAD와 current branch |
index가 필요한 이유
index는 다음 commit의 후보 snapshot입니다. 파일 두 개의 bug fix와 formatting, 한 파일 안의 서로 다른 hunk도 git add -p로 의도별로 나눌 수 있습니다. 같은 file을 stage한 뒤 추가 수정하면 index에는 이전 content가 남고 worktree에는 새 content가 남습니다. git status와 두 종류의 diff로 이 상태를 먼저 확인합니다.
git add -A는 지정 범위에서 add·modify·delete를 index에 반영할 수 있으므로, 의도치 않은 generated file이나 삭제도 함께 stage될 수 있습니다. pathspec을 명확히 쓰고 commit 전 git diff --staged로 실제 snapshot을 review합니다. ignored file은 기본적으로 add되지 않으며, force add는 ignore rule을 무시한다는 별도 선택입니다.
commit이 바꾸는 것
git commit은 index를 tree로 만들고 current branch tip을 새 commit으로 이동합니다. add만 한 상태는 local history가 바뀐 것이 아니며, editor를 닫거나 branch를 바꾸기 전에 uncommitted worktree/index를 Git이 항상 안전하게 보관해 준다고 가정하지 않습니다. branch switch·merge·rebase 전에 clean working state가 필요한 이유도 여기에 있습니다.
commit message는 title만으로 충분하지 않은 변경에는 why, risk, test/rollback 단서를 남깁니다. 하나의 commit을 되돌렸을 때 기능이 중간 상태로 깨지지 않는지도 검토합니다. 이는 commit을 기계적으로 작게 만들라는 뜻이 아니라, review·revert 가능한 변화 단위로 만든다는 뜻입니다.
혼합 상태를 다루기
stage한 수정 뒤 같은 파일에 새 worktree 변경을 만들고 status, diff, diff --staged를 직접 확인합니다. 잘못 stage했으면 git restore --staged <path>로 index만 되돌리고 worktree는 유지할 수 있습니다. discard와 unstage는 영향 범위가 다르므로 restore 카드에서 명령 전 diff를 확인합니다.
stage는 저장 버튼이 아닙니다. commit 전에는 history가 늘지 않고, commit도 push 전에는 remote에 없을 수 있습니다. 항상 git status와 staged diff를 함께 확인하세요.
참고 링크
3 sources