120 lines
4.1 KiB
Markdown

---
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