git checkout
Switch branches or restore working tree files
— Git 공식 매뉴얼(man git-checkout)
너무 고생을 많이 한 나머지 결국 정신 분열을 겪고 git switch와 git restore로 쪼개진 비운의 만능 맥가이버 칼. git checkout .을 치는 순간 내 3시간 동안의 주말 코딩은 차가운 우주먼지로 사라졌다(...)
1. 개요
과거 오랫동안 Git 생태계를 지켜온 다목적 일꾼 커맨드로, 주로 다른 브랜치로 이동하거나 특정 파일의 상태를 과거 시점으로 되돌리는 데 사용되었다. 워낙 다양한 상황에서 호출되다 보니 현재는 기능이 분리되는 수술을 받았으나, 10년 넘은 고인물들의 손가락에는 여전히 이 명령어의 흔적이 깊게 배어 있다.
2. 무소불위의 권력과 지나친 비대함
git checkout <branch>를 치면 평행 우주를 넘어 다니는 차원 이동 포탈이 열리지만, 똑같은 단어 뒤에 git checkout -- <file>을 치면 대기 중이던 임시 수정을 사정없이 짓밟고 과거의 정돈된 파일로 뒤엎어버린다. 이렇게 극단적으로 다른 기능이 한 명령어 안에 융합되어 있다 보니, 수많은 개발자들이 '브랜치 바꾸려다가 내 수정한 코드를 영원히 안드로메다로 날려버리는' 수많은 묵시록급 조난사고를 겪었다.1
3. 공포의 Detached HEAD 경고
특정 브랜치 이름 대신 과거의 고정된 커밋 해시값을 타겟으로 checkout을 갈기면, 기괴하고 무시무시한 장문의 에러 경고인 Detached HEAD 상태를 마주치게 된다. 이는 현재 머리가 둥둥 떠다니며 어느 브랜치에 가닿지 않은 미아가 되었다는 뜻이다. 이 상태에서 신나서 코딩을 하고 커밋을 갈겼다간, 다른 브랜치로 옮겨가는 순간 가차 없이 가비지 컬렉팅 대상이 되어 고아 상태로 버려진다.
4. 실제 사용 예시
예전 Git에서 브랜치를 이동하거나 새 브랜치를 만들 때 가장 흔하게 쓰던 형태다. 최신 Git에서는 브랜치 이동은 switch, 파일 복원은 restore로 나누는 편이 더 명확하다.
# 기존 브랜치로 이동
git checkout main
# 새 브랜치를 만들고 바로 이동
git checkout -b feature/login
특정 파일을 마지막 커밋 상태로 되돌릴 수도 있다. 되돌린 작업 내용은 사라질 수 있으니 실행 전 git diff로 확인하는 편이 좋다.
git diff src/app.ts
git checkout -- src/app.ts
5. 관련 밈 및 드립
5.1. 지워진 코드의 애도
실수로 잘못 고친 코드를 원상복구하겠답시고 git checkout . 혹은 git checkout -- 파일명을 갈겼다가, 지우면 안 되는 주말 야근 작업분까지 통째로 증발시키는 참사 밈이다. 이 명령어로 날아간 코드는 git reflog 구원 리스트에도 잡히지 않아, 멘탈이 완벽히 바스러지며 의자에서 뒤로 넘어지는 전설의 포즈를 시전하게 된다.
5.2. 고인물들의 checkout 집착
깃 측에서 머리가 덜 아픈 대체재인 git switch를 출시해 줬음에도 불구하고, 이미 근육 기억(Muscle Memory)이 절여질 대로 절여진 고인물들은 꿋꿋하게 타이핑이 훨씬 긴 git checkout -b를 고집하는 틀딱형 개발자 행태를 조명한 드립이다.
6. 여담
- 분가 성공: 2.23 버전부터 이 녀석의 혼란스러운 기능을 드디어 깔끔하게 갈라놓아, 브랜치 이동은
git switch, 파일 복구는git restore로 편안하게 사용이 가능해졌다. - 커밋 여행: 커밋 해시로 이동하면 과거의 빌드 환경이나 심각했던 시절의 버그를 그대로 생생하게 관찰하며 셀프 디스를 할 수 있는 소중한 시간 여행이 시작된다.
- 임시 가방: 체크아웃 시 현재 수정 중인 파일들이 걸리적거리면 깃은 경고를 뱉고 이사를 거부한다. 이때는 git stash를 활용해 짐을 잠시 보따리에 싸두어야 편히 다녀올 수 있다.