앞에서 팀원의 머지 실수를 방지하기 위해서 Branch protection rule을 지정하여 리뷰하는 방법을 기록하고자 합니다.
Require approvals를 체크
해야 PR을 했을 때 승인을 해주는 상대방이 1~여러명이 가능합니다! 이렇게 하면 무분별한 merge로 사고를 방지할 수 있습니다.
리뷰를 통해 Approve를 하는 경우
Review를 통해 Request changes를 하는 경우
승인 기능을 사용하면서 처음 알게된 부분이 PR을 하고나서 merge를 안했다면 커밋을 추가하더라도 추가된 기록이 기존 open 된 PR에 기록이 되어진 다는 것입니다. 이것을 몰랐을 때는 항상 PR이미 해버렸다고 하면서 추가로 커밋을 하지 않고 머지 후에 추가작업을 했던 저를 반성했습니다 ^^;
코드리뷰할 때 편하게 보는 방법
Viewed를 눌러두면 계속 기록이 저장되기 때문에 reviewer가 두고두고 몇일에 걸쳐서 리뷰를 한다면 본인이 이 코드를 봤는지 안봤는지 알아둘 필요가 있어서 저 Viewed 체크박스를 이용해서 코드리뷰가 필요한 파일들을 구분시키는 것이 매우 유용했습니다.
'Project History > - Seoul Dev Competition' 카테고리의 다른 글
nextjs typescript, tailwindcss의 eslint, prettier 설정 정리 (0) | 2023.05.08 |
---|---|
웹 개발 중에 페어 프로그래밍의 이해와 경험 정리 (0) | 2023.05.06 |
nextjs 백엔드 JWT 쿠키 저장 구현 (0) | 2023.05.05 |
git reset --hard 경험 기록 (0) | 2023.04.27 |
서울 열린데이터광장 공공데이터 활용 웹 개발 - 3주차 정리 (0) | 2023.04.24 |
폴더 구조를 출력하여 협업에 사용하기 (0) | 2023.04.24 |
댓글