Git branch protection rule setting (기초)

💡 깃 브랜치 세팅의 필요성

각 브랜치마다 기본적으로 세팅해야하는 것들이 있다.
예를들어 main 브랜치를 누구나 쉽게 merge하는 것을 방지하거나, 
어떻게해야 PR을 받을지 등의 설정이 필요하다. 

 

이번 포스팅에서는 Branch protection rule 들을 살펴보고 

간단하게 깃 브랜치별 필요한 설정을 기록한다.

그리고 전체적인 깃의 흐름을 파악해본다.

 

💡목차
1. Branch protection rule 
2. git branch별 세팅 예시 
3. git 협업 flow 예시

---

📚Branch protection rule

 

📗 Require a pull request before merging

병합 이전에 PR을 요청 후 공동 브랜치로 merge

 

 

- Require approvals 

일정 이상의 인원이 승인해야 병합 가능 (최소 멤버 수 설정)

 

-Dismiss stale pull request approvals when new commits are pushed

새로운 커밋이 push 되면 이전에 승인된 PR의 승인을 해제 (새로운 변경 사항과 충돌 방지)

 

-Require review from Code Owners

코드 영역 변경에 대해 코드 소유자들의 리뷰를 필수로 요구 (소유자의 승인 받기 전에 병합 X)

 

-Require approval of the most recent reviewable push

새로운 커밋을 push 했을 때 변경사항이 PR에 반영되면 리뷰어들이 변경 사항 리뷰할 수 있도록 

(항상 최신 변경 사항에 대한 리뷰 받을 수있음)

 

-> 체크 안하면 새로운 커밋 push 될 때마다 변경사항에 대한 승인이 강제되지 않음

 

 

📗  Require status checks to pass before merging

PR 병합되기 전에 특정한 상태 검사가 모두 통과되어야 함 

(품질이 보장된 코드만 병합 가능)

 

 

-Require branches to be up to date before merging

PR을 병합하기 전 브랜치가 최신 상태여야 함

 

📗   Require conversation resolution before merging

 

PR 관련된 대화나 댓글이 해결되어야 PR이 병합됨  (병합 이전에 모든 의견,이슈 해결 )

 

 

📗   Require signed commits 

 

보안 기능 중 하나로, 커밋이 서명되지 않으면 해당 커밋 PR 불가능

( 커밋 만든 개발자가 그 커밋을 만들었음을 증명)

 

📗   Require linear history

 

변경 이력이 선형적으로 유지되어야 한다.  (코드 병경의 추적 및 이해가 쉬움)

 

 

📗   Require deployments to succeed before merging

 

PR을 병합하기 전에 배포 작업이 성공적으로 완료 되어야 함 

(배포 작업 성공 여부 검증하여 시스템 안정성 유지)

 

 

📗   Do not allow bypassing the above settings 

설정된 규칙을 우회하지 못하도록 만듬 ( 설정 규칙 무시하고 PR을 병합하는 것을 방지 )

 

 

 

📗  Rules applied to everyone including administrators

  모든 사람에게 적용되는 규칙

 

 

- Allow force pushes  

push 권한이 있는 사용자에게 강제 푸시를 허용  (강제 푸시는 손상위험 있음)

 

- Allow deletions 

PR에서 파일또는 디렉토리 삭제를 허용 

 

---

📚 Git branch별 세팅 예시

브랜치는 main / deploy / feature 로 나누었다. 

 

🔍main

 

main 브랜치는 함부로 merge가 되어서는 안되기 때문에

모두의 승인이 있어야 하고, 읽기 전용으로 Lock 시켰다. 

 

 

🔍deploy

기본적으로 PR을 요청을 해야 merge 되도록 하고,

코드 소유자의 리뷰를 필수로 한다. 

 

 

🔍Feature

 

와일드카드 ( * ) 를 사용해서 Feat으로 끝나는 모든 브랜치의 규칙으로 만들어준다.

PR 이후에 브랜치를 삭제해야하기때문에,

Allow deletions을 체크해야 PR 승인 후 코드 주인이 branch를 바로 지울수 있다.

 

 

🧐 사실 더 체크해야 할 것은 많겠지만, 이제 막 협업을 시작해서 우리 팀에게는 이 정도만 있어도 될 것 같다.

 

---

📚 Git 협업  flow  

얼마전에 팀원들과 git 협업 연습을 해보았다. 

혼자 연습해보기는 했지만, 막상 여러명에서 하려고하니 난장판이 됐었다.

그래서 간단한 Git 협업 flow를 기록해본다.   (사진 X)

 

1. Repositories를 만들고 초기 명령어를 실행하여, 로컬 저장소와 원격 저장소를 연결 시켜준다 . 

 

2.  Project에서 Todo 리스트를 만들어두고 issue로 내보낸다. (Project는 public으로 설정)

 

3.  팀원 각자 맡은 Issue의 브랜치를 로컬, 원격 저장소에 각각 만들어준다. 개발 진행을 하고 업데이트 사항들을 원격으로 push 한 후 팀원들이 잘 이해 할 수 있도록 comment를 남긴다. 

 

4. 개발을 완료하면 PR을 작성한다.   (팀원은 코드 리뷰와 comment 또는 피드백을 남겨준다)

 

5. merge 조건이 충족되면 코드 담당자는 merge를 진행시킨다. 

 

6. 해당 issue는 닫아주고, merge된 브랜치는 원격/로컬 저장소에서 다 지워준다. 

 

7. 로컬 저장소의 deploy branch를 최신 버전으로 pull 한다.

 

8. 이 과정 반복

 

---