GitLab 머지 리퀘스트는 일반적으로 다음 플로 중 하나를 따릅니다:

• 단일 리포지터리에서 보호된 브랜치로 작업하기.
• 권위 있는 프로젝트의 포크로 작업하기.

보호된 브랜치 플로#

보호된 브랜치 플로에서는 포크 대신 모든 사람이 동일한 GitLab 프로젝트에서 작업합니다.

프로젝트 유지 관리자는 Maintainer 권한을 받고 일반 개발자는 Developer 권한을 받습니다.

유지 관리자는 권위 있는 브랜치를 'Protected'로 표시합니다.

개발자는 프로젝트에 기능 브랜치를 푸시하고, 해당 기능 브랜치를 검토받아 보호된 브랜치 중 하나에 병합하기 위해 머지 리퀘스트를 생성합니다.

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

• 장점:
  • 프로젝트 수가 적어 복잡성이 감소합니다.
  • 개발자는 하나의 원격 리포지터리만 고려하면 됩니다.
• 단점:
  • 새 프로젝트마다 보호된 브랜치를 수동으로 설정해야 합니다.

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

1. 먼저 기본 브랜치 보호로 기본 브랜치가 보호되어 있는지 확인합니다.

2. 팀에 여러 브랜치가 있고 변경 사항을 병합할 수 있는 사람과 푸시 또는 강제 푸시할 수 있는 사람을 명시적으로 관리하려면 해당 브랜치를 보호하는 것을 고려합니다:

   • 브랜치 관리 및 보호
   • 보호된 브랜치

3. 코드의 각 변경 사항은 커밋으로 전달됩니다. 푸시 규칙을 사용하여 코드베이스로 들어오는 변경 사항에 대해 SSH 키 서명 요구와 같은 형식 및 보안 조치를 지정할 수 있습니다:

   • 푸시 규칙

4. 코드를 팀 내 적절한 담당자가 검토하고 확인하도록 하려면 다음을 사용합니다:

   • 코드 소유자
   • 머지 리퀘스트 승인 규칙

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

• 상태 확인
• 보안 승인

포킹 워크플로#

포킹 워크플로에서는 유지 관리자가 권위 있는 리포지터리에서 Maintainer 권한을 받고 일반 개발자는 Reporter 권한을 받으므로, 일반 개발자는 해당 리포지터리에 변경 사항을 푸시할 수 없습니다.

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

변경 사항을 기본 브랜치에 반영하려면 포크 간 머지 리퀘스트를 생성해야 합니다.

• 장점:
  • 적절하게 구성된 GitLab 그룹에서 새 프로젝트는 일반 개발자에게 필요한 접근 제한을 자동으로 적용합니다. 새 프로젝트의 권한 부여를 구성하는 수동 단계가 줄어듭니다.
• 단점:
  • 프로젝트는 포크를 최신 상태로 유지해야 하며, 이를 위해서는 더 고급 Git 기술(여러 원격 리포지터리 관리)이 필요합니다.