Git Rebase: 언제 어떻게 사용해야 할까?

studylida 2025. 3. 12. 10:17

리베이스가 어려운 이유, 정말 그럴까?

Git을 배우다 보면 rebase라는 명령어를 접하게 됩니다. 그런데, 이 명령어에 대한 개발자들의 반응은 극과 극입니다.
어떤 회사에서는 “반드시 rebase를 활용하라”고 강조하는 반면, 어떤 팀은 “절대 rebase를 쓰지 말라”고 말하죠.

도대체 왜 이렇게 의견이 나뉘는 걸까요? 리베이스는 정말 어려운 개념일까요?

🤔 왜 리베이스가 어려운 개념처럼 느껴질까?

강의를 진행한 경험이 있는 개발자는 처음 Git을 배울 때, 스승으로부터 “리베이스는 절대 하지 마라”는 조언을 들었다고 합니다.
리베이스는 초보자가 건드리기엔 너무 위험한 기능이므로, 굳이 배울 필요가 없다는 것이 그 이유였습니다.

“나나 팀원들이 곤란해질 수 있기 때문이라 하면서, 초보자는 몰라도 된다 했어요.”

이 말이 완전히 틀린 것은 아닙니다. 리베이스는 Git의 히스토리를 변경하는 기능이기 때문에, 잘못 사용하면 협업 중인 동료들에게 큰 혼란을 줄 수도 있습니다.
하지만, 리베이스 자체가 어려운 개념은 아닙니다. 단지, 언제 사용해야 하는지, 언제 사용하면 안 되는지를 아는 것이 중요할 뿐이죠.

🔄 리베이스와 머지의 차이: 왜 리베이스를 쓰는가?

리베이스를 둘러싼 논쟁은, 결국 Git의 두 가지 병합 방법에서 비롯됩니다.

Git Merge
- 브랜치를 병합할 때, 기존 커밋을 유지하면서 새로운 병합 커밋을 생성합니다.
- 커밋 히스토리를 보존하지만, 때때로 불필요한 병합 커밋이 많아질 수 있습니다.
Git Rebase
- 병합 과정에서 불필요한 커밋을 제거하고, 더 깔끔한 히스토리를 유지합니다.
- 하지만, 히스토리를 재작성하기 때문에 협업 중에는 신중히 사용해야 합니다.

💡 비유로 이해해보자!
리베이스와 머지를 책상 정리에 비유해 볼 수 있습니다.

머지 방식은 새로 생긴 파일을 그대로 책상 위에 쌓아두는 것과 같습니다.
리베이스 방식은 새로운 파일들을 기존 파일들 사이에 정리해 넣어, 더 깔끔한 배열을 만드는 것과 같습니다.

어떤 방식을 사용할지는 개인의 스타일과 프로젝트의 요구 사항에 따라 다릅니다.

🔥 리베이스, 꼭 알아야 할까?

리베이스를 몰라도 Git을 사용하는 데는 큰 문제가 없습니다.
실제로 강의자는 "리베이스를 몰라도 수년간 Git을 사용하며 문제없이 개발을 해왔다"고 말합니다.

하지만 최근에는 Git Rebase를 적극적으로 활용하는 개발자들이 늘어나고 있는 추세입니다.
리베이스를 사용하면 커밋 히스토리를 깔끔하게 유지할 수 있기 때문이죠.

결국, 리베이스는 반드시 배워야 하는 개념은 아니지만, 알고 있으면 분명 유용한 기능입니다.

🔄 병합과 리베이스 비교하기: 당신의 선택은?

Git에서 브랜치를 병합하는 방법에는 크게 Merge(머지)와 Rebase(리베이스) 두 가지가 있습니다.
둘 다 같은 목적을 가지고 있지만, 방식과 결과가 크게 다릅니다.

이제 "왜 머지와 리베이스 중 하나를 선택해야 하는가?"에 대해 알아보겠습니다.

🏗️ 머지(Merge): 간단하지만 히스토리가 지저분해진다

머지는 브랜치를 병합할 때 가장 많이 사용하는 방식입니다.
특징은 단순 명료합니다.

한 브랜치의 변경 사항을 다른 브랜치로 합칠 때, 새로운 병합 커밋(Merge Commit)이 생깁니다.
기존 히스토리는 그대로 유지되며, 병합된 브랜치의 변경 사항이 반영됩니다.

💡 예제 상황

master 브랜치에서 feature 브랜치를 만들어 개발을 시작합니다.
feature 브랜치에서 몇 개의 커밋을 쌓았습니다.
그 사이에 다른 팀원이 master 브랜치에 새로운 기능을 추가했습니다.
feature 브랜치가 최신 master 브랜치 내용을 반영하려면 어떻게 해야 할까요?
- 머지를 사용하면?
```
git checkout feature
git merge master
```
- 새로운 병합 커밋이 생성됩니다.
- 이후에도 master 브랜치에 변경 사항이 생길 때마다 feature 브랜치에서 반복적으로 머지해야 합니다.
- 결국, 머지 커밋이 쌓여 히스토리가 복잡해집니다.

📌 머지의 문제점
✅ 충돌이 발생하면 해결 후 그대로 반영 가능
✅ 초보자도 쉽게 사용할 수 있음
❌ 머지 커밋이 계속 쌓이며 히스토리가 지저분해짐
❌ 같은 작업을 반복할 경우, 이력 분석이 어려워짐

🔄 리베이스(Rebase): 깔끔한 히스토리를 위한 선택

리베이스는 히스토리를 새롭게 정리하는 방법입니다.
머지와 달리 새로운 병합 커밋을 만들지 않고, feature 브랜치의 커밋을 master 브랜치의 최신 상태에 맞게 "다시 쌓는" 방식입니다.

💡 예제 상황 (위 머지 예제와 동일)

feature 브랜치에서 몇 개의 커밋을 했고, master에는 새로운 변경 사항이 추가됨
feature 브랜치를 최신 master 상태에 맞추려면?
- 리베이스를 사용하면?
```
git checkout feature
git rebase master
```
- 기존 feature 브랜치의 커밋들이 새롭게 재배치(rebase)됩니다.
- 결과적으로 불필요한 머지 커밋 없이, 마치 처음부터 master에서 작업한 것처럼 깔끔한 히스토리가 완성됩니다.

📌 리베이스의 장점
✅ 불필요한 머지 커밋 없이 깔끔한 히스토리
✅ 협업할 때 코드 흐름을 명확하게 정리할 수 있음
✅ git log로 히스토리를 봤을 때 분석이 쉬움

📌 리베이스의 단점
❌ 히스토리를 재작성하기 때문에, 공유된 브랜치에서 사용하면 안 됨
❌ 충돌이 발생하면 한 번에 해결해야 함

🔥 머지 vs 리베이스: 어느 것이 더 좋을까?

	Merge 🏗️	Rebase 🔄
커밋 히스토리	머지 커밋이 많아져 히스토리가 길어짐	히스토리가 깔끔하게 정리됨
충돌 해결	충돌이 발생하면 머지 커밋에서 해결	충돌이 발생하면 커밋 단위로 해결해야 함
협업 방식	공유된 브랜치에서도 사용 가능	공유된 브랜치에서 사용하면 안 됨 (히스토리 변형)
사용 추천 상황	대규모 협업 프로젝트, 커밋 히스토리 유지가 중요한 경우	개인 프로젝트, 히스토리를 깔끔하게 정리하고 싶은 경우

💡 실전 활용법

협업 중인 브랜치(master, develop 등)에서는 Merge를 사용
개인 브랜치에서는 Rebase를 활용해 깔끔한 히스토리 유지
Pull Request를 올릴 때는 Merge를 사용해 기존 히스토리 보존

✅ 결론: 리베이스는 히스토리를 정리하는 강력한 도구

리베이스는 Git의 히스토리를 깔끔하게 정리하는 강력한 도구입니다.
하지만, 공유된 브랜치에서 리베이스를 하면 다른 사람들에게 큰 혼란을 줄 수 있으므로 주의해야 합니다.

🛠️ 리베이스 데모 1부: 설정과 병합

이전 글에서는 머지와 리베이스의 차이를 비교해 보았습니다. 이제 실제로 Git에서 어떻게 동작하는지 데모를 통해 확인해 보겠습니다.

📂 프로젝트 설정

먼저, 실습을 위해 RebaseDemo라는 폴더를 생성하고 새로운 Git 저장소를 초기화합니다.

mkdir RebaseDemo
cd RebaseDemo
git init

이 프로젝트에서는 간단한 웹사이트 파일을 다룰 것입니다. 따라서 website.txt라는 파일을 만들고, 첫 번째 커밋을 진행하겠습니다.

echo "Website project" > website.txt
git add website.txt
git commit -m "Initial commit"

이제 마스터 브랜치에서 기본 작업을 완료한 상태입니다.

🔀 피처 브랜치 생성 및 작업

이제 새로운 기능을 개발하기 위해 feature 브랜치를 생성하고 전환합니다.

git checkout -b feature

여기에서 새로운 파일을 추가하고 커밋합니다.

echo "ONE" > feature.txt
git add feature.txt
git commit -m "Start feature development"

현재 Git 히스토리 구조는 다음과 같습니다.

* (feature) Start feature development
|
* (master) Initial commit

🎨 마스터 브랜치에서 변경 사항 발생

한편, 다른 개발자가 master 브랜치에서 새로운 기능을 추가했습니다. 우리는 footer를 추가했다고 가정하겠습니다.

git checkout master
echo "Add footer" >> website.txt
git commit -am "Add footer"

이제 마스터 브랜치와 feature 브랜치가 달라졌습니다.

* (feature) Start feature development
|
| * (master) Add footer
|/
* Initial commit

🔁 머지(Merge)를 사용한 방법

지금 feature 브랜치에서 작업을 계속하면서 최신 마스터 브랜치의 변경 사항을 반영하고 싶다면?
일반적인 방법은 머지를 사용하는 것입니다.

git checkout feature
git merge master

Git은 머지 커밋을 생성하여 두 브랜치를 하나로 합칩니다.

* (feature) Merge branch 'master' into feature
|\
| * (master) Add footer
* | Start feature development
|/
* Initial commit

📌 문제점

머지 커밋이 추가됨 → 시간이 지나면서 머지 커밋이 계속 누적될 수 있음
히스토리가 복잡해짐 → Git log를 확인할 때 필요 없는 머지 커밋이 많아져 가독성이 떨어짐

🛠️ 리베이스(Rebase) 사용

머지 커밋 없이 마스터 브랜치의 최신 변경 사항을 가져오고 싶다면?
리베이스를 사용하면 됩니다!

git checkout feature
git rebase master

리베이스는 feature 브랜치의 커밋을 마스터 브랜치의 최신 커밋 뒤에 재배치합니다.

* (feature) Start feature development
|
* (master) Add footer
|
* Initial commit

📌 리베이스의 장점
✅ 머지 커밋 없이 히스토리가 깔끔하게 정리됨
✅ 마치 처음부터 master 브랜치의 최신 변경 사항에서 개발한 것처럼 보임
✅ Git log가 직관적이며 관리하기 쉬움

📌 리베이스 시 주의할 점
⚠️ 공유된 브랜치(master, develop)에서는 사용 금지 → 히스토리를 재작성하면 충돌이 발생할 가능성이 큼
⚠️ 충돌 발생 시 직접 해결해야 함

🎯 결론: 머지 vs 리베이스

	Merge 🏗️	Rebase 🔄
히스토리 관리	머지 커밋이 계속 추가됨	깔끔한 히스토리 유지
브랜치 병합 방식	기존 히스토리를 유지하고 새로운 커밋을 추가	기존 커밋을 재배치
협업 시 권장 여부	팀 협업 브랜치에서는 머지 사용	개인 브랜치에서는 리베이스 사용
충돌 해결	한 번에 해결 가능	각 커밋마다 충돌 해결해야 함

🛠️ 리베이스 데모 2부: 리베이스의 실제

이제 리베이스(Git Rebase)가 실제로 어떻게 동작하는지 단계별로 알아보겠습니다.
앞선 데모에서는 merge를 사용했을 때의 문제점을 확인했죠.
이번에는 리베이스를 사용해 동일한 작업을 진행했을 때 히스토리가 어떻게 정리되는지 확인해 보겠습니다.

🔍 현재 Git 상태 확인

우리는 feature 브랜치에서 작업 중이고, 마스터 브랜치에서는 동료들이 계속해서 변경 사항을 반영하고 있습니다.
그러다 보니 마스터 브랜치의 최신 내용을 가져오고 싶지만, 머지 커밋 없이 깔끔하게 유지하고 싶다면 어떻게 해야 할까요?
바로 리베이스를 사용하면 됩니다.

현재 상태는 다음과 같습니다.

* (feature) Work on feature
* (feature) Start feature development
| * (master) Add footer
|/
* Initial commit

우리는 feature 브랜치에서 master의 변경 사항을 가져오려 합니다.

🔁 리베이스 실행

리베이스를 실행하려면 feature 브랜치에서 다음 명령어를 입력합니다.

git checkout feature
git rebase master

이제 무슨 일이 벌어질까요?
Git은 feature 브랜치의 커밋들을 모두 새롭게 생성하여 마스터 브랜치의 최신 커밋 뒤에 다시 쌓습니다.

* (feature) Work on feature (rebased)
* (feature) Start feature development (rebased)
* (master) Add footer
* Initial commit

✅ 히스토리가 깔끔한 직선 형태로 정리되었습니다!
✅ 불필요한 머지 커밋이 사라졌습니다.
✅ 마치 처음부터 마스터 브랜치의 최신 코드에서 개발을 시작한 것처럼 보입니다.

🎯 리베이스 후의 변화

🔹 머지를 사용한 경우

* (feature) Merge branch 'master' into feature
|\
| * (master) Add footer
* | Work on feature
* | Start feature development
|/
* Initial commit

❌ 불필요한 머지 커밋이 추가됨
❌ 이력을 추적할 때 복잡해짐

🔹 리베이스를 사용한 경우

* (feature) Work on feature (rebased)
* (feature) Start feature development (rebased)
* (master) Add footer
* Initial commit

✅ 불필요한 머지 커밋 없이 깔끔한 히스토리 유지
✅ 마스터 브랜치의 최신 코드 위에서 작업한 것처럼 보임

⚠️ 리베이스 실행 시 주의할 점

리베이스는 커밋을 재배치하는 과정에서 커밋을 새롭게 생성합니다.
따라서, 이미 원격 저장소에 푸시된 브랜치에서는 리베이스를 하면 안 됩니다!

⚠️ 공유된 브랜치(master, develop 등)에서 리베이스 금지
⚠️ 다른 개발자가 같은 브랜치를 사용하고 있다면 리베이스 후 강제 푸시를 하면 안 됨

💡 리베이스를 안전하게 사용하려면?

본인의 개인 브랜치에서만 리베이스 사용
공유된 브랜치에서는 머지를 사용하여 충돌 방지
리베이스 후 푸시할 때는 git push --force를 신중하게 사용

✅ 결론: 리베이스는 히스토리를 정리하는 강력한 도구

리베이스를 사용하면 머지 커밋 없이 깔끔한 Git 히스토리를 유지할 수 있습니다.
하지만, 리베이스를 언제 사용해야 하는지, 언제 사용하면 안 되는지를 확실히 이해하는 것이 중요합니다.

⚠️ 리베이스를 하면 안 되는 경우: 기본 원칙

Git Rebase는 강력한 도구이지만, 잘못 사용하면 심각한 문제가 발생할 수 있습니다.
특히 협업 환경에서는 절대 리베이스하면 안 되는 경우가 있으므로 반드시 주의해야 합니다.

이번 글에서는 리베이스를 안전하게 사용하는 법과 리베이스를 하면 안 되는 상황을 정리해 보겠습니다.

✅ 언제 리베이스를 해야 할까?

리베이스는 다음과 같은 상황에서 유용합니다.

✔️ 개인 브랜치에서 최신 변경 사항을 반영하고 싶을 때
✔️ 협업 중인 브랜치의 히스토리를 깔끔하게 정리하고 싶을 때
✔️ 머지 커밋 없이 선형적인 커밋 히스토리를 만들고 싶을 때

💡 예제: 개인 브랜치에서 리베이스 사용
git checkout feature
git rebase master
feature 브랜치를 master 브랜치의 최신 상태로 업데이트

머지 커밋 없이 깔끔한 히스토리 유지

그러나, 모든 경우에 리베이스를 사용하면 안 됩니다.
특정한 상황에서 리베이스를 실행하면 협업하는 팀원들에게 큰 혼란을 줄 수 있습니다.

❌ 리베이스를 하면 안 되는 경우

🚨 1. 이미 공유된 브랜치를 리베이스하면 안 된다

⚠️ "공유된 히스토리는 절대 바꾸지 마세요!"

한 번이라도 다른 개발자가 가져간 커밋이 있다면 리베이스를 하면 안 됩니다.
왜냐하면, 리베이스는 기존 커밋을 새롭게 생성하는 작업이므로 기존 히스토리와 불일치가 발생하기 때문입니다.

💡 예제: 공유된 브랜치에서 리베이스 금지

git checkout master
git rebase feature  # ❌ 위험한 작업!

master 브랜치의 히스토리를 변경하면, 이미 git pull한 팀원들이 문제가 발생할 수 있음

📌 무슨 일이 벌어질까?

여러분이 master 브랜치를 리베이스하면 기존 커밋들이 새롭게 생성됩니다.
그런데 다른 개발자들이 이전 master를 이미 받아갔다면?
그들의 로컬 저장소에는 기존 커밋이 남아 있는데, 여러분이 히스토리를 바꿔버렸기 때문에 같은 커밋이지만 다른 것으로 인식됩니다.
결국, 다른 개발자들이 git pull을 할 때 혼란과 충돌이 발생합니다.

🛠 해결 방법: 머지를 사용하세요!
공유된 브랜치를 업데이트할 때는 반드시 머지를 사용해야 합니다.

git checkout master
git merge feature  # ✅ 안전한 방법

🚨 2. 원격 저장소에 푸시한 후 리베이스하면 안 된다

⚠️ "한 번 푸시한 후에는 리베이스하지 마세요!"

여러분이 git push를 실행한 후에 리베이스를 하면, Git은 새로운 커밋을 생성하기 때문에 원격 저장소의 히스토리와 달라지게 됩니다.
이후 다른 사람이 git pull을 하면 혼란이 발생하고 충돌이 날 가능성이 큽니다.

💡 예제: 푸시한 후 리베이스 금지

git push origin feature
git rebase master  # ❌ 위험한 작업!

📌 무슨 일이 벌어질까?

원격 저장소에는 기존 커밋이 존재하지만, 여러분이 리베이스하면 동일한 커밋들이 새로운 커밋으로 바뀜
이후 git push를 다시 시도하면 푸시가 거부됨
git push --force로 강제 푸시하면 다른 개발자들의 히스토리가 꼬이게 됨

🛠 해결 방법: 대신 머지를 사용하세요!

git checkout feature
git merge master  # ✅ 안전한 방법

이렇게 하면 원격 저장소와 로컬의 히스토리를 안전하게 유지할 수 있습니다.

🚨 3. 협업 중인 메인 브랜치(master, develop)에서 리베이스하면 안 된다

⚠️ "팀원들과 공유하는 브랜치는 절대 리베이스하지 마세요!"

협업하는 프로젝트에서는 master나 develop 같은 메인 브랜치의 히스토리를 절대 바꿔서는 안 됩니다.
이 브랜치들은 여러 개발자가 함께 작업하는 공간이므로, 히스토리를 변경하면 모든 팀원이 영향을 받습니다.

💡 예제: 협업 브랜치에서 리베이스 금지

git checkout master
git rebase develop  # ❌ 위험한 작업!

📌 무슨 일이 벌어질까?

master 브랜치를 리베이스하면, 기존 커밋들이 새롭게 생성됩니다.
이미 이 브랜치를 가져간 개발자들이 git pull을 하면, Git은 두 개의 완전히 다른 히스토리로 인식
충돌 해결이 복잡해지고 팀원들의 작업이 꼬일 가능성이 커짐

🛠 해결 방법: 머지를 사용하세요!

git checkout master
git merge develop  # ✅ 안전한 방법

🎯 리베이스의 황금률: "나만 사용하는 브랜치에서만 리베이스하라!"

🚀 리베이스를 안전하게 사용하려면?
✅ 개인 브랜치에서만 사용
✅ 협업 중인 브랜치에서는 절대 사용하지 않기
✅ 리베이스 후 git push --force 하지 않기
✅ 공유된 히스토리를 변경하지 않기

📌 이렇게 하면 안전합니다!

# 개인 브랜치에서만 리베이스
git checkout feature
git rebase master  # ✅ 안전함!

# 팀원과 공유하는 브랜치에서는 머지를 사용
git checkout master
git merge feature  # ✅ 안전함!

✅ 결론: 리베이스는 신중하게 사용해야 한다

리베이스는 강력한 기능이지만, 협업 중에는 잘못 사용하면 심각한 문제를 일으킬 수 있습니다.
"나만 사용하는 브랜치에서만 리베이스한다"는 원칙을 지키면 안전하게 사용할 수 있습니다.

⚠️ 충돌과 리베이스 다루기: 문제 해결 가이드

리베이스는 머지 커밋 없이 깔끔한 히스토리를 유지하는 강력한 도구입니다.
하지만 리베이스 과정에서도 머지와 마찬가지로 충돌(conflict)이 발생할 수 있습니다.

이번 글에서는 리베이스 중 충돌이 발생하는 이유와 해결 방법을 단계별로 정리해 보겠습니다.

💥 리베이스 중 충돌이 발생하는 이유

리베이스는 마스터 브랜치의 최신 변경 사항을 반영한 후, feature 브랜치의 커밋을 다시 쌓는 과정입니다.
이 과정에서 같은 파일을 수정한 기록이 있다면 Git이 어느 변경 사항을 유지해야 할지 결정할 수 없기 때문에 충돌이 발생합니다.

💡 예제 상황

feature 브랜치에서 website.txt 파일을 수정함
그 사이 master 브랜치에서도 같은 파일을 수정함
이제 feature 브랜치를 master 위로 리베이스하면 충돌 발생

🛠️ 리베이스 중 충돌 해결 방법

✅ 1. 리베이스 실행 중 충돌 발생

git checkout feature
git rebase master

🔴 충돌 발생!
Git은 자동으로 충돌을 해결할 수 없을 때, 다음과 같은 메시지를 출력합니다.

CONFLICT (content): Merge conflict in website.txt
error: could not apply [commit hash] update website on feat
Resolve all conflicts manually, mark them as resolved with
"git add <file>" and then run "git rebase --continue".

⚠️ 현재 상태

일부 커밋이 재배치되었지만, 충돌로 인해 리베이스가 멈춘 상태
git status를 실행하면 충돌이 발생한 파일이 표시됨

git status

rebase in progress; onto [commit hash]
You are currently rebasing branch 'feature' on '[commit hash]'.
Unmerged paths:
  (use "git add <file>..." to mark resolution)

    both modified:   website.txt

✅ 2. 충돌 해결하기

이제 충돌이 발생한 website.txt 파일을 열어보면, 아래와 같은 충돌 표시가 있습니다.

<<<<<<< HEAD
Main navbar added in master branch
=======
Top navbar added in feature branch
>>>>>>> feature

📌 Git의 충돌 표시 형식

HEAD → 현재 master 브랜치의 내용
======= → 충돌이 발생한 위치
>>>>>>> feature → feature 브랜치의 변경 내용

💡 해결 방법

main navbar를 유지할지, top navbar를 유지할지 선택
또는 두 내용을 합쳐 새로운 버전을 만들 수도 있음

예를 들어, 최종적으로 아래와 같이 결정했다고 가정하겠습니다.

Top navbar and main navbar added

✅ 3. 충돌 해결 후 리베이스 계속 진행

수정한 파일을 저장한 후, Git에 변경 사항을 추가합니다.

git add website.txt

그리고 리베이스를 계속 진행합니다.

git rebase --continue

Git은 남은 커밋들을 계속 재배치하면서 리베이스를 완료합니다.

Applying [commit hash] work on feature
Applying [commit hash] more work on feature
Successfully rebased and updated refs/heads/feature.

🎉 리베이스 성공!
이제 feature 브랜치는 최신 master 브랜치 위에 깔끔하게 정리되었습니다.

🔄 리베이스 중단 방법

만약 리베이스 중 충돌이 발생했는데 이전 상태로 되돌리고 싶다면?

git rebase --abort

이 명령어를 실행하면, 리베이스를 시작하기 전 상태로 돌아갑니다.
⚠️ 이미 변경한 내용이 있다면, git stash 등을 이용해 임시 저장하는 것이 좋습니다.

🎯 결론: 리베이스 중 충돌을 해결하는 법

1️⃣ 리베이스 실행 (git rebase master)
2️⃣ 충돌 발생 시, 충돌이 난 파일을 수정
3️⃣ 수정 후 git add <파일명>으로 변경 사항 반영
4️⃣ git rebase --continue로 리베이스 계속 진행
5️⃣ 리베이스 완료 후, git status로 최종 확인

📌 추가 팁
✅ 충돌을 피하려면 자주 git pull --rebase를 실행하여 최신 코드를 유지하세요.
✅ 리베이스할 때 git rebase -i HEAD~3 같은 인터랙티브 모드를 활용하면 더 세밀한 조정이 가능합니다.

🔄 Git Rebase 완전 정리: 리베이스의 개념과 활용

Git을 사용하다 보면 브랜치를 정리하고 깔끔한 히스토리를 유지하고 싶을 때가 있습니다.
이때 강력한 도구가 바로 Git Rebase(리베이스)입니다.

이번 글에서는 Git Rebase의 개념, 사용 방법, 주의할 점을 한눈에 정리해 보겠습니다.

🚀 1. Git Rebase란?

Git Rebase는 브랜치의 시작점을 새로운 베이스(Base)로 변경하는 기능입니다.
이 과정에서 기존 커밋들이 새롭게 생성되며, 불필요한 머지 커밋 없이 깔끔한 히스토리를 유지할 수 있습니다.

🔹 Rebase vs Merge 비교

	Merge (머지) 🏗️	Rebase (리베이스) 🔄
커밋 히스토리	머지 커밋이 추가됨	히스토리를 깔끔하게 정리
충돌 해결 방식	충돌이 발생하면 한 번에 해결	충돌이 발생하면 커밋별로 해결해야 함
사용 목적	협업 브랜치에서 안전하게 병합	개인 브랜치에서 히스토리를 정리
결과물	브랜치가 분기된 상태 유지	브랜치가 마치 처음부터 최신 브랜치에서 시작된 것처럼 보임

💡 예제 상황

feature 브랜치에서 작업을 진행 중
master 브랜치에는 동료들이 새로운 기능을 추가
feature 브랜치를 최신 상태로 유지하고 싶다면?

✅ 머지를 사용하면:

git checkout feature
git merge master

* (feature) Merge branch 'master' into feature
|\
| * (master) New feature added
* | Work on feature
|/
* Initial commit

⚠️ 불필요한 머지 커밋이 추가됨

✅ 리베이스를 사용하면:

git checkout feature
git rebase master

* (feature) Work on feature (rebased)
* (master) New feature added
* Initial commit

🎯 머지 커밋 없이 히스토리가 깔끔하게 정리됨!

🛠️ 2. Git Rebase 사용법

✅ (1) 기본적인 리베이스 실행

git checkout feature
git rebase master

feature 브랜치를 master 브랜치의 최신 상태로 업데이트
feature 브랜치의 커밋들이 새롭게 생성되어 master의 최신 커밋 뒤에 정렬됨

✅ (2) 인터랙티브 리베이스 (커밋 수정, 삭제, 합치기)

git rebase -i HEAD~3

최근 3개의 커밋을 대상으로 리베이스를 수행
특정 커밋을 삭제, 수정하거나 다른 커밋과 합칠 수 있음

💡 인터랙티브 모드에서 보이는 화면 예시:

pick 123abc Fix typo in readme
pick 456def Add new feature
pick 789ghi Improve performance

pick → 커밋 유지
reword → 커밋 메시지 수정
edit → 커밋 내용 수정
squash → 이전 커밋과 합치기
drop → 커밋 삭제

✅ (3) 리베이스 중 충돌 해결

리베이스를 실행하면, 같은 파일을 수정한 커밋이 있는 경우 충돌이 발생할 수 있습니다.
이때 Git은 자동으로 해결하지 못하는 부분을 알려줍니다.

CONFLICT (content): Merge conflict in website.txt

💡 해결 방법
1️⃣ 충돌이 발생한 파일을 열어 원하는 내용으로 수정
2️⃣ 변경 사항을 스테이징(git add <파일명>)
3️⃣ git rebase --continue 실행

git add website.txt
git rebase --continue

🚀 충돌이 해결되면 리베이스가 계속 진행됩니다.

⚠️ 리베이스 중단 방법
만약 충돌이 너무 복잡하다면, 이전 상태로 되돌릴 수도 있습니다.

git rebase --abort

이 명령어를 실행하면 리베이스를 시작하기 전 상태로 되돌아갑니다.

⚠️ 3. Git Rebase 시 주의할 점

리베이스는 강력한 도구지만, 잘못 사용하면 협업 과정에서 혼란을 초래할 수 있습니다.
다음 원칙을 반드시 지켜야 합니다.

🚨 (1) 원격에 푸시한 브랜치는 리베이스하지 않는다

git push origin feature
git rebase master  # ❌ 위험한 작업!

💡 이유

리베이스는 기존 커밋을 새롭게 생성하는 작업
원격 저장소와 로컬의 히스토리가 달라져 git pull 시 충돌 발생
git push --force로 강제 푸시하면 팀원들의 히스토리가 꼬임

✅ 대신 머지를 사용하세요!

git checkout feature
git merge master  # ✅ 안전한 방법

🚨 (2) 공유된 브랜치(master, develop)에서는 리베이스 금지

git checkout master
git rebase feature  # ❌ 위험한 작업!

💡 이유

master 브랜치는 여러 개발자가 함께 사용하는 브랜치
리베이스하면 기존 커밋들이 변경되어 모든 팀원이 영향을 받음
협업 중인 브랜치는 머지 방식으로 병합해야 안전함

✅ 대신 머지를 사용하세요!

git checkout master
git merge feature  # ✅ 안전한 방법

🚨 (3) 리베이스 후 강제 푸시(`git push --force`)는 신중하게!

git push --force  # ❌ 위험!

💡 이유

--force 옵션은 기존 원격 브랜치 히스토리를 덮어씌우므로, 다른 팀원들의 작업을 날릴 수 있음

✅ 대신 --force-with-lease 옵션을 사용하세요.

git push --force-with-lease  # ✅ 더 안전한 방법

이 옵션은 다른 개발자가 브랜치에 추가한 커밋이 있는 경우 푸시를 차단하여 실수를 방지합니다.

🎯 4. 리베이스 정리: 언제 사용해야 할까?

✅ 리베이스를 사용해야 하는 경우
✔️ 개인 브랜치에서 최신 변경 사항을 반영하고 싶을 때
✔️ 깔끔한 커밋 히스토리를 유지하고 싶을 때
✔️ 여러 개의 작은 커밋을 하나로 합칠 때

❌ 리베이스를 사용하면 안 되는 경우
⚠️ 이미 원격 저장소에 푸시한 브랜치를 리베이스할 때
⚠️ 팀원들과 공유된 브랜치(master, develop)에서 사용할 때
⚠️ 협업 브랜치를 변경하는 작업을 수행할 때

✅ 결론: Git Rebase는 신중하게 사용하자!

리베이스는 Git 히스토리를 정리하고 깔끔하게 유지하는 강력한 도구입니다.
하지만 잘못 사용하면 협업 중인 동료들에게 혼란을 줄 수 있으므로 신중하게 사용해야 합니다.

📌 핵심 요약

리베이스는 머지 커밋 없이 브랜치를 최신 상태로 정리하는 기능
개인 브랜치에서만 사용하고, 공유된 브랜치에서는 사용 금지
충돌 발생 시 git rebase --continue로 해결
강제 푸시는 반드시 --force-with-lease 옵션 사용