git rebase와 merge 차이는 단순히 명령어 옵션 차이가 아닙니다. 둘 다 변경을 합치지만, 프로젝트의 커밋 히스토리를 어떻게 남길지에 대한 선택입니다.
핵심은 공유된 기록을 보존할지, 내 작업 기록을 새 기준 위에 정리할지입니다. 이 글은 Git 공식 문서를 기준으로 merge, rebase, conflict, shared branch 주의점을 정리합니다.
git rebase와 merge 차이를 히스토리 관점에서 보자
merge와 rebase는 모두 한 브랜치의 변경을 다른 브랜치에 반영합니다. 차이는 결과 히스토리입니다. merge는 두 흐름이 합쳐졌다는 사실을 남기고, rebase는 내 커밋들이 최신 기준에서 시작한 것처럼 다시 배치합니다.
git switch feature
git merge main
git switch feature
git rebase main두 명령 모두 feature 브랜치에 main의 변경을 반영할 수 있습니다. 하지만 협업에서 보이는 커밋 그래프는 다르게 남습니다.
merge는 합류 지점을 남긴다
merge는 두 브랜치의 공통 조상 이후 변경을 합칩니다. fast-forward가 불가능하면 merge commit이 생길 수 있습니다. 이 커밋은 ‘이 시점에 두 작업 흐름이 합쳐졌다’는 기록입니다.
- 작업 흐름의 합류 기록이 남는다
- 이미 공유된 브랜치에서도 비교적 안전하다
- 히스토리가 복잡해 보일 수 있다
rebase는 내 커밋을 다시 쌓는다
rebase는 내 브랜치의 커밋을 떼어낸 뒤 새로운 base 위에 다시 적용합니다. 그래서 히스토리가 직선처럼 깔끔해 보입니다.
git switch feature
git fetch origin
git rebase origin/mainPR을 올리기 전 내 feature 브랜치를 최신 main 위로 정리할 때 유용합니다. 다만 커밋 해시가 바뀌므로 이미 동료가 기반으로 삼은 커밋에는 조심해야 합니다.
rebase는 히스토리를 다시 쓰는 작업입니다. 내 로컬 브랜치 안에서만 쓰면 괜찮지만, 이미 원격에 올렸고 다른 사람이 그 커밋을 기준으로 작업했다면 문제가 복잡해집니다.
동료 입장에서는 같은 변경처럼 보이는 다른 커밋이 생기고, pull 과정에서 중복 커밋이나 복잡한 conflict를 만날 수 있습니다.
- 내가 혼자 쓰는 feature 브랜치: rebase 사용 가능
- 팀원이 함께 push하는 shared branch: rebase를 매우 신중하게 사용
- main, develop 같은 보호 브랜치: 일반적으로 rebase 대상으로 두지 않음
PR 전에는 무엇을 고르면 좋을까
- 내 feature 브랜치가 혼자 쓰는 브랜치인지 먼저 확인한다
- 혼자 쓰는 브랜치라면 rebase로 최신 main 위에 정리할 수 있다
- 이미 공유된 커밋이라면 merge가 더 안전한 경우가 많다
- conflict는 한 번에 몰아 해결하기보다 작은 커밋 단위로 이해한다
- 팀의 Git 정책이 있으면 개인 취향보다 팀 규칙을 따른다
정리
git rebase를 이해할 때는 명령어나 패턴 이름만 외우기보다 그 도구가 해결하려는 경계를 먼저 보는 편이 좋습니다. 오늘 글의 기준은 화면과 데이터, 실행과 import, 정상 흐름과 오류 흐름, 정합성과 동시성, 개인 브랜치와 공유 브랜치를 나눠 보는 것입니다.
함께 보면 좋은 내부 글은 Java Stream은 for문보다 항상 좋을까, Spring Boot profile은 언제 나눠야 할까, C 언어 헤더 파일은 왜 나눌까입니다. 외부 기준은 Git Docs – git-merge, Git Docs – git-rebase, Pro Git – Rebasing를 확인했습니다.
