[Git] Git rebase 재배치 사용법

---

[Git] Sourcetree rebase 재배치

---

 

rebase - 말 그대로 분기의 베이스(시작 위치)를 바꾸겠다는 말이다.

 

rebase와 merge는 브랜치를 합치는 역할이다.

merge를 쓰겠다면 굳이 쓰지 않아도 된다.

 

하지만 rebase만의 장점이 있다.

rebase가 merge보다 commit log가 깔끔해진다는 장점이 있다.

 

 

주의: 이미 공유된 커밋(main)은 리베이스하면 안된다. (커밋 해시 값이 변경됨)

---

 

 

 

main, newFunc 두 개의 브랜치가 있다.

base는 initial commit 이다.

 

브랜치 1, 브랜치 2가 각자 커밋이 진행하면

두 브랜치는 initial commit기점으로 하여 갈라지는 형태가 된다.

 

이 상태에서 rebase를 실행하려고 한다.

 

 

rebase를 하면 발생 문제 상황

 (1) 충돌이 나지 않는 경우

(2) 충돌이 나는 경우

 

---

(1) 충돌이 나지 않는 경우

 

rebase를 할 때는

현재 HEAD로 어떤 브랜치를 하고 있는지,

어떤 브랜치를 rebase로 사용할 것인지가 중요하다.

 

해당 사진은 브랜치 newFunc가 브랜치 main을 rebase 한 결과다.

newFunc(HEAD) -> rebase main

 

newFunc을 기준으로 main의 모든 커밋 내용들을 rebase됐다.

main에서는 newFunc까지 fast-forward 가능한 한줄기가 된다.

 

결과는 main commit내역이 밑으로 깔리고,

그 위로 newFunc가 이어서 작업한 것과 같은 형태가 된다.

 

 

rebase main

main의 마지막 commit을 새로운 base로 사용하겠다는 의미

main은 보통 공유하므로 rebase main을 하면 안된다.

 

rebase newFunc

newFunc의 마지막 commit을 새로운 base로 사용하겠다는 의미

 

 

rebase 대상을 HEAD branch 밑에 둔다

 

---

(2) 충돌이 나는 경우

 

충돌을 내기 위해 브랜치 newFunc와 브랜치 main이 같은 파일을 변경하고 커밋을 진행

 

이 상황에서 rebase를 하면 같은 파일을 변경했으므로 충돌이 일어난다.

newFunc(HEAD) -> rebase main

 

 

 

 

 

주의할 점은 newFunc(HEAD)에서 main을 rebase 했는데, 

병합 결과는 main(HEAD)로

HEAD가 바뀌어 나온다는 것이다.

 

이유는 rebase를 실행하면 HEAD가 main브랜치의 커밋 m1으로 이동한다.

그 후 지정하려는 main의 마지막 commit 부터 newFunc 브랜치의 커밋들을 위로 순차적으로 병합하게 된다.

 

현재 시점이 (m1)을 가르킨 상태에서 (1)을 병합하므로

HEAD(시점)은 (m1)이고 충돌은 (1)이 잡히는 것이다.

 

 

 

 

마찬가지로 (1)과의 병합을 마쳤다면 (2)를 병합을 해야한다.

 

cli 명령어

git rebase --continue

 

 

 

충돌이 발생하면 시점(HEAD)을 rebase로 하려는 브랜치로 옮기고 해당 위치부터

위로 순차적으로 기존 HEAD였던 브랜치의 커밋들을 병합하는 것이다. 

 

---

 

commit 로그 축약하기

interactive rebase

 

git rebase -i HEAD~3

커밋 3개 관리

 

 

명령어를 입력하면 나오는 화면

 

 

 

 

가장 최신 커밋 내용은 유지한채 최신 커밋을 줄인다. s (squash)

(pick)으로 3개의 커밋들을 병합

 

가장 아래가 최신 커밋 (내용은 유지하고, 커밋만 없앤다.)

 

 

 

https://meetup.toast.com/posts/39

git squash - 여러개의 커밋로그를 하나로 묶기 : NHN Cloud Meetup