# 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.