Basic Gitea Information
Basic Structure
기본 Gitea 환경 구조는 조직별로 리포지토리를 그룹화하는 것입니다. 각 조직은 여러 리포지토리와 여러 팀을 포함할 수 있습니다. 그러나 GitHub와 마찬가지로 사용자는 조직 외부에 리포지토리를 가질 수 있습니다.
또한, 사용자는 다양한 조직의 구성원이 될 수 있습니다. 조직 내에서 사용자는 각 리포지토리에 대해 다른 권한을 가질 수 있습니다.
사용자는 또한 다양한 팀의 일원이 되어 서로 다른 리포지토리에 대해 다른 권한을 가질 수 있습니다.
마지막으로 리포지토리는 특별한 보호 메커니즘을 가질 수 있습니다.
Permissions
Organizations
조직이 생성될 때 Owners라는 팀이 생성되고 사용자가 그 안에 배치됩니다. 이 팀은 조직에 대한 관리자 접근을 제공합니다. 이 권한과 팀의 이름은 수정할 수 없습니다.
Org admins(소유자)는 조직의 가시성을 선택할 수 있습니다:
공개
제한됨 (로그인한 사용자만)
비공개 (구성원만)
Org admins는 또한 repo admins가 팀에 대한 접근을 추가하거나 제거할 수 있는지 표시할 수 있습니다. 그들은 또한 최대 리포지토리 수를 지정할 수 있습니다.
새 팀을 생성할 때 여러 중요한 설정이 선택됩니다:
팀 구성원이 접근할 수 있는 조직의 리포지토리가 지정됩니다: 특정 리포지토리(팀이 추가된 리포지토리) 또는 모두.
구성원이 새 리포지토리를 생성할 수 있는지도 지정됩니다(생성자는 관리자 접근을 받습니다).
리포지토리의 구성원이 가질 권한:
관리자 접근
특정 접근:
Teams & Users
리포지토리에서 org admin과 repo admins(조직에서 허용하는 경우)는 협력자(다른 사용자)와 팀에 부여된 역할을 관리할 수 있습니다. 가능한 역할은 3가지입니다:
관리자
쓰기
읽기
Gitea Authentication
Web Access
사용자 이름 + 비밀번호를 사용하고, 가능하면(권장) 2FA를 사용합니다.
SSH Keys
하나 이상의 공개 키로 계정을 구성할 수 있으며, 관련된 개인 키가 귀하를 대신하여 작업을 수행할 수 있습니다. http://localhost:3000/user/settings/keys
GPG Keys
이 키로 사용자를 가장할 수는 없지만, 사용하지 않으면 서명 없는 커밋을 보내는 것으로 인해 발견될 수 있습니다.
Personal Access Tokens
응용 프로그램이 귀하의 계정에 접근할 수 있도록 개인 접근 토큰을 생성할 수 있습니다. 개인 접근 토큰은 귀하의 계정에 대한 전체 접근을 제공합니다: http://localhost:3000/user/settings/applications
Oauth Applications
개인 접근 토큰과 마찬가지로 Oauth 애플리케이션은 귀하의 계정과 귀하의 계정이 접근할 수 있는 장소에 대해 완전한 접근을 가집니다. docs에서 언급된 바와 같이, 범위는 아직 지원되지 않습니다:
Deploy keys
배포 키는 리포지토리에 대한 읽기 전용 또는 쓰기 접근을 가질 수 있으므로 특정 리포지토리를 손상시키는 데 흥미로울 수 있습니다.
Branch Protections
브랜치 보호는 사용자가 리포지토리에 대한 완전한 제어를 부여하지 않도록 설계되었습니다. 목표는 일부 브랜치에 코드를 작성하기 전에 여러 보호 방법을 설정하는 것입니다.
리포지토리의 브랜치 보호는 _https://localhost:3000/<orgname>/<reponame>/settings/branches_에서 찾을 수 있습니다.
조직 수준에서 브랜치 보호를 설정하는 것은 불가능합니다. 따라서 모든 보호는 각 리포지토리에서 선언해야 합니다.
브랜치에 적용할 수 있는 다양한 보호가 있습니다(예: master):
푸시 비활성화: 아무도 이 브랜치에 푸시할 수 없습니다.
푸시 활성화: 접근 권한이 있는 누구나 푸시할 수 있지만, 강제 푸시는 불가능합니다.
화이트리스트 제한 푸시: 선택된 사용자/팀만 이 브랜치에 푸시할 수 있습니다(강제 푸시 불가).
병합 화이트리스트 활성화: 화이트리스트에 있는 사용자/팀만 PR을 병합할 수 있습니다.
상태 검사 활성화: 병합 전에 상태 검사가 통과해야 합니다.
승인 요구: PR을 병합하기 전에 필요한 승인 수를 표시합니다.
화이트리스트에 제한된 승인: PR을 승인할 수 있는 사용자/팀을 표시합니다.
거부된 리뷰에서 병합 차단: 변경 요청이 있는 경우 병합할 수 없습니다(다른 검사가 통과하더라도).
공식 리뷰 요청에서 병합 차단: 공식 리뷰 요청이 있는 경우 병합할 수 없습니다.
오래된 승인 무효화: 새로운 커밋이 있을 때 오래된 승인은 무효화됩니다.
서명된 커밋 요구: 커밋은 서명되어야 합니다.
풀 리퀘스트가 오래된 경우 병합 차단
보호된/비보호 파일 패턴: 변경으로부터 보호/비보호할 파일 패턴을 표시합니다.
보시다시피, 사용자의 자격 증명을 얻었다 하더라도, 리포지토리가 보호되어 있어 마스터에 코드를 푸시하는 것을 방지할 수 있습니다. 예를 들어 CI/CD 파이프라인을 손상시키기 위해서입니다.
Last updated
