|
| 1 | +# Git Workflow & Branching Strategy |
| 2 | + |
| 3 | +This document outlines the standard Git workflow for our project. |
| 4 | + |
| 5 | +## 1. Branching Model |
| 6 | + |
| 7 | +We follow a simplified Gitflow-like model with `main` and `develop` as our primary long-lived branches. |
| 8 | + |
| 9 | +* **`main` Branch:** |
| 10 | + * Represents the **production-ready** code. |
| 11 | + * **Protected:** No direct pushes are allowed. |
| 12 | + * Only merges from the `develop` branch are permitted, typically for releases. |
| 13 | + |
| 14 | +* **`develop` Branch:** |
| 15 | + * Serves as the **integration branch** for all new features and bug fixes. |
| 16 | + * **Protected:** No direct pushes are allowed. |
| 17 | + * All new work must be merged into `develop` via a Pull Request (PR) from dedicated feature/fix branches. |
| 18 | + |
| 19 | +* **Feature/Fix/Hotfix Branches:** |
| 20 | + * **Purpose:** Where all active development takes place. |
| 21 | + * **Creation:** Always branched off `develop` (for features/fixes) or `main` (for critical hotfixes). |
| 22 | + * **Naming Convention:** |
| 23 | + * `feature/your-feature-name` (e.g., `feature/AM-123-new-login`) |
| 24 | + * `fix/your-bug-fix-name` (e.g., `fix/AM-456-broken-button`) |
| 25 | + * `hotfix/critical-issue` (only from `main`) |
| 26 | + |
| 27 | +## 2. Commit Message Guidelines |
| 28 | + |
| 29 | +We use [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) to ensure consistent and meaningful commit messages, which aids in changelog generation and understanding project history. |
| 30 | + |
| 31 | +* **Format:** `<type>(<scope>): <subject>` |
| 32 | +* **Example:** |
| 33 | + * `feat: add new user registration flow` |
| 34 | + * `fix(auth): correct password reset bug` |
| 35 | + * `chore: update dependencies` |
| 36 | + * `docs: update README with new API endpoint` |
| 37 | + |
| 38 | +### CI Enforcement (`commitlint`) |
| 39 | + |
| 40 | +Our CI pipeline includes a `commitlint` check that runs on every Pull Request targeting the `develop` branch. |
| 41 | +This action ensures that all commit messages within your PR adhere to the Conventional Commits specification. |
| 42 | +If any commit message in your PR violates the rules, the CI check will fail, and the PR cannot be merged until corrected. |
0 commit comments