## Introduction

GitFlow est un modele de branchement Git qui definit une structure stricte pour gerer le developpement, les releases et les corrections de bugs. SmartStack CLI automatise entierement ce workflow avec des commandes intelligentes qui gerent le versioning, les migrations EF Core et les conflits.

GitFlow is a Git branching model that defines a strict structure for managing development, releases and bug fixes. SmartStack CLI fully automates this workflow with intelligent commands that handle versioning, EF Core migrations and conflicts.

💡

##### Pourquoi GitFlow ?

##### Why GitFlow?

GitFlow est ideal pour les projets avec des cycles de release planifies, une equipe de plusieurs developpeurs, et un besoin de maintenir plusieurs versions en production.

GitFlow is ideal for projects with planned release cycles, a team of multiple developers, and a need to maintain multiple versions in production.

## Quick Start

🚀

##### Commandes essentielles

##### Essential Commands

Les commandes les plus utilisees pour demarrer rapidement.

The most commonly used commands to get started quickly.

Action Action | Commande Command | Raccourci Shorthand
--- | --- | ---
Demarrer feature Start feature | `/gitflow start feature xxx` | `/gitflow -f xxx`
Demarrer release Start release | `/gitflow start release 2.0.0` | `/gitflow -r 2.0.0`
Demarrer hotfix Start hotfix | `/gitflow start hotfix xxx` | `/gitflow -h xxx`
Commit | `/gitflow commit` | `/gitflow -a commit "msg"`
Creer PR Create PR | `/gitflow pr` | -
Merge | `/gitflow merge` | -
Finaliser Finish | `/gitflow finish` | -
Status | `/gitflow status` | `/gitflow -s`

### Flags disponibles Available Flags

Flag | Long | Description
--- | --- | ---
`-f` | `--feature` | Workflow feature (cible: develop) Feature workflow (target: develop)
`-r` | `--release` | Workflow release (cible: main, merge-back develop) Release workflow (target: main, merge-back develop)
`-h` | `--hotfix` | Workflow hotfix (cible: main, merge-back develop) Hotfix workflow (target: main, merge-back develop)
`-a` | `--auto` | Mode autonome: sauter les confirmations Autonomous mode: skip confirmations
`-s` | `--status` | Mode status: afficher l'etat uniquement Status mode: show state only
`-v` | `--verbose` | Sortie detaillee Verbose output
`` | `--dry-run` | Previsualiser sans executer Preview actions without executing

## Concepts cles Key Concepts

### SemVer (Semantic Versioning)

Le versioning semantique utilise le format `MAJOR.MINOR.PATCH` :

Semantic versioning uses the format `MAJOR.MINOR.PATCH`:

Type | Quand incrementer When to increment | Exemple Example
--- | --- | ---
MAJOR | Breaking changes, API incompatible Breaking changes, incompatible API | 1.0.0 → 2.0.0
MINOR | Nouvelles fonctionnalites retrocompatibles New backwards-compatible features | 1.0.0 → 1.1.0
PATCH | Corrections de bugs retrocompatibles Backwards-compatible bug fixes | 1.0.0 → 1.0.1

### Strategie de merge

### Merge Strategy

SmartStack CLI utilise `--no-ff` (no fast-forward) par defaut pour preserver l'historique des branches :

SmartStack CLI uses `--no-ff` (no fast-forward) by default to preserve branch history:

    # Avec --no-ff : cree un commit de merge
    *   Merge branch 'feature/login' into develop
    |\
    | * Add login form
    | * Add authentication logic
    |/
    *   Previous commit

    # Sans --no-ff : historique lineaire (perd le contexte)
    * Add authentication logic
    * Add login form
    * Previous commit

## Types de branches Branch Types

M
main / master
Production

Branche de production. Chaque commit represente une version deployee. Protegee contre les push directs.

Production branch. Each commit represents a deployed version. Protected from direct pushes.

Protected
D
develop
Integration

Branche d'integration. Recoit les features terminees. Base pour les nouvelles features et releases.

Integration branch. Receives completed features. Base for new features and releases.

Protected
F
feature/*
Nouvelles fonctionnalites
New features

Branches de developpement. Creees depuis develop, mergees dans develop. Increment MINOR automatique.

Development branches. Created from develop, merged into develop. Automatic MINOR increment.

+minor
R
release/*
Preparation de release
Release preparation

Preparation d'une nouvelle version. Creee depuis develop, mergee dans main ET develop. Tag cree automatiquement.

Preparation of a new version. Created from develop, merged into main AND develop. Tag created automatically.

+tag
H
hotfix/*
Corrections urgentes
Urgent fixes

Corrections critiques en production. Creee depuis main, mergee dans main ET develop. Increment PATCH automatique.

Critical production fixes. Created from main, merged into main AND develop. Automatic PATCH increment.

+patch

### Schema du workflow

### Workflow Diagram

💡 Cliquez sur n'importe quel element du schema pour voir sa definition et la commande associee. 💡 Click on any element in the diagram to see its definition and associated command.

#### Legende - Branches

#### Legend - Branches

main (production)
develop (integration)
feature/*
release/*
hotfix/*

#### Legende - Elements visuels

#### Legend - Visual Elements

Visuel Visual | Nom Name | Signification Meaning
--- | --- | ---
| Ligne pleine Solid line | Branche active - flux principal de developpement Active branch - main development flow
| Ligne pointillee Dashed line | Merge back - synchronisation vers develop apres merge dans main Merge back - sync to develop after merging into main
| Cercle plein Solid circle | Commit standard sur la branche Standard commit on the branch
| Cercle avec bordure Circle with border | Commit de merge - integration d'une branche (couleur bordure = source) Merge commit - branch integration (border color = source)
v1.0 | Tag de version Version tag | Version deployee en production (cree lors du finish) Version deployed to production (created on finish)
| Fleche de merge Merge arrow | Direction du merge (feature → develop) Merge direction (feature → develop)

### Quand utiliser quelle commande ? When to use which command?

💡

##### Deux methodes d'integration

##### Two Integration Methods

1. Methode PR (Recommandee) : `/gitflow pr` → `/gitflow finish`

- Cree une Pull Request pour revue de code
- Apres merge de la PR, `/gitflow finish` supprime la branche locale ET remote
- A utiliser pour : features, releases, hotfixes

2. Methode directe (Legacy) : `/gitflow plan` → `/gitflow merge`

- Merge directement sans Pull Request
- Utile pour les projets solo ou CI/CD automatise
- Attention : Ne supprime pas la branche remote automatiquement

1. PR Method (Recommended): `/gitflow pr` → `/gitflow finish`

- Creates a Pull Request for code review
- After PR merge, `/gitflow finish` deletes both local AND remote branches
- Use for: features, releases, hotfixes

2. Direct Method (Legacy): `/gitflow plan` → `/gitflow merge`

- Merges directly without Pull Request
- Useful for solo projects or automated CI/CD
- Warning: Does not automatically delete remote branch

🗑

##### Suppression des branches remote

##### Remote Branch Deletion

`/gitflow finish` supprime automatiquement la branche sur le remote (`git push origin --delete {branch}`). Pour un nettoyage complet des worktrees orphelins, utilisez `/gitflow cleanup`.

`/gitflow finish` automatically deletes the remote branch (`git push origin --delete {branch}`). For complete cleanup of orphan worktrees, use `/gitflow cleanup`.

## Architecture & Structure Architecture & Structure

### Structure des Worktrees

### Worktrees Structure

GitFlow utilise des git worktrees pour isoler chaque branche dans son propre repertoire. Cela permet de travailler sur plusieurs branches simultanement sans avoir a faire de checkout.

GitFlow uses git worktrees to isolate each branch in its own directory. This allows working on multiple branches simultaneously without having to checkout.

### Fichiers de configuration

### Configuration Files

Fichier File | Description Description
--- | ---
`.claude/gitflow/config.json` | Configuration principale : versioning, branches, EF Core, worktrees Main configuration: versioning, branches, EF Core, worktrees
`.claude/gitflow/plans/` | Plans d'integration generes par /gitflow plan Integration plans generated by /gitflow plan
`.claude/gitflow/logs/` | Historique des operations et checkpoints Operations history and checkpoints
`.claude/gitflow/migrations/` | Snapshots EF Core pour detection de conflits EF Core snapshots for conflict detection

### Creation automatique

### Automatic Creation

La structure est creee automatiquement par `/gitflow init`. Les worktrees sont crees lors du premier `/gitflow start`.

The structure is automatically created by `/gitflow init`. Worktrees are created on the first `/gitflow start`.

    # Initialiser GitFlow avec worktrees
    /gitflow init --with-worktrees

    # Demarrer une feature (cree le worktree automatiquement)
    /gitflow start feature user-auth
    # → Worktree cree: ../worktrees/features/user-auth/

    # Travailler sans worktree (meme repertoire)
    /gitflow start feature test --no-worktree

## Bonnes pratiques Best Practices

#### ✅ Nommage des branches Branch Naming

Utilisez des noms descriptifs et kebab-case :

Use descriptive names with kebab-case:

    # Bon
    feature/user-authentication
    feature/add-payment-gateway
    hotfix/fix-login-redirect
    release/v2.1.0

    # Mauvais
    feature/auth
    feature/MyNewFeature
    hotfix/fix
    release/new

#### ✅ Commits atomiques Atomic Commits

Chaque commit doit representer un changement logique unique. Utilisez `/gitflow commit` pour des commits structures.

Each commit should represent a single logical change. Use `/gitflow commit` for structured commits.

    # Bon - Commits atomiques
    feat(auth): add login form component
    feat(auth): implement JWT token validation
    fix(auth): handle expired token refresh

    # Mauvais - Commit fourre-tout
    WIP: auth stuff

#### ✅ Rebase avant merge Rebase Before Merge

Avant de merger une feature, rebaser sur develop pour avoir un historique propre et eviter les conflits de merge.

Before merging a feature, rebase on develop to have a clean history and avoid merge conflicts.

    # SmartStack CLI le fait automatiquement avec /gitflow merge
    # Manuellement :
    git checkout feature/my-feature
    git fetch origin
    git rebase origin/develop
    # Resoudre les conflits si necessaire
    git checkout develop
    git merge --no-ff feature/my-feature

#### ✅ Ne jamais push sur main directement Never Push to Main Directly

Toutes les modifications doivent passer par des branches feature, release ou hotfix. SmartStack CLI protege automatiquement les branches principales.

All changes must go through feature, release or hotfix branches. SmartStack CLI automatically protects main branches.

#### 🗑 Nettoyer regulierement les worktrees Regularly Clean Up Worktrees

Apres chaque release ou hotfix, les worktrees sont nettoyes automatiquement. Pour un audit complet, utilisez `/gitflow cleanup` depuis main ou develop.

After each release or hotfix, worktrees are automatically cleaned up. For a full audit, use `/gitflow cleanup` from main or develop.

    # Audit et nettoyage complet (depuis main ou develop)
    /gitflow cleanup

    # Audit seul sans suppression
    /gitflow cleanup --dry-run

    # Nettoyage automatique des orphelins
    /gitflow cleanup --force

#### ✅ Tester avant de merger Test Before Merging

`/gitflow merge` execute automatiquement les tests, le build et le lint avant tout merge.

`/gitflow merge` automatically runs tests, build and lint before any merge.

⚠

##### Eviter les anti-patterns

##### Avoid Anti-patterns

❌ Ne jamais force push sur main ou develop Never force push to main or develop
❌ Ne pas merger une feature non testee Don't merge an untested feature
❌ Ne pas laisser des branches ouvertes trop longtemps Don't leave branches open too long
❌ Ne pas ignorer les conflits de ModelSnapshot (EF Core) Don't ignore ModelSnapshot conflicts (EF Core)

## Commandes GitFlow GitFlow Commands

SmartStack CLI fournit 11 commandes pour gerer le workflow GitFlow. Chaque commande inclut son prompt complet.

SmartStack CLI provides 11 commands to manage the GitFlow workflow. Each command includes its complete prompt.

`/gitflow init` Setup

Cette commande est le point d'entree obligatoire pour tout nouveau projet utilisant GitFlow. Elle analyse le repository existant pour detecter la source de version (package.json, .csproj, VERSION file), identifie les branches deja presentes, et detecte automatiquement si le projet utilise Entity Framework Core. A partir de cette analyse, elle genere un plan d'initialisation detaille que l'utilisateur peut valider avant execution. Une fois approuve, elle cree la structure complete : branches main et develop, dossier .claude/gitflow/ avec la configuration, et met a jour CLAUDE.md avec les informations du projet. Cette approche en deux temps (plan puis execution) garantit une initialisation sans surprise et parfaitement adaptee au contexte du projet.

This command is the mandatory entry point for any new project using GitFlow. It analyzes the existing repository to detect the version source (package.json, .csproj, VERSION file), identifies branches already present, and automatically detects if the project uses Entity Framework Core. From this analysis, it generates a detailed initialization plan that the user can validate before execution. Once approved, it creates the complete structure: main and develop branches, .claude/gitflow/ folder with configuration, and updates CLAUDE.md with project information. This two-step approach (plan then execution) ensures a surprise-free initialization perfectly adapted to the project context.

    /gitflow init

`/gitflow status` Info

Cette commande est votre tableau de bord avant toute action GitFlow. Elle collecte et affiche l'etat complet du repository : branche courante et son type (feature/release/hotfix), version actuelle lue depuis la source configuree, synchronisation avec develop et main (commits ahead/behind), et etat des migrations EF Core. Elle detecte egalement les risques potentiels comme une divergence importante avec develop, des migrations non commitees, ou des conflits ModelSnapshot imminents. Utilisez-la systematiquement avant de commencer une operation pour avoir une vision claire de la situation. L'option --all-branches permet de voir l'etat des migrations sur toutes les branches actives avec un ordre de merge recommande.

This command is your dashboard before any GitFlow action. It collects and displays the complete repository state: current branch and its type (feature/release/hotfix), current version read from the configured source, synchronization with develop and main (commits ahead/behind), and EF Core migrations status. It also detects potential risks such as significant divergence from develop, uncommitted migrations, or imminent ModelSnapshot conflicts. Use it systematically before starting an operation to have a clear view of the situation. The --all-branches option shows migration status across all active branches with a recommended merge order.

    /gitflow status

    # Voir toutes les branches avec migrations
    /gitflow status --all-branches

`/gitflow commit` Git

Cette commande remplace le commit Git standard par un commit intelligent adapte au workflow GitFlow et EF Core. Elle analyse automatiquement les fichiers modifies pour valider que les migrations EF Core sont completes (les 3 fichiers requis), detecte les operations destructives comme DropTable ou DropColumn qui necessitent une confirmation explicite, et genere un message de commit structure selon les conventions (feat:, fix:, db:). Si vous travaillez dans un worktree, elle propose automatiquement de pousser vers le remote apres le commit. Cette validation en amont evite les erreurs courantes comme committer une migration incomplete ou oublier de signaler une operation destructive a l'equipe.

This command replaces the standard Git commit with a smart commit adapted to GitFlow and EF Core workflow. It automatically analyzes modified files to validate that EF Core migrations are complete (the 3 required files), detects destructive operations like DropTable or DropColumn that require explicit confirmation, and generates a structured commit message following conventions (feat:, fix:, db:). If you're working in a worktree, it automatically offers to push to remote after the commit. This upstream validation prevents common errors like committing an incomplete migration or forgetting to signal a destructive operation to the team.

    /gitflow commit

🚀

##### Push automatique pour worktrees

##### Automatic push for worktrees

Si vous travaillez dans un git worktree, le push est automatique apres le commit. Configurable dans `.claude/gitflow/config.json` via `workflow.push.afterCommit`.

If you're working in a git worktree, push is automatic after commit. Configurable in `.claude/gitflow/config.json` via `workflow.push.afterCommit`.

`/gitflow plan` Planning

Cette commande prepare une integration complexe en analysant tous les aspects critiques avant l'execution. Elle examine la branche courante pour determiner le nombre de commits a integrer, detecte les migrations EF Core presentes et verifie s'il y a un conflit ModelSnapshot avec la branche cible. En fonction du type de branche (feature, release, hotfix), elle determine la strategie optimale : rebase simple, rebase avec recreation de migration si conflit, ou merge direct. Le resultat est un fichier plan detaille dans .claude/gitflow/plans/ qui liste toutes les etapes a executer, les risques identifies, et les actions de rollback possibles. Ce plan peut etre relu et valide avant execution avec /gitflow merge.

This command prepares a complex integration by analyzing all critical aspects before execution. It examines the current branch to determine the number of commits to integrate, detects present EF Core migrations and checks for ModelSnapshot conflicts with the target branch. Based on branch type (feature, release, hotfix), it determines the optimal strategy: simple rebase, rebase with migration recreation if conflict, or direct merge. The result is a detailed plan file in .claude/gitflow/plans/ listing all steps to execute, identified risks, and possible rollback actions. This plan can be reviewed and validated before execution with /gitflow merge.

    /gitflow plan

`/gitflow merge` Execution

Cette commande execute le plan genere par /gitflow plan de maniere securisee et tracable. Elle commence par creer un checkpoint permettant un rollback en cas de probleme, puis execute chaque etape du plan : fetch des dernieres modifications, rebase sur la branche cible si necessaire (avec gestion automatique des conflits ModelSnapshot), merge avec l'option --no-ff pour preserver l'historique, et mise a jour du versioning. Pour les releases et hotfixes, elle gere automatiquement le tag Git et l'increment de version. A chaque etape, elle valide le build et les tests. En cas d'echec, elle peut etre reprise avec --resume ou annulee avec /gitflow abort. L'option --dry-run permet de simuler l'execution sans rien modifier.

This command executes the plan generated by /gitflow plan in a secure and traceable manner. It starts by creating a checkpoint allowing rollback in case of issues, then executes each plan step: fetching latest changes, rebasing on target branch if needed (with automatic ModelSnapshot conflict handling), merging with --no-ff option to preserve history, and version update. For releases and hotfixes, it automatically handles Git tag and version increment. At each step, it validates build and tests. On failure, it can be resumed with --resume or cancelled with /gitflow abort. The --dry-run option allows simulating execution without modifying anything.

    /gitflow merge

`/gitflow abort` Rollback

Cette commande est votre filet de securite quand une operation GitFlow tourne mal. Elle detecte automatiquement l'etat actuel du repository (merge en cours, rebase interrompu, conflit non resolu) et propose les options de recuperation appropriees. Elle peut annuler un merge avec git merge --abort, restaurer l'etat complet depuis un checkpoint sauvegarde par /gitflow merge, abandonner completement une branche feature/hotfix en la supprimant proprement, ou nettoyer le working directory. Avant toute operation destructive, elle affiche clairement ce qui sera perdu et demande une confirmation explicite. C'est la commande a utiliser en cas de probleme pour revenir a un etat stable sans perdre de travail.

This command is your safety net when a GitFlow operation goes wrong. It automatically detects the current repository state (ongoing merge, interrupted rebase, unresolved conflict) and offers appropriate recovery options. It can cancel a merge with git merge --abort, restore complete state from a checkpoint saved by /gitflow merge, completely abandon a feature/hotfix branch by cleanly deleting it, or clean the working directory. Before any destructive operation, it clearly shows what will be lost and asks for explicit confirmation. This is the command to use when problems occur to return to a stable state without losing work.

    /gitflow abort

`/gitflow pr` PR

Cette commande automatise la creation de Pull Request en generant un contenu professionnel et complet. Elle commence par verifier que vous etes sur une branche de travail valide (feature, release, hotfix), execute les pre-checks (build, tests) et detecte la presence de migrations EF Core. Elle genere ensuite automatiquement le titre depuis le nom de branche, construit la description a partir des commits effectues, ajoute les labels appropries (feature, bugfix, enhancement) et lie les issues mentionnees. La PR ciblee est determinee automatiquement : develop pour les features, main pour les releases et hotfixes. L'option --draft permet de creer une PR en mode brouillon pour obtenir des feedbacks avant finalisation.

This command automates Pull Request creation by generating professional and complete content. It starts by verifying you're on a valid working branch (feature, release, hotfix), runs pre-checks (build, tests) and detects EF Core migrations presence. It then automatically generates the title from the branch name, builds the description from commits made, adds appropriate labels (feature, bugfix, enhancement) and links mentioned issues. The target PR is determined automatically: develop for features, main for releases and hotfixes. The --draft option creates a draft PR to get feedback before finalization.

    # PR vers develop (default)
    /gitflow pr

    # PR vers main (release/hotfix)
    /gitflow pr main

    # PR en draft
    /gitflow pr --draft

`/gitflow merge` Review

Cette commande effectue une revue de code structuree et exhaustive d'une Pull Request. Elle analyse le diff complet en verifiant plusieurs aspects : qualite du code (patterns existants, duplication, nommage, gestion d'erreurs), bonnes pratiques .NET (injection de dependances, async/await, null safety, LINQ), migrations EF Core si presentes (reversibilite, breaking changes, indexes, foreign keys), securite (exposition de donnees sensibles, validation d'inputs, SQL injection) et couverture de tests. Elle genere un rapport structure avec une recommandation finale (APPROVE ou CHANGES_REQUESTED). Les options --security et --ef-core permettent de se concentrer sur un aspect specifique, tandis que --quick produit une checklist rapide pour les petits changements.

This command performs a structured and exhaustive code review of a Pull Request. It analyzes the complete diff checking multiple aspects: code quality (existing patterns, duplication, naming, error handling), .NET best practices (dependency injection, async/await, null safety, LINQ), EF Core migrations if present (reversibility, breaking changes, indexes, foreign keys), security (sensitive data exposure, input validation, SQL injection) and test coverage. It generates a structured report with a final recommendation (APPROVE or CHANGES_REQUESTED). The --security and --ef-core options focus on specific aspects, while --quick produces a fast checklist for small changes.

    # Review PR #123
    /gitflow merge 123

    # Focus securite
    /gitflow merge 123 --security

    # Focus migrations EF Core
    /gitflow merge 123 --ef-core

`/gitflow merge` Merge

Cette commande finalise l'integration d'une Pull Request de maniere securisee et controlee. Elle verifie d'abord tous les pre-requis : approbations des reviewers, statut CI (tous les checks doivent etre verts), absence de conflits et branche a jour. La strategie de merge est determinee automatiquement selon le type de branche : squash merge pour les features (historique propre dans develop), merge commit pour les releases et hotfixes (preservation de l'historique complet). Apres le merge, elle nettoie automatiquement la branche source sur le remote et met a jour les branches locales. L'option --auto permet d'activer l'auto-merge qui s'executera des que la CI sera verte.

This command finalizes Pull Request integration in a secure and controlled manner. It first verifies all prerequisites: reviewer approvals, CI status (all checks must be green), no conflicts and branch up to date. Merge strategy is determined automatically based on branch type: squash merge for features (clean history in develop), merge commit for releases and hotfixes (full history preservation). After merge, it automatically cleans up the source branch on remote and updates local branches. The --auto option enables auto-merge that will execute as soon as CI is green.

    # Merge PR #123
    /gitflow merge 123

    # Auto-merge quand CI vert
    /gitflow merge 123 --auto

    # Simulation
    /gitflow merge 123 --dry-run

`/gitflow start` Branch

Cette commande est le point de depart pour tout nouveau travail dans GitFlow. Elle cree la branche appropriee (feature depuis develop, release depuis develop, hotfix depuis main) et l'isole dans un worktree separe par defaut. Cette isolation permet de travailler sur plusieurs branches simultanement sans avoir a switcher constamment. L'assistant analyse d'abord le contexte du projet (version actuelle, commits en avance sur develop, branches existantes) puis pose des questions adaptees pour guider la creation. Pour les releases, elle detecte si main a diverge et propose de le resynchroniser, et si trop de migrations EF Core existent, elle propose de les consolider. L'option --no-worktree permet de creer la branche dans le repertoire courant si les worktrees ne sont pas souhaites.

This command is the starting point for any new work in GitFlow. It creates the appropriate branch (feature from develop, release from develop, hotfix from main) and isolates it in a separate worktree by default. This isolation allows working on multiple branches simultaneously without constantly switching. The assistant first analyzes project context (current version, commits ahead on develop, existing branches) then asks adapted questions to guide creation. For releases, it detects if main has diverged and offers to resync it, and if too many EF Core migrations exist, it offers to consolidate them. The --no-worktree option creates the branch in the current directory if worktrees are not desired.

    # Demarrer une feature
    /gitflow start feature authentication

    # Demarrer une release (avec options avancees EF Core)
    /gitflow start release

    # Demarrer un hotfix
    /gitflow start hotfix critical-bug

    # Sans worktree (meme repertoire)
    /gitflow start feature test --no-worktree

💡

##### Fonctionnalites avancees pour releases

##### Advanced features for releases

Lors de la creation d'une release, l'assistant detecte automatiquement :
• Main divergent : Si main contient des commits absents de develop, propose de reset main via cette release
• Migrations multiples : Si plus de 3 migrations existent, propose de les consolider en une seule migration propre

When creating a release, the assistant automatically detects:
• Divergent main: If main contains commits missing from develop, offers to reset main via this release
• Multiple migrations: If more than 3 migrations exist, offers to consolidate them into a single clean migration

`/gitflow finish` Branch

Cette commande finalise proprement une branche apres que sa Pull Request a ete mergee. Le comportement depend du type de branche : pour une feature, elle effectue simplement le nettoyage (suppression de la branche locale et remote). Pour une release ou un hotfix, elle execute le workflow complet GitFlow : checkout de main, creation du tag de version, merge back vers develop pour synchroniser les branches, puis nettoyage. Pour les hotfixes, elle gere automatiquement l'increment de version PATCH et la mise a jour du fichier source de version avant de creer le tag. Le worktree associe est egalement supprime si present. Cette commande garantit que toutes les etapes du GitFlow sont correctement executees apres un merge.

This command properly finalizes a branch after its Pull Request has been merged. Behavior depends on branch type: for a feature, it simply performs cleanup (local and remote branch deletion). For a release or hotfix, it executes the complete GitFlow workflow: checkout main, create version tag, merge back to develop to sync branches, then cleanup. For hotfixes, it automatically handles PATCH version increment and version source file update before creating the tag. The associated worktree is also removed if present. This command ensures all GitFlow steps are properly executed after a merge.

    /gitflow finish

`/gitflow cleanup` Maintenance

Cette commande de maintenance audite et nettoie les worktrees accumules au fil du temps. Elle categorise chaque worktree trouve : permanents (main, develop - jamais supprimes), actifs (branches avec travail en cours), orphelins (la branche Git associee n'existe plus), stale (inactifs depuis plus de 30 jours), ou dirty (modifications locales non commitees). L'audit affiche un rapport complet avec recommandations. En mode interactif, elle propose de supprimer les worktrees orphelins et stale un par un avec confirmation. Elle doit etre executee depuis main ou develop pour eviter de supprimer le worktree courant. Cette commande est automatiquement appelee par /gitflow finish et /gitflow abort pour maintenir l'environnement propre.

This maintenance command audits and cleans up worktrees accumulated over time. It categorizes each found worktree: permanent (main, develop - never deleted), active (branches with ongoing work), orphan (associated Git branch no longer exists), stale (inactive for more than 30 days), or dirty (uncommitted local changes). The audit displays a complete report with recommendations. In interactive mode, it offers to delete orphan and stale worktrees one by one with confirmation. It must be run from main or develop to avoid deleting the current worktree. This command is automatically called by /gitflow finish and /gitflow abort to keep the environment clean.

    /gitflow cleanup

## Exemple complet Complete Example

Voici un exemple complet de workflow GitFlow avec SmartStack CLI :

Here's a complete GitFlow workflow example with SmartStack CLI:

    # 1. Initialiser GitFlow (une seule fois)
    /gitflow init

    # 2. Verifier l'etat du projet
    /gitflow status

    # 3. Demarrer une nouvelle feature
    /gitflow start feature user-dashboard

    # 4. Developper la feature...
    # ... ecrire du code ...

    # 5. Commits reguliers
    /gitflow commit

    # 6. Creer une Pull Request vers develop
    /gitflow pr

    # 7. Review de la PR (optionnel, peut etre fait par un collegue)
    /gitflow merge 123

    # 8. Merger la PR apres approbation
    /gitflow merge 123

    # 9. Preparer une release
    /gitflow start release

    # 10. Tests finaux et corrections mineures...
    /gitflow commit

    # 11. Creer PR vers main et merger
    /gitflow pr main
    /gitflow merge 456

    # 12. Finaliser la release (tag + merge back + cleanup auto)
    /gitflow finish

    # La release est maintenant sur main avec un tag!

    # 13. Maintenance: Audit des worktrees (depuis main ou develop)
    /gitflow cleanup

💡

##### Astuce

##### Tip

Utilisez `/gitflow` sans argument pour obtenir une analyse du contexte et des suggestions d'actions basees sur l'etat actuel du projet.

Use `/gitflow` without arguments to get a context analysis and action suggestions based on the current project state.