[종합 프로젝트] Branch Protection Rule 적용

Branch Protection Rule 을 적용한 이유

• 특정 Branch가 실수로 지워지는 것을 방지 가능
• Pull Request 가 아닌 다른 방식으로 Commit 을 추가하는 것을 막아서 코드 리뷰를 강제함
• 로컬에서는 아무렇게나 작업해도 제약이 없지만, 협업할 것이라면 프로텍션 룰을 적용하는게 좋음

---

Require a pull request before merging

• 브랜치로 적용될 커밋들은 반드시 보호되지 않는 브랜치로 일단 커밋되고, Pull Request (이하 PR) 과정을 거쳐서 리뷰 된 다음 merge 되도록 함
• 예: develop 브랜치에 팀원이 작업을 하는 경우, develop 브랜치에 해당 보호를 걸어주고 각자 자기 개발 브랜치 (feature 브랜치)에 작업을 한 다음, PR을 통해서 develop 브랜치로 코드를 반영하도록 함

---

Require a status checks to pass before merging'

• 테스트 결과 이상이 없을 시에만 merge 가능
• Require branches to be up to data before merging: PR이 항상 최신 브랜치 상태에서 테스트 됨

---

Require conversation resolution before merging

• PR의 모든 Conversation (토론)이 해결되어야 merge 가능
• PR을 올린 개발자와 리뷰어가 PR에 대한 변경 사항을 논의하고, PR에서 요청한 변경 사항에 대해 양측 모두가 합의할 수 있도록 함
• 이 규칙을 사용하면 PR에 대한 변경 사항에 대해 모든 의견이 공유되고 이해 되었는지 확인 가능해서 의견 차이나 갈등 해결 할 수 있음

---

Require signed commits

• GPG (GNU Privacy Guard) 서명이 필요하도록 설정함
• GPG 서명을 사용하면 커밋이 실제로 특정 개발자에 의해 만들어졌음을 증명할 수 있음
• 이 규칙은 개발자들이 코드에 대한 책임을 더욱 강제화하고, 코드 무결성을 유지하는데 도움 됨
• 보안에 민감한 프로젝트에서 사용

---

Require linear history

• Rebase 를 사용하여 브랜치를 병합하지 않도록 강제함
• 브랜치를 병합할 때 항상 merge 를 사용하여 브랜치를 병합해야해서 Git 히스토리가 복잡해질 수 있음
• 커밋 히스토리가 단순하고 깨끗하게 유지 됨

---

Include adminisrators

• 모든 보호 규칙들이 관리자에게도 적용되도록 함

---

Allow force pushes

• Force push 를 사용하면 이전 버전의 커밋을 무시하고 현재 변경 사항을 강제로 새로운 커밋으로 밀어 넣음
• 초보자가 잘못 사용할 경우, 저장소의 커밋 히스토리를 손상시킬 수 있으므로 주의해야 함

---

Allow deletions

• 저장소의 브랜치에서 파일을 삭제할 수 있도록 허용하거나 제한 가능
• 팀 내에서 파일 삭제에 대한 권한을 세밀하게 제어 가능
• 초보자가 사용하면 실수로 저장소에서 필요한 파일을 삭제할 수 있으므로 사용하지 말기

 

---

참고

1. https://hbase.tistory.com/215