1월3일

Pull Request 심화

저번 팀 프로젝트에서 PR을 처음 써보기 시작한 이후로 매우 많은 PR을 다뤘다.

그 때는 팀원들이 다들 군더더기 없는 코드로 잘 올려주셔서

PR이 올라오면 잘 됐거니 하고 강제 Merge pull request를 했고, 문제가 없었는데

 

이번 팀 프로젝트에는 코딩에 익숙치 않은 팀원들이 있어서

merge 하는 과정에 좀 더 신중을 기해야 하는 상황이 생겼다.

(팀 프로젝트에서 git을 안써보신 분도 계셨다.)

 

다행히 git 사용법이나 브랜치를 나눠 PR하는거까지 다 알려줘야 되는 상황은 아니었고

github 관리를 맡은 나만 merge PR 할 때 조심하면 됐는데

 

merge PR을 좀 더 까다롭게 확인 후 하는 과정에 대해 정리해보고자 한다.

 

리뷰어, 담당자 정하기

PR을 등록할 때 오른쪽에서 리뷰어와 담당자를 정할 수 있다.

• Reviewers: 현재 PR를 리뷰해줄 팀원을 지정한다.
• Assigness: 현재 PR 작업의 담당자를 지정한다.
  PR을 올리는 사람이 주로 담당자일 것이므로 assign yourself를 누르면 나로 지정된다.

톱니바퀴를 누르면 위처럼 팀원을 지정할 수 있다.

 

Review 작성

PR 한다면 확인하는 사람이 review를 작성할 수 있을텐데

파일 하나하나 변경점을 확인하며 오른쪽의 Viewed 버튼에 체크하여 file viewed의 개수를 채울 수 있다.

모든 파일을 다 확인했다면 Review changes 버튼으로 메시지와 함께 review를 끝내는데

 

세가지 옵션이 있어 보통 처음 PR을 할 때 여기서 많이 검색을 할 것이다.

정리하면 다음과 같다.

• Comment: 승인과 무관하게 일반적인 커멘트를 남긴다.
• Approve: Comment와 다르게 리뷰어가 승인하는 것으로, merge해도 괜찮다는 의견을 남기는 것이다.
• Request changes: 변경을 요청하는 것으로, 직역하자면 '병합하기전에 변경해야 하는 피드백을 남김'
  즉, 승인을 거부하는 것을 뜻한다.

 

정리

예전부터 PR을 사용하면서 궁금한 부분이었는데 이번 기회에 제대로 정리하게 되어 기쁘다.

앞으로도 깔끔하게 git을 사용할 수 있게끔 안전장치가 생긴 것 같아 

안심하고 PR을 할 수 있을 것 같다.

 

 

 

 

참고한 곳

https://devlog-wjdrbs96.tistory.com/231

[Github] Pull Request를 통해 코드리뷰(Code Review)하는 법