docs: Add comprehensive Gitea Repository Management document detailing repository types, creation process, configuration, and best practices
This commit is contained in:
parent
fa96cbf11d
commit
687febcc12
@ -13,17 +13,17 @@ Our Gitea instance serves as the central repository management platform for all
|
||||
|
||||
### Key Benefits
|
||||
|
||||
* **Project Isolation** → Each project has its own organization with dedicated repositories.
|
||||
* **Technology Separation** → Distinct boundaries between technology stacks.
|
||||
* **Access Control** → Project-specific permissions and team assignments.
|
||||
* **Resource Management** → Organized repositories, teams, and settings per project.
|
||||
* **Scalability** → Easy to add new projects or initiatives.
|
||||
- **Project Isolation** → Each project has its own organization with dedicated repositories.
|
||||
- **Technology Separation** → Distinct boundaries between technology stacks.
|
||||
- **Access Control** → Project-specific permissions and team assignments.
|
||||
- **Resource Management** → Organized repositories, teams, and settings per project.
|
||||
- **Scalability** → Easy to add new projects or initiatives.
|
||||
|
||||
---
|
||||
|
||||
## Organization Structure
|
||||
|
||||
Our Gitea instance is organized around **project-based organizations** rather than functional teams. Each organization represents a specific project or development initiative, allowing for clear project isolation and focused development workflows.
|
||||
Each organization represents a specific project or development initiative, allowing for clear project isolation and focused development workflows.
|
||||
|
||||
### 🎮 Main Development Projects
|
||||
|
||||
@ -57,7 +57,7 @@ Support Organizations are internal or auxiliary projects that provide tools, res
|
||||
### Team Creation Process
|
||||
|
||||
1. **Request Submission** → Team Leader submits a team creation request.
|
||||
2. **HoD[^2] Approval** → Head of Department reviews and approves the request.
|
||||
2. **HoD[^1] Approval** → Head of Department reviews and approves the request.
|
||||
3. **Team Setup** → HoD creates the team with appropriate permissions.
|
||||
4. **Member Assignment** → HoD adds members to the team.
|
||||
5. **Repository Access** → Repositories are assigned to the team as needed.
|
||||
@ -67,55 +67,67 @@ Support Organizations are internal or auxiliary projects that provide tools, res
|
||||
All organizations follow a standardized team structure with **four core team types** (structure can be modified as needed):
|
||||
|
||||
#### 👑 Owners Team
|
||||
* **Purpose:** Provide full administrative control over the organization.
|
||||
* **Members:** Head of Department (HoD)[^1] and senior management for that organization.
|
||||
* **Permissions:**
|
||||
* Create, modify, and delete resources within the organization.
|
||||
* Manage organization-wide settings, policies, and access controls.
|
||||
* Add or remove teams and members.
|
||||
* Approve major changes and policy updates.
|
||||
* Full access to all repositories.
|
||||
- **Purpose:** Provide full administrative control over the organization.
|
||||
- **Members:** HoD and senior management for that organization.
|
||||
- **Permissions:**
|
||||
- Create, modify, and delete resources within the organization.
|
||||
- Manage organization-wide settings, policies, and access controls.
|
||||
- Add or remove teams and members.
|
||||
- Approve major changes and policy updates.
|
||||
- Full access to all repositories.
|
||||
|
||||
#### 👥 Leaders Team
|
||||
* **Purpose:** Project management and technical leadership.
|
||||
* **Members:** Team Leaders.
|
||||
* **Permissions:**
|
||||
* Create repositories.
|
||||
* Manage team member permissions and assignments.
|
||||
* Configure repository settings and branch protection rules.
|
||||
* Review and approve pull requests.
|
||||
* Oversee project workflows.
|
||||
- **Purpose:** Project management and technical leadership.
|
||||
- **Members:** Team Leaders.
|
||||
- **Permissions:** (Administrator Access)
|
||||
- Create repositories.
|
||||
- Manage team member permissions and assignments.
|
||||
- Configure repository settings and branch protection rules.
|
||||
- Review and approve pull requests.
|
||||
- Oversee project workflows.
|
||||
|
||||
#### 💻 Developers Team
|
||||
* **Purpose:** Core development work and feature implementation.
|
||||
* **Members:** Game Developers.
|
||||
* **Permissions:**
|
||||
* Create branches and submit pull requests.
|
||||
* Access assigned repositories and project resources.
|
||||
* Participate in code reviews and technical discussions.
|
||||
* Implement features and contribute to development.
|
||||
- **Purpose:** Core development work and feature implementation.
|
||||
- **Members:** Game Developers.
|
||||
- **Permissions:**
|
||||
- Create branches and submit pull requests.
|
||||
- Access assigned repositories and project resources.
|
||||
- Participate in code reviews and technical discussions.
|
||||
- Implement features and contribute to development.
|
||||
|
||||
| **Unit** | **Description** | **Permission** |
|
||||
|:---------|:----------------|:--------------|
|
||||
| **Code** | Access source code, files, commits and branches | Write |
|
||||
| **Issues** | Organize bug reports, tasks and milestones | Write |
|
||||
| **Pull Requests** | Enable pull requests and code reviews | Write |
|
||||
| **Releases** | Track project versions and downloads | Read |
|
||||
| **Wiki** | Write and share documentation with collaborators | Write |
|
||||
| **Projects** | Manage issues and pulls in projects | Read |
|
||||
| **Packages** | Manage repository packages | Read |
|
||||
| **Actions** | Manage actions | Read |
|
||||
| **Access to External Wiki** | Link to an external wiki | No Access |
|
||||
| **Access to External Issues** | Link to an external issue tracker | No Access |
|
||||
|
||||
#### 🔧 Builders Team
|
||||
* **Purpose:** Manage build and deployment automation.
|
||||
* **Members:** Automation accounts (and optionally DevOps engineers).
|
||||
* **Permissions:**
|
||||
* Manage and run CI/CD pipelines.
|
||||
* Execute build configurations and scripts.
|
||||
* Perform automated deployments.
|
||||
* Hold cross-organization access for shared infrastructure.
|
||||
- **Purpose:** Manage build and deployment automation.
|
||||
- **Members:** Automation accounts (and optionally DevOps engineers).
|
||||
- **Permissions:** (Administrator Access)
|
||||
- Manage and run CI/CD pipelines.
|
||||
- Execute build configurations and scripts.
|
||||
- Perform automated deployments.
|
||||
- Hold cross-organization access for shared infrastructure.
|
||||
|
||||
---
|
||||
|
||||
## Team Assignment Guidelines
|
||||
|
||||
* **Organization-Specific Teams:** Each organization maintains its own complete set of base teams.
|
||||
* **Owners Team Scope:** Each organization has its own Owners Team, with authority limited to that organization.
|
||||
* **Cross-Project Access:** Builders Team may hold access to multiple organizations for shared infrastructure.
|
||||
* **Role Flexibility:** Team members may belong to multiple teams within the same organization if required.
|
||||
* **Permission Inheritance:** Team permissions are standardized and inherited from the base team structure.
|
||||
* **Isolation:** Owners of one organization cannot access or modify another organization.
|
||||
- **Organization-Specific Teams:** Each organization maintains its own complete set of base teams.
|
||||
- **Owners Team Scope:** Each organization has its own Owners Team, with authority limited to that organization.
|
||||
- **Cross-Project Access:** Builders Team may hold access to multiple organizations for shared infrastructure.
|
||||
- **Role Flexibility:** Team members may belong to multiple teams within the same organization if required.
|
||||
- **Permission Inheritance:** Team permissions are standardized and inherited from the base team structure.
|
||||
- **Isolation:** Owners of one organization cannot access or modify another organization.
|
||||
|
||||
---
|
||||
|
||||
[^1]: Continuous Integration/Continuous Deployment
|
||||
[^2]: Head of Department
|
||||
[^1]: Head of Department
|
||||
120
docs/02-version-control/04-gitea-repository.md
Normal file
120
docs/02-version-control/04-gitea-repository.md
Normal file
@ -0,0 +1,120 @@
|
||||
---
|
||||
id: 04-gitea-repository
|
||||
title: Gitea Repository
|
||||
---
|
||||
|
||||
# Gitea Repository Management
|
||||
|
||||
This document provides comprehensive guidelines for creating, configuring, and managing repositories in our Gitea instance. It covers repository setup, configuration, security settings, and best practices for effective repository management.
|
||||
|
||||
## Repository Overview
|
||||
|
||||
Repositories in our Gitea instance serve as the central storage and collaboration points for all code, documentation, and project assets. Each repository follows standardized practices to ensure consistency, security, and maintainability across all projects.
|
||||
|
||||
### Repository Types
|
||||
- **Project Repositories** → Game, lobby, and tools projects
|
||||
- **Library Repositories** → Shared code libraries and frameworks
|
||||
- **Documentation Repositories** → Project documentation and guides
|
||||
- **Template Repositories** → Project templates and boilerplates
|
||||
|
||||
---
|
||||
|
||||
## Repository Organization
|
||||
|
||||
### **Project Repositories**
|
||||
```
|
||||
<engine/platform>-<project-name>
|
||||
```
|
||||
**Examples:**
|
||||
- `unity-project-a` → Unity Engine project
|
||||
- `cocos-project-b` → Cocos Creator project
|
||||
- `haxe-project-c` → Haxe project
|
||||
- `p4f-game-core` → Game core project
|
||||
|
||||
## Repository Creation
|
||||
|
||||
### Prerequisites
|
||||
- **Team Leader or Owner Creation** → Repository must be created by a Team Leader or Owner
|
||||
- **Clear Purpose** → Repository must have a defined purpose and scope
|
||||
- **Naming Convention** → Repository name must follow established conventions
|
||||
|
||||
### Creation Process
|
||||
|
||||
#### 1. **Choose Right Organization**
|
||||
- Select appropriate organization based on project type
|
||||
- Verify organization permissions and access
|
||||
- Confirm project alignment with organization purpose
|
||||
|
||||
#### 2. **Create Repository**
|
||||
- Repository Name: `<project-name>-<component>`
|
||||
- Purpose: Brief description of repository purpose
|
||||
- Set default branch to `develop`
|
||||
- Choose appropriate visibility level
|
||||
|
||||
#### 3. **Initialize Project**
|
||||
- Add README.md with project information
|
||||
- Configure .gitignore for project type
|
||||
- Set up initial project structure
|
||||
|
||||
#### 4. **Create Branches**
|
||||
- Create `master` branch (main production branch)
|
||||
- Create `develop` branch (integration branch)
|
||||
- Create `release` branch (release preparation branch)
|
||||
|
||||
#### 5. **Configure Repository Features**
|
||||
- Enable required features (Issues, PRs, Wiki, Releases, Actions)
|
||||
- Set up project-specific settings
|
||||
|
||||
#### 6. **Configure Branch Protection**
|
||||
- Set up branch protection rules for `master`
|
||||
- Set up branch protection rules for `develop`
|
||||
- Set up branch protection rules for `release`
|
||||
- Configure required status checks and reviews
|
||||
|
||||
---
|
||||
|
||||
## Repository Configuration
|
||||
|
||||
### Basic Settings
|
||||
|
||||
#### **Repository Information**
|
||||
- **Name**: Follow established naming conventions
|
||||
- **Description**: Clear, concise description of purpose
|
||||
|
||||
#### **Visibility Settings**
|
||||
- **Private** → Only team members can access
|
||||
- **Internal** → Organization members can access
|
||||
- **Public** → Anyone can view (use with caution)
|
||||
|
||||
#### **Required Features**
|
||||
- **Code** → Required for code review process
|
||||
- **Issues** → Required for bug tracking and feature requests
|
||||
- **Pull Requests** → Required for code review process
|
||||
- **Releases** → Required for version management
|
||||
- **Wiki** → Optional for documentation
|
||||
- **Projects** → Required for project management
|
||||
- **Actions** → Required for CI/CD pipeline
|
||||
|
||||
---
|
||||
|
||||
## Branch Protection Rules
|
||||
Branch: **master**, **develop**, **release**\
|
||||
Protection Rules:
|
||||
- Disable push and force push
|
||||
- Disallow deletions
|
||||
- Limit Pull Request Approvals/Merges to Team Leaders
|
||||
- Automatically dismiss approvals when new commits change the pull request content
|
||||
- Prevent merging if reviews are rejected
|
||||
- Prevent merging on official review requests
|
||||
- Prevent merging if the pull request is outdated
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Repository Management
|
||||
- **Clear Documentation** → Maintain comprehensive README files
|
||||
- **Consistent Naming** → Follow established naming conventions
|
||||
- **Regular Updates** → Keep dependencies and documentation current
|
||||
- **Branch Hygiene** → Regular cleanup of merged feature branches
|
||||
- **Commit Standards** → Follow established commit message conventions
|
||||
Loading…
x
Reference in New Issue
Block a user