rebase ↹

특정 브랜치 기반 (base) 커밋을 다른 커밋 위로 옮기고, 내 커밋들을 다시 쌓아 올리는 작업을 말한다.

히스토리가 직선으로 정리되어 특정 브랜치에서 여러 사람이 브랜치를 따고, 작업해서 머지하는 과정을 정리해주는 기능이다. 

 

장점

• 히스토리가 직선으로 예쁘게 정리된다. 

 

단점

• 커밋 해시가 바뀐다.
• 이미 푸시한 브랜치를 rebase하면 협업자와 충돌 가능성이 크다.

 

언제 사용하는가?

• 기능 브랜치의 최신화 (내 기능 브랜치를 최신 기반으로 깔끔하게 맞추고 싶을 때)
• PR (Pull Request) 전에 히스토리 정리할 때
• 커밋 내용 수정할 때

 

언제 사용하지 않아야 하는가?

• 이미 푸시해서 다른 사람이 작업하고 있는 브랜치 (이럴 때에는 merge)
• merge 커밋이 이미 있는 경우 (대규모 merge, 릴리즈할 때, 이럴 때에도 merge)

 

1. 내 기능 브랜치를 main/master 최신으로 맞추기

# 기능 브랜치에 있음 (예: feature/login)
git fetch origin
git rebase origin/main
# 충돌 나면 파일 고치고
git add <수정한_파일들>
git rebase --continue
# 포기하려면
git rebase --abort

# 이미 원격에 올린 브랜치였다면(주의!)
git push --force-with-lease

 

 

2. rebase로 커밋 정리

# 최근 5개 커밋을 손질
git rebase -i HEAD~5

 

 

편집기에서 사용할 액션:

• pick: 그대로 두기
• reword: 커밋 메시지만 수정
• edit: 커밋 내용 고치기(수정 후 git add → git rebase --continue)
• squash: 이전 커밋과 합치고 메시지 합치기
• fixup: 이전 커밋과 합치되 메시지는 버리기
• drop: 커밋 버리기

 

merge vs. rebase

merge: 히스토리가 보존되며 안전하고 간단하다. 대신, 히스토리 가지가 분기되어 보기 복잡하다.

rebase: 히스토리가 직선으로 보여 보기 깔끔하다. 대신, 커밋 재작성이나 공유된 브랜치에는 위험하다.

 

 

예시

4259e764 계약 플로우 페이지 추가

7a2fffa3 계약 플로우 페이지 사용되는 컴포넌트 추가

7877572e 운용상세 추가

5727b432 자문 정보 변경 수정

e00d17d1 API 연결 추가

.

.

.

// 3개의 커밋을 하나로 묶음
rebase -i HEAD~3
// 확인하기
git log --oneline
git rebase -i HEAD~2

// open editor
pick -> s로 바꾸기 (sqush의 약자)
x -> 합치기

git push origin -f <branch name>

 

개발하면서 가장 떨리는 게 merge, push 같은 git을 사용하는 것이다. 코드는 잘못 짜면 쉽게 수정할 수 있지만, git은 잘못 만지면 되돌리는 것도  심장이 철렁하기 때문이다 🫀

 

 

이상 스텔라였습니다 ✍🏻