나의 깃허브를 지키자

Github protection rule

같이 작업을 하기 위해서 깃허브를 사용하지만 바로 적용시키다보면 무질서해질 수 있다. 컨벤션을 따르지 않거나 실제로 오류가 나면서 사소한 변경이라고 생각해서 바로 푸시할 경우 등이 있을 것이다.
따라서, 깃허브에서는 이를 방지하고자 branch별로 protection rule을 적용시킬 수 있다.

1. 경로 : Github repository의 Settings → Branches

   • 추가시 : Add rule
     • 최초 추가시 : Add branch protection rule

2. Branch name pattern : 적용시킬 브랜치 명

   • 원하는 브랜치를 적용할 수 있지만 main 혹은 develop 브랜치가 아닐 경우 조금 더 포괄적으로 적용시킬 필요가 있다.
     • 와일드카드(*)을 사용하자.
       • 모든 브랜치에 대해 적용시키고 싶다면 *만 작성
       • 혹은 특정 단어로 시작하는 것에 대해 적용시키고 싶다면 feature-* 형식으로 작성할 수도 있겠다.
       • 단어가 포함된 것에 대해 적용시키고 싶다면 *feature* 같이 작성
   • 우선순위 : 먼저 적용시킨 rule이 우선순위가 된다.
     • 따라서, main 브랜치에 대한 rule을 먼저 적용시킨 뒤 *에 대한 브랜치 rule을 적용시켜도 main은 기존 rule을 따른다.

3. Protect matching branches

   • Require a pull request before merging
     • 가장 필요한 것이 아닌가 생각이 든다.
     • 다른 브랜치에서 작업을 한 뒤 해당 브랜치로 merge를 할 수 있도록 정해주는 것
     • options
       • Require approvals : review에 대해 몇 명의 approve가 필요한가!
       • Dismiss stale pull request approvals when new commits are pushed
         • 기존에 approve된 상태에서 새로운 pr이 들어온다면 기존 approve를 해제할 것인가!
       • Require review from Code Owners : 코드 소유자에게 pr을 받아야하는가!
       • Require approval of the most recent reviewable push
         • 사실 잘 모르겠다. 다른 사람의 pr을 approve하고 안좋은 코드를 제출한 뒤 스스로 approve를 할 때 사용하는 것이라고는 하는데...
         • 알아보자
   • Require status checks to pass before merging
     • status check(테스트 결과 이상이 없을 시)를 통과해야 merge 가능
   • Require conversation resolution before merging
     • 모든 conversation을 resolve해야 merge 가능
   • Require signed commits
     • 모든 commit은 작성자의 서명(Verified된 사용자)이 필요
   • Require linear history : merge commit이 히스토리에 남지 않도록 한다.
     • 히스토리 추적을 쉽게하기 위함
   • Require deployments to succeed before merging
     • deployment(배포)가 성공해야 merge 가능
   • Lock branch : read-only로 만든다.
   • Do not allow bypassing the above settings
     • administrator도 포함시키기

4. Rules applied to everyone including administrators

   • 2개는 특별한 일이 아니면 사용하지 말라고 한다.