git add -p: 필요한 조각만 stage하기

git add -p는 의도를 골라 stage하는 방법이야

git add file.js는 파일 전체를 stage하고, git add .는 현재 directory의 변경을 전부 stage해. 한 파일의 모든 변경이 같은 commit에 들어갈 때는 괜찮지만 실제 작업은 좀처럼 그렇게 얌전하지 않아. 기능을 만들다 오타를 고치고, bug를 잡다 지우지 않은 debug log를 남기고, refactor하다 console.log가 끼어들기 마련이야. 이걸 한 commit에 뭉치면 검토가 흐려지고 나중의 bisect도 덜 쓸모 있어져.

이럴 때 쓰는 답이 git add -p, 곧 --patch야. 변경 hunk를 하나씩 보여주며 stage할지 물어봐. y는 선택, n은 건너뛰기, s는 더 작은 hunk로 나누기, e는 직접 편집하기야. 그러면 한 commit에는 bug fix만, 다른 commit에는 오타 수정만, 또 다른 commit에는 debug log 제거만 담을 수 있어. 이력이 또렷하게 읽히고 bisect도 실패를 제대로 가를 수 있지.

짝이 되는 명령은 unstage하거나 일부 변경을 버릴 때 쓰는 git restore -p와 옛 동의어인 git checkout -p야. 요즘 편집기도 GUI hunk staging을 제공해. VS Code의 "Stage Selected Ranges," Tower, GitKraken, GitHub Desktop 같은 도구를 골라도 돼. 도구보다 중요한 습관은 commit하기 전에 모든 diff를 검토하는 거야. 오늘 입력한 것을 몽땅 commit하는 게 아니고.

git add -A는 삭제와 untracked file까지 repo 전체의 모든 변경을 stage해. 편한 만큼 위험하지. 관련 없는 test 결과물, secret이 든 .env 수정, 우연히 생긴 binary가 commit에 숨어드는 길이 될 수 있어. 그래서 숙련자 상당수는 -A 대신 git add -p와 명시적인 파일 이름을 써.

Code

대화형 patch staging·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로 더 작게 나눈 뒤 조각마다 다른 결정을 내려. 끝나면 초점이 분명한 message로 commit 두 개를 만들어. git log --oneline -p -n 2에서 한 덩어리 dump가 아니라 깔끔한 두 이야기로 읽히는지 확인해.

git add -p는 의도를 골라 stage하는 방법이야

Code

External links

Exercise

Progress

댓글 0