전체 목록
GitMedium#266

merge와 rebase의 차이점을 설명해주세요.

#Git#merge#rebase#히스토리

답변 포인트

히스토리 보존과 재작성를 기준으로 정의, 장점, 한계, 예시를 함께 설명해보세요.

정답 및 해설

빠른 요약

merge는 히스토리를 보존하며 병합 커밋을 만들 수 있고, rebase는 커밋을 새 기준 위에 다시 적용해 선형 히스토리를 만듭니다. 공유 브랜치 rebase는 주의가 필요합니다.

merge는 히스토리를 보존하며 병합 커밋을 만들 수 있고, rebase는 커밋을 새 기준 위에 다시 적용해 선형 히스토리를 만듭니다. 공유 브랜치 rebase는 주의가 필요합니다.

핵심 개념

핵심 기준은 히스토리 보존과 재작성입니다.

merge는 두 브랜치의 이력을 그대로 연결하고, rebase는 내 커밋을 새 기준점 위에 다시 쌓아 커밋 해시를 바꿉니다. merge는 협업 맥락을 남기기 좋고, rebase는 아직 공유하지 않은 작업 브랜치를 깔끔하게 정리할 때 유용합니다.

동작 흐름

  1. 현재 브랜치의 상태와 변경 범위를 먼저 확인합니다.
  2. 명령이 히스토리, 브랜치 포인터, 작업 디렉터리 중 무엇을 바꾸는지 구분합니다.
  3. 공유 브랜치에 영향을 주는 작업인지 확인합니다.
  4. 실행 후 git statusgit log --oneline --graph로 결과를 검증합니다.

실제 예시

Bash
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는 주의가 필요합니다. 개념의 정의뿐 아니라 적용 조건과 실패했을 때의 증상까지 함께 이해하는 것이 중요합니다.

관련 질문

같은 카테고리/태그 기준