merge와 rebase, 둘 다 브랜치를 합치는 명령어인데 왜 팀마다 쓰는 규칙이 다를까요? 최근 dev.to에 올라온 10 Git Commands You’ll Wish You Knew Earlier라는 글이 개발자 커뮤니티에서 꽤 화제였습니다. add·commit·push는 이미 몸에 익었지만, 그 다음 단계에서 헤매는 개발자가 여전히 많다는 뜻이겠죠.
이 글은 원문이 소개한 중급 명령어 10가지를 국내 실무 상황에 맞게 재구성했습니다. 단순히 ‘이 명령어는 이런 뜻이다’로 끝내지 않고, 왜 이 명령어를 어떻게 쓰느냐가 팀 안에서 후배님의 평판과 신뢰로 이어지는지까지 함께 짚어보겠습니다.
1. 머지 vs 리베이스 — 팀 히스토리를 대하는 태도의 차이
feature 브랜치에서 작업하는 동안 main에 새 커밋이 쌓였다고 가정해봅시다. 이걸 내 브랜치로 가져오는 방법은 크게 두 가지입니다.
머지, 있는 그대로 남기기
git merge main을 실행하면 두 히스토리를 합치는 병합 커밋이 하나 생깁니다. 브랜치가 언제 갈라졌고 언제 다시 만났는지가 그대로 남아서, 나중에 사고가 났을 때 원인을 추적하기 좋습니다. 다만 merge를 반복하면 히스토리가 그물처럼 얽혀서 git log가 지저분해진다는 단점이 있어요.
리베이스, 깔끔하지만 위험한 재작성
git rebase main은 내 커밋들을 최신 main 위로 옮겨 붙입니다. 히스토리가 일직선으로 깔끔해지지만, 이때 만들어지는 커밋은 원본과 해시가 다른 새 커밋입니다. 즉 리베이스는 히스토리를 다시 쓰는 작업이라는 뜻이죠. 그래서 실무에서 통하는 규칙은 단순합니다. 아직 나만 보고 있는 브랜치라면 리베이스해도 괜찮지만, 동료가 이미 그 커밋을 기준으로 작업을 시작했다면 리베이스는 신중해야 합니다.
충돌 대응, 그리고 탈출 버튼 –abort
merge든 rebase든 충돌은 날 수 있습니다. merge는 한 번에 충돌을 해결하고 git merge --continue로 마무리하면 되지만, rebase는 커밋 단위로 하나씩 충돌이 올라오기 때문에 체감 난이도가 더 높습니다. 상황이 너무 꼬였다면 git merge --abort 또는 git rebase --abort로 시작 전 상태로 되돌릴 수 있다는 것만 기억해도 패닉할 이유가 줄어듭니다.
2. 커밋을 다듬는 명령어 3가지 — amend, rebase -i, stash
commit –amend, 방금 저지른 실수 수정
커밋을 올리자마자 디버그용 콘솔 로그를 지우는 걸 깜빡했다는 걸 발견한 적 있으실 거예요. 새 커밋을 또 쌓는 대신 git commit --amend --no-edit로 직전 커밋에 합쳐버리면 히스토리가 훨씬 깔끔합니다. 단, amend도 결국 새로운 커밋을 만드는 작업이라 이미 원격에 푸시된 브랜치에서 쓰면 강제 푸시가 필요해진다는 점은 알아둬야 합니다.
rebase -i, pick·squash·fixup으로 히스토리 정리
git rebase -i HEAD~5로 최근 커밋 5개를 열어보면 pick, reword, squash, fixup, drop 같은 옵션이 보입니다. squash는 이전 커밋과 합치면서 메시지도 새로 쓰고, fixup은 합치되 메시지는 버립니다. “Fix typo”, “Fix typo again” 같은 커밋이 리뷰어 눈에 그대로 노출되는 걸 막아주는 도구라고 보면 됩니다.
stash, 급한 불부터 끄기
기능 개발 중간에 운영 장애 알림이 오면 지금 하던 작업을 커밋하지 않고도 잠시 치워둘 수 있습니다. git stash push -u -m "WIP 로그인 기능"처럼 이름을 붙여두면, 나중에 stash가 여러 개 쌓였을 때 어떤 게 뭔지 몰라 헤매는 상황을 피할 수 있어요.
3. 힘 조절이 필요한 명령어 — force-with-lease와 cherry-pick
리베이스나 amend로 히스토리를 바꾼 뒤 git push를 하면 non-fast-forward 오류가 납니다. 여기서 git push --force를 쓰면 원격 브랜치를 무조건 내 버전으로 덮어씁니다. 그사이 동료가 뭔가를 push했다면 그 작업이 통째로 사라질 수 있어요.
그래서 Git 공식 문서도 --force-with-lease를 대안으로 안내합니다. 내가 마지막으로 알고 있던 원격 상태와 실제 원격 상태가 같을 때만 강제 푸시를 허용하고, 다르면 거부합니다. cherry-pick도 비슷하게 절제가 필요한 명령어입니다. 다른 브랜치의 커밋 하나만 딱 가져오고 싶을 때 git cherry-pick <커밋해시>를 쓰는데, 브랜치 전체를 머지하거나 리베이스하는 것보다 영향 범위가 훨씬 좁다는 게 장점입니다.
같은 명령어라도 –force 대신 –force-with-lease를 습관적으로 쓰는 사람인지가, 저는 그 사람의 협업 감각을 판단하는 기준 중 하나라고 생각합니다.
4. 되돌리기의 3단계 — reset, reflog, revert
git reset은 세 가지 강도로 나뉩니다. --soft는 커밋만 되돌리고 변경 내용은 스테이징 상태로 남기고, --mixed(기본값)는 스테이징까지 풀어주고, --hard는 작업 디렉터리 파일까지 되돌립니다. 세 번째가 제일 위험한 이유는 명확하죠. 파일 자체가 사라지니까요.
혹시 reset --hard를 잘못 눌러서 며칠치 작업이 날아간 것처럼 보여도 아직 희망은 있습니다. git reflog는 HEAD가 최근에 가리켰던 위치를 순서대로 보여주는데, 여기서 사라진 것처럼 보이던 커밋 해시를 찾아 git branch rescue <해시>로 임시 브랜치를 만들어두면 침착하게 상황을 복구할 수 있습니다.
이미 배포된 브랜치라면 이야기가 다릅니다. reset으로 히스토리를 되돌리고 강제 푸시하는 대신 git revert <커밋해시>로 그 커밋의 변경분을 되돌리는 새 커밋을 하나 더 쌓는 편이 안전합니다. 무슨 일이 있었고 왜 되돌렸는지가 히스토리에 그대로 남아서, 함께 작업하는 팀원 입장에서도 상황 파악이 쉬워집니다.
5. 이 명령어들이 실무에서 신뢰를 만드는 이유
여기까지 읽으면서 ‘이걸 다 언제 외우나’ 싶으셨다면, 후배님만 그런 게 아니니 안심하셔도 돼요. 실무에서 중요한 건 명령어 문법을 암기하는 게 아니라, 지금 상황에 어떤 도구가 안전한지 판단하는 감각입니다.
예를 들어 리베이스로 히스토리를 깔끔하게 정리해서 올리는 주니어와, 공유 브랜치에 무심코 --force를 날려 동료 커밋을 날려버리는 주니어는 코드 실력과 무관하게 완전히 다른 평판을 얻습니다. 저도 예전에 팀원이 이미 작업 중이던 브랜치에 무심코 강제 푸시를 했다가, 그날 오후 내내 사라진 커밋을 reflog로 복구해준 경험이 있습니다. 그 뒤로 우리 팀은 공유 브랜치에서는 –force 자체를 금지하고 –force-with-lease만 쓰기로 규칙을 정했어요.
결국 이 명령어들을 안다는 건 코드 리뷰에서 ‘이 사람은 자기 작업이 남에게 어떤 영향을 주는지 생각하고 커밋한다’는 신호를 준다는 뜻이에요. 그게 쌓여서 시니어로 넘어갈 때 필요한 신뢰가 만들어집니다.
6. 국내 개발자 채용에서 Git 이해도를 보는 이유
Stack Overflow Developer Survey는 여러 해에 걸쳐 Git을 압도적으로 가장 널리 쓰이는 버전 관리 도구로 꼽아 왔습니다. 국내 채용 공고에도 ‘협업 도구 활용 능력’이나 ‘코드 리뷰 문화 이해’가 자주 등장하는데, 실제 기술 면접에서는 이 능력을 확인하는 가장 손쉬운 방법이 Git 시나리오 질문이에요.
“공유 브랜치에서 실수로 커밋을 지웠다면 어떻게 복구하시겠어요?”나 “머지와 리베이스 중 언제 뭘 쓰시나요?” 같은 질문은 실제로 국내 스타트업·중견 기업 면접에서 흔히 나오는 유형입니다. 정답이 하나로 정해진 질문이 아니라, 후배님이 상황을 어떻게 판단하는지를 보려는 질문이라는 걸 알면 답변 방향을 잡기가 훨씬 쉬워져요.
판단 체크리스트 — 이 명령어, 언제 써야 할까
- 혼자 작업 중인 브랜치인가요? → 리베이스·amend로 히스토리를 자유롭게 정리해도 괜찮습니다.
- 이미 동료가 기준으로 삼은 공유 브랜치인가요? → 리베이스 대신 머지, 강제 푸시가 필요하면 –force-with-lease만 사용하세요.
- 배포된 브랜치에서 문제가 생겼나요? → reset보다 revert로 안전하게 되돌리세요.
- 뭔가 사라진 것 같은데 원인을 모르겠나요? → 당황하기 전에 git reflog부터 확인하세요.
- 다른 브랜치의 커밋 하나만 필요한가요? → 전체 머지 대신 cherry-pick으로 영향 범위를 좁히세요.
관련 글
이번 글에서 다룬 명령어를 팀 협업 습관으로 더 넓혀보고 싶다면 아래 글도 함께 읽어보시길 권합니다.
- 공유 브랜치에서 지켜야 할 기본 습관이 궁금하다면 실무 git 명령어 10가지, 몰랐으면 협업에서 손해봅니다를 참고하세요.
- 장애 상황에서 침착하게 복구하는 방법은 git 명령어 8가지, 장애 복구할 때 시니어와 신입이 갈립니다에 더 자세히 정리되어 있습니다.
- 코드 리뷰에서 실력이 드러나는 습관이 궁금하다면 코드 리뷰에서 티 나는 git 명령어 10가지, 신입과 시니어의 차이도 함께 보시면 좋습니다.
📌 함께 보시면 좋은 글
이직·퇴사·연봉 협상을 혼자 판단하기 어렵다면
1:1 개발자 커리어 상담 신청하기 →
※ 본 글은 AI(Claude)의 초안을 기반으로 편집자 검수를 거쳐 발행되었습니다. (한국 AI기본법 대응 고지)
이직·퇴사, 지금 움직여도 될지 헷갈리시나요?
막연히 불안한 건지, 정말 시점이 온 건지 판단이 어려울 때가 있습니다.
5분 체크리스트로 지금 상태를 먼저 정리해보세요.
결론을 대신 내리기보다, 스스로 판단할 기준을 잡는 데 도움을 드립니다.
아직 확신이 없다면, 지금이 ‘고민 단계’인지부터 먼저 점검해보세요