Github에서 분기 보호 설정 시 작업 노트

개요

지점의 운용 주위를 정리하고,
지금까지 잘 깨닫지 못해서 노트를 남겼어요.

단계

분기 보호 설정 화면 열기

저장소 위쪽Settings

Settings 메뉴에서 Branches

Branch protection rules의Add rules

화면 설정

Branch name parttern

빨간 테두리 부분Branch name pattern...어?
참고로 보도된 기사를 보니, 나는 내가 한 지점을 선택했다고 생각한다
요즘 좀 바뀐 것 같아요.
도안 성냥을 사용할 수 있습니다...!!!(기대가 크다)
공식 문서
역시 사용할 수 있는 모양입니다.🤪
※ 여기feature/*에서 이렇게 지정하면 작업 지점도 push 할 수 없으므로 주의해야 합니다.

Rule settings

Protect matching branches
패턴에 맞는 지점 이름이 강제적으로 push되거나 삭제되지 않도록 보호합니다
※ 이 설정은 반드시 들어갑니다.
Require pull request reviews before merging
패턴과 일치하는 지점으로 통합하기 전에 드래그 요청에서 심사 설정을 받아들여야 합니다.
이 설정을 추가하면 "확인"전에 병합할 수 없습니다
게다가 검사를 하면 항목은 다음과 같이 전개된다

Required approving reviews

approve의 최소한의 수량을 설정(예를 들어 2로 설정하면 최소 2명의 승인이 필요함)

Dismiss stale pull request approvals when new commits are pushed

승인 후push에 새로운commit가 있으면 자동으로 승인 취소

Require review from Code Owners

코드 소유자의 설정을 보려면 = > 참고 자료

Restrict who can dismiss pull request reviews

프롤릭의 검토를 거부할 수 있는 사람, 팀을 지정할 수 있는 사람

Require status checks to pass before merging
CI 등 서비스 제휴 시 설정.
CI 등의 실행이 성공하지 않으면 통합할 수 없습니다.
선택하면 다음과 같이 확장됩니다.

Require branches to be up to date before merging

저장소에서 일부 서비스를 협업할 때 여기에 표시되며, 각 서비스는 보호 조건에 포함될 수 있습니다

Require signed commits
서명 제출 요구 설정
서명이 없으면 합병할 수 없다
Include administrators
관리자도 이 지점 보호 제한에 포함됩니까
선택한 경우 관리자도 병합할 수 없습니다.
Restrict who can push to matching branches
패턴과 일치하는 지점으로 밀어낼 수 있는 사람을 제한할 수 있습니다.
선택하면 다음과 같이 확장됩니다.

확장된 양식에서 승인할 사람 또는 팀 이름을 입력하고 선택합니다.

값 설정

결과적으로 ↓의 느낌으로 정리되었다

지점의 모델 지정은 지점의 운용에 따라 달라지기 때문에 어느 것이 최선의 실천이 없는 것 같습니까?↓

master 또는 main

이야, 이건 절대

release/*

지계 발표도 당연하다

develop/*

develop 지점도 같은 설정으로 운용보호

참고 자료

[GitHub] 브랜치 보호 설정 활용 [심사 통과 전까지 통합하지 않음]

끝내다