Merge Request 워크플로우
Tier: Free, Premium, Ultimate
Offering: GitLab.com, Self-Managed, GitLab Dedicated
GitLab에서 Merge Request 워크플로우를 적용하는 두 가지 주요 방법이 있습니다:
- 단일 리포지터리에서 보호된 브랜치로 작업.
- 권한이 있는 프로젝트의 포크로 작업.
보호된 브랜치 워크플로우
보호된 브랜치 워크플로우에서 모든 사람은 동일한 GitLab 프로젝트에서 작업합니다.
프로젝트 유지보수자는 유지자 역할(Maintainer role)을 갖고, 일반 개발자는 개발자 역할(Developer role)을 갖습니다.
유지보수자는 권한 있는 브랜치를 ‘보호된’ 상태로 표시합니다.
개발자들은 기능 브랜치를 프로젝트에 푸시하고, 그들의 기능 브랜치가 리뷰되어 보호된 브랜치 중 하나로 Merge되도록 Merge Request을 생성합니다.
기본적으로, 보호된 브랜치에 변경사항을 Merge할 수 있는 권한은 유지자 역할을 가진 사용자에게만 부여됩니다.
장점
- 프로젝트 수가 적으면 혼란이 줄어듭니다.
- 개발자는 하나의 원격 리포지터리만을 고려해야 합니다.
단점
- 각 새로운 프로젝트마다 보호된 브랜치의 매뉴얼 설정이 필요합니다.
보호된 브랜치 워크플로우를 설정하려면:
- 기본 브랜치가 기본 브랜치 보호로 보호되었는지 확인합니다.
- 여러 브랜치가 있는 경우 변경사항을 Merge할 수 있는 사용자와 푸시 또는 강제 푸시 옵션이 있는 사용자를 관리하고 싶다면, 해당 브랜치를 보호하지 않았다면 다음을 고려해 보세요.
- 코드에 대한 각 변경사항을 커밋으로부터 가져옵니다. 변경사항이 코드베이스로 들어오는 양식과 SSH 키 서명이 필요한 보안조치와 같은 보안 조치를 지정할 수 있습니다:
- 코드가 팀 내에서 올바르게 검토되고 확인되도록 하려면 다음을 사용하세요:
Ultimate 티어에서도 가능:
포킹 워크플로우
포킹 워크플로우에서, 유지보수자는 권한자 프로젝트에서 유지자 역할을, 일반 개발자는 보고자 역할을 갖습니다. 이로써 권한이 있는 프로젝트에 변경사항을 푸시하는 것을 금지합니다.
개발자들은 권한이 있는 프로젝트의 포크를 생성하고, 자신의 포크에 기능 브랜치를 푸시합니다.
기본 브랜치에 변경사항을 반영하기 위해, 다른 포크 사이에서 Merge Request을 생성해야 합니다.
장점
- 적절하게 구성된 GitLab 그룹에서는 새 프로젝트가 자동으로 일반 개발자에 대한 필요한 액세스 제한을 받으므로, 새 프로젝트에 대한 권한 설정에 매뉴얼 단계가 적어집니다.
단점
- 프로젝트는 자신의 포크를 최신 상태로 유지해야 하며, 이는 보다 고급스러운 Git 기술(여러 원격 리포지터리 관리)을 요구합니다.
도움말