git add -p: 수술식 staging

git add -p 가 프로의 staging 방식

git add file.js 는 파일 전체를 stage. git add . 는 현재 디렉토리 전부 stage. 한 파일의 모든 변경이 같은 commit 에 들어갈 단순 케이스엔 둘 다 OK. 근데 단순 케이스가 드물어. 실전 코딩 세션은 보통 관련 없는 것들 건드려 — 기능 + 오타 수정, bug fix + 지우려다 깜빡한 debug log, refactor + 떠다니는 console.log. 한 commit 에 뭉치면 review 가 깨지고 bisect 도 나중에 망가져.

프로의 답은 git add -p (또는 --patch). 변경 'hunk' 를 하나씩 보여주면서 이거 stage 할래? 물어. y (yes), n (no), s (더 작은 hunk 로 split), e (직접 편집) 으로 답해. 결과: commit 하나엔 정확히 bug fix, 다른 거엔 정확히 오타 수정, 또 다른 거엔 정확히 debug-log 제거. history 가 깨끗하게 읽히고 bisect 가 실패를 분리할 수 있어.

짝꿍은 unstage / 선택적 discard 용 git restore -p 와 옛 동의어 git checkout -p. modern editor 도 GUI hunk staging 줘 — VS Code 의 "Stage Selected Ranges," Tower, GitKraken, GitHub Desktop. 도구는 자유, 키워야 하는 근육은 'commit 전 모든 diff 검토' — '오늘 친 거 다 commit' 이 아니라.

한 가지 보충: git add -A 는 repo 전체의 모든 변경 (삭제, untracked 포함) 을 stage. 편하고 위험해 — 관련 없는 test 산출물, secret .env 편집, 우발 binary 가 이렇게 commit 에 들어가. 시니어들 상당수가 -A 를 통째로 안 쓰고 git add -p + 명시적 파일 이름으로 다 처리해.

Code

interactive patch staging session·bash

# 수정된 모든 파일의 모든 hunk 를 순회하면서 hunk 별로 선택:
git add -p

# prompt 키:
#   y  이 hunk stage
#   n  안 함
#   q  나가기
#   a  이 파일의 이 hunk + 남은 hunk 전부 stage
#   d  이 파일의 이 hunk + 남은 hunk 전부 안 함
#   s  더 작은 hunk 로 split
#   e  stage 전 hunk 직접 편집
#   ?  도움말

선택적 unstage / restore·bash

# 실수로 add 한 일부 hunk unstage:
git restore --staged -p src/app.js

# unstaged 변경 interactive 로 버리기 (위험 — 신중히):
git restore -p src/style.css

Exercise

관련 없는 편집 여러 개 들어 있는 파일 찾아 (없으면 일부러 만들어). git add -p 실행. 적어도 hunk 두 개에서 s 로 split 하고 조각별로 다르게 결정해. 끝나면 commit 두 개로 끊어 — 각자 초점 잡힌 메시지로. git log --oneline -p -n 2 로 commit 들이 한 덩어리 dump 가 아니라 깨끗한 두 이야기로 읽히는지 확인.

git add -p: 수술식 staging

git add -p 가 프로의 staging 방식

Code

External links

Exercise

Progress

댓글 0