병합 요청 워크플로우

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

GitLab에서 병합 요청 워크플로우를 수행하는 두 가지 주요 방법이 있습니다.

보호된 브랜치 워크플로우

보호된 브랜치 워크플로우에서 모든 사람은 동일한 GitLab 프로젝트 내에서 작업합니다.

프로젝트 유지자는 유지자 역할(Maintainer)을 부여받고, 일반 개발자는 개발자 역할(Developer)을 부여받습니다.

유지자들은 권위 있는 브랜치를 ‘보호된’ 상태로 표시합니다.

개발자들은 기능 브랜치를 프로젝트에 푸시하고, 그들의 기능 브랜치가 리뷰되어 보호된 브랜치 중 하나로 병합될 수 있도록 병합 요청을 생성합니다.

기본적으로, 보호된 브랜치에 변경 사항을 병합할 수 있는 사용자는 유지자 역할을 가진 사용자뿐입니다.

장점

단점

보호된 브랜치 워크플로우를 설정하려면:

기본 브랜치가 기본 브랜치 보호로 보호되었는지 확인합니다.
팀에 여러 브랜치가 있고 변경 사항을 누가 병합할 수 있는지, 누가 명시적으로 푸시하거나 힘들게 밀어넣을 수 있는지 관리하려면 이러한 브랜치를 보호하기로 결정하세요:
- 브랜치 관리 및 보호
- 보호된 브랜치
코드에 대한 각 변경 사항이 커밋으로 이루어집니다. 변경 사항이 코드 베이스로 전달되는 형식 및 보안 조치(예: 푸시 규칙을 통한 SSH 키 서명 필요)를 지정할 수 있습니다:
- 푸시 규칙
코드가 팀 내 올바른 사람들에 의해 검토되고 확인되도록 보장하기 위해 다음을 사용하세요:
- 코드 소유자
- 병합 요청 승인 규칙

Ultimate 티어에서도 사용할 수 있습니다:

포킹 워크플로우에서, 유지자는 권한자 저장소(권위 있는 저장소)에서 유지자 역할을 부여받고, 일반 개발자는 보고자 역할을 부여받아 해당 저장소에 변경 사항을 푸시할 수 없으며 권한이 없습니다.

개발자들은 권위 있는 프로젝트의 포크를 생성하고, 자신의 포크에 기능 브랜치를 푸시합니다.

그들의 변경 사항을 기본 브랜치에 반영하려면, 포크 간에 병합 요청을 생성해야 합니다.

장점

적절하게 구성된 GitLab 그룹에서는 새 프로젝트가 자동으로 일반 개발자에 대한 필수 액세스 제한을 받으므로 새 프로젝트의 인가를 구성하는 수동 단계가 줄어듭니다.

단점