Git pull --rebase 방식과 충돌(conflict)시 대처법

 

pull --rebase 란?

먼저 rebase이 무엇인지 알아보자.

영어 뜻대로 re-base, 즉 re(다시 ) base(기반)을 잡겠다는 뜻이다.

아래 그림을 보면 좀더 이해가 쉽다.

 

왼) rebase없이 pull 한경우, 오른) rebase를 통해 pull한 경우

 

파란색 branch를 develop 이라 생각하고 빨간색 branch를 feature 기능 브랜치라고 생각해보자.

최초 develop에서 feature 브랜치를 만들고 작업을 1, 2, 3 해나갈것이다. 그리고 해당 기능을 완성하고 develop에 다시 PR merge를 할려고할때 최초 develop에서 가져왔을때 이외에 추가된 commit history가 존재한다고 하면(다른 팀원이 작업이나 새로운 기능이 완료되어 develop에 PR merge 된 경우), 왼쪽 그림처럼 rebase없이 git pull 을 할경우 새로운 gray commit history가 생기고 그 gray commit이 develop에 합쳐진다. 이때 commit history가 서로 믹스되어 알아보기 힘들다.

 

만약 rebase를 한 경우라면 오른쪽과 같이 commit history를 develop의 최신 commit history와 엮어서 마치 한 줄기처럼 이어주고 이를 develop에 합치며 gray commit 하나가 남게되어 가독성과 history를 따라가기 매우 편하다.

 

git pull --rebase origin devleop 을 했는데 충돌(conflict)이 났을때 해결방법

그런데 종종 pull 을 할때 conflict이 나는 경우가 있는데 이는 같은 파일에서 서로 다른 수정이 이루워졌다면 무엇이 맞는지 모르기 때문에 conflict가 나게 된다.

 

해결법은 VSCode와 같이 자신이 쓰는 에디터에서 current 가 맞는지 incomming 이 맞는지 선택한후 문제가 없다면 resolve를 하면된다.

 

하. 지. 만

 

--rebase로 할경우 또다른 이슈가 발생한다. 위의 그림처럼 빨간 feature 브랜치를 만들고 commit을 1,2,3,4, ... 10개를 했다고 하자.

그리고 충돌이 난 파일이 유저 게시판 페이지라고 할때 rebase를 하기위해서 commit 수만큼 해결을 해줘야한다. 이떄 commit을 보존하면서 해결하기위해 10개의 commit이 있다면 commit한 시점의 코드를 이해하고 이때는 이게 맞아 resolve.... ->두번째 commit으로 가서 이때는 다시 지웠던게 맞아. resolve ->....10번째 commit 이런식으로 진행해야되는데 여간 피로한 작업이고 소요되는 시간도 길어지게 된다. 사람은 완벽하지 않고 기계처럼 모든걸 머릿속에 기억하고있지 않기때문에 그 시점에서 무엇이 맞는지 모른다.

 

그래서 나는 다음과 같이 가설을 세우고 테스트를 거쳐 해결하였다.

 

1. 만약 commit 수대로 resolve를 해야지 완성한다면 commit을 1개로 묶으면 되지 않을까?

2. commit을 묶는 방법으로는 git rebase -i HEAD~  를 통해 fixup 또는 squash 를 하면 된다.

3. fixup을 통해 빨간 branch의 최초 commit까지 묶어준다.

commit을 fixup으로 묶어줌

4. 위의 그림처럼 c8이라는 commit으로 합치고, 다시 git pull --rebase origin develop 시도

5. 충돌이 1번 나느데 수정후 resolve 하면 완성 

 

 

단점: fixup / squash 의 경우 commit history를 하나로 묶는거기 때문에 history를 followup 싶을때는 통째로 들어간 history내용만 볼수있다는 단점이있다.