[Git] Rebase

[Git] Rebase 

Git에서 한 브랜치에서 다른 브랜치로 합치는 방법에는 두가지가 있음

하나는 Merge고 하나는 Rebase

 

Merge

브랜치가 experiment와 master로 나누어진 경우

두 브랜치를 합치는 가장 쉬운 방법은 Merge 명령어를 사용하는 것 

커밋 두개 (C3, C4) 와 공통 조상 (C2)를 사용하는 3-way Merge로 새로운 커밋 (C5) 을 만들어냄 

 

Rebase

C3에서 변경된 사항을 Patch로 만들고 이를 다시 C4에 적용하는 방법이 있음

이와 같은 방식을 Rebase라고 함 

 

🔎 Git Patch

: Commit을 하나의 Patch 파일로 만들 수 있음

패치를 이메일로 보내거나 여러개의 커밋을 하나의 패치로 만들 수 있음

 

아래와 같은 명령어로 rebase 

git checkout experiment
git rebase master

1. Checkout한 브랜치 (experiment)가  가르키는 커밋까지 diff를 만들어 어딘가에 임시로 저장

 

2. rebase 할 브랜치 (experiment) 가 합칠 브랜치 (master)가 가르키는 커밋을 가르키게 한 후

저장해 놓았던 변경사항을 차례대로 저장 

 

Rebase 과정 후  master 브랜치를 Fast-forward

git checkout master
git merge experiment

rebase 병합을 하는 경우 git merge를 했을 때 보다 변경 이력을 알기 쉬움

 

🔎 Fast-forward

: 현재 브랜치의 HEAD가 대상 브랜치의 HEAD까지로 옮기는 merge

main 브랜치의 Head를 feature-view 브랜치의 Head까지 옮김

 

Rebase의 위험성

✔ 이미 공개 저장소에 Push한 커밋을 Rebase 하지마라

: Rebase는 기존의 커밋을 그대로 사용하는 것이 아니라 내용은 같지만 다른 커밋을 새로 만듦

커밋을 git rebase 로 바꿔서 Push 해버리면 동료가 다시 Push 했을 때 동료는 다시 Merge 해야 함

 

Rebase 한 것을 다시 Rebase 하기

: 어떤 팀원이 강제로 내가 한일을 덮어썼다고 할 때, 덮어쓴 내용이 무엇인지 알아 내야 함

아래와 같은 명령을 실행하면 덮여쓰여지지 않은 커밋을 결정하여 새로운 브랜치 (teamone/master) 에 적용

git rebase teamone/master

 

Push하기 전 history 정리를 위해 사용하는 것은 가능

하지만 별도의 알림 없이 history를 임의로 변경시키기 때문에 주의가 필요

git pull --rebase

위 명령어를 실행하면 다음과 같은 모양이 됨

 

참조

https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-Rebase-%ED%95%98%EA%B8%B0