Basic Gitea Information
기본 구조
기본 Gitea 환경 구조는 **조직별(repository)**로 저장소를 그룹화하는 것이며, 각 저장소는 여러 개의 저장소와 여러 개의 팀을 포함할 수 있습니다. 그러나 github와 마찬가지로 사용자는 조직 외에도 저장소를 가질 수 있습니다.
또한 사용자는 다른 조직의 구성원이 될 수 있습니다. 조직 내에서 사용자는 각 저장소에 대해 다른 권한을 가질 수 있습니다.
사용자는 또한 다른 팀에 속할 수 있으며 다른 저장소에 대해 다른 권한을 가질 수 있습니다.
마지막으로 저장소에는 특별한 보호 메커니즘이 있을 수 있습니다.
권한
조직
조직이 생성되면 **소유자(Owners)**라는 팀이 생성되고 사용자가 그 안에 넣어집니다. 이 팀은 조직에 대한 관리 액세스를 제공하며 해당 권한 및 팀의 이름은 수정할 수 없습니다.
조직 관리자(소유자)는 조직의 가시성을 선택할 수 있습니다:
공개
제한된(로그인한 사용자만)
비공개(구성원만)
조직 관리자는 또한 저장소 관리자가 팀에 대한 액세스를 추가하거나 제거할 수 있는지를 지정할 수 있습니다. 또한 최대 저장소 수를 지정할 수 있습니다.
새 팀을 만들 때 여러 가지 중요한 설정이 선택됩니다:
팀 구성원이 액세스할 수 있는 조직의 저장소가 지정됩니다: 특정 저장소(팀이 추가된 저장소) 또는 모든 저장소.
구성원이 새로운 저장소를 만들 수 있는지 여부도 지정됩니다(생성자는 관리자 액세스를 받게 됨)
저장소 구성원이 가질 권한:
관리자 액세스
특정 액세스:
팀 및 사용자
저장소에서 조직 관리자 및 저장소 관리자(조직에서 허용된 경우)는 협력자(다른 사용자) 및 팀에 부여된 역할을 관리할 수 있습니다. 3가지 역할이 있습니다:
관리자
쓰기
읽기
Gitea 인증
웹 액세스
사용자 이름 + 비밀번호 및 (권장되는) 2단계 인증을 사용합니다.
SSH 키
관련 개인 키가 사용자를 대신하여 작업을 수행할 수 있도록 하나 이상의 공개 키로 계정을 구성할 수 있습니다. http://localhost:3000/user/settings/keys
GPG 키
이러한 키로 사용자를 가장할 수는 없지만, 사용하지 않으면 커밋을 보내기 위해 서명이 없는 커밋을 보낼 수 있습니다.
개인 액세스 토큰
개인 액세스 토큰을 생성하여 응용 프로그램이 계정에 액세스할 수 있도록 할 수 있습니다. 개인 액세스 토큰은 계정 전체에 대한 완전한 액세스 권한을 부여합니다: http://localhost:3000/user/settings/applications
Oauth 애플리케이션
개인 액세스 토큰과 마찬가지로 Oauth 애플리케이션은 계정 및 계정이 액세스하는 위치에 대해 완전한 액세스를 갖게 됩니다. 왜냐하면 문서에서 나타난 바와 같이 스코프가 아직 지원되지 않기 때문입니다:
배포 키
배포 키는 저장소에 대해 읽기 전용 또는 쓰기 액세스를 가질 수 있으므로 특정 저장소를 침해하는 데 흥미로울 수 있습니다.
브랜치 보호
브랜치 보호는 사용자에게 저장소의 완전한 제어를 제공하지 않도록 설계되었습니다. 목표는 일부 브랜치에 코드를 작성하기 전에 여러 보호 방법을 두는 것입니다.
저장소의 브랜치 보호는 _https://localhost:3000/<orgname>/<reponame>/settings/branches_에서 찾을 수 있습니다.
조직 수준에서 브랜치 보호를 설정할 수 없습니다. 따라서 모든 것은 각 저장소에서 선언되어야 합니다.
브랜치에 다양한 보호가 적용될 수 있습니다(예: 마스터):
푸시 비활성화: 누구도 이 브랜치로 푸시할 수 없음
푸시 활성화: 액세스 권한이 있는 모든 사람이 푸시할 수 있지만 강제 푸시는 불가능
화이트리스트 제한 푸시: 선택된 사용자/팀만 이 브랜치로 푸시할 수 있음(강제 푸시 불가)
병합 화이트리스트 활성화: 화이트리스트에 등록된 사용자/팀만 PR을 병합할 수 있음
상태 확인 활성화: 병합하기 전에 상태 확인을 통과해야 함
승인 필요: PR을 병합하기 전에 필요한 승인 수를 나타냄
승인을 화이트리스트로 제한: PR을 승인할 수 있는 사용자/팀을 나타냄
거부된 리뷰에서 병합 차단: 변경 사항이 요청되면 병합할 수 없음(다른 확인이 통과되더라도)
공식 리뷰 요청에서 병합 차단: 공식 리뷰 요청이 있으면 병합할 수 없음
오래된 승인 무시: 새로운 커밋이 있으면 이전 승인이 무시됨
서명된 커밋 필요: 커밋은 서명되어야 함
풀 리퀘스트가 오래될 경우 병합 차단
보호/보호되지 않은 파일 패턴: 변경에 대한 파일 패턴을 보호/보호해제할 수 있음
보안 자격 증명을 얻었더라도 저장소가 보호될 수 있어 CI/CD 파이프라인을 침해하는 것을 방지할 수 있습니다.
最終更新
