Branch Protection 무엇일까요 ?
프로젝트에서 여러 사람들과 함께 협업을 할 때, main (또는 master) 브랜치는 주요한 코드 기반이며, 개인이 임의로 이 브랜치의 코드를 수정해서는 안 됩니다. 이를 위해서 GitHub Branch Protection을 사용하면 특정 브랜치에 대한 접근과 변경에 대한 제어를 강화할 수 있습니다. 이렇게 함으로써 협업 환경에서 코드의 안정성과 품질을 유지하며 프로젝트를 보호할 수 있습니다.
이러한 제어 기능을 사용하면 다음과 같은 장점을 얻을 수 있습니다.
-
안정성 유지: main 또는 master 브랜치는 보통 제품 릴리스나 배포에 사용되는 중요한 브랜치입니다. 이 브랜치를 보호하면 품질 검증을 거친 안정적인 코드만이 병합되어 배포될 수 있습니다.
-
실수 방지: 강제 푸시를 제한하고, 코드 리뷰 및 상태 체크 등을 요구함으로써 실수로 인한 코드 손상을 방지할 수 있습니다. 특히 main 또는 master 브랜치에서의 실수는 전체 프로젝트에 영향을 미칠 수 있으므로, 이를 사전에 방지하는 것이 중요합니다.
-
코드 리뷰 강화: 풀 리퀘스트를 열 때 특정 리뷰어의 승인을 요구함으로써 코드 리뷰 프로세스를 강화할 수 있습니다. 이는 코드 품질을 높이고 버그 및 보안 취약점을 사전에 찾을 수 있는 기회를 제공합니다.
-
협업 강화: 변경 사항을 다른 사람들과 함께 검토하고 논의함으로써 팀 내 협업을 강화할 수 있습니다. 모두가 변경 사항에 대해 동의하고 검증을 거친 후에만 병합할 수 있도록 하는 것이 중요합니다.
이제 설정을 해볼까요 ?
설정할 레포지토리에서 Setting -> Branches를 클릭합니다.
저는 기존에 만들어 놓아서 main 에 대한 rule이 적용되어 있네요 !
Add rule를 해볼까요 ?
되게 많은 것들이 있네요 ! 하나하나 알아보겠습니다.
Branch name Pattern
- 설정한 rule 규칙들에 영향을 받을 브랜치를 설정합니다. main과 같이 특정 브랜치를 입력하면 해당 브랜치에만 적용이 되고, 와일드카드( * )를 이용하면 모든 브랜치에 적용되게 됩니다.
Require a pull request before merging
- 옵션을 활성화하면 해당 브랜치에 대한 수정 사항을 머지하기 위해서는 반드시 풀 리퀘스트를 열고 해당 풀 리퀘스트를 검토 및 승인 받아야 합니다. 직접적으로 브랜치에 코드를 푸시하여 수정하는 것이 아니라, 풀 리퀘스트를 통해 변경 사항을 제출하고 검토를 거친 후에만 머지할 수 있습니다.
Require status checks to pass before merging
- 개발자가 풀 리퀘스트를 생성하거나 브랜치를 머지하려고 할 때, 지정된 상태 체크(일반적으로 CI/CD 파이프라인의 테스트 및 빌드)가 자동으로 실행됩니다.
- GitHub Actions 또는 다른 CI/CD 도구를 사용하여 테스트 코드나 다양한 검증 작업을 실행할 수 있습니다.
- 만약 상태 체크가 성공적으로 완료되면, 해당 변경 사항은 머지될 수 있습니다.
- 하나라도 상태 체크가 실패하면, 해당 변경 사항은 머지되지 않습니다.
이렇게 함으로써 개발자들은 변경 사항을 머지하기 전에 코드 품질과 안정성을 검증하는 과정을 거치게 됩니다. 상태 체크를 통해 자동화된 테스트나 검증 작업이 수행되므로, 코드의 문제나 버그를 사전에 확인하고 수정할 수 있습니다.
참고 링크
Require conversation resolution before merging
- 풀 리퀘스트에 남겨진 모든 코멘트(코드 리뷰나 논의 사항)가 해결되거나 답변을 달아주어야만 해당 풀 리퀘스트가 머지될 수 있습니다.
Require signed commits
- 서명된 커밋만 푸시할 수 있도록 규칙을 설정하는 옵션입니다. 서명된 커밋은 개발자의 개인 키를 사용하여 디지털 서명을 한 커밋으로, 커밋의 무결성과 출처를 보장해주는 역할을 합니다.
Require linear history
- 선형적인 히스토리를 유지하기 위해 일반적인 머지를 막고, 스쿼시나 리베이스와 같은 방식을 사용한 머지만을 허용하는 규칙을 설정하는 옵션입니다.
- 브랜치 히스토리가 단순하고 선형적인 구조를 유지하게 되어, 문제 발생 시 히스토리 추적과 이전 상태로 복원하기가 더 쉬워집니다. 특히 큰 팀이나 복잡한 프로젝트에서 이 옵션을 활성화하여 코드 히스토리를 관리하면 혼란을 줄이고 유지 보수를 용이하게 할 수 있습니다.
Require merge queue
- 특정 브랜치에 대한 머지 작업을 머지 큐를 통해서만 허용하도록 설정하는 옵션입니다.
Require deployments to succeed before merging
- 머지되기 전에 특정 환경으로의 배포가 성공해야만 머지가 가능하도록 규칙을 설정하는 옵션입니다. 이러한 방식으로 변경 사항이 배포 환경에서 성공적으로 테스트되고 배포됨을 보장하여, 머지된 코드의 품질과 안정성을 높일 수 있습니다.
Lock branch
- 특정 브랜치를 읽기 전용으로 만들어서 더 이상 푸시를 할 수 없도록 제한하는 옵션입니다. 이를 통해 다른 개발자들이 해당 브랜치에 새로운 코드나 변경 사항을 푸시하는 것을 방지할 수 있습니다.
Do not allow bypassing the above settings
- 관리자와 "branch protections 우회" 권한이 있는 사용자에게도 위 설정을 적용합니다.
Restrict who can push to matching branches
- 지정된 사용자, 팀 또는 앱만 해당 브랜치에 푸시할 수 있도록 제한합니다. 하지만 필요한 상태 체크가 실패하면 머지가 불가능합니다.
Rules applied to everyone including administrators
- 관리자 권한을 가진 사용자들도 설정된 보호 규칙을 무시하고 변경 사항을 머지하거나 수정할 수 없도록 막습니다. 이를 통해 보안과 프로젝트의 일관된 규칙 준수를 유지할 수 있습니다.
Allow force pushes
- 강제 푸시를 허용합니다.(push 권한이 있는 모든 사용자에게 적용)
Allow deletions
- 푸시 권한을 가진 사용자가 해당 브랜치를 삭제할 수 있도록 허용합니다.
추가적으로 하면 좋아요 !
Git issue template를 사용하면 프로젝트의 이슈 관리를 더 체계적으로 수행할 수 있으며, 효율성과 협업성을 향상시킬 수 있습니다.
이슈 템플릿 관련 링크
