Git Rebase vs Merge

Overview

Git에서 협업 시 자주 사용하는 Merge와 Rebase는 모두 브랜치 간의 변경 사항을 통합하는 역할을 하지만, 프로젝트 히스토리 관리 방식에서 큰 차이점이 있다.

• Merge는 여러 브랜치의 작업 내역을 하나의 공통 커밋(Merge Commit)으로 통합하며, 비선형 히스토리(non-linear history) 를 만들어 작업 흐름을 명확히 보존한다.
• Rebase는 한 브랜치의 커밋을 다른 브랜치의 최신 커밋 이후로 재적용(replay) 하며, 선형 히스토리(linear history) 를 유지하는 데 유용하다.

 

또한, 충돌 상황에서 자주 마주치는 ours와 theirs 개념은 Merge와 Rebase 상황에서 의미가 다르므로 주의가 필요하다.
특히 Rebase에서는 많은 혼동을 야기할 수 있으므로, 개념을 정확히 파악하고 사용하는 것이 중요하다.

 

 

이 글은 이러한 개념들의 실제 사례와 함께, 대화형 Rebase 시 사용할 수 있는 커맨드들, 그리고 상황에 따라 적절히 선택해야 할 전략을 안내하고 있다. 협업 중 히스토리를 깔끔하게 유지하거나, 브랜치 병합 중 충돌을 해결할 때 많은 도움이 된다.

 

 

 

 

 

 

 

 

 

 

 

---

 

 

 

 

Git Rebase

Rebase는 Feature Branch에서 Another Branch(typically the main branch)의 베이스로 Commit을 이동하거나 "replaying"함으로써 한 Branch에서 다른 Branch로 변경 사항을 통합하는 데 사용되는 강력한 Git 기능이다. Rebase의 주요 목표는 선형 프로젝트 히스토리(linear project history)를 만드는 것이다.

​

 

 

 

 

 

Functions in Rebase

대화형 Rebase(`git rebase -i`)를 수행하는 동안 사용할 수 있는 몇 가지 일반적인 기능은 다음과 같다.

• pick: 수정 없이 Commit을 그대로 사용
• reword: Commit을 사용하되 Commit 메시지를 변경
• edit: 어떤 방식으로든 Commit을 수정할 수 있도록 이 Commit에서 Rebase를 일시 중지(code changes, splitting the commit, further amends).
• squash: 이 Commit을 이전 Commit과 결합하고 새 커밋 메시지를 제공하라는 메시지를 표시
• fixup: squash와 유사하지만 이전 Commit의 메시지를 유지하고 이 Commit의 로그 메시지를 삭제
• drop: 기록에서 Commit을 완전히 제거

 

 

 

 

 

Git Merge

Merge는 Merge된 Branch의 변경 사항을 결합한 새로운 "Merge Commit"을 생성하여 한 Branch의 변경 사항을 다른 Branch로 통합하는 데 사용된다. (non-linear history)

 

​

 

 

 

 

 

Understanding `ours` and `theirs` in Git

Git의 충돌을 해결할 때, 특히 Merge 및 Rebase 작업 중에 ours와 theirs 서로 다른 지점의 변경 사항을 참조할 수 있는 방법을 제공한다.

 

 

작업 유형 (Operation)	ours (우리 것)	theirs (상대 것)	설명 (Description)
Merge (병합)	현재 브랜치의 변경 사항	병합하려는 브랜치의 변경 사항	병합 시 ours는 현재 내가 있는 브랜치(병합 대상 브랜치)를 의미하고, theirs는 병합하려는 브랜치를 의미한다. 충돌 발생 시 어떤 변경 사항을 우선시할지 결정하는 데 사용된다.
Rebase (리베이스)	리베이스 하려는 브랜치의 변경 사항	리베이스 대상 브랜치의 변경 사항	리베이스 시에는 ours와 theirs의 의미가 Merge와 반대가 된다. ours는 리베이스를 시도하는 원래 브랜치이고, theirs는 새로운 기준이 되는 브랜치를 뜻한다. 이 개념의 전환은 혼란을 줄 수 있어 주의가 필요하다.

 

 

 

In Merge

• ours: 현재 있는 Branch를 말하며, 이는 다른 Branch가 Merge되는 대상 Branch이다. feature를 main에 Merge하고 main Branch에 있는 경우 ours는 main Branch의 변경 사항을 나타낸다.
• theirs: 대상 Branch에 Merge되는 Branch를 나타낸다. 위의 예를 들어 게속 설명하면 theirs는 feature Branch의 변경 사항을 나타낸다.

 

 

 

 

 

 

In Rebase

• ours: 상황에 따라 변경된다. Rebase 중에 ours는 다른 Branch로 Rebase되는 Branch의 변경 사항을 나타낸다. feature를 main으로 Rebase하는 경우 충돌이 발생하면 ours는 원래 feature에 있던 것을 참조한다.
• theirs: Rebase의 맥락에서 theirs는 Rebase하는 Branch에 대한 새 기반을 제공하는 Branch를 나타낸다. feature를 main으로 Rebase하는 경우 theirs는 Rebase가 적용되는 지점에서 main Branch의 변경 사항을 나타낸다.

 

 

 

 

 

 

 

Practical Usage

• Merge 시나리오: 두 개의 Branch를 Merge하고 충돌이 발생하면 우선순위를 지정하려는 Branch의 관점(target or incoming)에 따라 ours 또는 theirs 해결 방법을 선택할 수 있다.
• Rebase 시나리오: Rebase 중에 ours 와 theirs 중에서 선택하는 것은 변경 사항 및 기본 컨텍스트에 따라 역할이 전환되기 때문에 좀 더 혼란스러울 수 있다. ours는 (현재) Rebase되는 Branch이고, theirs는 (충돌시킨) Branch이다.

 

 

 

 

Popular Commands in Merge vs. Rebase

• Merge는 빨리 fast-forward merge이 가능한 경우에도 Merge Commit을 생성하기 위해 `--no-ff`(no fast forward)와 같은 옵션과 함께 자주 사용되어 기능 분기의 과거 존재에 대한 정보를 보존한다.
• Rebase는 일련의 변경 사항을 기본 프로젝트 분기에 병합하기 전에 정리하기 위해 `--interactive` 와 함께 자주 사용된다.

 

 

 

 

 

---

 

 

 

마무리

Git에서 Rebase와 Merge는 각각의 목적과 장점을 가진 중요한 브랜치 통합 도구이다.

Merge는 브랜치 간의 변경 사항을 안전하게 유지하며 기록을 남기고, Rebase는 깔끔하고 선형적인 커밋 히스토리를 유지하는 데 효과적이다.

 

그러나 이 두 방법은 충돌 발생 시 ours와 theirs의 의미가 서로 다르게 해석되기 때문에 혼란을 초래할 수 있다.
따라서 작업 전 충분한 이해를 바탕으로 신중하게 선택하고 사용하는 것이 중요하다.

 

팀 협업에서 커밋 히스토리를 어떻게 관리할지, 어떤 전략이 더 나은지에 대한 논의는 필수이며, 상황에 따라 Rebase 또는 Merge 중 적절한 방법을 선택하는 유연함이 필요하다.

 

 

궁극적으로 중요한 것은 기록의 일관성과 협업의 효율성이다.
정리를 잘 해두면 나중에 히스토리를 추적하고 디버깅하는 데 큰 도움이 된다.

 

 

 

 

 

 

 

---

Reference

https://git-scm.com/book/ko/v2/Git-브랜치-Rebase-하기

https://seosh817.tistory.com/240

https://nitaym.github.io/ourstheirs/

https://wonyong-jang.github.io/git/2021/02/05/Github-Rebase.html