이번 포스팅은 효율적인 코드 리뷰를 위한 PR관리와 커밋 관리입니다.
여러 코드 리뷰 툴이 있는 것으로 알고 있지만 해당 포스팅에선 github을 기준으로 설명합니다.
git툴은 인텔리제이를 기준으로 설명합니다.
먼저 글에 들어가기 앞서 왜 코드 리뷰를 위해 커밋을 쪼개고 PR을 나눠서 해야 할까요?
이유는 간단합니다. 리뷰어가 좀 더 적은 File change(이하 파일 체인지)를 확인하게 하여 리뷰어의 피로감을 줄이고 코드 리뷰 시 좀 더 집중하기 편하게 하기 위해서입니다.
예를 들어 파일 20개짜리가 한 번에 코드 리뷰가 올라온다고 생각하여보세요.
한 두 번이야 괜찮지만 매번 코드 리뷰가 10~20개의 파일을 전부 확인하면서 해야 한다면 리뷰하는 입장에서 굉장히 괴롭습니다.
하지만 프로젝트 처음 시작 후 기능을 붙이는 경우이거나 아예 너무나도 다른 기능을 프로젝트에 시작해야 해서 등등 여러의 이유로 파일이 많이 생길 수 있습니다.
그럴 때 과연 어떻게 해야 할까요?
가장 간단한 방법은 작업을 최대한 쪼갠다. 입니다
(해당 글은 git을 다루는 내용이기에 이 부분을 깊게 다루진 않겠습니다.)
그러나 이 방법이 모든 해결은 아닙니다. 어쩔 수 없이 File이 굉장히 많이 쌓일 때가 있습니다.
이제 그럴 경우 어떻게 해야 할까요?
다음과 같은 커밋 리스트를 다시 한번 쪼갠 후 커밋 단위를 묶을 생각입니다.
먼저 제일 바탕이 되는 git의 커밋 시점으로 롤백합니다.
저는 맨 아래 커밋인 'api isEnd시 까지 긁어오기 완료'를 기준으로 리셋하겠습니다.
주의해야 할 점은 soft reset를 사용하여야 합니다.
소프트 리셋 후 보시면 여태 커밋한 파일들이 change list에 있는 것을 확인하실 수 있습니다.
커밋을 다음과 같은 기준으로 묶습니다.
-
코드 리뷰가 필요한 파일과 불필요한 파일을 구분합니다
- 이미지, 테스트 코드를 위한 데이터 파일 등 리소스 폴더의 파일의 경우 굳이 세세한 코드 리뷰가 필요하지 않은 경우가 많습니다. 빌드에 영향을 안주는 경우도 많죠.
이럴 땐 커밋을 분리하여 따로 PR을 생성하여 바로 머지 후 진행하면 됩니다. -
구현 코드를 먼저 커밋하고 테스트 코드를 추후 커밋하여 구현 / 테스트를 분리합니다.
- 개발은 TDD로 하여도 코드 리뷰를 위해 구현과 테스트 코드를 분리하는 방법입니다.
코드 리뷰할 때는 테스트 코드가 꼭 필요 없죠 코드 리뷰 시점에서는 테스트 코드를 꼭 먼저 리뷰할 필요는 없습니다.
34개의 파일을 각자의 기능별로 묶어서 파일을 커밋을 나누었습니다.
나누어진 커밋을 하나씩 PR을 날려 병합하면서 코드 리뷰를 진행하면 됩니다. (병합 후 병합한 브랜치에서 합치고 싶은 변경내역을 cherry pick 하면 더 쉽게 병합이 가능합니다)
생각보다 간단하죠?
이런 방식으로 코드 리뷰를 하면 리뷰어 입장에선 굉장히 편리합니다.
코드 리뷰에 피로감도 줄어드는 장점도 있고요.
작업을 진행하는 요청자 입장에선 조금 귀찮다 생각할 순 있지만
오히려 이후에 PR을 생각 안 하고 개발 시엔 편하게 커밋과 롤백을 하며 개발 후 마지막에 커밋을 정리돼서 오히려 편리합니다.
