Rebase 하기
Git에서 한 브랜치에서 다른 브랜치로 합치는 방법은 두 가지가 존재한다. 하나는 Merge이고, 다른 하나는 Rebase이다. 두 방법의 차이점을 살펴본다.
Merge
Rebase
그림을 보면 어떤 점이 다른 것 같은가? Merge의 경우, 기존의 커밋 히스토리는 남겨두고 merge하고자 하는 브랜치를 기준으로 새로운 커밋이 생긴다. 하지만 Rebase는 기존의 커밋은 사라지고 rebase하고자 하는 브랜치를 기준으로 커밋을 재정렬한다. 개인적으로 두 방법 중에 Merge가 좋은 것 같다. Rebase를 사용하면 커밋이 재정렬되어 깔끔해보이긴 하겠지만 큰 프로젝트에서 전체적인 프로세스 과정을 이해하거나 히스토리를 살펴볼 때는 Merge를 사용하면 이전 기록이 모두 남아있어서 더 좋지 않을까라는 생각이 든다.
Rebase 를 사용한 실습
위 트리를 보면 일자로 알아보기 쉽게 나와있다. 커밋메시지를 제대로 작성하지 않는다면 분명 헷갈릴 여지가 있다. 아직 큰 프로젝트의 개발을 해본 건 아니지만, 개인적으로는 Merge에 한표 던진다.
Conflict 상황 해결하기
나는 Merge를 했을 때의 Conflict에 대해 다뤄보려고 한다. 현재 main에서 1회 commit 후 bugFix로 checkout한 뒤 c1,c2,c3의 commit을 해주었고, main으로 checkout한 뒤 c4,c5,c6의 커밋을 해준 상태(Merge 하기 전 상태)이다. 그리고 merge를 해주었더니 rebase를 했을때와는 다른 결과를 보인다. rebase의 경우 3개의 커밋을 모두 수정해야한다는 뜻으로 오른쪽 파란 글씨로 (1/3) 과 같이 나왔었다. 하지만 merge의 경우, main|MERGING이라고 나온다.
git status를 보면 rebase를 했을 때와 동일한 결과가 나오는 것을 볼 수 있다. 즉, merge를 하던 rebase를 하던 같은 파일을 수정하려고 하면 충돌이 발생한다. 다시 수정을 해주자 !
결과적으로 아래와 같이 merge된 것을 볼 수 있다. rebase처럼 일자로 된 기록이 남는 것 보다 조금 못생기더라도 아래와 같은 히스토리를 남기는 것이 더 좋아보인다.
