Cas particuliers & Avancés

Les conventions de base couvrent 80 % des situations. Les cas particuliers et avancés couvrent les 20 % restants, mais ce sont eux qui distinguent un développeur débutant d’un ingénieur professionnel.

1. Découpage et taille des branches

Plusieurs fonctionnalités dans une même branche

Mauvaise pratique Utiliser une seule branche générique pour plusieurs tâches sans rapport :
- Branche : feature/login
- Commits : feat: add login page, feat: add dashboard, fix: navbar issue
- Problème : La branche devient difficile à relire, à tester et à fusionner.
Bonne pratique Diviser le travail en branches à but unique :
- feature/login
- feature/dashboard
- feature/notifications
- Avantage : Chaque branche a un objectif unique, est rapide à tester et produit des Pull Requests faciles à relire.

Règle HashCode : Une branche = une responsabilité unique.

Une fonctionnalité trop volumineuse

Parfois, une fonctionnalité comme feature/dashboard est trop imposante et regroupe les statistiques, les graphiques, les paramètres, l’administration, etc.

Bonne pratique Découper en sous-branches plus petites :
- feature/dashboard-layout (la structure globale)
- feature/dashboard-stats (les chiffres et indicateurs)
- feature/dashboard-notifications (le centre de notifications)
- feature/dashboard-settings (l’écran de configuration)

Règle HashCode : Si une branche devient difficile à expliquer en une seule phrase, elle est probablement trop grande. Découpez-la !

2. Types de branches spécifiques

En dehors du développement courant de fonctionnalités, l’ingénierie logicielle requiert des types de branches spécialisés.

`hotfix/` (Correction urgente en production)

Utilisé lorsqu’un bug critique survient en production (ex: crash de connexion, échec de paiement) et doit être résolu immédiatement sans attendre la prochaine version planifiée.

Syntaxe : hotfix/description-courte
Exemples : hotfix/login-crash, hotfix/payment-failure, hotfix/security-patch
Workflow :
1. Créer la branche directement depuis main ou la branche de production.
2. Appliquer la correction et tester.
3. Créer une PR urgente et fusionner dans main (et la reporter sur develop si nécessaire).

`experiment/` (Travaux expérimentaux)

Utilisé lorsque vous souhaitez tester une idée, réaliser un prototype ou explorer une nouvelle technologie sans engagement ni risque d’altérer la branche principale.

Syntaxe : experiment/description-courte
Exemples : experiment/new-ui, experiment/graphql-api, experiment/chat-system
Avantage : Indique immédiatement à l’équipe que le code est un prototype et peut être abandonné ou réécrit.

`spike/` (Recherche et Spikes techniques)

Un “Spike” est une tâche d’investigation ou de recherche technique pour explorer des solutions, tester des faisabilités ou évaluer la complexité d’une future fonctionnalité.

Syntaxe : spike/sujet-de-recherche
Exemples : spike/oauth-authentication, spike/microservices, spike/docker-deployment
Avantage : Le but du code d’un Spike n’est pas d’être livré en production, mais de produire de la connaissance et de la documentation.

3. Typologie avancée des commits

Maintenance vs Fonctionnalité

Mauvaise pratique Nommer une mise à jour ou un renommage sous forme de fonctionnalité :
- feat: rename user service ou feature/update
Bonne pratique Utiliser les types adéquats selon l’intention :
- Renommage/Restructuration (sans changement fonctionnel) : refactor: rename user service (Branche : refactor/clean-architecture)
- Maintenance / Outils : chore: update dependencies, chore: update-react (Branche : chore/update-dependencies)
- Infrastructure / Pipeline : ci: add github actions workflow (Branche : chore/github-actions)
- Documentation : docs: update README, docs: add installation guide (Branche : docs/readme)

Amélioration de sécurité (`security`)

Les modifications de sécurité méritent d’être clairement visibles dans l’historique de commits plutôt que d’être cachées sous un simple fix.

Syntaxe : security: description
Exemples :
- security: sanitize user inputs
- security: rotate application secrets
- security: add rate limiting
- security: add csrf protection

4. Gestion des commits et de l’historique

Plusieurs changements dans un seul commit

Mauvaise pratique Créer un commit générique englobant plusieurs tâches distinctes :
- Commit : feat: update project (contenant en vrac le login, le dashboard, du style CSS, la doc et la CI).
Bonne pratique Faire des commits atomiques (un seul but logique par commit) :
- feat: add login page
- feat: add dashboard
- docs: update README
- ci: add pipeline

Règle HashCode : Un commit = une intention unique.

Utilisation des commits WIP (Work In Progress)

Pendant la phase locale de développement, vous pouvez avoir besoin de sauvegarder des états intermédiaires non finalisés.

Localement (Autorisé) : Vous pouvez commiter temporairement avec le préfixe wip :
- wip: login page
- wip: form validation
Sur la branche principale (Interdit) : Avant de fusionner votre Pull Request, ces commits intermédiaires doivent être écrasés (squashed) et renommés de façon conventionnelle (ex: feat: add login page).

Annuler un changement (`revert`)

Si une fonctionnalité casse le site ou la production, la règle professionnelle est d’ouvrir un commit d’annulation propre plutôt que d’effacer l’historique ou de bricoler à la hâte.

Syntaxe : revert: description du commit annulé
Exemples :
- revert: remove payment service integration
- revert: rollback dashboard redesign
Avantage : L’historique du dépôt montre explicitement pourquoi et quand la fonctionnalité a été désactivée.

5. Stratégies de branche avancées (Branching Workflows)

En entreprise, le choix de la gestion des branches structure le rythme des livraisons de code. Voici les 3 stratégies majeures :

GitHub Flow (Simple & Rapide)

Principe : Tout part de main. On crée une branche de feature, on fait une Pull Request, on teste, et on fusionne directement sur main qui est déployée en production.
Idéal pour : Les applications web à livraison continue (SaaS).

Git Flow (Historique & Robuste)

Principe : Utilise deux branches à vie longue : main (production stable) et develop (intégration des features). Les releases se préparent sur des branches release/ temporaires avant d’aller sur main.
Idéal pour : Les logiciels avec des versions planifiées (ex: applications mobiles, progiciels).

Trunk-Based Development (Moderne & Agile)

Principe : Les développeurs fusionnent de très petits commits fréquemment (plusieurs fois par jour) directement sur la branche principale main (le Trunk). Les fonctionnalités non finies sont cachées derrière des Feature Flags.
Idéal pour : Les équipes matures cherchant à éviter les fusions douloureuses.

6. Préciser le périmètre avec les Scopes

Pour rendre votre historique encore plus lisible, vous pouvez ajouter un scope (périmètre) entre parenthèses après le type du commit. Cela indique immédiatement quel composant de l’application est impacté.

Structure

type(scope): description

Exemples réels

feat(auth): add login page (Nouvelle fonctionnalité sur le module d’authentification)
fix(profile): resolve image upload issue (Correction sur le module profil)
refactor(core): simplify service container (Refactoring du cœur de l’application)
docs(api): update authentication guide (Doc liée à l’API)
ci(actions): add testing pipeline (CI liée à GitHub Actions)
security(auth): add rate limiting (Sécurité sur l’authentification)

7. Pratiques de Production Avancées

Le Rebase Interactif (`git rebase -i`)

Le rebase interactif est utilisé pour nettoyer et structurer son historique de commits local avant d’ouvrir ou de fusionner une Pull Request. Il permet d’éviter les commits polluants de type “wip”, “fix typo” ou “test”.

Commande (pour les $N$ derniers commits) :
Terminal window
```
git rebase -i HEAD~N
```
Actions principales dans l’éditeur :
- pick : Conserver le commit tel quel.
- reword : Modifier le message du commit.
- squash (ou s) : Fusionner le commit avec le commit précédent en combinant les messages.
- drop (ou d) : Supprimer complètement le commit.

Git Hooks & Automatisation avec Husky

Les Git Hooks sont des scripts qui s’exécutent automatiquement à des moments clés du cycle Git (avant un commit, avant un push, etc.). Husky est l’outil standard pour gérer ces hooks facilement dans un projet JavaScript/Node.

Hook pre-commit : Lance le formatage de code (Prettier) et le linter (ESLint) pour s’assurer qu’aucun code mal formaté ou contenant des erreurs de syntaxe n’est enregistré.
Hook commit-msg : Valide automatiquement que le message du commit respecte la convention Conventional Commits (ex: rejet du commit si le message est simplement “update”).
Hook pre-push : Exécute les tests unitaires avant l’envoi sur GitHub pour éviter de casser la branche distante.

Signature des commits (GPG / SSH)

Pour garantir la sécurité et l’intégrité de la chaîne de livraison, les commits en entreprise doivent souvent être signés numériquement. Cela prouve que le commit provient bien de vous et n’a pas été usurpé (badge Verified vert sur GitHub).

Configurer la signature avec une clé SSH :

# Indiquer à Git d'utiliser SSH pour signer
git config --global gpg.format ssh

# Définir le chemin vers votre clé SSH publique
git config --global user.signingkey ~/.ssh/id_ed25519.pub

# Activer la signature automatique de tous les commits
git config --global commit.gpgsign true

💡 Règle d’or HashCode

Avant de créer une branche, d’écrire un commit ou de soumettre une Pull Request, posez-vous toujours ces trois questions :

Quel est le type ? (S’agit-il d’une fonctionnalité, d’une correction, de maintenance, de sécurité, de recherche ?)
Quel est le périmètre (scope) ? (Quel module ou fichier de l’application est concerné ?)
Quelle est l’intention ? (Quel est le changement concret apporté et pourquoi est-il fait ?)

Si ces trois éléments sont clairs, votre historique Git sera propre, explicite, professionnel et facile à maintenir à long terme.