MODULE 8 – BONNES PRATIQUES PROFESSIONNELLES

Code Opération : OMBRE-ET-VERSIONS-8

OBJECTIFS :

• Standardiser les procédures pour rester invisible.
• Structurer le travail pour qu'il survive à l'inspection.
• Adopter des conventions qui parlent silencieusement aux initiés.

1. CONVENTION DE NOMMAGE DES BRANCHES
Un nom de branche est un code. Il doit être clair, bref, et suivre un pattern.
Exemples :

• feature/ajout-protocole
• bugfix/correction-fuite-memoire
• hotfix/urgence-securite
• release/v1.2.0
• docs/update-readme

Le slash / crée une hiérarchie logique.
Tout le monde sait instantanément le type de travail, et son objet.
Pas de place pour l'ambiguïté dans une opération.

2. COMMITS ATOMIQUES
Un commit = une modification logique unique.
Pas : "Correction de bugs et ajout de la fonctionnalité X".
Mais deux commits séparés.
Pourquoi ? Parce que c'est plus facile à revert, à cherry-pick, à comprendre.
Un commit atomique est comme une balle : elle a un seul objectif, elle l'atteint, rien de plus.

Règle : "Si vous pouvez décrire le commit avec un 'et', c'est qu'il y a deux commits."

3. GIT FLOW / TRUNK BASED DEVELOPMENT

Git Flow : Un workflow structuré, avec des branches dédiées (develop, feature/*, release/*, hotfix/*).
Idéal pour les projets avec cycles de release définis.
Plus lourd, mais trace tout avec précision.

Trunk Based Development : Branche principale (main/trunk) unique. Les développeurs créent des branches courtes, les fusionnent rapidement.
Idéal pour le déploiement continu.
Plus agile, nécessite une grande discipline.

Choisissez votre arme en fonction du terrain.

4. .gitignore – LA LISTE NOIRE
Un fichier pour dire à Git ce qu'il doit ignorer.
Les fichiers sensibles (mots de passe, clés API).
Les artefacts de build (node_modules/, .class, .pyc).
Les fichiers personnels (.DS_Store, Thumbs.db).

Créez-le tôt. Adaptez-le à votre écosystème.
Un .gitignore propre, c'est ne pas laisser de traces inutiles sur la scène.

5. VERSIONNEMENT SÉMANTIQUE (SemVer)
Un système de numérotation pour les releases : MAJEUR.MINEUR.PATCH (1.4.2).

• MAJEUR : Changements incompatibles.
• MINEUR : Nouvelles fonctionnalités rétrocompatibles.
• PATCH : Corrections de bugs rétrocompatibles.

C'est un contrat avec vos alliés. Ils savent à quoi s'attendre quand le numéro change.
Respectez-le.

TRAVAUX PRATIQUES – SCÉNARIO : MISE EN PLACE D'UNE DISCIPLINE
Opération "Cadre de Travail"

Partie 1 : Mise en place d'un workflow Git Flow simplifié

1. Initialisez un nouveau dépôt operation-silence.
2. Créez les branches structurelles :

   git checkout -b develop
   git push origin develop
   

3. Depuis develop, créez une feature branch :

   git checkout -b feature/ajout-logging
   

4. Ajoutez un fichier log.md avec du contenu, commitez (git add . && git commit -m "Ajout du système de logging de base").
5. Fusionnez la feature dans develop :

   git checkout develop
   git merge --no-ff feature/ajout-logging  # --no-ff pour garder une trace de la branche
   git push origin develop
   

Partie 2 : Création d'un .gitignore adapté

1. À la racine, créez un fichier .gitignore.
2. Ajoutez ces lignes :

   # Secrets
   *.key
   *.pem
   config.local.json
   .env
   
   # Système
   .DS_Store
   Thumbs.db
   
   # Build / Dépendances
   node_modules/
   dist/
   *.pyc
   __pycache__/
   
   # IDE
   .vscode/
   .idea/
   *.swp
   

3. Testez en créant un fichier test.key et en vérifiant qu'il n'apparaît pas dans git status.
4. Commitez le .gitignore : git add .gitignore && git commit -m "Ajout du fichier .gitignore de base".

Partie 3 : Application de SemVer

1. Sur main, créez un tag pour la première release :

   git checkout main
   git merge develop  # Simule la préparation d'une release
   git tag -a v1.0.0 -m "Release initiale - Système de logging opérationnel"
   git push origin v1.0.0
   

2. Faites une correction mineure sur develop, puis préparez un patch release :

   git checkout develop
   # Faites une petite correction dans log.md
   git add . && git commit -m "Correction typo dans la documentation des logs"
   git checkout main
   git merge develop
   git tag -a v1.0.1 -m "Patch : correction de typo"
   git push origin v1.0.1
   

FIN DE LA FORMATION.
Vous avez maintenant toutes les clés.
La technique, les outils avancés, et la discipline pour les utiliser en milieu professionnel.
Git n'est pas qu'un outil. C'est une manière de penser. De structurer le chaos. De laisser une trace propre, ou de ne pas en laisser du tout.

Travaillez dans l'ombre, mais versionnez à la lumière.

Rapport final clos.