반쯤 한 작업이 벤치에 있을 때 hotfix
방해 패턴. feature/profile-page 에서 작업 중, editor 에 미완성 작업 2 시간치. On-call 채널 ping: 프로덕션에 critical 버그, main 에 한 줄 fix 즉시 ship 필요. 잘못된 동작은 '가진 거 그냥 commit' 이나 진행 중 작업 잃기. 옳은 동작은 잘 연습된 거: 진행 중 작업 shelter, branch, fix, ship, 복귀. 연습된 경우 총 15 분.
가능한 shelter 둘. Stash — 작업이 작고 단기일 때: git stash push -u -m "WIP: profile-page" 가 staged + unstaged + untracked 파일 저장, tree 깨끗. Worktree — hotfix 가 30 분 이상 걸릴 거 같거나 다른 창에서 feature 편집 계속하고 싶을 때: git worktree add ../repo-hotfix hotfix/login-crash main 가 feature 안 흔들고 작업 가능한 병렬 checkout 생성.
Hotfix 자체는 작은 변경과 같음: main 분기, 명확한 메시지로 한 commit 으로 fix, push, urgency 이유 적은 PR description 으로 PR 열기, 빠른 리뷰 (branch 보호 허용하면 승인자 1), merge, 배포. 의식이 잘못된 도구일 때 의식 건너뛰기 — 단 fix 가 실제로 버그 고친다는 걸 보여주는 test 는 절대 건너뛰지 마. 검증 없이 'should work' 인 hotfix 가 프로덕션이 두 번째 outage 받는 방법.
복귀가 팀이 망치는 곳. Hotfix land + 배포 후 feature 로 돌아가 main 을 가져와야 함: feature branch 가 hotfix 이전 main 에 base 했고 이제 뒤짐. git switch feature/profile-page, git stash pop (stash 했으면) 또는 정상 worktree 로 cd ../, git fetch origin, git rebase origin/main. Hotfix 가 진행 중 작업과 같은 줄 건드렸으면 conflict, 작은 fix 엔 드물어. 작업 계속.