[Git] Rebase란?

Rebase

말 그대로 Base를 바꾸는 작업을 말한다. 

 

Rebase에서 잘 알고 있어야 하는 내용은 Rebase 자체에 대한 것도 중요하지만,

Merge와의 차이점을 잘 알고 있어야 한다.

 

Merge VS Rebase

먼저 Merge의 경우를 살펴보자. (3-way-merge)

 

위의 이미지의 경우에 Merge를 하면 어떻게 될까? 

 

 

 

초기설정을 하고 메인 UI까지 작업을 한 다음, UI에 대해서 리펙토링을 하기 위해 Sokyte라는 브랜치를 파서 작업을 한다고 가정했을 때 (예를 들어서 기존의 CollectionView에 대해 DiffableDataSource, CompositionalLayout을 적용하기 위해 새로 브랜치를 판 경우를 생각해볼 수 있다 ..) 

그리고 기존의 메인 브랜치에서는 리펙토링을 하는 것과 동시에 기능을 구현하고 QA까지 구현한 경우라고 해보자.

 

그렇다면 이는 분기된 시점을 기준으로 메인 브랜치에 커밋이 생겼기 때문에 3-way-merge가 발생할 것이다. 

그리고 머지를 하게 되면 머지 커밋도 함께 생길 것이다.

 

각 브랜치에서의 상황을 보게 되면, 시간 순서대로 커밋이 쌓이게 된다.

위와 같은 경우에 머지를 하고 각 브랜치에서의 상황을 살펴보면 아래와 같다.

이 때 이 순서까지 고려해야 하는가? 

-> 실제로 큰 규모의 프로젝트가 아니라면, 또는 의존성 주입/분리 등의 문제가 아니라면 크게 고려할 필요는 없다. 

 

✅ 여기까지가 머지에 관한 내용 !!

 

그렇다면 위의 상황에서 rebase를 하게 된다면?

- rebase는 앞서 말한 것과 같이 base를 다시 만들어주는 것이다. 

- 분기된 베이스 커밋의 위치를 마지막 커밋으로 옮긴다. 

 

똑같이 위의 상황을 이미지로 표현하면 아래와 같다.

 

🔥 이 때 주의할 점은 !!!

rebase를 하면 parent commit이 변경된다.

만약 분기한 시점 이후로 remote에 올라간 상태라면, rebase를 하면 안된다.

깃은 부모 커밋을 참조하고 있기 때문에 부모 커밋이 바뀌게 되면 그 아래로도 커밋 id가 바뀌게 된다. 

그러므로 rebase -> remote로 올려야 한다 !!!

 

즉 커밋이 다시 생기므로

특히 !! 협업할 때 사용에 주의해야 한다. 

 

 

rebase를 할 때는 방향성이 중요하다.

merge의 경우 main 브랜치에서 sokyte의 브랜치를 merge했다면,

rebase의 경우는 sokyte 브랜치에서 main 브랜치를 rebase 해야한다. 

 

 

rebase를 하고, 다시 merge를 해야한다.

rebase는 말 그대로 베이스 커밋의 위치를 변경한 것이므로 다시 merge를 해야 반영이 된다.

(헤드가 이동한 것이므로, 어디로 이동? 해당 브랜치의 가장 마지막 커밋으로 이동 - 메인에서 가장 마지막 작업이 QA이므로 QA를 기준으로 sokyte 브랜치에서 작업한 내용이 따라 붙게 된다.) 

 

 

또 한가지 알고 있어야 할 점은 .. ! ff 상태라면 rebase를 할 필요가 없다.

당연한 이야기 .. 

 

---

 

Rebase를 통해서 이전 git 내용을 편집할 수 있다. 

실습을 통해서 알아보자 !!! 

 

예를 들어서 .. 실제로 그럴 일은 없겠지만 .. 아래와 같은 상황이라고 가정하자.

목요일에 작업을 하고 커밋한 내역에 대해서 알고보니 .. 수요일까지 작업을 했어야 하는 내용이었을 때 .. 이제 무서운 상사(예를 들면 .. hue .. ? 🫶🏻) 가 와서 .. 깃 커밋 내역 좀 보죠. 라고 한거지 .. 

 

이럴 때 어떻게 수정할 수 있는가!?

 

작업을 만들어보자.

 

그리고 수정할 작업이 무엇인지 확인하기 위해 log를 찍어보자 

 

 

 

rebase를 이용해서 깃 내역을 수정하자.

여기서 commit9에 대해서 수정을 하고 싶을 때 !!

주의할 점은 !! commit9에 대한 커밋 id가 필요한 것이 아니라, 그 앞의 커밋 id가 필요하다 !!!

 

 

그 앞의 커밋 id를 전부 복사해도 되지만 앞의 7자리 정도(4f2d489) 복사를 해서 

git rebase -i { 커밋 id }

이렇게 명령어를 친다. (여기서 -i는 interactive rebase를 의미한다.) 

 

그러면 VSCode가 실행될 것이다. (만약 VSCode와 연결을 하지 않았다면 vi 편집기가 열릴 것.)

여기서 수정할 커밋을 골라, 즉 commit9 를 찾아서 그 앞의 pick을 편집할 수 있도록 edit으로 바꿔준다. 위의 이미지를 아래로 변경!

 

그리고 저장(command + s)을 하고 돌아가면 .. (= 창을 닫으면)

위와 같이 나타날 것이다.

 

이제 수정할 내용을 입력하면 된다 !!

나의 경우 날짜를 바꿔주고 싶으므로 .. 아래와 같은 명령어를 입력하면 된다.

git commit --amend --allow-empty --date="{Jul 11 15:00:00 2000 +0900}"

이 때, 실제로 작업을 한 경우에는

git commit --amend --date="{Jul 11 15:00:00 2000 +0900}"

이렇게만 작성해도 된다.

 

실습을 하는 거라서 .. 빈 파일로 만들었기 때문에 --allow-empty 이 옵션이 필요한 것 ..

 

위의 명령어를 입력하면 다시 VSCode가 실행될 것이다. 

만약 커밋 메시지에 별다른 수정을 하고 싶지 않다면 그대로 닫아도 된다.

(커밋 메시지를 수정하고 싶으면 수정해도 된다!!)

 

그리고 나서 아래의 명령어로 반영을 해줘야 한다.

git rebase --continue

그러면 !!!

성공적으로 rebase가 되었다는 문구가 나올 것이다 !!

(git log로 내역을 확인해보면 수정한 날짜로 반영된 것을 확인할 수 있다.)

 

 

날짜 뿐만 아니라, 작업한 사람 .. 내용 등등을 수정할 수 있다.

실제로 현업에서 많이 사용한다고 하니까 .. 잘 익혀두도록 하자 ..