머지 리퀘스트 워크플로우

GitLab에서 가장 일반적인 머지 리퀘스트 플로우는 포크, 보호 브랜치 또는 둘 다를 사용합니다.

GitLab 머지 리퀘스트는 일반적으로 다음 플로우 중 하나를 따릅니다: 단일 저장소에서 보호 브랜치 로 작업하기. 권위 있는 프로젝트의 포크로 작업하기. 보호 브랜치 플로우 # 보호 브랜치 플로우에서는 포크 대신 모든 사람이 동일한 GitLab 프로젝트에서 작업합니다. 프로젝트 유지 관리자는 Maintainer 권한을 받고 일반 개발자는 Developer 권한을 받습니다. 유지 관리자는 권위 있는 브랜치를 '보호됨'으로 표시합니다. 개발자는 프로젝트에 기능 브랜치를 푸시하고 기능 브랜치를 검토하여 보호 브랜치 중 하나에 병합하도록 머지 리퀘스트를 생성합니다. 기본적으로 Maintainer 권한을 가진 사용자만 보호 브랜치에 변경 사항을 병합할 수 있습니다. 장점: 프로젝트 수가 적어 복잡성이 감소합니다. 개발자는 하나의 원격 저장소만 고려하면 됩니다. 단점: 새 프로젝트마다 보호 브랜치를 수동으로 설정해야 합니다 보호 브랜치 플로우를 설정하려면: 먼저 기본 브랜치 보호 로 기본 브랜치가 보호되어 있는지 확인합니다. 팀에 여러 브랜치가 있고 변경 사항을 병합할 수 있는 사람과 푸시하거나 강제 푸시할 수 있는 사람을 명시적으로 관리하려면 해당 브랜치를 보호하는 것을 고려하세요: 브랜치 관리 및 보호 보호 브랜치 코드의 각 변경 사항은 커밋으로 전달됩니다. 푸시 규칙을 사용하여 코드베이스에 들어오는 변경 사항에 대해 SSH 키 서명 요구와 같은 형식 및 보안 조치를 지정할 수 있습니다: 푸시 규칙 코드가 팀에서 적절한 사람에게 검토 및 확인되도록 하려면 다음을 사용합니다: 코드 소유자 머지 리퀘스트 승인 규칙 Ultimate 티어에서도 사용 가능합니다: 상태 확인 보안 승인 포킹 워크플로우 # 포킹 워크플로우에서는 유지 관리자가 권위 있는 저장소에서 Maintainer 권한을 받고 일반 개발자는 Reporter 권한을 받아 변경 사항을 푸시할 수 없습니다. 개발자는 권위 있는 프로젝트를 포크하고 자신의 포크에 기능 브랜치를 푸시합니다. 변경 사항을 기본 브랜치에 반영하려면 포크 간에 머지 리퀘스트를 생성해야 합니다. 장점: 적절하게 구성된 GitLab 그룹에서 새 프로젝트는 일반 개발자에게 필요한 접근 제한을 자동으로 적용합니다: 새 프로젝트에 대한 권한 부여를 구성하는 수동 단계가 줄어듭니다. 단점: 프로젝트는 포크를 최신 상태로 유지해야 하며, 이는 더 고급 Git 기술이 필요합니다(여러 원격 저장소 관리).