git 명령어, 몇 개나 알고 계신가요? add, commit, push, pull은 이미 손에 익었을 텐데, 정작 화면이 새하얘지는 순간에는 그 네 가지만으로는 답이 안 나옵니다.
최근 dev.to에 올라온 10 Git Commands You’ll Wish You Knew Earlier는 신입 시절 시니어에게 배운 실무형 git 명령어를 정리해 화제가 됐습니다. 후배님이 지금 알고 있는 git 명령어가 몇 개인지보다, 사고가 터졌을 때 어떤 걸 꺼내 쓰는지가 실무에서는 훨씬 중요합니다.
reset 삼형제 — 되돌릴 수 있는 실수, 되돌리기 힘든 실수
코드를 쓰다가 “이 방향이 아니다”라고 느끼는 순간은 누구에게나 옵니다. 이때 git reset을 어떤 옵션으로 쓰느냐에 따라 결과가 완전히 달라집니다. 커밋 이력, 스테이징 영역, 작업 디렉터리 중 어디까지 되돌릴지를 정하는 게 핵심입니다.
git reset –soft
마지막 커밋만 취소하고 변경 내용은 스테이징 상태로 남겨둡니다. 커밋 메시지를 다시 쓰거나 커밋을 합치고 싶을 때 씁니다.
git reset –mixed
기본값입니다. 커밋을 취소하고 변경 내용은 파일에 남지만 스테이징은 풀립니다. 다시 git add부터 해야 합니다.
git reset –hard
가장 위험한 옵션입니다. 커밋뿐 아니라 작업 디렉터리의 변경 내용까지 통째로 사라집니다. 실행 전에 정말 필요한 옵션인지 한 번 더 확인하는 습관이 필요합니다.
공유 브랜치에서 벌어지는 진짜 사고
merge와 rebase는 겉으로 보면 비슷해 보입니다. 둘 다 다른 브랜치의 변경 내용을 내 브랜치로 가져오는 작업이니까요. 하지만 이력을 다루는 방식은 완전히 다릅니다.
merge와 rebase, 이력을 남기는 방식이 다릅니다
merge는 두 브랜치의 이력을 그대로 유지한 채 병합 커밋을 하나 추가합니다. 실제로 무슨 일이 있었는지 이력이 그대로 남는 대신, 반복하면 이력이 복잡해집니다. rebase는 내 커밋을 최신 브랜치 위로 옮겨 다시 적용하기 때문에 이력이 깔끔해지지만, 커밋 해시가 바뀌면서 이력을 다시 쓰게 됩니다.
본인 작업은 rebase해도 괜찮지만, 다른 사람이 이미 내 커밋을 기반으로 작업하고 있다면 rebase는 신중해야 합니다.
10 Git Commands You’ll Wish You Knew Earlier, dev.to
force보다 force-with-lease를 써야 하는 이유
rebase나 amend로 이력을 바꾼 뒤 원격 저장소에 올리려면 강제 push가 필요할 때가 있습니다. git push --force는 원격의 상태를 무시하고 내 로컬로 덮어씁니다. 그사이 동료가 커밋을 하나라도 올렸다면 그 작업이 통째로 사라질 수 있습니다.
git push --force-with-lease는 다릅니다. 내가 마지막으로 확인한 원격 상태와 실제 원격 상태가 다르면 push 자체를 거부합니다. 팀 저장소에서는 force 대신 이 옵션을 기본값으로 삼는 걸 권합니다.
커밋을 깔끔하게 정리하는 법 — amend와 interactive rebase
코드 리뷰를 앞두고 커밋 이력이 지저분하면 리뷰어도, 나중의 나 자신도 고생합니다. 두 명령어만 알아도 이력을 훨씬 깔끔하게 관리할 수 있습니다.
git commit –amend로 실수 고치기
커밋을 올리자마자 파일 하나를 빠뜨렸다는 걸 알아챈 경험, 다들 있으실 거예요. 이럴 때 새 커밋을 또 만드는 대신 git commit --amend --no-edit로 직전 커밋에 합쳐버리면 이력이 훨씬 깨끗해집니다. 단, 이미 원격에 올라간 커밋을 amend하면 로컬과 원격 이력이 어긋나므로 push 방식을 다시 신경 써야 합니다.
git rebase -i로 커밋 정리하기
인터랙티브 리베이스(git rebase -i HEAD~5)를 쓰면 최근 커밋들을 pick, reword, squash, fixup, drop 중 원하는 방식으로 재구성할 수 있습니다. “Fix validation”, “진짜 fix validation” 같은 커밋이 쌓였다면 squash나 fixup으로 하나로 합쳐 리뷰어가 보기 좋은 이력으로 정리할 수 있습니다.
급한 일이 생겼을 때 — stash와 안전한 되돌리기
기능 개발을 한창 하던 중 운영 장애가 접수됐다고 상상해보세요. 파일 절반이 수정된 상태라 커밋도, 브랜치 전환도 애매합니다.
git stash로 작업 임시 저장
git stash push -u -m "WIP 로그인 기능"처럼 이름을 붙여 저장해두면 나중에 git stash list로 여러 개를 구분하기 쉽습니다. -u 옵션을 빼먹으면 새로 추가한 파일은 stash에 포함되지 않는다는 점도 기억해둘 만합니다.
git revert로 안전하게 되돌리기
운영 브랜치에 이미 올라간 커밋이 문제라면 git reset --hard로 지우기보다 git revert <커밋해시>를 씁니다. 기존 커밋을 지우지 않고 반대 내용을 담은 새 커밋을 추가하는 방식이라, 무슨 일이 있었는지 이력에 그대로 남습니다. 공유 브랜치에서는 이력을 다시 쓰는 reset·force push보다 revert가 훨씬 안전합니다.
화면이 하얘지는 순간, reflog와 cherry-pick
실무에서 자주 쓰이진 않지만, 딱 한 번 필요한 순간에 이 두 명령어를 모르면 몇 시간짜리 작업을 통째로 날릴 수 있습니다.
git reflog로 사라진 커밋 되찾기
후배님, git reset --hard를 잘못 실행해서 이틀치 작업이 담긴 브랜치가 통째로 사라진 경험 있으신가요? 이럴 때 git log에는 안 보여도 git reflog에는 HEAD가 최근에 가리켰던 지점이 모두 남아 있습니다. 원하는 커밋 해시를 찾았다면 git branch rescue <해시>로 새 브랜치를 만들어 안전하게 복구할 수 있습니다. 다만 한 번도 커밋되지 않은 변경 사항은 reflog로도 되살릴 수 없다는 점은 분명히 알아둬야 해요.
git cherry-pick으로 필요한 커밋만 가져오기
다른 브랜치의 커밋 하나만 필요할 때, 브랜치 전체를 merge하거나 rebase할 필요는 없습니다. git cherry-pick <커밋해시>로 원하는 변경 사항만 새 커밋으로 가져올 수 있습니다. 환경설정 변경처럼 특정 커밋 하나만 옮겨야 하는 상황에서 특히 유용합니다.
채용 시장에서 git 실력이 갖는 의미
RhodeCode가 정리한 버전관리 시스템 통계에 따르면 2025년 기준 Git 사용률은 93.87%로, 2016년 87.1%보다 더 올랐습니다(RhodeCode, 2025). 이제 git은 “쓸 줄 아느냐”의 문제가 아니라 “얼마나 능숙하게 다루느냐”의 문제로 넘어갔습니다.
면접에서 “git 충돌 나면 어떻게 해결하세요?”라는 질문을 받아보신 적 있나요? 이 질문의 진짜 의도는 merge와 rebase 정의를 외웠는지가 아니라, 사고 상황에서 침착하게 대응할 수 있는지를 보는 겁니다. reset 삼형제의 차이, force-with-lease를 쓰는 이유, reflog로 복구하는 절차를 구체적인 사례와 함께 설명할 수 있다면 시니어급 판단력을 어필하기 좋습니다.
원티드랩 기술 블로그의 채용 공고 스킬 트렌드 분석을 봐도, 개발 직군에서 git 같은 기본기 스킬은 시기와 무관하게 꾸준히 요구되는 항목으로 꼽힙니다. 화려한 신규 프레임워크 경험보다, 사고가 났을 때 git 이력을 침착하게 정리하는 능력이 오히려 실무 신뢰도를 더 크게 좌우한다는 걸 후배님도 한 번쯤 느껴보셨을 거예요.
이 정도는 알아야 실무에서 안 흔들립니다
아래 체크리스트로 지금 나의 git 실전 대응력을 점검해보세요.
- reset –soft / –mixed / –hard의 차이를 설명할 수 있다
- 공유 브랜치에서는 rebase 대신 merge를, force 대신 force-with-lease를 쓴다
- 커밋 이력을 rebase -i로 정리해본 적이 있다
- 운영 브랜치 사고는 reset이 아니라 revert로 처리한다
- reflog로 사라진 커밋을 복구해본 경험이 있다
다섯 개 중 서너 개에 체크했다면 이미 실무형 git 감각을 갖춘 셈입니다. 두 개 이하라면 오늘 다룬 명령어 중 하나를 골라 개인 저장소에서 먼저 연습해보시길 권합니다.
관련 글
git 명령어를 더 깊이 다뤄보고 싶다면 아래 글도 함께 참고해보세요.
- 코드 리뷰에서 신입과 시니어의 git 습관 차이가 궁금하다면 코드 리뷰에서 티 나는 git 명령어 10가지, 신입과 시니어의 차이를 읽어보세요.
- AI 에이전트 도입이 git 워크플로우에 어떤 부담을 주는지는 AI 에이전트가 키운 Git 확장성 문제, 시니어 개발자가 알아야 할 이유에서 다뤘습니다.
- 기본기가 채용 경쟁력으로 이어지는 다른 사례는 freeCodeCamp 다시 뜬 이유, 독학 개발자 채용 경쟁력은에서 확인할 수 있습니다.
📌 함께 보시면 좋은 글
이직·퇴사·연봉 협상을 혼자 판단하기 어렵다면
1:1 개발자 커리어 상담 신청하기 →
※ 본 글은 AI(Claude)의 초안을 기반으로 편집자 검수를 거쳐 발행되었습니다. (한국 AI기본법 대응 고지)
이직·퇴사, 지금 움직여도 될지 헷갈리시나요?
막연히 불안한 건지, 정말 시점이 온 건지 판단이 어려울 때가 있습니다.
5분 체크리스트로 지금 상태를 먼저 정리해보세요.
결론을 대신 내리기보다, 스스로 판단할 기준을 잡는 데 도움을 드립니다.
아직 확신이 없다면, 지금이 ‘고민 단계’인지부터 먼저 점검해보세요