GitHub 리포지토리 branch ruleset 설정하기

※때에 따라서 해당 웹 페이지의 인터페이스 디자인이 조금씩 변하므로,

조회하시는 시간과 본 포스트 작성의 시간적 격차가 있는 경우

해당 설명과 상이한 부분이 있을 수 있습니다!

 

 

반갑습니다!

저번 포스트에서는 리포지토리에 Collaborator를 초대해봤는데요 ^^

한 리포지토리를 공유하며 여러 멤버들이 작업을 하다보면, 주의해야할 부분이 있습니다

바로 충돌(Conflict) 문제입니다

 

어떤 Application을 만들 것인지 기획도 하고, 디자인도 하고, 화면계획도 하고,

모든 밑 준비가 끝나고 본격적으로 개발에 들어가면 업무 분담을 하시겠죠? ^^

그리고 기한을 맞추시기 위해서 뜨겁게 개발을 하실텐데,

만약에 충돌이 생겨서 작업물이 반영이 제대로 안 된다거나 또는 에러가 생긴다면

개발 흐름이 끊겨서 김이 새는 경우도 있죠 ㅜㅜ

 

그래서 각 작업자들이 자신의 분량을 개발하고 리포지토리에 반영할 때,

main에다가 바로 반영하지 않고 자신들의 브랜치를 만들어서 먼저 작업하고 pull request를 생성해서

일종의 검증 단계를 거친 다음에 반영을 할겁니다 ^^

 

오늘은 이 branch에 대한 ruleset(규칙 설정)을 해보도록 하겠습니다!

이 규칙에는 enforcement(강제성)가 부여되기 때문에, 혹시 모를 미연의 사고를 방지할 수 있죠!

강제성이 부여된 규칙이 없다면 물론 그럴 일은 없겠지만, 만에 하나

팀원 중 누군가가 악의를 품고 리포지토리에서 지금까지의 작업물을 망친 다음에 도주할 수도 있으니까요 ^^;;

 

 

 

 

 

우선 GitHub 사이트에 접속해서 로그인 해주신 다음에 우측 상단의 본인 프로필 사진을 클릭해주세요 ^^!

 

 

 

 

Your repositories를 클릭한 다음 목록의 리포지토리들 중에서

본인 임의의 해당 리포지토리로 이동해주세요 ^^!

 

 

 

 

해당 리포지토리의 메뉴 탭에서 Settings를 클릭해주세요 ^^!

 

 

 

 

해당 리포지토리의 Settings 메뉴 목록 중에서 Branches를 클릭해주세요 ^^!

 

 

 

 

Branch protection rules가 보입니다

딱 봐도 브랜치를 보호하기 위해서 (강제할 수 있는)설정할 수 있는 규칙의 느낌이죠 ^^?

이 rule은 관리자가 멤버들을 억압하기나 휘두르기 위한 도구가 아니라,

시스템적으로 구성되는 규칙이기 때문에 해당 규칙을 두면 리포지토리의 소유자라도 무조건 규칙에 따라야 합니다 ^^!

 

 

 

 

Ruleset Name 부분에 해당 규칙의 이름을 설정해주시면 되겠습니다!

그리고 그 밑에 Enforcement status 부분이 있는데

이 부분을 Active로 설정해주셔야 규칙에 대한 강제성이 부여되어 브랜치들이 해당 규칙에 의해 보호될 수 있습니다 ^^!!

 

 

 

 

이제 Bypass list와 Targets가 보이는데요!

Rule이란 것도 적절한 상황과 대상이 있는 것인데,

반드시 모든 Rule이 모든 범위에 걸쳐 적용되기만 하면 좀 이용하기 어렵겠죠 ^^?

 

Bypass list는 이 규칙의 예외 대상을 추가하는 목록입니다!

만약에 해당 규칙을 만들고 자기 자신을 리스트에 추가하면,

본인은 해당 규칙 발효에 있어 제외 대상인거죠 ^^

 

Target branches는 이 규칙을 특정 브랜치에 국한시켜 적용시키게 하는 부분입니다!

Bypass list와 Target branches를 이용하여 Rule의 대상을 보다 정교하게 설정할 수 있는거죠 ^^!!

 

 

 

 

이제 본격적인 Rule list인데요!

상기 이미지에 체크되어 있는 것들은 default 값들입니다

추가로 더 설정할 수도 있고 제외시킬 수도 있습니다 ^^!

 

여러 규칙들을 선택할 수 있는데요!

Require a pull request before merging 규칙이 가장 핵심입니다 ^^!!

 

작업자들이 본인의 브랜치를 만들어서 작업을 마친 뒤 다른 브랜치에 병합(merge)할 때

꼭 pull request 작업을 필요로 하도록 강제하는 규칙입니다!

 

 

 

 

해당 규칙을 선택하면 상세항목을 설정할 수 있도록 하단에 추가 하위 목록이 생겨납니다 ^^!

pull request를 생성하고나서 일정 수 이상의 팀원들이 해당 코드를 확인(review)하고

코드가 괜찮다, 문제 없다 싶으면 승인(approval)을 남길 수 있는데요!

일정 수 이상의 승인을 받아야 merge할 수 있는 자격이 생기도록 강제할 수 있는 부분입니다 ^^!!

 

규칙이 설정 되면,

어떤 브랜치에 대해 함부로 merge할 수도 없고,

pull request를 생성해 다른 작업자들이 볼 수 있도록 해야하며,

일정 수 이상에게 검증 받아야(approval을 얻어야) merge할 수 있는 자격이 생기는거죠!

 

 

브랜치 보호와 동시에, 팀원의 코드를 함께 review하며 토론하고 피드백하는

성숙한 개발 문화의 장(場)이 이 규칙 하나를 통하여 강제될 수 있는 것이죠 ^^!

 

물론 규칙이 단순한 과정에 그쳐 유명무실해질 수도 있습니다만...^^;;

 

 

 

오늘은 이렇게 브랜치 ruleset에 대해서 간략하게 알아보았습니다!

부족한 포스트 읽어주셔서 감사드리고,

드넓은 개발의 세계를 항해하는 모든 분들 건승하시고 행복하시기 바랍니다 ^^!!