[Git] Git에서 rebase vs merge 차이 알아보기

개요

나는 그동안 develop이나 master 브랜치로 작업 내용을 합칠 때, merge를 사용했다.

Pull Request에 올리면 자연스럽게 master 브랜치로 merge가 되기도 한다.

그런데 오늘. Git 히스토리가 너무 꼬여 정리를 하고 있었고,

협업에서 같이 일하는 선배는 rebase를 사용하길래 문득 그 차이가 궁금해졌다.

 

* git rebase와 git merge는 두 가지 모두 Git에서 브랜치를 통합하는 데 사용되는 명령어이다.

---

git merge

• 목적 두 브랜치를 하나의 공통 커밋 히스토리로 병합.
• 작동 방식
  • 병합 시, 새로운 커밋(merge commit)이 생성됨
  • 두 브랜치의 히스토리를 합치는 역할을 하며, 히스토리가 그대로 보존
• 장점
  • 기존의 모든 커밋 히스토리를 보존하므로, 브랜치의 개발 과정을 명확하게 추적 가능
  • 충돌이 발생하면 충돌 해결 후 다시 병합 가능
• 단점
  • 브랜치가 많아지면, 커밋 히스토리가 복잡해짐

현재 우리 회사 소스 같은 경우는 지하철 5호선까지 만들어진 상태…

대체 라인이 몇개인지 ㅠㅠ

# feature 브랜치를 main 브랜치로 병합
git checkout main
git merge feature

---

git rebase

• 목적 브랜치의 커밋을 다른 베이스(기준) 위로 재배치.
• 작동 방식
  • 커밋들을 현재 브랜치의 베이스 위로 하나씩 적용하여 새로운 커밋 히스토리를 만듦
  • 병합 커밋이 생성되지 않음
• 장점
  • 히스토리가 깔끔하게 유지되며, 브랜치가 한 줄로 이어짐
  • 프로젝트 히스토리가 더 직관적이고 단순해짐
• 단점
  • 이미 공유된 히스토리를 rebase하면 다른 사용자와 충돌 발생 가능
  • 충돌 해결이 필요할 경우, 커밋 하나하나마다 충돌을 해결해야 함.

오늘 나도 같은 현상을 경험했다 …ㅎ;;

결국 merge로 해결함

# feature 브랜치를 main 브랜치 위로 재배치
git checkout feature
git rebase main

---

주요 차이점

• 히스토리: merge는 병합 커밋을 생성하여 두 브랜치의 히스토리를 모두 보존하지만, rebase는 하나의 직선형 히스토리를 만든다.
• 충돌 해결: merge는 한 번의 충돌 해결로 병합이 가능하지만, rebase는 각 커밋마다 충돌을 해결해야 할 수 있다.
• 용도: merge는 팀 협업에서 각 브랜치의 히스토리를 보존하고자 할 때 유용하며, rebase는 히스토리를 깔끔하게 유지하고자 할 때 유용하다.

---

언제 사용해야 할까?

• git merge: 협업 브랜치를 병합할 때, 다른 사람의 히스토리를 보존해야 할 때.
• git rebase: 깔끔한 커밋 히스토리가 필요할 때, 개인 브랜치에서 작업한 후 메인 브랜치에 통합할 때.

이 두 명령은 각각의 장단점이 있으므로 상황에 맞게 적절하게 사용하면 좋을 것 같다.

rebase는 줄기가 하나로 합쳐져 history를 볼 때 편하긴 하지만, 협업 과정에서 충돌을 피하기 어려울 것 같다.

충돌 해결이 쉽고, 히스토리 추적이 쉬운 merge가 더 안전한 느낌이다.