PR 관리 및 코드 리뷰 프로세스의 비효율성
협업 과정 진행 중 , PR을 올리고 승인하고 하는 연습을 모두가 하기 위해, 모두에게 관리자 권한을 부여했었다.
그 이후 ,,, 팀원 중 한 명이 실수로 main에 merge 하는 issue가 생겼다..(현우형이라고 말 진짜 안할 거임 진짜로).
또, 각자 모두 관리자 권한으로서 pr을 승인하고 그런 과정 중에 크게는 3가지의 단점이 존재했다.
PR 승인의 비일관성 및 커뮤니케이션 부족
- PR 승인을 모두가 하다 보니, PR을 언제 받았는지 무엇이 바뀌었는지 전파가 잘 안 되었다.
물론, 완료된 PR 목록을 가면 확인할 수 있었지만, 쉽게 실수하고, 무엇이 바뀌었는지도 모르는 상황이 일어났다.
이로 인해 코드 변경사항 추적이 어려워지고, 중요한 업데이트나 변경사항을 놓치는 경우가 발생했다.
책임 소재의 불명확성
- PR을 모두가 받다 보니 만약 문제가 발생했다면, 어디서 누군가의 merge로 문제가 발생했는지 불분명하여 좀 힘들었다.
이는 문제 해결 과정을 지연시키고, '어디서 문제가 발생했는지 추적'과 수정에 더 많은 시간과 노력이 소요되었다.
경험 부족으로 인한 merge 실수
- 물론 나도 경험이 부족하지만, 조금 더 숙련도가 부족한 팀원이 관리자 권한을 부여받다 보니 팀원의 실수가 있었다.
잘못된 merge로 인한 롤백 작업이 필요한 경우도 있었다
💻이러한 문제점들을 해결하기 위해서 방법을 찾아보았다.
브랜치를 보호하자!( Rulset)
구글링을 한 결과, 브랜치를 보호하는 방법이 있었다. 보호하는 방법으로는 Rule를 정하는 것이다.
초기설정
이렇게 우선 브랜치를 지킬 Ruleset 창을 와서 Rulset Name이름을 정한이후(Protect branch)
Bypass list에서는 이 모든 룰을 말 그대로 패스할 수 있는 목록을 정하는 것이었다. 팀장인 나에게 그 권한을 주었다( 무법자)
Target branches 에서는 보호할 브랜치를 정할 수 있다. 모든 브랜치를 포함하거나, 특정 이름의 패턴을 가진 브랜치를 보호할 수 있게끔 설정을 할 수 있었다. 나는 중요한 "main", "develop" 브랜치를 보호하기 위하여 이름 패턴을 설정하였다.
이제 룰을 세팅해 보자!
Branch rules에서는 원하는 규칙들을 설정할 수 있는데, 나는 기본적인 설정 몇 개만 체크하였다.
- Restrict updates: 특정 권한(Bypass 권한)을 가진 사용자만 브랜치를 업데이트할 수 있도록 제한합니다.
- Restrict deletions: 브랜치 삭제를 특정 권한(Bypass 권한)을 가진 사용자로 제한합니다.
- Require a pull request before merging: 모든 변경사항이 PR을 통해 검토되도록 합니다.
- Required approvals-1 : PR이 병합되기 전에 최소 1개의 승인(리뷰)이 필요합니다.
- Block force pushes: force push를 방지하여 히스토리 보호에 도움이 됩니다.
이렇게 브랜치 보호를 완료하였다. 권한이 잘 적용됐나 너무 궁금해서 토요일 저녁에 양심 없이 팀원 형에게 pr 올려달라고 부탁했다ㅎㅎ
(기다리는 중..)
이렇게 팀원의 화면에서는 1개의 리뷰 승인이 있어야 되고, merge의 권한이 막혀있다.
리뷰 승인
리뷰 승인을 위해서는 일반 comment와는 다르게 Files chaneged을 눌러 코드의 변경 사항을 확인하는 페이지를 가야 한다.
초록색 버튼인 Review changes를 클릭하면 밑 사진과 같은 리뷰창이 나온다!
- Comment (코멘트) : 일반적인 피드백을 명시적 승인 없이 제출.
- Approve (승인) : PR의 변경 사항을 검토하고 merge할 준비가 되었다고 판단할 때 사용.
- Request changes(변경 요청) : PR에 중요한 수정이 필요하다고 판단될 때 사용.
Pr Merge
본인을 제외한 다른 사람의 리뷰 승인이 떨어지면 팀장인 내가 병합을 할 수 있다
나는 이렇게 merge를 할 수 있다!!!!
🙇♂️ 결론
bypass를 통한 권한으로 브랜치 보호를 하였다. 다만 이건 우선 "브랜치 보호"라는 라는 목적만을 위해서 강력한 룰을 적용한 것이다.
피치 못할 상황을 대비하여 팀 내 내부규칙(팀장만 merge) 을 통해 보호하는 것이 합리적이라는 생각이 들었다.
우선 내가 하고자 하는 목적은 달성했다! (롤체 한판 해야지ㅎ)

'Git' 카테고리의 다른 글
Commit은 어느 시점, 어느 단위로 쪼개는 게 좋을까? (0) | 2025.03.31 |
---|---|
[GitHub]Issue 및 Pr Template (4) | 2024.09.02 |
[GitHub] 협업 과정 워크 플로우 (0) | 2024.08.11 |