Git Workflow

Git Workflow

This skill provides universal Git workflow and conventional commits guidelines.

See @REFERENCE.md for detailed documentation.

Quick Reference

• Commits: <type>(<scope>): <description>
• Types: feat, fix, docs, style, refactor, perf, test, build, ci, chore
• Branches: feature/, fix/, refactor/, docs/
• Max branch life: 3 days
• Review: Required before merge

Git Workflow

Universal Git workflow guidelines with GitHub Flow and Conventional Commits.

Part of Claude-Craft -- AI-assisted development framework for Claude Code.

Installation

Copy this directory to your project's .claude/skills/ directory:

cp -r git-workflow/ your-project/.claude/skills/git-workflow/

What's Included

• SKILL.md -- Skill definition with triggers and quick reference
• REFERENCE.md -- Comprehensive Git workflow guidelines covering GitHub Flow, conventional commits, branching, pull requests, and code review

Covers

• GitHub Flow -- main branch always deployable, feature branches, PRs
• Conventional Commits -- <type>(<scope>): <description> format
• Branch naming -- feature/, fix/, refactor/, docs/
• Pull request templates -- checklists for code, tests, docs, security
• Code review process -- reviewer checklists, constructive feedback

Technology Agnostic

This skill provides universal Git workflow practices applicable to any project regardless of language or framework. Works with GitHub, GitLab, Bitbucket, or any Git hosting platform.

License

MIT -- See Claude-Craft for full license.

Git Workflow

Vue d'ensemble

Le workflow Git est basé sur GitHub Flow avec des Conventional Commits obligatoires.

Principes:

• ✅ Branche main toujours déployable
• ✅ Feature branches courtes (< 3 jours)
• ✅ Pull Requests obligatoires
• ✅ Code review avant merge
• ✅ CI doit passer (tests + qualité)

---

Table des matières

1. GitHub Flow 2. Conventional Commits 3. Branches 4. Pull Requests 5. Code Review 6. Checklist PR

---

GitHub Flow

Workflow

main (production-ready)
  │
  ├─> feature/add-user-authentication
  │   │
  │   ├─ commit: feat: add login form
  │   ├─ commit: feat: add auth service
  │   ├─ commit: test: add auth tests
  │   │
  │   └─> Pull Request → Code Review → Merge
  │
  └─> main (updated)

Règles

1. `main` est toujours déployable 2. Nouvelle fonctionnalité = nouvelle branche 3. Commits atomiques et testés 4. PR + Review obligatoires 5. CI doit passer avant merge 6. Squash merge pour historique propre

Pre-Release Strategy (SemVer)

Avant une release en production, utiliser des pre-releases pour validation :

Workflow :

feature/add-payment
  ├─ 2.0.0-alpha.1 (branche develop)
  ├─ 2.0.0-beta.1 (tests QA)
  ├─ 2.0.0-rc.1 (staging)
  └─ 2.0.0 (main → production)

Règles SemVer :

• MAJOR (X.0.0) : Breaking changes
• MINOR (x.Y.0) : Nouvelles features, backward-compatible
• PATCH (x.y.Z) : Bug fixes uniquement

---

Conventional Commits

Format

<type>(<scope>): <description>

[optional body]

[optional footer(s)]

Types obligatoires

Scopes recommandés

Utilisez les bounded contexts ou modules de votre projet:

• auth - Authentification
• user - Gestion utilisateurs
• order - Commandes
• payment - Paiements
• notification - Notifications
• infra - Infrastructure

Outils de validation

• Commitlint: @commitlint/config-conventional avec subject-max-length: 72
• Git hook: .husky/commit-msg → npx --no-install commitlint --edit "$1"

---

Branches

Nomenclature

<type>/<description-courte>

Types:

• feature/ - Nouvelle fonctionnalité
• fix/ - Correction de bug
• refactor/ - Refactoring
• docs/ - Documentation
• chore/ - Maintenance

Exemples

feature/add-user-registration    ✅
fix/login-validation-error       ✅
refactor/extract-auth-service    ✅
dev-branch                       ❌
my-work                          ❌
feature123                       ❌

Durée de vie

• Maximum 3 jours de développement
• Si > 3 jours → découper en plusieurs PRs
• Merge dès que fonctionnel (même si incomplet)
• Utiliser feature flags si nécessaire

Toujours partir de main à jour : git checkout main && git pull origin main

---

Pull Requests

Labels

---

Code Review

Checklist Reviewer

Architecture

• [ ] Principes SOLID respectés
• [ ] Couches bien séparées
• [ ] Pas de dépendances inversées

Code Quality

• [ ] KISS / DRY / YAGNI appliqués
• [ ] Nommage explicite
• [ ] Pas de duplication de code
• [ ] Complexité acceptable (< 10)
• [ ] Méthodes courtes (< 20 lignes)

Tests

• [ ] Tests pour la logique métier
• [ ] Couverture ≥ 80%
• [ ] Tous les tests passent
• [ ] Pas de tests commentés

Sécurité

• [ ] Pas de secrets en dur
• [ ] Validation des inputs
• [ ] Protection XSS/CSRF

Performance

• [ ] Pas de N+1 queries
• [ ] Indexes appropriés
• [ ] Pagination si nécessaire

Process de review

1. Auto-review (auteur) — relire, vérifier checklist, tester manuellement 2. Première passe (reviewer) — architecture, logique métier, tests 3. Deuxième passe (reviewer) — détails d'implémentation, nommage, optimisations 4. Commentaires — constructifs, suggérer des solutions, expliquer le "pourquoi" 5. Approbation — ✅ Approve / 💬 Comment / 🔴 Request changes

---

Checklist PR

Avant de créer la PR

• [ ] Tests passent (make test)
• [ ] Couverture ≥ 80% (make test-coverage)
• [ ] Linter : 0 erreur (make quality)
• [ ] Self-review : git diff main...HEAD

Pendant la review

• Appliquer les suggestions avec un commit fix: apply code review suggestions
• Rebaser si nécessaire : git rebase origin/main puis git push --force-with-lease

Avant le merge

• [ ] Branche à jour avec main
• [ ] CI passe
• [ ] Au moins 1 approve
• [ ] Squash and merge (historique propre)

---

Ressources

• GitHub Flow: Guide
• Conventional Commits: Specification
• Commitlint: Documentation
• Git Best Practices: Atlassian Guide

---

Date de dernière mise à jour: 2026-04 Version: 1.1.0 Auteur: The Bearded CTO