Git 사용 ~~ PR Review

협업엔 규칙이 따른다. 그것이 누군가를 귀찮게 하지만 결국 다수가 하나를 사용하기 위한 가장 적절한 방법이기 때문이다.

이전 회사에 근무할땐 T사에서 저런걸 할리가 없다. 그냥 그런회사 아닌가.
그 전회사인 anypointmedia 는 잘 구축되어 돌아갔다. 협업의 관점이 괜찮았다고나 할까.
그것과 똑같은 수는 없지만, 또 똑같을 필요도 없겠지만 정리를 해본다.

1. 서브 브랜치 명명 규칙

• 보통 Prefix를 사용하여 브랜치를 구분지어 생성 한다.

Prefix	용도	예시
feature/	새로운 기능 개발	feature/login-api
fix/	버그 수정	fix/navbar-overlap
hotfix/	긴급 수정	hotfix/payment-error
release/	릴리스 준비	release/v1.2.0
chore/	잡일, 설정 변경 등	chore/update-eslint
test/	테스트 관련 작업	test/unit-login
docs/	문서 수정	docs/readme-update
refactor/	리팩토링	refactor/user-service

프리픽스 + 슬래쉬(/) + 설명명 을 하이픈으로 구분!

2. github, gitlab 등에서 PR (Pull Request) 만듬

• 리뷰어 지정, 팀원에게 알림

3. 코드 리뷰 요청 & 리뷰 작성

• PR 올라오면 팀원 또는 오픈소스 기여자들이 코드를 확인하고 의견을 제시함.
• 코드리뷰를 작성할 수 있음

4. Files changed 확인

• PR 페이지에서 Files changed 를 보면 변경된 파일과 코드 라인이 표시
• 수정된 코드를 상세히 보면서 피드백 부분이나 의견 제시

5. 라인별 코멘트 달기

• 코드 라인 번호 근처에 마우스 올리면 + 아이콘 나타남
• +아이콘 클릭하면 해당 줄에 대한 코멘트 남길 수 있음
• 제안이 있는 경우 Suggested change 형식으로 작성

suggestion
// 다음과 같은 코드면 어떨까?

• 남긴 코멘트는 원작자가 commit suggestion 으로 바로 적용 가능
  -> 브랜치에 적용
• 커밋 후 git pull 통해 변경 내려받아 내용 확인

6. Review changes > submit

• 코멘트 모두 단 뒤, 화면 우측 상단 Review changes 버튼 누름
• 필요 따라 Comment(단순의견), Approve(승인), Request changes(수정요청) 등 옵션 선택 후 최종적으로 submit 함

7. pull request 에 review 달림 -> 리뷰 확인 후 수정 제안 반영

• 깃 리포지토리에 내가 만든 pull request로 이동
• PR conversation 탭이나 Files changed 탭을 통해 내용 확인
• 코드 블록 위에 suggested change 로 표시된 부분 찾기
• 코멘트 오른쪽의 commit suggestion 버튼을 누르면 해당 제안 바로 브랜치에 커밋
• 여러 제안이 있다면 add suggestion to batch 로 모아둔 뒤 한번에 커밋도 가능

8. 변경사항 확인 후 머지

• suggested change 반영하면 새로운 커밋이 pr에 자동으로 추가
• 코드가 문제없이 동작하는지 확인 후 팀원들과 논의를 거쳐 (사내 규칙 필요) PR을 Merge 함

9. 로컬 반영 해보기

• pull request 브랜치 체크아웃
• 제안된 내용을 수동으로 반영 : 리뷰 코멘트 참조해 적절하게 수정함
• 커밋 하고 푸시하고
• pull request 에 새로운 커밋 반영 확인 : 변경된 커밋내용 확인하고 추가 피드백 대응

참고. 반영 분류

• 사내 정책에 따라 메인 브랜치에서 dev, staging, prod 등의 환경으로 나뉨
• 이전 재직하던 회사에선 개발을 feature 를 따서 하고
• PR 리뷰 다 끝난것은 dev로 반영을 하고
• 그 시기것의 (비슷한 시기) dev를 실행 체크하여 전반적 (특히 개발데이터 및 화면) 문제 없으면
• staging 에 반영하겨 상용 DB와 같은 수준의 데이터 체크를 하고
• 역시 문제 없으면 한데 모아 prod 에 상용 커밋 푸시를 진행하였음
• 여러 단계를 거치지만 한번에 반영하기 무리인 경우나 절차적 오류 확인에는 도움이 됨
• 다만 역시 다수의 배포로 인해 시간이 오래 걸리는건 어쩔 수 없음이었음.