git-flow-branch-creator

Instructions

<instructions>
    <title>Git Flow Branch Creator</title>
    <description>Ce prompt analyse vos changements git actuels en utilisant git status et git diff (ou git diff --cached), puis détermine intelligemment le type de branche approprié selon le modèle de branching Git Flow et crée un nom de branche sémantique.</description>
    <note>
        Il vous suffit d'exécuter ce prompt et Copilot analysera vos changements et créera la branche Git Flow appropriée pour vous.
    </note>
</instructions>

Workflow

Suivez ces étapes :

1. Exécutez git status pour examiner l'état actuel du repository et les fichiers modifiés.
2. Exécutez git diff (pour les changements non indexés) ou git diff --cached (pour les changements indexés) pour analyser la nature des changements.
3. Analysez les changements en utilisant le cadre d'analyse Git Flow ci-dessous.
4. Déterminez le type de branche approprié en fonction de l'analyse.
5. Générez un nom de branche sémantique suivant les conventions Git Flow.
6. Créez la branche et basculez vers elle automatiquement.
7. Fournissez un résumé de l'analyse et les prochaines étapes.

Git Flow Branch Analysis Framework

<analysis-framework>
    <branch-types>
        <feature>
            <purpose>Nouvelles fonctionnalités, améliorations, améliorations non critiques</purpose>
            <branch-from>develop</branch-from>
            <merge-to>develop</merge-to>
            <naming>feature/descriptive-name ou feature/ticket-number-description</naming>
            <indicators>
                <indicator>Nouvelle fonctionnalité en cours d'ajout</indicator>
                <indicator>Améliorations UI/UX</indicator>
                <indicator>Nouveaux endpoints ou méthodes API</indicator>
                <indicator>Ajouts de schéma de base de données (non-breaking)</indicator>
                <indicator>Nouvelles options de configuration</indicator>
                <indicator>Améliorations de performance (non-critiques)</indicator>
            </indicators>
        </feature>

        <release>
            <purpose>Préparation de la version, mise à jour de version, tests finaux</purpose>
            <branch-from>develop</branch-from>
            <merge-to>develop ET master</merge-to>
            <naming>release-X.Y.Z</naming>
            <indicators>
                <indicator>Changements de numéro de version</indicator>
                <indicator>Mises à jour de configuration de build</indicator>
                <indicator>Finalisation de documentation</indicator>
                <indicator>Corrections de bugs mineurs avant la version</indicator>
                <indicator>Mises à jour des notes de version</indicator>
                <indicator>Verrous de version de dépendances</indicator>
            </indicators>
        </release>

        <hotfix>
            <purpose>Corrections de bugs critiques en production nécessitant un déploiement immédiat</purpose>
            <branch-from>master</branch-from>
            <merge-to>develop ET master</merge-to>
            <naming>hotfix-X.Y.Z ou hotfix/critical-issue-description</naming>
            <indicators>
                <indicator>Corrections de vulnérabilités de sécurité</indicator>
                <indicator>Bugs critiques en production</indicator>
                <indicator>Corrections de corruption de données</indicator>
                <indicator>Résolution de pannes de service</indicator>
                <indicator>Changements de configuration d'urgence</indicator>
            </indicators>
        </hotfix>
    </branch-types>
</analysis-framework>

Branch Naming Conventions

<naming-conventions>
    <feature-branches>
        <format>feature/[ticket-number-]descriptive-name</format>
        <examples>
            <example>feature/user-authentication</example>
            <example>feature/PROJ-123-shopping-cart</example>
            <example>feature/api-rate-limiting</example>
            <example>feature/dashboard-redesign</example>
        </examples>
    </feature-branches>

    <release-branches>
        <format>release-X.Y.Z</format>
        <examples>
            <example>release-1.2.0</example>
            <example>release-2.1.0</example>
            <example>release-1.0.0</example>
        </examples>
    </release-branches>

    <hotfix-branches>
        <format>hotfix-X.Y.Z OU hotfix/critical-description</format>
        <examples>
            <example>hotfix-1.2.1</example>
            <example>hotfix/security-patch</example>
            <example>hotfix/payment-gateway-fix</example>
            <example>hotfix-2.1.1</example>
        </examples>
    </hotfix-branches>
</naming-conventions>

Analysis Process

<analysis-process>
    <step-1>
        <title>Change Nature Analysis</title>
        <description>Examinez les types de fichiers modifiés et la nature des changements</description>
        <criteria>
            <files-modified>Regardez les extensions de fichiers, la structure de répertoire et l'objectif</files-modified>
            <change-scope>Déterminez si les changements sont additifs, correctifs ou préparatoires</change-scope>
            <urgency-level>Évaluez si les changements abordent des problèmes critiques ou sont de développement</urgency-level>
        </criteria>
    </step-1>

    <step-2>
        <title>Git Flow Classification</title>
        <description>Mappez les changements au type de branche Git Flow approprié</description>
        <decision-tree>
            <question>S'agit-il de corrections critiques pour des problèmes en production ?</question>
            <if-yes>Envisagez une branche hotfix</if-yes>
            <if-no>
                <question>S'agit-il de changements de préparation de version (mises à jour de version, ajustements finaux) ?</question>
                <if-yes>Envisagez une branche release</if-yes>
                <if-no>Utilisez par défaut une branche feature</if-no>
            </if-no>
        </decision-tree>
    </step-2>

    <step-3>
        <title>Branch Name Generation</title>
        <description>Créez un nom de branche sémantique et descriptif</description>
        <guidelines>
            <use-kebab-case>Utilisez des minuscules avec des traits d'union</use-kebab-case>
            <be-descriptive>Le nom doit indiquer clairement l'objectif</be-descriptive>
            <include-context>Ajoutez les numéros de ticket ou le contexte du projet quand disponibles</include-context>
            <keep-concise>Évitez les noms trop longs</keep-concise>
        </guidelines>
    </step-3>
</analysis-process>

Edge Cases and Validation

<edge-cases>
    <mixed-changes>
        <scenario>Les changements incluent à la fois des features et des corrections de bugs</scenario>
        <resolution>Priorisez le type de changement le plus significatif ou suggérez de diviser en plusieurs branches</resolution>
    </mixed-changes>

    <no-changes>
        <scenario>Aucun changement détecté dans git status/diff</scenario>
        <resolution>Informez l'utilisateur et suggérez de vérifier git status ou de faire des changements d'abord</resolution>
    </no-changes>

    <existing-branch>
        <scenario>Vous êtes déjà sur une branche feature/hotfix/release</scenario>
        <resolution>Analysez si une nouvelle branche est nécessaire ou si la branche actuelle convient</resolution>
    </existing-branch>

    <conflicting-names>
        <scenario>Le nom de branche suggéré existe déjà</scenario>
        <resolution>Ajoutez un suffixe incrémental ou suggérez un autre nom</resolution>
    </conflicting-names>
</edge-cases>

Examples

<examples>
    <example-1>
        <scenario>Ajout d'un nouvel endpoint API d'enregistrement d'utilisateur</scenario>
        <analysis>Nouvelle fonctionnalité, changements additifs, non critique</analysis>
        <branch-type>feature</branch-type>
        <branch-name>feature/user-registration-api</branch-name>
        <command>git checkout -b feature/user-registration-api develop</command>
    </example-1>

    <example-2>
        <scenario>Correction d'une vulnérabilité de sécurité critique en authentification</scenario>
        <analysis>Correction de sécurité, critique pour la production, déploiement immédiat nécessaire</analysis>
        <branch-type>hotfix</branch-type>
        <branch-name>hotfix/auth-security-patch</branch-name>
        <command>git checkout -b hotfix/auth-security-patch master</command>
    </example-2>

    <example-3>
        <scenario>Mise à jour de la version vers 2.1.0 et finalisation des notes de version</scenario>
        <analysis>Préparation de version, mise à jour de version, documentation</analysis>
        <branch-type>release</branch-type>
        <branch-name>release-2.1.0</branch-name>
        <command>git checkout -b release-2.1.0 develop</command>
    </example-3>

    <example-4>
        <scenario>Amélioration de la performance des requêtes de base de données et mise à jour du cache</scenario>
        <analysis>Amélioration de performance, amélioration non critique</analysis>
        <branch-type>feature</branch-type>
        <branch-name>feature/database-performance-optimization</branch-name>
        <command>git checkout -b feature/database-performance-optimization develop</command>
    </example-4>
</examples>

Validation Checklist

<validation>
    <pre-analysis>
        <check>Le repository est dans un état propre (aucun changement non committé qui causerait un conflit)</check>
        <check>La branche actuelle est un point de départ approprié (develop pour les features/releases, master pour les hotfixes)</check>
        <check>Le repository distant est à jour</check>
    </pre-analysis>

    <analysis-quality>
        <check>L'analyse des changements couvre tous les fichiers modifiés</check>
        <check>La sélection du type de branche suit les principes Git Flow</check>
        <check>Le nom de branche est sémantique et suit les conventions</check>
        <check>Les cas limites sont considérés et traités</check>
    </analysis-quality>

    <execution-safety>
        <check>La branche cible (develop/master) existe et est accessible</check>
        <check>Le nom de branche proposé n'entre pas en conflit avec les branches existantes</check>
        <check>L'utilisateur a les permissions appropriées pour créer des branches</check>
    </execution-safety>
</validation>

Final Execution

<execution-protocol>
    <analysis-summary>
        <git-status>Sortie de la commande git status</git-status>
        <git-diff>Portions pertinentes de la sortie git diff</git-diff>
        <change-analysis>Analyse détaillée de ce que représentent les changements</change-analysis>
        <branch-decision>Explication du type de branche spécifique choisi</branch-decision>
    </analysis-summary>

    <branch-creation>
        <command>git checkout -b [branch-name] [source-branch]</command>
        <confirmation>Vérifiez la création de la branche et le statut de la branche actuelle</confirmation>
        <next-steps>Fournissez des conseils sur les prochaines actions (committer les changements, pousser la branche, etc.)</next-steps>
    </branch-creation>

    <fallback-options>
        <alternative-names>Suggérez 2-3 noms de branche alternatifs si la suggestion principale n'est pas appropriée</alternative-names>
        <manual-override>Permettez à l'utilisateur de spécifier un type de branche différent si l'analyse semble incorrecte</manual-override>
    </fallback-options>
</execution-protocol>

Git Flow Reference

<gitflow-reference>
    <main-branches>
        <master>Code prêt pour la production, chaque commit est une version</master>
        <develop>Branche d'intégration pour les features, derniers changements de développement</develop>
    </main-branches>

    <supporting-branches>
        <feature>Branche depuis develop, fusion vers develop</feature>
        <release>Branche depuis develop, fusion vers develop et master</release>
        <hotfix>Branche depuis master, fusion vers develop et master</hotfix>
    </supporting-branches>

    <merge-strategy>
        <flag>Utilisez toujours le flag --no-ff pour préserver l'historique des branches</flag>
        <tagging>Tagguez les versions sur la branche master</tagging>
        <cleanup>Supprimez les branches après une fusion réussie</cleanup>
    </merge-strategy>
</gitflow-reference>