---
id: 02-git-management
title: Git Management
---

This document defines the Git management policies, access controls, and branch protection rules for our development workflow. It ensures secure, consistent, and collaborative use of Git across teams by clearly defining permissions and naming conventions.

## Git Repository

🔗 [https://gitea.plp19.com/](https://gitea.plp19.com/)

---

## Organization Permissions

✅ Only the HoD[^1] can create, modify, and delete organizations.\
✅ Only the HoD can add teams and grant permissions for organizations.

---

## Repository Permissions

✅ Only the HoD and Team Leaders can create, modify, and delete repositories.\
✅ Only the HoD and Team Leaders can change settings for repositories.

---

## Branch Permissions

### 🔒 `master` branch
Contains code that is deployed to live environments.
- Prevent rewriting history.
- Prevent branch deletion.
- Prevent changes without a pull request.
- Limit write access to Team Leaders and HoD.

### 🔒 `release` branch
Contains code that is being prepared for production release.
- Prevent rewriting history.
- Prevent branch deletion.
- Prevent changes without a pull request.
- Limit write access to Team Leaders and HoD.

### 🔒 `develop` branch
Integration branch for features, contains the latest development changes.
- Prevent rewriting history.
- Prevent branch deletion.
- Prevent changes without a pull request.
- Limit write access to Team Leaders and HoD.

### 🔒 Other branches

- Developers have full access to create, update, and delete their own branches.  
- Naming must follow branch prefix conventions.  

---

## Branch Prefixes

### ✅ `feature/<name>`
For new feature development.  
- Branches are created from `develop`.  
- Merged back into `develop` via pull request.  

### ✅ `bugfix/<name>`
For fixes identified during development or staging (pre-production).  
- Branches are created from `release`.  
- Merged back into both `release` and `develop` via pull request.  

### ✅ `hotfix/<name>`
For urgent fixes to LIVE production.  
- Branches are created from `master`.  
- Merged back into both `master` and `develop` via pull request.  

---

## Enforcement Rules

To maintain consistency and stability, the following rules must be enforced in the Git platform (Gitea):

- `master`, `release`, and `develop` must be protected branches.
- All merges into protected branches require a pull request.
- Pull requests into `master` and `release` must have at least 1 review approval from a Team Leader or HoD.
- Force pushes and direct commits to protected branches are disabled.
- CI/CD checks must pass before merging into `release` or `master`.

---

## Code Review Standards

To maintain quality:
- Every **Pull Request** must be reviewed by at least one **Team Leader**.
- Review checklist includes:
    - Code follows style guidelines.
    - No unused or debug code.
    - Tests added/updated where necessary.
    - Security and performance considerations checked.

---
[^1]: Head of Department