merge와 rebase의 차이점을 설명해주세요.
답변 포인트
히스토리 보존과 재작성를 기준으로 정의, 장점, 한계, 예시를 함께 설명해보세요.
정답 및 해설
빠른 요약
merge는 히스토리를 보존하며 병합 커밋을 만들 수 있고, rebase는 커밋을 새 기준 위에 다시 적용해 선형 히스토리를 만듭니다. 공유 브랜치 rebase는 주의가 필요합니다.
merge는 히스토리를 보존하며 병합 커밋을 만들 수 있고, rebase는 커밋을 새 기준 위에 다시 적용해 선형 히스토리를 만듭니다. 공유 브랜치 rebase는 주의가 필요합니다.
핵심 개념
핵심 기준은 히스토리 보존과 재작성입니다.
merge는 두 브랜치의 이력을 그대로 연결하고, rebase는 내 커밋을 새 기준점 위에 다시 쌓아 커밋 해시를 바꿉니다. merge는 협업 맥락을 남기기 좋고, rebase는 아직 공유하지 않은 작업 브랜치를 깔끔하게 정리할 때 유용합니다.
동작 흐름
- 현재 브랜치의 상태와 변경 범위를 먼저 확인합니다.
- 명령이 히스토리, 브랜치 포인터, 작업 디렉터리 중 무엇을 바꾸는지 구분합니다.
- 공유 브랜치에 영향을 주는 작업인지 확인합니다.
- 실행 후
git status와git log --oneline --graph로 결과를 검증합니다.
실제 예시
git switch main && git merge feature/search
git switch feature/search
git fetch origin
git rebase origin/main예시는 핵심 흐름을 단순화한 것입니다. 실무에서는 팀의 배포 방식, 데이터 크기, 장애 영향도, 유지보수 비용까지 함께 고려해야 합니다.
실무에서 주의할 점
- 공유된 히스토리를 재작성하면 동료의 로컬 작업과 충돌할 수 있습니다.
- 충돌 해결은 한쪽 선택이 아니라 양쪽 변경 의도를 통합하는 과정입니다.
- 위험한 작업 전에는 임시 브랜치나 태그로 복구 지점을 남기면 안전합니다.
함께 연결해서 보면 좋은 키워드
Git, merge, rebase, history
정리
한 줄로 정리하면, merge는 히스토리를 보존하며 병합 커밋을 만들 수 있고, rebase는 커밋을 새 기준 위에 다시 적용해 선형 히스토리를 만듭니다. 공유 브랜치 rebase는 주의가 필요합니다. 개념의 정의뿐 아니라 적용 조건과 실패했을 때의 증상까지 함께 이해하는 것이 중요합니다.