Git rebase 써야할까?
git rebase.. 부트캠프에서 처음 코딩을 배우며 팀 프로젝트를 진행했을 때 굉장히 자주 쓰던 git command 였으나 2번째 팀 프로젝트에서 모든 팀원들의 commit 이 시간 순서대로 무작위로 합쳐지면서 각 브랜치에서 작업했던 모든 코드들이 혼합되어 병합되면서 대혼돈의 멀티버스를 경험하였다.
프로젝트 코드를 다함께 처음부터 훑으면서 최종 코드만 남기느라 하루종일 애를 먹었고, 그 이후에는 사용하지 않게 되었다.
하지만 새로 입사한 회사에서 원활한 협업을 위해 rebase 사용을 권장하기에, 다시 한번 rebase 에 대해 학습하고 이전의 실수를 반복하지 않고 장점만 취하기 위해 이 글을 작성한다.
Rebase의 단점
위 사례에서 알 수 있듯이 rebase의 단점은 commit 들간의 충돌이나 잘못된 병합으로 인한 사이드 이펙트가 있을 수 있다는 것이다.
때문에 rebase를 사용할 때 반드시 주의해야할 점이 2가지 존재한다.
- remote에 push 된 commit들은 rebase 하지 않는다.
- local 에서의 history를 관리할 때만 사용한다.
그럼에도 Rebase를 써야하는 이유?
- 가독성
commit은 시간순서대로 정리된다.
여러 팀원이 협업하며 각각 branch에서 업무를 진행하며 commit을 쌓았다고 가정해보자.
팀원 A와 팀원 B가 각각 작업한 branch를 main에 push를 한다면 commit message는 어떻게 될까?
commit 의 시간 순서에 따라 branch 들이 뒤섞여서 history가 쌓이게 된다.
branch, 작성자와 무관하게 오직 시간순서에 따라 commit history를 확인할 수 있다.
main 에서 모든 코드를 병합하고 나면 commit history를 조회할 때 가독성이 무척 떨어지게 된다.
기능 단위/업무 단위로 commit를 확인할수 없기 때문이다.
rebase를 활용하면 기능별/업무별로 commit history를 확인할 수 있기 때문에 협업 환경에서 프로젝트 코드의 가독성을 높일 수 있는 수단이 된다.
- 원활한 코드리뷰
취준을 하면서 여러 커뮤니티를 경험해본 바, 스스로 취준을 하면서 느낀 바로는 많은 주니어들이 회사를 선택하는데 있어 상당히 중요한 요소 중 하나가 바로 좋은 개발문화가 있는 회사인가? 이다.
그 좋은 개발 문화 중 가장 대표적인게 코드리뷰이다. 하지만 코드 리뷰가 오히려 개발문화를 해치는 경우도 존재한다.
PR을 올린지 한참이 지나도 코드리뷰가 진행되지 않아 팀원들 간의 갈등이 생기거나 코드 리뷰에 너무 많은 공수를 들여 업무 진행에 방해가 되는 커뮤니케이션 비용의 문제가 발생할 수 있기 때문이다.
rebase 를 활용하면 핵심 commit 만 남길 수 있어, 코드 리뷰어 입장에서 핵심적으로 봐야하는 코드가 어디인지 파악하기 쉽고 코드를 읽는데 시간을 단축시킬 수 있으니 좀 더 적극적으로 빠르게 리뷰할 수 있는 환경을 제공할 수 있다.
즉, rebase 를 하면 무조건 원활한 코드리뷰가 되는 것은 아니지만 코드리뷰에 대한 부담감을 낮추고 불필요한 커뮤니케이션 비용을 낮춤으로써 업무효율을 높일 수 있다.
참고자료
Git - Rebase 하기 (git-scm.com)
Git Rebase (1) (suhwan.dev)
Git Rebase (2) (suhwan.dev)