dev-public/doc-development-workflow
19
0
Fork 0
Code Issues Pull Requests Actions Projects Releases Activity
doc-development-workflow/docs/02-version-control/02-git-management.md
Le Hoang Nam b432ce83f3 Replace Git Workflow category with Version Control category and add Gitflow and Git Management documents 
- Deleted the obsolete Git Workflow category.
- Introduced a new Version Control category with a comprehensive guide to Git workflow, branching strategies, and repository management.
- Added Gitflow document detailing branching strategies and release management.
- Added Git Management document outlining Git policies, permissions, and branch protection rules.
2025-09-12 16:42:09 +07:00

3.0 KiB
Raw Blame History

id, title
id title
02-git-management 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/

Organization Permissions

✅ Only the HoD1 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 ↩︎