add, commit, push, pull—입사 초년차에 배운 이 네 가지 명령어만으로 어찌어찌 버텨온 개발자, 생각보다 많으실 거예요. 그런데 연차가 쌓이다 보면 이 네 가지로는 감당이 안 되는 순간이 반드시 옵니다. 최근 dev.to에 올라온 10 Git Commands You’ll Wish You Knew Earlier를 읽으면서, 저 역시 신입 시절 이 명령어들을 하나씩 몸으로 부딪혀가며 배웠던 기억이 났습니다.
오늘은 실무 git 명령어 10가지를 정리합니다. 단순히 사용법만 나열하지 않고, 기술적으로 어떻게 동작하는지와 함께 팀 안에서 어떤 협업 매너로 이어지는지까지 같이 살펴볼게요.
add·commit·push 다음 단계, 왜 필요할까
이 네 가지 명령어만 알아도 코드는 저장되고 원격 저장소에 올라갑니다. 문제는 여러 명이 같은 레포지토리에서 동시에 작업할 때부터 시작되죠. 브랜치가 꼬이고, 커밋 이력이 지저분해지고, 급하게 되돌려야 하는 순간이 옵니다. 그럴 때 필요한 게 오늘 소개할 명령어들입니다.
후배님이 시니어와 같이 일하며 “저 사람은 왜 저렇게 침착하게 상황을 되돌리지?”라고 느낀 적 있다면, 대부분 이 명령어 중 하나를 알고 있어서예요. 기술 자체는 어렵지 않습니다. 언제 어떤 걸 써야 하는지 판단하는 감각이 관건이죠.
머지냐 리베이스냐, 브랜치 전략부터 정합니다
git merge는 두 브랜치의 이력을 합치면서 머지 커밋을 새로 만듭니다. 원래 히스토리가 그대로 남기 때문에 무슨 일이 있었는지 추적하기는 쉽지만, 반복하다 보면 이력이 복잡해집니다. 반대로 git rebase는 내 커밋을 최신 브랜치 위로 옮겨 다시 적용합니다. 이력은 깔끔해지지만 커밋 해시가 바뀌기 때문에, 이미 다른 사람과 공유된 브랜치에서는 조심해야 합니다.
Rebase your own work. Be careful rebasing shared history.
Git 공식 문서, git-scm.com
그래서 실무 팀에서는 “내 브랜치에서만 작업 중이면 리베이스, 이미 다른 사람이 내 커밋 위에 작업을 얹었으면 머지”라는 규칙을 컨벤션으로 정해두는 경우가 많습니다. 이 규칙을 누가 정하느냐—대개 시니어의 몫이고, 신입 때는 그냥 따르다가 연차가 쌓이면서야 왜 그런 규칙이 있는지 이해하게 되죠. Git 공식 문서에도 이 원칙이 명시돼 있습니다.
커밋 이력을 손보는 법
커밋 하나 고치기: git commit –amend
커밋 직후 console.log 하나를 빼먹은 걸 발견했다면, 새 커밋을 또 만드는 대신 git add 후 git commit --amend --no-edit로 직전 커밋에 합칠 수 있습니다. 다만 이 명령은 기존 커밋을 수정하는 게 아니라 새로운 해시를 가진 커밋으로 교체하는 것이라, 이미 push한 브랜치라면 그다음이 중요해집니다.
이력을 바꿨다면: git push –force-with-lease
git push --force는 “내 로컬이 진리다, 원격을 덮어써라”는 명령이라 팀원이 그사이 올린 커밋까지 날려버릴 위험이 있습니다. --force-with-lease는 내가 알고 있던 원격 상태와 실제 원격이 같을 때만 강제 push를 허용해서, 사고를 미리 막아줍니다. 협업 브랜치에서는 --force 대신 이 옵션을 습관으로 만드는 걸 권합니다.
커밋을 통째로 정리: git rebase -i
git rebase -i HEAD~5로 최근 5개 커밋을 열면 pick·reword·squash·fixup·drop 같은 명령으로 이력을 재구성할 수 있습니다. 이건 리뷰어가 나를 평가하는 기준이 아니라, PR을 올리기 전에 스스로 이력을 정돈하는 습관에 가깝습니다. “Fix validation”, “Actually fix validation”, “Fix validation again” 같은 커밋들을 하나로 squash해두면, 나중에 이력을 다시 읽을 미래의 나(혹은 동료)가 훨씬 편해집니다.
급한 이슈 대응: stash와 cherry-pick
기능 개발 중간에 프로덕션 버그 리포트가 들어오는 상황, 다들 한 번쯤 겪어보셨을 거예요. 지금 작업 중인 코드는 절반만 완성돼 있고 빌드도 안 되는데, 당장 브랜치를 바꿔야 합니다. 이럴 때 쓰는 게 git stash push -u -m "WIP 기능명"입니다. 작업 중이던 변경 사항을 임시로 치워두고 깨끗한 상태로 돌아갈 수 있어요.
- git stash list — 쌓인 스태시 목록 확인
- git stash pop — 가장 최근 스태시를 복원하고 목록에서 제거
- git cherry-pick 커밋해시 — 다른 브랜치의 커밋 하나만 현재 브랜치로 가져오기
버그를 급하게 고친 커밋 하나만 다른 배포 브랜치에도 반영해야 할 때, 브랜치 전체를 머지하지 않고 cherry-pick으로 그 커밋만 옮기면 됩니다. 핫픽스를 여러 브랜치에 백포트할 때 실무에서 자주 쓰는 방법입니다.
되돌리기 3단계
reset: soft·mixed·hard
- git reset –soft HEAD~1 — 커밋만 취소, 변경 내용은 스테이징 상태로 유지
- git reset –mixed HEAD~1 (기본값) — 커밋 취소 + 스테이징도 해제, 파일 내용은 보존
- git reset –hard HEAD~1 — 커밋과 파일 변경 내용 모두 삭제, 되돌릴 수 없음
revert: 공유 브랜치에서는 이걸 쓰세요
이미 배포되거나 여러 명이 공유하는 브랜치에서 문제 커밋을 되돌려야 한다면 reset --hard 대신 git revert 커밋해시를 씁니다. revert는 기존 커밋을 지우지 않고, 그 반대 내용을 담은 새 커밋을 추가하는 방식이라 이력이 그대로 남습니다. “문제가 생겼고, 되돌렸다”는 기록이 남는 것과, 이력 자체가 사라지는 것은 팀 신뢰도 측면에서 완전히 다릅니다.
reflog: 저도 이걸로 살아난 적이 있습니다
저도 예전에 git reset --hard를 실행하다가 최근 커밋이 아니라 이틀치 작업이 담긴 브랜치 전체를 날려버린 적이 있습니다. 그때 살려준 게 git reflog였어요. git log는 현재 이력에서 보이는 커밋만 보여주지만, reflog는 HEAD가 최근에 가리켰던 위치를 전부 기록해둡니다. 사라진 것처럼 보였던 커밋 해시를 reflog에서 찾아 git branch rescue 커밋해시로 새 브랜치를 만들면 안전하게 복구할 수 있습니다.
이 명령어, 지금 우리 팀에 필요한지 판단 체크리스트
- 같은 브랜치에서 2명 이상이 동시에 작업하는가 → merge·rebase 컨벤션부터 팀에서 정하기
- 강제 push를 쓸 일이 있는가 → –force 대신 –force-with-lease를 기본값으로
- PR 리뷰 전 커밋이 지저분한 편인가 → rebase -i로 정리하는 습관 들이기
- 운영 중인 배포 브랜치를 다루는가 → 되돌릴 땐 reset이 아니라 revert
- 실수로 브랜치를 날린 경험이 있는가 → reflog 사용법 미리 익혀두기
이 다섯 가지 중 두세 개 이상 해당한다면, 오늘 소개한 명령어들을 팀 온보딩 문서에 정리해두는 걸 추천합니다. 신입이 실수하기 전에 미리 알려주는 것과, 사고가 난 뒤에 알려주는 것은 팀 분위기에서 꽤 큰 차이를 만듭니다.
관련 글
git 명령어를 더 깊이 알고 싶다면 아래 글도 함께 참고해보세요.
- 장애 상황에서 바로 써야 하는 명령어가 궁금하다면 git 명령어 8가지, 장애 복구할 때 시니어와 신입이 갈립니다를 확인해보세요.
- 코드 리뷰에서 이력 관리가 어떻게 평가받는지는 코드 리뷰에서 티 나는 git 명령어 10가지, 신입과 시니어의 차이에서 다뤘습니다.
- 사고 복구 명령어를 더 자세히 보고 싶다면 Git 복구 명령어 5가지, 사고 났을 때 시니어가 먼저 찾는 이유도 참고하세요.
📌 함께 보시면 좋은 글
이직·퇴사·연봉 협상을 혼자 판단하기 어렵다면
1:1 개발자 커리어 상담 신청하기 →
※ 본 글은 AI(Claude)의 초안을 기반으로 편집자 검수를 거쳐 발행되었습니다. (한국 AI기본법 대응 고지)
이직·퇴사, 지금 움직여도 될지 헷갈리시나요?
막연히 불안한 건지, 정말 시점이 온 건지 판단이 어려울 때가 있습니다.
5분 체크리스트로 지금 상태를 먼저 정리해보세요.
결론을 대신 내리기보다, 스스로 판단할 기준을 잡는 데 도움을 드립니다.
아직 확신이 없다면, 지금이 ‘고민 단계’인지부터 먼저 점검해보세요