여러 사람들이 동시에 같은 코드 베이스에서 작업을 하다보면 여러가지 문제가 생길 수 있다. 허락받지 않은 사람이 무질서하게 코드를 작성하고 머지하는 경우도 발생할 수 있다. 깃허브는 'Pull Request(PR)'라는 작업으로 코드를 머지할 때 리뷰를 받을 수 있는 장치를 제공하고 있다.
기본적으로는 PR을 받지 않고 코드를 머지할 수 있지만 중요한 코드의 경우 반드시 리뷰를 받고, 일정 테스트를 통과해야 코드를 머지할 수 있도록 설정할 수도 있다.
Github 브랜치 보호규칙
깃허브는 공통의 코드베이스에 작업하는 개발자들이 질서있게 코드를 수정할 수 있도록 브랜치를 보호하는 규칙을 만들 수 있는 기능을 제공한다.
우선 깃허브 저장소에서 'Settings' 버튼을 눌러 설정 화면으로 간다.
저장소 설정 중 왼쪽 메뉴에서 'Branches' 탭을 클릭한다.
현재 이 저장소에는 아무런 보호 규칙도 적용되지 않았다. 우측 상단에 있는 'Add rule' 버튼을 눌러서 브랜치 보호 규칙을 추가한다.
생성할 보호규칙이 적용될 브랜치 이름 패턴을 입력해야한다. 브랜치의 이름은 fnmatch 문법을 사용하게 된다. 특정 브랜치 이름을 입력할 수도 있고, 와일드카드(*)를 이용해서 모든 브랜치에 적용되도록 규칙을 만들 수도 있다. 예를 들어 release 라는 단어가 들어간 모든 브랜치에 적용될 규칙을 만들고 싶으면 *release* 라고 브랜치 이름 패턴을 입력하면 된다. 모든 브랜치에 적용될 규칙이라면 와일드카드 문자 * 만 입력하면 된다.
와일드카드로 확장이 가능하기 때문에 여러개의 보호 규칙이 하나의 브랜치에 적용되는 경우가 있다. 이 경우 특정 브랜치의 이름을 포함하고 있을 수록 우선순위가 높게 적용된다. 만약 특정 브랜치의 이름을 포함하고 있는 보호 규칙이 여러가지라고 하면 그 때는 먼저 생성된 규칙이 우선순위가 높게 적용된다. *, ?, ] 등 특수 문자가 포함된 보호 규칙의 경우 역시 오래된 규칙이 우선순위를 갖는다.
만약 기존에 존재하는 특정 보호 규칙에 예외 사항을 추가하고 싶다면 좀 더 높은 우선순위의 새로운 보호 규칙을 추가하는 식으로 작업을 하면 된다. 예를 들어 와일드카드를 이용한 브랜치 이름 패턴으로 규칙을 추가하고 특정 브랜치 이름으로 예외 규칙을 만들어주는 식으로 작업하면 된다.
브랜치 보호규칙들
브랜치 보호규칙이 적용될 브랜치의 이름 패턴이 정해지면 생성될 보호 규칙들을 선택하면 된다.
'Require a pull request before merging'
브랜치로 적용될 커밋들은 반드시 보호되지 않는 브랜치로 일단 커밋되고 PR 과정을 거쳐서 리뷰된 다음 머지되도록 한다. 예를 들어 develop 브랜치에 팀원이 작업을 하는 경우 develop 브랜치에 이 보호를 걸어주고 각자 자기 개발 브랜치(feature 브랜치)에 작업을 한다음 PR을 통해서 develop 브랜치로 코드를 반영하도록 하는 것이다.
이 옵션에는 서브 옵션들이 있는데, 'Require approvals'는 몇 명의 동료가 리뷰 승인을 해줘야하는지 설정하는 것이고, 'Dismiss stale pull request approvals when new commits are pushed'는 리뷰 승인 이후 새로운 코드가 추가로 들어왔을 때, 기존 리뷰 승인을 무효화 할 것인지 여부다. 'Require review from Code Owners'는 코드의 소유자에게도 PR을 받아야하는지 여부다.
'Require status checks to pass before merging'
규칙이 적용되는 브랜치로 커밋이 머지되는 경우 반드시 status check를 통과해야하는 보호 규칙을 설정할 수 있다. 반영되려는 커밋이 특정 테스트를 통과하는지 자동으로 검증하도록 설정할 수 있다. 이와 관련해서 나중에 별도의 포스트를 할애해서 다뤄보겠다.
'Require branches to be up to date before merging' 이라는 서브 옵션을 선택하면 PR이 항상 최신 브랜치 상태에서 테스트되도록 한다.
Require conversation resolution before merging
코드가 머지되기 전에 모든 대화 내용을 Resolve 하도록 강제할 수 있다.
Require signed commits
작성자가 직접 서명한 커밋만 허용한다. 서명한 사용자가 직접 수정한 것이라는 사실을 확인할 수 있다. (git 명령에서 user.email과 user.name은 그냥 바꿀 수 있기 때문에 신뢰하지 못 할 수 있다.)
Require linear history
머지 커밋이 히스토리에 남지 안도록 한다.
Include administrators
모든 보호 규칙들이 관리자(Administrator)에게도 적용되도록 한다.
댓글