Pull Request, 어떻게 사용할까?

지나가다 백기선님의 풀리퀘스트(Pull Requests) 그렇게 만들면 안되는데... 영상 제목을 보고, 최근 졸업프로젝트가 생각나 보게 되었다.

Pull Request는 어떻게 작성하는게 좋을까?

백기선님이 영상에서 말씀하신 내용을 정리해보면 다음과 같다.

• Pull Request(이하 PR)는 "내가 이렇게 작성한 코드를 당겨서 가져가주세요."라는 요청을 보내는 것이다.
• 하나의 PR는 오로지 한 가지의 일만 해야한다.
  • Single Responsibility Principle 원칙에 빗대어 이해해볼 수 있다.
  • 그래야 코드를 리뷰하기 쉽고, 문제가 생겼을 때 추적하기도 쉽다.
  • 하나의 PR에 여러가지 일을 담는 것은 좋지 않다.
  • 적당한 PR이라 하면, 여러 커밋이 있더라도 한 가지 일을 담당하고 있다.

이는 마치 KISS(Keep It Simple, Stupid) Principle과 유사해보인다.

이전까지 PR을 작성할 때, PR에 담기는 메시지와 관련된 Issue를 명시하는 것에 초점을 뒀었다. 그렇다보니 하나의 PR을 리뷰할 때 여러가지 기능이 뒤섞이는 것이 다반사였다. PR을 한 가지 기능만 하도록 나누었을 때, 아무리 생각해도 단점이 생각나지 않는다. 앞으로는 하나의 PR에는 하나의 기능만 하도록 수정을 해야겠다.

그럼 하나의 기능만 하는 Pull Request는 알겠는데, Commit의 단위는?

PR에 이어서 생긴 궁금증은, 그렇다면 Commit은 어느 단위로 해야할까?였는데, 생각보다 답은 단순한 것 같다. 기능이든 수정이든, 도메인 별로 구분하는 것이다. 그리고 기본적으로 Commit 또한 한 가지 기능만 하도록 파일의 변경사항을 추적해야 한다고 생각한다. 그래서 가장 단순한 구조라고 한다면, 하나의 PR에는 하나의 Commit이 있는 셈이다.

하지만 기능 외에도 여러 Commit이 포함 될 여지는 충분히 많다. 가령, 오탈자를 수정한다거나, formatting을 할 때 사용될 수 있다. 그 외에도 하나의 기능이 여러 파일에 걸쳐 있을 경우, 도메인 별로 구분해서 Commit을 진행할 수도 있다.

즉, Commit의 단위 또한 하나의 기능만 하도록 해야하는데, 이때는 어떤 Issue를 해결하려는 PR보다는 보다 세부적으로 도메인을 구분해 파일을 추적할 수 있을 것이다.

하지만 때로는 너무 세세하게 구분한 Commit이 리뷰어로 하여금 피로를 가져올 수도 있다고 생각한다. 약간의 취향이 반영될 수도 있긴 하겠지만 PR이 그 목적을 올바르게 제시하고 있다면 괜찮다고 생각한다.

너무 세세하게 구분된 commit의 경우, 오히려 conflict 등의 문제가 발생했을 때, revert 하기 어렵다는 것을 오늘(2024.02.21) 느낄 수 있었다.