Branch Rules (브랜치 규칙)

Branch Rules (브랜치 규칙)

This section outlines the different rules you can apply to branches in your repository to control how changes are made and merged. (이 섹션은 변경 사항이 어떻게 이루어지고 병합되는지 제어하기 위해 리포지토리의 브랜치에 적용할 수 있는 다양한 규칙을 설명합니다.)

• Restrict creations (생성 제한):
  • Only allow users with bypass permission to create matching refs. (바이패스 권한이 있는 사용자만 일치하는 참조를 생성할 수 있도록 허용합니다.)
  • 한글 해설: 특정 브랜치 이름 패턴(matching refs)에 해당하는 브랜치를 생성할 수 있는 사용자를 바이패스 권한을 가진 사용자로 제한합니다. 즉, 일반 사용자는 특정 브랜치를 함부로 만들 수 없게 합니다.
• Restrict updates (업데이트 제한):
  • Only allow users with bypass permission to update matching refs. (바이패스 권한이 있는 사용자만 일치하는 참조를 업데이트할 수 있도록 허용합니다.)
  • 한글 해설: 특정 브랜치 이름 패턴(matching refs)에 해당하는 브랜치를 업데이트(push)할 수 있는 사용자를 바이패스 권한을 가진 사용자로 제한합니다. 즉, 일반 사용자는 특정 브랜치에 함부로 코드를 push할 수 없게 합니다.
• Restrict deletions (삭제 제한):
  • Only allow users with bypass permissions to delete matching refs. (바이패스 권한이 있는 사용자만 일치하는 참조를 삭제할 수 있도록 허용합니다.)
  • 한글 해설: 특정 브랜치 이름 패턴(matching refs)에 해당하는 브랜치를 삭제할 수 있는 사용자를 바이패스 권한을 가진 사용자로 제한합니다. 즉, 일반 사용자는 중요한 브랜치를 함부로 삭제할 수 없게 합니다.
• Require linear history (선형 히스토리 요구):
  • Prevent merge commits from being pushed to matching refs. (일치하는 참조로 병합 커밋이 푸시되는 것을 방지합니다.)
  • 한글 해설: 특정 브랜치 이름 패턴(matching refs)에 해당하는 브랜치에 merge commit이 포함된 push를 금지합니다. 이는 브랜치의 history를 깔끔하게 유지하기 위해, merge commit이 아닌 rebase를 통해 변경사항을 반영하도록 유도합니다.
• Require deployments to succeed (배포 성공 요구):
  • Choose which environments must be successfully deployed to before refs can be pushed into a ref that matches this rule. (이 규칙과 일치하는 참조로 푸시되기 전에 성공적으로 배포해야 하는 환경을 선택합니다.)
  • 한글 해설: 특정 브랜치 이름 패턴(matching refs)에 해당하는 브랜치에 push 하기 전에, 특정 환경(예: staging, production)에 성공적으로 배포가 완료되어야 함을 요구합니다. 코드 안정성을 높이기 위한 규칙입니다.
• Require signed commits (서명된 커밋 요구):
  • Commits pushed to matching refs must have verified signatures. (일치하는 참조로 푸시된 커밋은 확인된 서명이 있어야 합니다.)
  • 한글 해설: 특정 브랜치 이름 패턴(matching refs)에 해당하는 브랜치에 push되는 모든 커밋은 유효한 서명(예: GPG 서명)을 가지고 있어야 합니다. 이는 커밋의 무결성을 보장하고 위조를 방지하기 위한 규칙입니다.
• Require a pull request before merging (병합 전 풀 리퀘스트 요구):
  • Require all commits be made to a non-target branch and submitted via a pull request before they can be merged. (모든 커밋은 대상이 아닌 브랜치에 작성되고 병합되기 전에 풀 리퀘스트를 통해 제출되어야 합니다.)
  • 한글 해설: 직접 특정 브랜치(target branch, e.g., main, develop)에 commit하는 것을 금지하고, 반드시 별도의 브랜치에서 작업 후 pull request를 통해 코드 리뷰를 거쳐야 병합할 수 있도록 합니다. 코드 품질 향상과 협업을 위한 중요한 규칙입니다.
• Required approvals (필수 승인):
  • The number of approving reviews that are required before a pull request can be merged. (풀 리퀘스트를 병합하기 전에 필요한 승인 리뷰의 수입니다.)
  • 한글 해설: 풀 리퀘스트를 병합하기 위해 필요한 최소 승인 리뷰 수를 설정합니다. 코드 리뷰의 품질을 높이고, 다양한 의견을 반영하기 위한 규칙입니다.
• Dismiss stale pull request approvals when new commits are pushed (새 커밋 푸시 시 오래된 풀 리퀘스트 승인 해제):
  • New, reviewable commits pushed will dismiss previous pull request review approvals. (새로운 검토 가능한 커밋이 푸시되면 이전 풀 리퀘스트 검토 승인이 해제됩니다.)
  • 한글 해설: 풀 리퀘스트에 새로운 커밋이 추가되면 기존의 승인 리뷰를 무효화합니다. 변경 사항에 대한 최신 리뷰를 받도록 강제하여 코드 품질을 유지합니다.
• Require review from Code Owners (코드 소유자의 리뷰 요구):
  • Require an approving review in pull requests that modify files that have a designated code owner. (지정된 코드 소유자가 있는 파일을 수정하는 풀 리퀘스트에서 승인 리뷰를 요구합니다.)
  • 한글 해설: 특정 파일 또는 디렉토리의 코드 소유자(Code Owners)가 변경 사항을 리뷰하고 승인해야 풀 리퀘스트를 병합할 수 있습니다. 해당 영역에 대한 전문 지식을 가진 사람의 검토를 거치도록 보장합니다.
• Require approval of the most recent reviewable push (최근 검토 가능한 푸시에 대한 승인 요구):
  • Whether the most recent reviewable push must be approved by someone other than the person who pushed it. (가장 최근의 검토 가능한 푸시가 해당 푸시를 한 사람이 아닌 다른 사람에 의해 승인되어야 하는지 여부입니다.)
  • 한글 해설: 풀 리퀘스트에 포함된 가장 최근의 변경사항(push)은 반드시 작성자가 아닌 다른 사람의 승인을 받아야 합니다. 이는 자기 검열을 방지하고 객관적인 시각으로 코드를 검토하도록 유도합니다.
• Require conversation resolution before merging (병합 전 대화 해결 요구):
  • All conversations on code must be resolved before a pull request can be merged. (코드에 대한 모든 대화는 풀 리퀘스트를 병합하기 전에 해결되어야 합니다.)
  • 한글 해설: 풀 리퀘스트 내의 모든 코드 관련 코멘트(conversations)가 해결(resolved)되어야 풀 리퀘스트를 병합할 수 있습니다. 미해결된 논쟁이나 질문 없이 코드를 병합하여 코드 품질을 향상시키고 잠재적인 문제 발생을 줄입니다.
• Request pull request review from CopilotPreview (CopilotPreview로부터 풀 리퀘스트 리뷰 요청):
  • Automatically request review from Copilot for new pull requests, if the author has access to Copilot code review. (작성자가 Copilot 코드 리뷰에 액세스할 수 있는 경우, 새 풀 리퀘스트에 대해 Copilot으로부터 자동으로 리뷰를 요청합니다.)
  • 한글 해설: 풀 리퀘스트 생성 시 자동으로 GitHub Copilot에게 코드 리뷰를 요청합니다 (작성자가 Copilot 코드 리뷰 기능을 사용할 수 있는 경우). Copilot의 자동 코드 리뷰를 통해 초기 단계에서 코드 품질을 개선하고 잠재적인 문제를 식별할 수 있습니다.
• Allowed merge methodsPreview (허용된 병합 방법 미리보기):
  • When merging pull requests, you can allow any combination of merge commits, squashing, or rebasing. At least one option must be enabled. (풀 리퀘스트를 병합할 때 병합 커밋, 스쿼시 또는 리베이스의 조합을 허용할 수 있습니다. 적어도 하나의 옵션은 활성화되어야 합니다.)
  • 한글 해설: 풀 리퀘스트를 병합할 때 사용할 수 있는 병합 방법(merge commits, squashing, rebasing)을 선택합니다. 프로젝트의 히스토리 관리 정책에 따라 적절한 병합 방법을 선택하여 일관성을 유지할 수 있습니다. 최소한 하나의 병합 방법은 활성화되어야 합니다.
• Require status checks to pass (상태 확인 통과 요구):
  • Choose which status checks must pass before the ref is updated. When enabled, commits must first be pushed to another ref where the checks pass. (참조가 업데이트되기 전에 통과해야 하는 상태 확인을 선택합니다. 활성화되면 커밋은 먼저 검사가 통과되는 다른 참조로 푸시되어야 합니다.)
  • 한글 해설: 특정 브랜치 이름 패턴(matching refs)에 해당하는 브랜치에 push 하기 전에, 설정된 상태 확인(status checks, e.g., 빌드 성공, 테스트 통과, 린트 통과)을 모두 통과해야 합니다. 코드 품질 및 안정성을 확보하기 위한 중요한 규칙입니다. 먼저 다른 브랜치에 push하여 상태 확인을 통과한 후, 해당 브랜치를 target branch에 병합해야 합니다.
• Block force pushes (강제 푸시 차단):
  • Prevent users with push access from force pushing to refs. (푸시 권한이 있는 사용자가 참조로 강제 푸시하는 것을 방지합니다.)
  • 한글 해설: 특정 브랜치 이름 패턴(matching refs)에 해당하는 브랜치에 force push(-f 옵션 사용) 하는 것을 금지합니다. 히스토리 꼬임 및 데이터 손실 위험을 줄이기 위한 규칙입니다.
• Require code scanning results (코드 스캔 결과 요구):
  • Choose which tools must provide code scanning results before the reference is updated. When configured, code scanning must be enabled and have results for both the commit and the reference being updated. (참조가 업데이트되기 전에 어떤 도구가 코드 스캔 결과를 제공해야 하는지 선택합니다. 구성되면 코드 스캔이 활성화되어 있어야 하며 업데이트되는 커밋과 참조 모두에 대한 결과가 있어야 합니다.)
  • 한글 해설: 특정 브랜치 이름 패턴(matching refs)에 해당하는 브랜치에 push하기 전에, 설정된 코드 스캔 도구(예: SonarQube, Snyk)의 결과가 있어야 합니다. 코드 취약점 및 보안 문제를 사전에 감지하고 해결하기 위한 규칙입니다.