내가 PR 템플릿을 적용하게 된 이유
프로젝트를 처음 진행했을 때부터 코드 리뷰어들을 위해 항상 템플릿에 맞춰 PR을 작성하고는 했다.
왜냐하면 초반에는 커밋의 단위 / PR 단위에 대한 개념이 없었기 때문에 파일 변경 수가 10개가 넘어가는 일이 다반사였고,
내 자신이 봐도 이런 PR을 보고 리뷰하기가 쉽지 않을 거라는 생각이 들었기 때문이다.
처음 프로젝트에서는 나혼자 나만의 PR 템플릿을 적용시켰고,
두 번째 프로젝트에서는 미리 팀원들끼리 합의하여 템플릿을 정한 뒤 PR을 올릴 때마다 템플릿을 복사하여 사용했다.
세 번째 프로젝트에서도 똑같이 사전에 PR 템플릿을 정했지만, 문득 계속 복사해서 PR 템플릿을 작성하는 것이 번거롭다고 느꼈다.
그래서 찾아본 결과 GitHub에서 PR 템플릿을 설정하면, 그 후 PR을 올릴 때 자동으로 템플릿이 적용된다는 것이었다.
그렇다면 PR 템플릿에는 어떤 내용이 들어가면 좋을까?
나의 PR 템플릿
아무래도 PR은 코드 리뷰가 주요 목적인 것 같아서 내가 리뷰어일 때 어떤 내용이 있어야 파악하기 쉬울지 생각하며 구성해 보았다.
먼저 나는 모든 프로젝트에서 기본적으로 수정한 파일, 작업 내역, 참고 사항을 작성하도록 템플릿을 설정했다.
필요에 의해서 유동적으로 스크린샷이라던지 컴포넌트 사용방법 등을 추가하기도 했다.
이렇게 선정한 이유는 아래와 같다.
수정한 파일
수정한 파일 목록을 작성한 건 충돌 방지를 위해서가 컸다.
원래 변경된 파일들을 확인할 수 있지만, 먼저 수정한 파일들을 나열하여 보여주면 보는 사람들이
해당 파일을 피해서 작업하지 않을까? 라는 생각에 넣게 되었다.
작업 내역
작업 내역은 말 그대로 이 사람이 어떤 작업을 했는지 알기 위해서 필요했다.
또한 체크리스트 형식으로 해서 스스로도 어떤 작업을 진행했는지 파악하고,
이로 인해 빠트린건 없는지 다시 한번 확인할 수도 있기 때문에 넣게 되었다.
참고 사항
참고 사항에는 부가적으로 설명하고 싶은 내용이나 기타 이슈 사항, 질문 등을 적기 위해 추가했다.
이전 PR 템플릿을 보고 수정하고 싶은 부분이 생겼다.
GitHub에서 Issue를 작성했다면 Issue 번호와 작업 내역, 스크린샷, 참고 사항을 넣을 것 같다.
수정한 파일 목록은 따로 확인할 수 있기 때문에 굳이 넣을 필요는 없을 것 같아서 제외하는 게 나을 것 같다.
이슈가 있다면 이슈 번호도 함께 넣는 것이 도움이 될 것 같고 스크린샷도 있으면 작업 내용을 더 이해하기 쉬울 것 같아서 추가할 것 같다.
사람마다 생각은 다르겠지만, 내가 생각했을 때는 위의 내용들이 필수로 들어가야 리뷰어들이 내용을 쉽게 파악할 수 있을 것 같다!
PR 템플릿 설정 방법
PR 템플릿 설정 방법은 엄청 간단하다.
1. 프로젝트의 최상위 경로에서 .github 폴더를 생성한다.
2. .github 폴더 안에 PULL_REQUEST_TEMPLATE.md 파일을 생성한다.
3. 마크다운 문법으로 원하는 PR 템플릿을 작성하면 끝!
내가 생각했을 때의 PR 템플릿의 이점
개인적으로는 매번 PR을 따로 작성하지 않아도 돼서 시간이 조금이라도 단축된다는 점이 좋은 것 같다.
또한 PR 템플릿에 중요한 내용을 주로 적용시켰기 때문에 작성하면서 작업 내역 등을 다시 한번 확인할 수 있고,
그로 인해 빠트린 부분이 없는지 생각하며 실수를 방지할 수 있을 것 같다.
리뷰어로써도 중요한 내용이 적혀있기 때문에 조금은 더 코드를 파악하기 용이할 것 같다.
팀적으로는 일관된 템플릿을 사용하는 게 팀원들이 PR을 확인했을 때 좋을 것 같고,
더불어 이렇게 템플릿이 있을 경우 나중에 새로운 팀원이 들어왔을 때도 편하지 않을까 하는 생각이 들었다.
아무래도 이렇게 규칙이 조금은 있는 편이 협업할 때 좋은 것 같다고 느끼기 때문일지도 ㅎㅎ ..
프로젝트마다 GitHub 이슈를 잘 활용하지 않아서 몰랐는데 이슈 템플릿도 만들 수 있다고 한다.
PR 템플릿과는 다르게 여러 개의 템플릿을 만들 수 있다는데 이 내용은 다른 포스트에 정리할 예정이다!
