-
[GIT] Git Rebase란?카테고리 없음 2023. 1. 6. 19:06
Git Rebase란
말그대로 다시 베이스를 재설정한다는 의미
브랜치를 합치는 가장 쉬운 방법은 merge입니다.
그렇다면 두개는 무슨 차이가 있고 rebase를 썼을 때 장단점은 무엇이 있을까요?
Merge
아래처럼 master, experiment 브랜치를 2개 새로 만들고 C3, C4 커밋을 했다고 가정해봅시다.
master에 experiment의 내용을 합치고 싶다고 할 때 단순히 브랜치 포인터를 최신 커밋으로 옮기는게 아니라
별도의 커밋으로(C5) 만들고, master 브랜치가 그 커밋(C5)을 가리키도록 이동합니다.
이 방법이 가장 간단하고 안전하기 때문에 보통은 merge를 사용합니다.
Rebase
experiment를 리베이스한다고 해봅시다.
Rebase는 위에서 언급한 것 처럼 다시 베이스를 재설정하는 것이기 때문에 단순히 가르키도록만 변경하는것이 아닙니다.
실제로는 아래와 같은 동작들을 수행합니다.
- 두 브랜치가 나뉘기 전 커밋(C2)으로 임시로 이동하고,
- 그 커밋부터 지금 checkout한 브랜치(experiment)가 가리키는 커밋까지 diff(C4)를 차례로 만들어
- 어딘가에 임시로 저장해 놓습니다.
- Rebase 할 브랜치(experiment)가 합칠 브랜치(master)가 가르키는 커밋을(C3)를
- 가리키게 하고 아까 3번에 저장해놓았던 변경사항을 차례대로 적용합니다.
이렇게만 봤을 때는 무슨 차이가 있는지 잘 모르시겠죠?
간단히 말하자면 merge는 기존 히스토리를 보존하고, rebase는 히스토리를 재작성합니다.
리베이스를 사용하면 위의 'Merge branch....' 커밋이 없습니다!
이 말은 다르게 표현하면 잘못 사용하면 굉장히 위험해질수도 있다는 뜻입니다.
그렇다면 어떨때 사용하면 좋을까요?
보통 현업에서 일을 하게 된다면 아래처럼 복잡한 브랜치 형태를 띄게 됩니다. (아마 훨씬 더 복잡하겠죠)
지금 나는 Dev4 브랜치에서 작업을 하고있는데 Dev1, Dev2의 내용이 필요하다면 어떻게 할까요?
각각의 Dev1, Dev2 브랜치를 Dev4로 merge?
그렇게 한다면 간단..은 하겠지만 나중에 헬을 볼 수 있습니다 ㅋㅋ
- 브랜치를 딴 역순으로
- Dev1, 2를 각각의 Feature브랜치에 합친 후
- 다시 그것을 Base에 merge하고
- Dev4로 checkout한 후에 Base에 리베이스합니다.
이렇게 하면 dev1, 2의 내용이 잘 ~ 합쳐집니다 :)
dev1, dev2를 base로 합쳐봅니다.
그리고 dev4를 base에 리베이스합니다.
저는 Github desktop을 쓰고있는데, 이런 고급 기능들은 지원하지않아서 intelliJ의 도움을 받고있습니다.
방법은 우측하단의 브랜치(dev4)를 선택후에
리베이스 할 브랜치인 base를 선택하여 'Rebase dev4 onto base'를 택합니다.
(onto : ~에, ~위에, into : ~ 안에)
그럼 아래처럼 base에 merge되었던 dev4에 dev1, dev2의 커밋이 들어와있습니다.
rebase도 당연 충돌은 납니다.
덮어씌어지지 않으니 걱정하지 않으셔도 됩니다.
유의점
해당 브랜치에 여러사람이 작업을 할 경우에, 이전 기준 브랜치로 base를 변경해버리면 작업자들의 커밋이 날라갈 수 있습니다!!
그러니 반드시 브랜치는 각자 따서 작업을 하고, 그 상위에 브랜치를 만들어서 그곳에 merge를 하는 식으로 작업을 해야합니다.
Ref
https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-Rebase-%ED%95%98%EA%B8%B0