80 lines
3.0 KiB
Markdown
80 lines
3.0 KiB
Markdown
# Team Contribution & Git Guidelines
|
|
|
|
This document defines the Git conventions, branching strategy, and contribution workflow for the `acc-installer` team.
|
|
|
|
---
|
|
|
|
## 1. Branching Strategy
|
|
|
|
Our team uses a **Feature Branch** workflow based on `main` and `develop`:
|
|
|
|
* `main` — **Production / Release**: Contains only stable, tested code. Direct commits or push to `main` are strictly forbidden.
|
|
* `develop` — **Integration / Staging**: Contains completed features ready for integration and testing.
|
|
* `feature/<feature-name>` — **New Features**: Branch created from `develop` for a specific feature or task (e.g. `feature/ui-installer`, `feature/config-loader`).
|
|
* `fix/<bug-name>` — **Bug Fixes**: Branch created from `develop` to fix bugs.
|
|
* `hotfix/<issue-name>` — **Critical Fixes**: Branch created directly from `main` for critical production hotfixes.
|
|
|
|
```text
|
|
main ─────────────────────────● (v1.0.0) ───────────● (v1.1.0)
|
|
▲ ▲
|
|
│ │
|
|
develop ──────●─────────────────●───────────────────●
|
|
\ / \ /
|
|
feature ●──────●──────● ●──────●───────●
|
|
(feature/copy) (feature/extract)
|
|
```
|
|
|
|
---
|
|
|
|
## 2. Commit Message Conventions (Conventional Commits)
|
|
|
|
All commit messages must follow the format:
|
|
|
|
```text
|
|
<type>(<scope>): <short summary>
|
|
|
|
[optional body explaining context or breaking changes]
|
|
```
|
|
|
|
### Allowed Types:
|
|
* `feat`: A new feature or functionality
|
|
* `fix`: A bug fix
|
|
* `refactor`: Code restructuring without changing external behavior
|
|
* `docs`: Documentation updates (`README.md`, docstrings, etc.)
|
|
* `chore`: Maintenance tasks, config updates, `.gitignore`, dependencies
|
|
* `test`: Adding or modifying tests
|
|
|
|
### Examples:
|
|
* `feat(copier): add verification checksum after file copy`
|
|
* `fix(drive): fallback to C: drive when no other drive exists`
|
|
* `docs: update setup steps in README`
|
|
|
|
---
|
|
|
|
## 3. Pull Request / Merge Request Workflow
|
|
|
|
1. **Pull latest changes** before starting:
|
|
```powershell
|
|
git checkout develop
|
|
git pull origin develop
|
|
```
|
|
2. **Create a new branch**:
|
|
```powershell
|
|
git checkout -b feature/your-feature-name
|
|
```
|
|
3. **Make commits** adhering to conventional commit rules.
|
|
4. **Push branch to remote**:
|
|
```powershell
|
|
git push -u origin feature/your-feature-name
|
|
```
|
|
5. **Open a Merge Request / Pull Request** targeting the `develop` branch.
|
|
6. **Code Review**: At least one peer review is required before merging.
|
|
7. **Delete merged branch** after merging.
|
|
|
|
---
|
|
|
|
## 4. Code Standards
|
|
* Use Python type annotations (`str`, `Optional[str]`, `Path`, etc.).
|
|
* Avoid hardcoded paths; use `module.config.InstallerConfig`.
|
|
* Keep error messages clear and informative with actionable failure reasons.
|