병합 요청 워크플로우

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

GitLab에서 병합 요청 흐름을 갖는 두 가지 주요 방법이 있습니다:

보호된 브랜치 흐름

보호된 브랜치 흐름에서는 모든 사람이 동일한 GitLab 프로젝트 내에서 작업합니다.

프로젝트 유지 관리자는 Maintainer 역할을 가지고 있으며 정기 개발자는 Developer 역할을 가집니다.

유지 관리자는 권위 있는 브랜치를 ‘보호됨’으로 표시합니다.

개발자는 프로젝트에 기능 브랜치를 푸시하고 그 기능 브랜치를 검토하고 보호된 브랜치 중 하나에 병합하기 위해 병합 요청을 생성합니다.

기본적으로 Maintainer 역할을 가진 사용자만 보호된 브랜치에 변경 사항을 병합할 수 있습니다.

장점

단점

보호된 브랜치 흐름을 설정하려면:

기본 브랜치가 기본 브랜치 보호로 보호되어 있는지 확인합니다.
팀에 여러 브랜치가 있고 변경 사항을 병합할 수 있는 사람과 푸시 또는 강제 푸시 옵션을 가진 사람을 관리하고 싶다면 해당 브랜치를 보호된 브랜치로 만들 수 있습니다:
- 브랜치 관리 및 보호
- 보호된 브랜치
코드에 대한 각 변경 사항은 커밋으로 들어옵니다.
푸시 규칙을 사용하여 코드 베이스로 들어오는 변경 사항에 대해 SSH 키 서명을 요구하는 형식 및 보안 조치를 지정할 수 있습니다:
- 푸시 규칙
코드가 팀의 적절한 사람에 의해 검토되고 확인되도록 하려면 다음을 사용합니다:
- 코드 소유자
- 병합 요청 승인 규칙

궁극적 계층에서 제공됨:

포크 워크플로우에서는 유지 관리자가 Maintainer 역할을 가지고 권위 있는 리포지토리에서 정규 개발자는 Reporter 역할을 가지므로 이를 푸시할 수 없습니다.

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

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

장점

적절히 구성된 GitLab 그룹에서 새 프로젝트가 자동으로 정규 개발자를 위한 필요한 액세스 제한을 받습니다: 새 프로젝트에 대한 권한 설정을 위한 수동 단계가 줄어듭니다.

단점