Github 랑 친해지기
라고 했지만 친해질수 있을까?
쓰면 쓸수록 어려운게 git 인거 같다
배운다고 배우지만 배울수록 모르는게 더 많은..
오늘은 그중에서 PR(Pull Request)를 알아보자
What is PR?
PR은 "Pull Request"의 줄임말.
Pull Request는 변경사항을 리뷰하고 병합하기 위해 다른 브랜치에 제안하는 요청. 자신의 브랜치에서 작업한 내용을 메인 브랜치나 다른 브랜치에 병합해달라고 요청할 때 Pull Request를 만들어서 다른 팀원들에게 review를 요청받고 별다른 문제가 없으면 승인을 받아야지 merge 할 수 있도록 하는 협업 명령어
그동안 했던 프로젝트에서는 Git관리를 주로 팀장님이 하셨기 때문에 딱히 신경쓸 부분이 없었는데 이번 심화반 프로젝트에서는 프론트, 백이 딱 나눠져 있고 내가 맡은 프론트 인원이 2명 뿐이고, 나 말고 다른 분은 아예 Git이 뭔지도 잘 모르시는 분이고.. 해서 어쩌다보니 Git을 배워야 일을 진행 할 수 있는 상황이 되어버렸다.
나 혼자 일할때는 PR이 뭐야 그딴거 몰라 하겠지만 팀프로젝트를 할때는 상당히 곤란해질 수 있는 부분
자동으로 마구 merge가 되어버려서 코드 다 날리고 싶은게 아니라면 최소한의 장치가 필요하겠다 싶었다.
그래서 PR에 rule을 만들기로 함.
알고보니 전 프로젝트에서 내가 만들진 않았었지만 이미 하고있었기도 했고 이참에 설정하는 법 알아놓으면 좋으니까
- Reviewer 설정
- 누구에게 Review를 받을지 정하기
- 프론트 팀원 2명을 reviewer로 선택
- pr 신청을 하면 저 2명에게 request가 가고
- 2명이 확인을 해야한다(인원수는 아래에서 결정)
- 1명 이상에게 Review 받지 못하면 merge 못하게 하기
- request를 받았으면 본인 코드와 비교해서 충돌이 있는지 없는지 확인
- merge하면 안되는게 있는지 등도 확인 가능!
- 문제가 없다면 merge confirm해준다
- 1명 이상에게 comment를 받을지 어떨지는 선택 가능
- 메인에 바로 올리지 않고 dev에서 합치기
- 메인에 바로 올리면 문제가 생길수 도 있기 때문에
- 개인이 작업한 브랜치에 올리고
- 브랜치에 올렸으면 review 받고 dev에 합치기
Rule 정하기
- Repository → settings
- General → Rules → Rulesets

- New ruleset → New branch ruleset

- Ruleset Name 설정 → Enforcement status 를 Active로 전환

- Target Branch 설정
- 규칙을 적용할 브랜치 설정하기

- Branch rules 에서 원하는 내용 활성화 하기
- 내가 원하는건 merge 전에 Pullrequest를 받아야 merge할 수 있는 거였으니까 저부분만 체크하기

브랜치 규칙 해석
- 생성 제한
- 업데이트 제한
- 삭제 제한
- 선형 히스토리 요구
- 병합 대기열 요구
- 배포 성공 요구
- 서명된 커밋 요구
- 병합 전 풀 리퀘스트 요구
모든 커밋은 대상이 아닌 브랜치에 이루어지고 풀 리퀘스트를 통해 review를 받아야 merge 가능*
- 상태 확인 요구
- 강제 푸시 차단
- 코드 스캔 결과 요구
- 이제 Rule을 정했으니 Pull request 했다고 바로 합쳐지지 않는다!