본문 바로가기

카테고리 없음

모르면 손해보는 git rebase (2)

지난 글에서 git rebase 를 interactive 하게 사용하면서 불필요한 커밋은 다른 커밋과 병합하거나 커밋 내용을 수정하는 방법에 대해 알아봤다. 리모트에 올라간 커밋을 수정하는 것은 사실 협업할 때 지양하는 일이지만 장기적으로 봤을 때 불필요하거나 알아보기 힘든 커밋 메시지를 수정하는 것은 가끔씩 필요하기도 하다. 그래서 가능하다면 하나의 브랜치 위에서 협업하기보다는 각자 하나의 브랜치 위에서 작업하는 방식을 추천한다.

 

이번 글에서는 여러 사람이 각자의 브랜치 위에서 작업할 때, git merge 대신에 git rebase 를 어떻게 쓸 수 있는지에 대해 이야기하려고 한다. 이번 글의 경우에는 자세한 케이스를 두고 설명하는 게 이해하기 좋을 것 같아서 한가지 상황을 가정하려고 한다.

 

✅ git merge를 사용한다면 ...

A, B, C 세 명의 사람이 하나의 프로젝트에서 (그리고 하나의 레포에서) 협업한다고 가정해보자.

세 명은 각자 하나의 태스크를 할당 받았고, 정해진 기간 내에 PR 리뷰까지 마치고 develop 브랜치로 다시 병합해야 한다.

 

할당 받은 태스크는 프로젝트가 시작됨과 동시에 develop으로부터 각각의 feauture/* 브랜치로 분기했다.

그 이후로 각자의 브랜치에서 작업한 후 한두 개의 커밋을 남겼다면 아래와 같은 그래프로 볼 수 있을 것이다.

그림 1. (점선은 develop 브랜치가 나아가는 방향을 가르키기 위해 사용했다)

 

 

이때, 가장 손이 빠른 C가 작업을 완료한 후, Pull Request를 생성했고, 동료들(혹은 리뷰어들)로부터 빠르게 검토 받아서 가장 먼저 develop 브랜치로 merge 되었다고 가정해보자. 여기서 git branch 그래프는 develop이 최신화되면서 아래와 같은 형태로 보일 것이다.

그림 2. 

 

 

그 다음으로 손이 빠른 B가 Pull Request 를 생성하고 merge가 완료되었다면 브랜치는 어떻게 보이게 될까? feature/B가 feature/C 라인 위로 보일 것이다. 아직까진 볼만하다.

 

그럼 이번엔 feature/A가 조금 손이 느려서 작업을 하는 데에 시간이 좀 오래 걸렸다고 해보자. 그런데 마침 feature/C가 수정한 라인과 동일한 부분을 수정했다고 가정해보자. 예상했겠지만 당연하게도 conflict가 발생했을 것이다.

 

이때 git merge 를 통해 conflict를 해결했다면 브랜치는 어떤 과정으로 병합되었을까?

아래와 같이 병합하기 위한 commit 이 하나 더 생긴 뒤에 main 으로 간 것을 확인할 수 있다.

 

 

그럼 이렇게 지저분한 브랜치를 git rebase 를 사용해서 정리해보자. (물론 브랜치가 이렇게 분기 / 병합되는 것이 나쁜 것도 아니고 보기에 아주 어려운 것도 아니지만 분기되는 브랜치가 많을수록, 그리고 히스토리가 오래될수록 git rebase는 빛을 발한다.)

 

 

✅ git rebase를 사용한다면 ...

다시 처음의 상황으로 되돌아가보자. 우리는 develop 브랜치로부터 세 브랜치로 분기가 되었다.

 

그리고 똑같이 가장 손이 빠른 C의 브랜치가 가장 먼저 merge 되었다고 가정해보자. 여기서 feature/C의 브랜치가 아래처럼 보이는 것까지는 동일하다.

 

 

그런 다음 B가 feature/B 브랜치의 PR을 생성하고 브랜치를 병합하려고 한다고 해보자. 그리고 B는 feature/C의 브랜치가 이미 머지된 상황임을 알고 있다고 해보자. 그러면 B는 아래의 명령어를 사용하여 어렵지 않게 브랜치를 최신화할 수 있다.

 

$ git rebase develop

 

 

이때 주의할 점은 git rebase를 한 후에는 commit hash 가 변경되기 때문에 그냥 git push 하는 경우엔 아래와 같이 git pull을 받으라는 메시지를 받게 된다. 하지만 개의치 않고 git push --force를 통해 커밋을 푸시하면 된다. 다만 글의 서두에도 강조했지만 다른 사람과 협업하는 브랜치 위에서는 가능하면 쓰지 않기를 권장한다.

 

그런 다음 feature/B 의 PR이 병합된 결과를 브랜치로 본다면 아래와 같은 형태일 것이다.

 

마찬가지로 feature/A 브랜치도 동일한 방식으로 git rebase 를 한다면 우린 최종적으로 아래와 같은 결과를 얻을 수 있다.

 

 

git merge 를 사용했을 때와 비교해본다면 훨씬 더 깔끔해진 것을 눈으로 확인할 수 있다.

 

 

 정리하며

이번 글에서는 git rebase 를 사용하여 여러 사람과의 협업에서 브랜치를 깔끔하게 관리하는 방법에 대해 알아보았다.

부디 많은 분들이 git rebase 를 잘 활용할 수 있길!