이 API를 사용하여 보호된 브랜치를 관리합니다.

GitLab Premium 및 GitLab Ultimate는 브랜치에 대한 푸시를 더 세분화된 방식으로 보호할 수 있습니다. 관리자는 특정 사용자 대신 배포 키에만 보호된 브랜치를 수정하고 푸시할 수 있는 권한을 부여할 수 있습니다.

유효한 액세스 수준#

ProtectedRefAccess.allowed_access_levels 메서드는 푸시, 머지, 보호 해제 구성에서 사용되는 다음 액세스 수준을 정의합니다:

• 0: 액세스 없음 - 푸시 및 머지 액세스 수준에만 유효합니다. 보호 해제 액세스 수준에는 유효하지 않습니다.
• 30: Developer
• 40: Maintainer
• 60: Administrator - GitLab Self-Managed에서만 유효합니다.

역할 기반 액세스 수준 외에도 다음으로 액세스를 할당할 수 있습니다:

• 사용자 (user_id): 푸시, 머지, 보호 해제 액세스 수준에 유효합니다.

• 그룹 (group_id): 푸시, 머지, 보호 해제 액세스 수준에 유효합니다. 그룹은 프로젝트에 대해 Developer, Maintainer 또는 Owner 역할이 있어야 합니다.

• 배포 키 (deploy_key_id): 푸시 액세스 수준에만 유효합니다.

자세한 내용은 저장소 브랜치 보호 예시를 참조하세요.

보호된 브랜치 목록 조회#

히스토리

• 배포 키 정보가 GitLab 16.0에서 도입되었습니다.

UI에서 정의된 대로 프로젝트의 보호된 브랜치 목록을 가져옵니다. 와일드카드가 설정된 경우, 해당 와일드카드와 일치하는 브랜치의 정확한 이름 대신 와일드카드가 반환됩니다.

GET /projects/:id/protected_branches

지원되는 속성:

성공 시 200 OK와 함께 다음 응답 속성을 반환합니다:

다음 예시 요청에서 프로젝트 ID는 5입니다.

curl --header "PRIVATE-TOKEN: <your_access_token>" \
  --url "https://gitlab.example.com/api/v4/projects/5/protected_branches"

다음 예시 응답에는 다음이 포함됩니다:

• ID가 100과 101인 두 개의 보호된 브랜치.
• ID가 1001, 1002, 1003인 push_access_levels.
• ID가 2001과 2002인 merge_access_levels.

[
  {
    "id": 100,
    "name": "main",
    "push_access_levels": [
      {
        "id":  1001,
        "access_level": 40,
        "access_level_description": "Maintainers"
      },
      {
        "id": 1002,
        "access_level": 40,
        "access_level_description": "Deploy key",
        "deploy_key_id": 1
      }
    ],
    "merge_access_levels": [
      {
        "id":  2001,
        "access_level": 40,
        "access_level_description": "Maintainers"
      }
    ],
    "allow_force_push":false,
    "code_owner_approval_required": false
  },
  {
    "id": 101,
    "name": "release/*",
    "push_access_levels": [
      {
        "id":  1003,
        "access_level": 40,
        "access_level_description": "Maintainers"
      }
    ],
    "merge_access_levels": [
      {
        "id":  2002,
        "access_level": 40,
        "access_level_description": "Maintainers"
      }
    ],
    "allow_force_push":false,
    "code_owner_approval_required": false
  }
]

GitLab Premium 또는 Ultimate 사용자는 user_id, group_id, inherited 파라미터도 확인할 수 있습니다. inherited 파라미터가 존재하면 설정이 프로젝트 그룹에서 상속된 것입니다.

다음 예시 응답에는 다음이 포함됩니다:

• ID가 100인 하나의 보호된 브랜치.
• ID가 1001과 1002인 push_access_levels.
• ID가 2001인 merge_access_levels.

[
  {
    "id": 101,
    "name": "main",
    "push_access_levels": [
      {
        "id":  1001,
        "access_level": 40,
        "user_id": null,
        "group_id": null,
        "access_level_description": "Maintainers"
      },
      {
        "id": 1002,
        "access_level": 40,
        "access_level_description": "Deploy key",
        "deploy_key_id": 1,
        "user_id": null,
        "group_id": null
      }
    ],
    "merge_access_levels": [
      {
        "id":  2001,
        "access_level": null,
        "user_id": null,
        "group_id": 1234,
        "access_level_description": "Example Merge Group"
      }
    ],
    "allow_force_push":false,
    "code_owner_approval_required": false,
    "inherited": true
  }
]

보호된 브랜치 또는 와일드카드 보호 브랜치 조회#

지정된 보호된 브랜치 또는 와일드카드 보호 브랜치를 조회합니다.

GET /projects/:id/protected_branches/:name

지원되는 속성:

성공 시 200 OK와 함께 다음 응답 속성을 반환합니다:

다음 예시 요청에서 프로젝트 ID는 5이고 브랜치 이름은 main입니다:

curl --header "PRIVATE-TOKEN: <your_access_token>" \
  --url "https://gitlab.example.com/api/v4/projects/5/protected_branches/main"

응답 예시:

{
  "id": 101,
  "name": "main",
  "push_access_levels": [
    {
      "id":  1001,
      "access_level": 40,
      "access_level_description": "Maintainers"
    }
  ],
  "merge_access_levels": [
    {
      "id":  2001,
      "access_level": 40,
      "access_level_description": "Maintainers"
    }
  ],
  "allow_force_push":false,
  "code_owner_approval_required": false
}

GitLab Premium 또는 Ultimate 사용자는 user_id와 group_id 파라미터도 확인할 수 있습니다.

응답 예시:

{
  "id": 101,
  "name": "main",
  "push_access_levels": [
    {
      "id":  1001,
      "access_level": 40,
      "user_id": null,
      "group_id": null,
      "access_level_description": "Maintainers"
    }
  ],
  "merge_access_levels": [
    {
      "id":  2001,
      "access_level": null,
      "user_id": null,
      "group_id": 1234,
      "access_level_description": "Example Merge Group"
    }
  ],
  "allow_force_push":false,
  "code_owner_approval_required": false
}

저장소 브랜치 보호#

히스토리

• deploy_key_id 구성이 GitLab 17.5에서 도입되었습니다.
• deploy_key_id 구성이 GitLab 18.10에서 GitLab Premium에서 GitLab Free로 이동되었습니다.

단일 저장소 브랜치 또는 와일드카드 보호 브랜치를 사용하여 여러 프로젝트 저장소 브랜치를 보호합니다.

POST /projects/:id/protected_branches

지원되는 속성:

액세스 수준을 구성할 때:

• allowed_to_push와 allowed_to_merge에 대해 여러 액세스 수준을 동시에 설정할 수 있습니다.
• 가장 허용적인 액세스 수준이 해당 작업을 수행할 수 있는 사람을 결정합니다.
• allowed_to_push, allowed_to_merge, 또는 allowed_to_unprotect 배열에 id를 포함하지 마세요. id 필드는 기존 액세스 수준 레코드를 식별하며 보호된 브랜치를 업데이트할 때만 유효합니다. 기존 레코드와 일치하지 않는 id를 포함하면 API는 404 Not Found를 반환합니다.

이 동작은 No one (access_level: 0)을 선택할 때 다른 역할 선택을 자동으로 지우는 UI와 다릅니다.

성공 시 201 Created와 함께 다음 응답 속성을 반환합니다:

다음 예시 요청에서 프로젝트 ID는 5이고 브랜치 이름은 *-stable입니다.

curl --request POST \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --url "https://gitlab.example.com/api/v4/projects/5/protected_branches?name=*-stable&push_access_level=30&merge_access_level=30&unprotect_access_level=40"

예시 응답에는 다음이 포함됩니다:

• ID가 101인 보호된 브랜치.
• ID가 1001인 push_access_levels.
• ID가 2001인 merge_access_levels.
• ID가 3001인 unprotect_access_levels.

{
  "id": 101,
  "name": "*-stable",
  "push_access_levels": [
    {
      "id":  1001,
      "access_level": 30,
      "access_level_description": "Developers + Maintainers"
    }
  ],
  "merge_access_levels": [
    {
      "id":  2001,
      "access_level": 30,
      "access_level_description": "Developers + Maintainers"
    }
  ],
  "unprotect_access_levels": [
    {
      "id":  3001,
      "access_level": 40,
      "access_level_description": "Maintainers"
    }
  ],
  "allow_force_push":false,
  "code_owner_approval_required": false
}

GitLab Premium 또는 Ultimate 사용자는 user_id와 group_id 파라미터도 확인할 수 있습니다:

다음 예시 응답에는 다음이 포함됩니다:

• ID가 101인 보호된 브랜치.
• ID가 1001인 push_access_levels.
• ID가 2001인 merge_access_levels.
• ID가 3001인 unprotect_access_levels.

{
  "id": 1,
  "name": "*-stable",
  "push_access_levels": [
    {
      "id":  1001,
      "access_level": 30,
      "user_id": null,
      "group_id": null,
      "access_level_description": "Developers + Maintainers"
    }
  ],
  "merge_access_levels": [
    {
      "id":  2001,
      "access_level": 30,
      "user_id": null,
      "group_id": null,
      "access_level_description": "Developers + Maintainers"
    }
  ],
  "unprotect_access_levels": [
    {
      "id":  3001,
      "access_level": 40,
      "user_id": null,
      "group_id": null,
      "access_level_description": "Maintainers"
    }
  ],
  "allow_force_push":false,
  "code_owner_approval_required": false
}

사용자 푸시 액세스 및 그룹 머지 액세스 예시#

allowed_to_push / allowed_to_merge / allowed_to_unprotect 배열의 요소는 {user_id: integer}, {group_id: integer}, 또는 {access_level: integer} 형태여야 합니다. 각 사용자는 프로젝트에 접근할 수 있어야 하며 각 그룹은 이 프로젝트를 공유해야 합니다. 이러한 액세스 수준을 통해 보호된 브랜치 액세스를 더 세분화된 방식으로 제어할 수 있습니다. 자세한 내용은 그룹 권한 구성을 참조하세요.

다음 예시 요청은 사용자 푸시 액세스와 그룹 머지 액세스가 있는 보호된 브랜치를 생성합니다. user_id는 2이고 group_id는 3입니다.

curl --request POST \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --url "https://gitlab.example.com/api/v4/projects/5/protected_branches?name=*-stable&allowed_to_push%5B%5D%5Buser_id%5D=2&allowed_to_merge%5B%5D%5Bgroup_id%5D=3"

다음 예시 응답에는 다음이 포함됩니다:

• ID가 101인 보호된 브랜치.
• ID가 1001인 push_access_levels.
• ID가 2001인 merge_access_levels.
• ID가 3001인 unprotect_access_levels.

{
  "id": 101,
  "name": "*-stable",
  "push_access_levels": [
    {
      "id":  1001,
      "access_level": null,
      "user_id": 2,
      "group_id": null,
      "access_level_description": "Administrator"
    }
  ],
  "merge_access_levels": [
    {
      "id":  2001,
      "access_level": null,
      "user_id": null,
      "group_id": 3,
      "access_level_description": "Example Merge Group"
    }
  ],
  "unprotect_access_levels": [
    {
      "id":  3001,
      "access_level": 40,
      "user_id": null,
      "group_id": null,
      "access_level_description": "Maintainers"
    }
  ],
  "allow_force_push":false,
  "code_owner_approval_required": false
}

배포 키 액세스 예시#

히스토리

• GitLab 17.5에서 도입되었습니다.
• GitLab 18.10에서 GitLab Premium에서 GitLab Free로 이동되었습니다.

allowed_to_push 배열의 요소는 {user_id: integer}, {group_id: integer}, {deploy_key_id: integer}, 또는 {access_level: integer} 형태여야 합니다. 배포 키는 프로젝트에 활성화되어 있어야 하며 프로젝트 저장소에 쓰기 액세스 권한이 있어야 합니다. 다른 요구 사항은 보호된 브랜치에 배포 키 푸시 허용을 참조하세요.

요청 예시:

curl --request POST \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --url "https://gitlab.example.com/api/v4/projects/5/protected_branches?name=*-stable&allowed_to_push[][deploy_key_id]=1"

다음 예시 응답에는 다음이 포함됩니다:

• ID가 101인 보호된 브랜치.
• ID가 1001인 push_access_levels.
• ID가 2001인 merge_access_levels.
• ID가 3001인 unprotect_access_levels.

{
  "id": 101,
  "name": "*-stable",
  "push_access_levels": [
    {
      "id":  1001,
      "access_level": null,
      "user_id": null,
      "group_id": null,
      "deploy_key_id": 1,
      "access_level_description": "Deploy"
    }
  ],
  "merge_access_levels": [
    {
      "id":  2001,
      "access_level": 40,
      "user_id": null,
      "group_id": null,
      "access_level_description": "Maintainers"
    }
  ],
  "unprotect_access_levels": [
    {
      "id":  3001,
      "access_level": 40,
      "user_id": null,
      "group_id": null,
      "access_level_description": "Maintainers"
    }
  ],
  "allow_force_push":false,
  "code_owner_approval_required": false
}

푸시 허용 및 머지 허용 액세스 예시#

히스토리

• GitLab 13.9에서 GitLab Premium으로 이동되었습니다.

요청 예시:

curl --request POST \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --header "Content-Type: application/json" \
  --data '{
    "name": "main",
    "allowed_to_push": [
      {"access_level": 30}
    ],
    "allowed_to_merge": [
      {"access_level": 30},
      {"access_level": 40}
    ]
  }' \
  --url "https://gitlab.example.com/api/v4/projects/5/protected_branches"

다음 예시 응답에는 다음이 포함됩니다:

• ID가 105인 보호된 브랜치.
• ID가 1001인 push_access_levels.
• ID가 2001과 2002인 merge_access_levels.
• ID가 3001인 unprotect_access_levels.

{
    "id": 105,
    "name": "main",
    "push_access_levels": [
        {
            "id": 1001,
            "access_level": 30,
            "access_level_description": "Developers + Maintainers",
            "user_id": null,
            "group_id": null
        }
    ],
    "merge_access_levels": [
        {
            "id": 2001,
            "access_level": 30,
            "access_level_description": "Developers + Maintainers",
            "user_id": null,
            "group_id": null
        },
        {
            "id": 2002,
            "access_level": 40,
            "access_level_description": "Maintainers",
            "user_id": null,
            "group_id": null
        }
    ],
    "unprotect_access_levels": [
        {
            "id": 3001,
            "access_level": 40,
            "access_level_description": "Maintainers",
            "user_id": null,
            "group_id": null
        }
    ],
    "allow_force_push":false,
    "code_owner_approval_required": false
}

보호 해제 액세스 수준 예시#

특정 그룹만 브랜치 보호를 해제할 수 있는 보호된 브랜치를 생성하려면:

curl --request POST \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --header "Content-Type: application/json" \
  --data '{
    "name": "production",
    "allowed_to_unprotect": [
      {"group_id": 789}
    ]
  }' \
  --url "https://gitlab.example.com/api/v4/projects/5/protected_branches"

여러 유형의 사용자가 브랜치 보호를 해제할 수 있도록 허용하려면:

curl --request POST \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --header "Content-Type: application/json" \
  --data '{
    "name": "main",
    "allowed_to_unprotect": [
      {"user_id": 123},
      {"group_id": 456},
      {"access_level": 40}
    ]
  }' \
  --url "https://gitlab.example.com/api/v4/projects/5/protected_branches"

이 구성을 통해 다음 사용자들이 브랜치 보호를 해제할 수 있습니다:

• ID가 123인 사용자.
• ID가 456인 그룹의 멤버.
• Maintainer 또는 Owner 역할의 사용자 (액세스 수준 40).

저장소 브랜치 보호 해제#

지정된 보호된 브랜치 또는 와일드카드 보호 브랜치의 보호를 해제합니다.

DELETE /projects/:id/protected_branches/:name

지원되는 속성:

성공 시 204 No Content를 반환합니다.

다음 예시 요청에서 프로젝트 ID는 5이고 브랜치 이름은 *-stable입니다:

curl --request DELETE \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --url "https://gitlab.example.com/api/v4/projects/5/protected_branches/*-stable"

보호된 브랜치 업데이트#

히스토리

• deploy_key_id 구성이 GitLab 17.5에서 도입되었습니다.

보호된 브랜치를 업데이트합니다.

PATCH /projects/:id/protected_branches/:name

지원되는 속성:

여러 값을 설정할 때 액세스 수준이 상호작용하는 방법에 대한 정보는 저장소 브랜치 보호를 참조하세요.

성공 시 200 OK와 함께 다음 응답 속성을 반환합니다:

요청 예시:

curl --request PATCH \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --url "https://gitlab.example.com/api/v4/projects/5/protected_branches/feature-branch?allow_force_push=true&code_owner_approval_required=true"

allowed_to_push, allowed_to_merge, allowed_to_unprotect 배열의 요소는 user_id, group_id, 또는 access_level 중 하나여야 하며, {user_id: integer}, {group_id: integer} 또는 {access_level: integer} 형태여야 합니다.

allowed_to_push에는 {deploy_key_id: integer} 형태의 추가 요소 deploy_key_id가 포함됩니다.

업데이트하려면:

• user_id: 업데이트된 사용자가 프로젝트에 접근할 수 있는지 확인합니다. 해시에 액세스 수준 레코드의 id를 포함합니다.
• group_id: 업데이트된 그룹이 이 프로젝트를 공유했는지 확인합니다. 해시에 액세스 수준 레코드의 id를 포함합니다.
• deploy_key_id: 배포 키가 프로젝트에 활성화되어 있고 프로젝트 저장소에 쓰기 액세스 권한이 있는지 확인합니다.

기존 액세스 수준 레코드의 다른 필드를 업데이트하려면 해시에 레코드의 id를 포함합니다.

삭제하려면 _destroy를 true로 설정해야 합니다. 다음 예시를 참조하세요.

예시: push_access_level 레코드 생성#

curl --header 'Content-Type: application/json' --request PATCH \
  --data '{"allowed_to_push": [{"access_level": 40}]}' \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --url "https://gitlab.example.com/api/v4/projects/22034114/protected_branches/main"

응답 예시:

{
   "name": "main",
   "push_access_levels": [
      {
         "id": 12,
         "access_level": 40,
         "access_level_description": "Maintainers",
         "user_id": null,
         "group_id": null
      }
   ]
}

예시: push_access_level 레코드 업데이트#

curl --header 'Content-Type: application/json' --request PATCH \
  --data '{"allowed_to_push": [{"id": 12, "access_level": 0}]}' \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --url "https://gitlab.example.com/api/v4/projects/22034114/protected_branches/main"

응답 예시:

{
   "name": "main",
   "push_access_levels": [
      {
         "id": 12,
         "access_level": 0,
         "access_level_description": "No One",
         "user_id": null,
         "group_id": null
      }
   ]
}

예시: push_access_level 레코드 삭제#

curl --header 'Content-Type: application/json' --request PATCH \
  --data '{"allowed_to_push": [{"id": 12, "_destroy": true}]}' \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --url "https://gitlab.example.com/api/v4/projects/22034114/protected_branches/main"

응답 예시:

{
   "name": "main",
   "push_access_levels": []
}

예시: unprotect_access_level 레코드 업데이트#

사전 조건:

• 이 API를 호출하는 사용자는 allowed_to_unprotect 구성에 포함되어 있어야 합니다.
• user_id로 지정된 사용자는 프로젝트 멤버여야 합니다.
• group_id로 지정된 그룹은 프로젝트에 접근할 수 있어야 합니다.

기존 보호된 브랜치의 보호를 해제할 수 있는 사람을 수정하려면 기존 액세스 수준 레코드의 id를 포함합니다. 예를 들면:

curl --request PATCH \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --header "Content-Type: application/json" \
  --data '{
    "allowed_to_unprotect": [
      {"id": 17486, "user_id": 3791}
    ]
  }' \
  --url "https://gitlab.example.com/api/v4/projects/5/protected_branches/main"

특정 액세스 수준을 제거하려면 _destroy: true를 사용합니다.

관련 항목#

• 보호된 브랜치
• 브랜치
• 브랜치 API