팀프로젝트에 git을 사용하면서, 여러 브랜치를 내다 보면
수 많은 브랜치를 만들고, 병합하기를 반복하게 됩니다.
이때, 브랜치를 합칠 때, merge 만 이용한다면 git 그래프가 굉장히 지저분해 질 수 있습니다.
아래가 대표적으로, 아주 지저분한 예시입니다.
이때, merge가 아닌 rebase를 이용했다면, 훨씬 깔끔하게 git 그래프를 관리할 수 있습니다.
그래프를 깔끔하게 관리하는 것은 필수는 아니지만, 다른 사람이 프로젝트를 분석할 때, 더 편하게 도와줄 수 있습니다.
그런데, 이런 rebase는 base를 새롭게 정하는 행위이기 때문에, merge랑은 여러 차이점이 있습니다.
일단 새로운 커밋을 만들어내서 병합하는 merge와 다르게, 새 커밋을 만들지 않고, 기존 브랜치의 마지막 커밋 뒤에 병합할 브랜치들의 커밋들을 줄줄히 합쳐서, 병합할 브랜치의 커밋이 마지막 커밋이 되게 합니다.
이러한 특성 때문에, conflict이 발생했을 때, 여러번 커밋했다면, 그 파일을 커밋한 횟수만큼 conflict를 해결해줘야합니다.
그렇다면, Github에서 PR을 날릴 때, conflict를 어떻게 해결해야할까요?
다음과 같은 브랜치가 있고, 이걸 여기서 브랜치를 내서 작업 후 rebase로 merge를 하려는 상황을 가정해 보겠습니다.
그런데 여기서 만약 내가 병합하기 전에 다른 사람이 다른 작업을 진행한 후 다음과 같이 병합해 놨다면 conflict가 발생하게 됩니다.
이 상태에서 PR을 올리기 위해서는 일단 충돌을 해결해야 합니다.
충돌하기 위해 local-dev에 origin/dev를 rebase을 이용하여 pull 합니다
git pull --rebase origin develop
그럼, 위 그림과 같은 형태가 되어, 충돌없이 PR을 날릴 수 있는 형태가 됩니다.
git은 이전 commit의 내용을 포함해서 hash값을 생성하므로, 이전 commit이 바뀌었기에 새로운 hash 값이 생성되어, a1이 아닌 ab1와 같은 새로운 해시값을 갖게 됩니다.
그럼 인제, local-dev 브랜츠를 push 한 후 PR을 날리면 충돌없이 rebase merge를 할 수있습니다.
git push origin local-dev만약, 여기서 새 commit이 없어 push가 되지 않는다면원격에 있는 브랜치를 삭제 후 다시 push 하면 됩니다.
