서론
- 필자는 협업도중 소스트리를 깔끔하게 정돈하여 커밋하고 올리고싶은 생각에 검색하던 도중 Rebase 라는 방법으로 Merge 할 수 있는 방법을 알아냈다. 하지만 Rebase 를 사용하는 방법을 몰라 이렇게 Merge 하고 저렇게 Merge 하고 계속 충돌의 무한반복을 돌아 이번에 개념을 확실하게 정리하려고 한다.
Merge와 Rebase의 차이
Merge 명령으로 브랜치를 통합할경우 통합된 타겟 브랜치에 Commit 헤드가 하나 새로 생기게되며 브랜치가 갖고있던 커밋로그가 소스트리에 그대로 남아있게된다
반면에 Rebase 로 브랜치 병합이 이뤄진경우 타겟브랜치에 Commit 로그가 1열로 정렬되며 커밋 히스토리를 깔끔하게 정리할 수 있다. 아래 실습으로 알아보자.
Merge 병합
- 위 사진에 보았을때 master 를 기준으로 patrick1 브랜치가 3개의 커밋을 진행하여 가지를 뻗어나간것을 볼 수 있다
위 상태에서 git merge 를 진행해보면
아래와 같이 최상위에 커밋 하나가 더 생성되어 master와 patrick1 의 브랜치가 병합되어있는것을 볼 수 있다.
지금이야 협업하는 사람이 한명밖에 없지만 여러명이 있을경우 아래와같은 브랜치 스파게티를 경험할 수 있다
위 사진은 실제 필자가 현업에서 다른팀 브랜치 관리가 어떻게 되고 있는지를 가져온 커밋트리이다.
리베이스 없이 머지만으로 브랜치 병합이 이뤄질 경우 위와같이 스파게티 커밋이 되기 직전까지 갈 수 있음을 보여준다.
Rebase 병합
위 사진에서 master 브랜치는 patrick2 브랜치와 버젼이 같은시점으로부터 총 3번의 커밋이 일어났고
patrck2의 브랜치는 총 4번의 커밋이 일어났다 위 브랜치를 Rebase로 병합을 해보면
서브 브랜치에 있던 rebaseTest1 , 2, 3 가 master 로 합쳐진것을 볼 수 있습니다.
Rebase 명령어는 병합할 타겟브랜치 즉 master 브랜치에서 명령어를 실행하는것이 아닌 서브 브랜치에서 명령을 내려주는것이다.
- 즉 from patrick into master 일 경우 patrick 브랜치에서 rebase 명령어를 실행해야 patrick 의 커밋내역이 master 브랜치에 1렬로 정렬된다.
이제 리베이스 작업이 끝났으니 마스터 브랜치에서 patrick2 브랜치의 병합을 진행한다.
머지 명령어는 타겟 브랜치 즉 목적지 브랜치에서 실행한다.
이후 patrick2 의 브랜치를 삭제해한 후 커밋 트리를 살펴보면
마스터 브랜치의 커밋 로그가 1열로 깔끔하게 정돈된것을 확인할 수 있다.
Reabase 주의사항
- Rebase 는 기존의 커밋을 그대로 사용하는것이 아니라 내용은 같지만 다른 커밋을 새로만든다
- git rebase 는 이전의 커밋 히스토리를 변경하기 때문에 GitHub 원격 저장소에 push가 올라온 커밋을 rebase로 바꾸려고 하면 해쉬값이 불일치 하여 push가 올라가지 않을것이다 이때 git push --force 를 사용해야하는데 이는 내 코드를 리모트에 강제 덮어쓰게 되어 깃이 꼬일수 있는 상황이 발생하니 주의해서 사용한다.
