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.

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:

<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

Pull latest changes before starting:

git checkout develop
git pull origin develop

Create a new branch:

git checkout -b feature/your-feature-name

Make commits adhering to conventional commit rules.

Push branch to remote:

git push -u origin feature/your-feature-name

Open a Merge Request / Pull Request targeting the develop branch.
Code Review: At least one peer review is required before merging.
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.

3.0 KiB Raw Blame History