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.
This commit is contained in:
parent
419a93837f
commit
b432ce83f3
@ -1,11 +0,0 @@
|
||||
{
|
||||
"label": "Git Workflow",
|
||||
"collapsible": false,
|
||||
"collapsed": false,
|
||||
"className": "blue",
|
||||
"link": {
|
||||
"type": "generated-index",
|
||||
"title": "Git Workflow",
|
||||
"description": "Git Workflow"
|
||||
}
|
||||
}
|
||||
@ -3,9 +3,21 @@ id: 02-gitflow
|
||||
title: Gitflow
|
||||
---
|
||||
|
||||
## **Overview**
|
||||
Gitflow is a branching strategy for Git that defines how to organize, develop, and release code in a structured way.
|
||||
|
||||
Gitflow is really just an abstract idea of a Git workflow. This means it dictates what kind of branches to set up and how to merge them together. We will touch on the purposes of the branches below.
|
||||
It provides a clear framework for:
|
||||
- Branch creation → where new features, fixes, or releases should start.
|
||||
- Branch merging → how and when to integrate changes.
|
||||
- Release management → preparing stable builds before deployment.
|
||||
- Hotfix handling → quickly addressing urgent issues in production.
|
||||
|
||||
By separating ongoing development from production-ready code, Gitflow ensures:
|
||||
- Smooth parallel development across teams.
|
||||
- Stable and reliable production releases.
|
||||
- A transparent and predictable release cycle.
|
||||
- A fast response to urgent production incidents.
|
||||
|
||||
---
|
||||
|
||||
## **Branches**
|
||||
|
||||
@ -261,7 +273,7 @@ They are similar to bugfix branches but always originate from the master branch,
|
||||
|
||||
## **Pull request flow**
|
||||
|
||||
A pull request is a development process that provides a platform for discussion and review of a completed feature. Its purpose is to notify team members that the feature has been completed and it is open for discussion or modifications. The discussion usually occurs to improve the quality of the code; it is basically a code review process.
|
||||
A pull request is a development process that provides a platform for discussion and review of a completed feature. Its purpose is to notify **developers** that the feature has been completed and it is open for discussion or modifications. The discussion usually occurs to improve the quality of the code; it is basically a code review process.
|
||||
|
||||
### What Needs to Be Done Before Creating a Pull Request?
|
||||
1. Commit code in your feature branch. Note that a feature can have any number of commits.
|
||||
@ -277,7 +289,7 @@ Note: Pull requests require two distinct branches. There needs to be a differenc
|
||||
1. When creating a pull request, you add a brief overview of your feature, select the branch to which the code needs to be merged, and select the assignee who will be reviewing it.
|
||||
2. Once it is created, it is open for discussion or modifications.
|
||||
3. Sometimes conflicts occur after creating a pull request, and you must resolve these conflicts.
|
||||
4. Usually, the assigned person reviews the code, but it is not mandatory that only the assignee performs the review. Any team member can take part in the review process and give their feedback or discuss potential modifications to the code.
|
||||
4. Usually, the **Team Leader** reviews the code, but it is not mandatory that only the assignee performs the review. Any **developer** can take part in the review process and give their feedback or discuss potential modifications to the code.
|
||||
5. Any feedback or modifications are added in the form of comments near the code line.
|
||||
6. The developer resolves comments and replies to the reviewer.
|
||||
7. This process continues until all comments are resolved.
|
||||
@ -321,4 +333,69 @@ To resolve the conflict, developer B must rebase the feature B branch by retriev
|
||||
|
||||
---
|
||||
|
||||
## Workflow Example
|
||||
|
||||
1. Developer creates `feature/new-feature` from `develop`.
|
||||
2. Developer pushes changes and opens a **Pull Request** to `develop`.
|
||||
3. After review and approval, the feature is merged into `develop`.
|
||||
4. Merge `develop` into `release` via **Pull Request**, make a **SAT** version is created from `release` and tagged with a version number.
|
||||
5. QA tests and approves the **SAT** version.
|
||||
6. Merge `release` into `master` for production and back into `develop` via **Pull Request**.
|
||||
7. If a production bug is found, a `hotfix/critical-payment-bug` branch is created from `master`, fixed, and merged into both `master` and `develop`.
|
||||
8. Make a new **LIVE** version from `master` and tagged with a version number.
|
||||
|
||||
```mermaid
|
||||
---
|
||||
config:
|
||||
theme: 'base'
|
||||
gitGraph:
|
||||
mainBranchName: 'master'
|
||||
showCommitLabel: false
|
||||
---
|
||||
gitGraph
|
||||
commit
|
||||
branch release
|
||||
branch develop
|
||||
checkout develop
|
||||
branch feature/new-feature
|
||||
commit
|
||||
checkout develop
|
||||
merge feature/new-feature
|
||||
checkout release
|
||||
merge develop tag: "v1"
|
||||
checkout master
|
||||
merge release
|
||||
branch hotfix/critical-bug
|
||||
commit
|
||||
checkout master
|
||||
merge hotfix/critical-bug tag: "v1_1"
|
||||
checkout develop
|
||||
merge hotfix/critical-bug
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Commit Message Guidelines
|
||||
|
||||
To ensure a clean and readable history, commit messages should follow the Conventional Commits format:
|
||||
|
||||
```
|
||||
<type>(<scope>): <short description>
|
||||
```
|
||||
|
||||
**Types:**
|
||||
|
||||
- `feat`: new feature
|
||||
- `fix`: bug fix
|
||||
- `chore`: maintenance / tooling changes
|
||||
- `docs`: documentation updates
|
||||
- `refactor`: code refactor without feature changes
|
||||
- `test`: adding or updating tests
|
||||
|
||||
**Example commits:**
|
||||
|
||||
- `feat(auth): add login API integration`
|
||||
- `fix(ui): resolve button alignment issue on mobile`
|
||||
- `docs(git): update branching guidelines`
|
||||
|
||||
[^1]: Site Acceptance Test
|
||||
100
docs/02-version-control/02-git-management.md
Normal file
100
docs/02-version-control/02-git-management.md
Normal file
@ -0,0 +1,100 @@
|
||||
---
|
||||
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
|
||||
11
docs/02-version-control/_category_.json
Normal file
11
docs/02-version-control/_category_.json
Normal file
@ -0,0 +1,11 @@
|
||||
{
|
||||
"label": "Version Control",
|
||||
"collapsible": false,
|
||||
"collapsed": false,
|
||||
"className": "blue",
|
||||
"link": {
|
||||
"type": "generated-index",
|
||||
"title": "Version Control",
|
||||
"description": "Comprehensive guide to Git workflow, branching strategies, and repository management using Gitea"
|
||||
}
|
||||
}
|
||||
Loading…
x
Reference in New Issue
Block a user