Git Masterclass

Modifications qui seront validées :

modifié :   index.html

Modifications qui ne sont pas validées pour la validation :

modifié :   assets/style.css

Fichiers non suivis :

scripts/auth.js

a. Si vous tapez immédiatement git commit -m "Mise à jour", quel(s) fichier(s) sera(seront) inclus dans le commit ? Justifiez.

b. Quelle(s) commande(s) devez-vous taper pour que assets/style.css et scripts/auth.js soient aussi inclus dans ce même commit ?

4

Anatomie et résolution manuelle d'un conflit de fusion

Lors de la fusion de la branche feature-contact dans main, Git s'arrête avec le message CONFLICT (content) in contact.html. Voici l'état du fichier :

<<<<<<< HEAD

  <p>Contactez-nous à support@mon-site.fr</p>

=======

  <p>Écrivez-nous via le formulaire de contact</p>

>>>>>>> feature-contact

Consigne de l'équipe : L'équipe décide de conserver l'adresse e-mail ET d'ajouter le lien vers le formulaire. Rédigez ci-dessous le contenu final nettoyé du bloc sans aucun marqueur de conflit :

Une fois le fichier nettoyé, quelles sont les 2 commandes pour finaliser la fusion ? _______________________________________

Bilan réflexif : Mes compétences acquises aujourd'hui

Je distingue le Working Tree, l'Index et le Repo

Je sais créer et basculer sur une branche

Je rédige des messages de commit clairs

Je sais identifier et résoudre un conflit de merge

Fiche Étudiant • Git En Action Page 2 / 2

Corrigé Exercice 2 (5 pts)

Ordre chronologique exact attendu :

1. git switch -c fix-login (Créer branche)
2. git add auth.py (Indexer modifs)
3. git commit -m "..." (Valider commit)
4. git switch main (Revenir sur main)
5. git merge fix-login (Fusionner le fix)

Corrigé Exercice 3 : Analyse du git status (5 pts)

a. Fichiers inclus dans le commit immédiat (2.5 pts) :

Seul le fichier index.html sera committé. Justification : C'est le seul présent dans la section "Modifications qui seront validées" (en vert / dans le Staging). Le fichier assets/style.css est modifié mais non indexé, et scripts/auth.js est non suivi (untracked).

b. Commandes pour tout inclure (2.5 pts) :

git add assets/style.css scripts/auth.js ou simplement git add ., suivi de la commande de commit.

Corrigé Exercice 4 : Résolution de conflit (6 pts)

Contenu attendu du fichier nettoyé (3 pts) :

Important : Les balises de conflit (<<<<<<< HEAD, =======, >>>>>>> feature-contact) doivent être impérativement supprimées.

Commandes de finalisation (3 pts) : git add contact.html puis git commit -m "merge: résolution conflit footer" (ou simplement git commit).

Différenciation & Adaptation

Pour les apprenants en difficulté : Fournir l'alias git log --graph --oneline ou autoriser temporairement une extension visuelle (GitLens / VS Code) pour visualiser les branches.

Pour les apprenants avancés : Proposer la création d'un fichier .gitignore pour exclure les fichiers secrets (.env, node_modules/) et explorer git stash.

Guide Enseignant • Git En Action Page 2 / 2

Tous les développeurs fusionnent sur la branche unique (trunk) plusieurs fois par jour.

Branches ultra-courtes

Durée de vie d'une branche : moins de 24 heures. Fini les branches qui dérivent pendant 3 semaines.

Feature Flags (Drapeaux)

Le code inachevé est fusionné en prod mais désactivé dynamiquement via des drapeaux conditionnels.

Automatisation totale

Suite de tests automatisés ultra-rapide. Si le build casse, c'est la priorité numéro 1 de l'équipe.

Zéro conflit de fusion bloquant • Feedback instantané entre collègues • Déploiements 10x à 50x par jour

04 // ARBRE DE DÉCISION Comment guider votre choix ?

Matrice comparative des workflows

Choisissez la stratégie en fonction de votre produit, pas de la mode.

💡 Recommandation : Commencez toujours par GitHub Flow. N'ajoutez de la complexité que si votre modèle économique l'exige.

05 // GOUVERNANCE Règles d'or en entreprise

Les 3 garde-fous indispensables

Peu importe le workflow, configurez ces sécurités sur votre dépôt distant :

🛡️

Branch Protection

Interdire les push directs sur main. Obliger le passage par Pull Request.

👀

Revue Obligatoire

Exiger au minimum 1 approbation (code review) par un pair avant toute fusion en production.

🤖

Tests CI au vert

Bloquer automatiquement le bouton de merge si les tests unitaires ou le linter échouent.

À vous d'analyser 3 cas d'entreprise réels ! Fiche Étude de Cas →

| | trunk (ou main) | Trunk-Based |

|

3

Configuration des règles de protection (Branch Protection Rules)

Vous êtes Tech Lead sur GitHub/GitLab. Quelles options cochez-vous pour protéger la branche main ? Cochez et justifiez.

Require a pull request before merging (Require approvals: min 1)

Pourquoi cette règle est-elle vitale en équipe ?

Require status checks to pass before merging (CI Build & Tests)

Quel risque élimine-t-on ainsi ?

Do not allow bypassing the above settings (même pour les Admins)

Pourquoi appliquer cette contrainte même au Lead Developer ?

Mini-Projet Personnel : Quel workflow pour votre prochain projet ?

Indiquez le nom de votre projet : __________________________________. Quel workflow adoptez-vous et pour quelle raison technique principale ?

Fiche Étude de Cas • Git Masterclass Page 2 / 2

Cas C (ScalePlatform) ➔ Trunk-Based Development (2 pts) : Grande échelle (250 dev), cadence très élevée (80 deploys/jour), durée de vie des branches < 24h et tests très rapides. Justification : seule l'intégration directe sur le tronc avec feature flags évite la dérive de branches et les conflits insolubles à cette échelle.

Corrigé Exercice 2 : Rôles de branches (4 pts)

• develop (Gitflow) : Branche d'intégration permanente de toutes les features achevées en vue de la prochaine release.
• release/x.y.z (Gitflow) : Branche temporaire de stabilisation finale (correctifs mineurs, bump de version).
• trunk (Trunk-Based) : Branche centrale unique recevant tous les commits quotidiens validés par la CI.

Corrigé Exercice 3 : Branch Protection (4 pts)

• PR obligatoire + 1 approval : Empêche les push accidentels et force la relecture mutuelle pour détecter failles et incohérences.
• Status checks CI : Garantit qu'aucun code cassant les tests unitaires ou le build ne puisse contaminer la production.
• Pas de bypass Admin : Évite les "hotfixes sauvages" un vendredi soir et maintient la discipline pour toute l'équipe.

Arbre de Décision Synthétique à projeter au tableau

1. Devez-vous maintenir et patcher plusieurs versions majeures en parallèle ? ➔ Si OUI : Gitflow

2. Déployez-vous en production plusieurs fois par jour avec des tests robustes ? ➔ Si OUI : Trunk-Based

3. Déployez-vous une application web standard via des revues régulières ? ➔ Si OUI : GitHub Flow

Guide Formateur • Git Masterclass Page 2 / 2

Git ne détruit presque jamais rien. reflog mémorise chaque déplacement de la tête de lecture (HEAD).

1. Inspection du reflog :

$ git reflog

7b3f91a HEAD@{0}: commit: login

4c12a88 HEAD@{1}: reset: HEAD~1

Le hash du commit perdu apparaît : 7b3f91a.

2. Restauration instantanée :

# Recréer la branche :

git checkout -b rescue 7b3f91a

Vos fichiers prétendument perdus sont immédiatement revenus intacts !

🧘 Sérénité : Le reflog conserve les commits orphelins pendant 30 à 90 jours. Zéro panique

04 // ORFÈVRERIE DE L'HISTORIQUE Polir son code avant la revue

Rebase interactif & Cherry-pick

Transformer vos brouillons désordonnés en un historique impeccable.

git rebase -i HEAD~3 Nettoyage

Ouvre un éditeur pour réorganiser, renommer ou fusionner vos 3 derniers commits :

• pick : conserver tel quel
• reword : modifier le message de commit
• squash / fixup : fusionner avec le commit précédent

git cherry-pick <hash> Pêche ciblée

Applique un commit spécifique venant d'une autre branche sur votre branche courante sans fusionner toute la branche.

git cherry-pick a1b2c3d

Parfait pour importer un correctif d'urgence présent sur une branche expérimentale.

💎 Un historique propre et lisible est la marque de fabrique d'un développeur professionnel.

05 // MATRICE D'URGENCE Que faire en cas d'erreur ?

Prêt pour les simulations de sauvetage en direct ? Fiche de Secours →

b. Écrivez la commande permettant de ressusciter immédiatement ce commit sur une nouvelle branche appelée sauvetage-api :

4

Chirurgie de branche : Nettoyer avec git rebase -i

Vous lancez git rebase -i HEAD~3. Voici la liste des 3 commits affichée dans votre éditeur :

pick a1b2c3d feat: ajout page profil

pick e4f5g6h fix typo dans profil

pick j7k8l9m oups oubli bouton logout

Vous voulez fusionner les deux commits de correction (e4f5g6h et j7k8l9m) directement dans le premier pour qu'il n'y ait qu'un seul commit propre sur la Pull Request. Réécrivez les 3 lignes de commandes d'instructions du rebase :

Checklist de Sérénité du Développeur

Je ne panique jamais devant un reset

Je connais le réflexe git reflog

Je privilégie revert sur les branches partagées

Je sais utiliser git stash avant de switcher

Fiche Étudiant • Git Masterclass Page 2 / 2

Corrigé Exercice 2 : Revert vs Reset (6 pts)

1. Déjà sur GitHub : git revert a4f89d

Crée un commit d'annulation sans écraser l'historique public de l'équipe.

2. Local non partagé : git reset --soft HEAD~1

Annule le commit tout en préservant le code dans l'Index et l'éditeur.

Corrigé Exercice 3 : Sauvetage Reflog (5 pts)

a. Identification du SHA-1 (2 pts) : e715ab0 (ligne HEAD@{1} associée au commit API avant le reset).

b. Commande de sauvetage attendue (3 pts) : git checkout -b sauvetage-api e715ab0 (ou alternativement : git switch -c sauvetage-api e715ab0).

Corrigé Exercice 4 : Rebase Interactif (5 pts)

Instructions exactes à laisser dans l'éditeur de rebase :

pick a1b2c3d feat: ajout page profil

fixup e4f5g6h fix typo dans profil

fixup j7k8l9m oups oubli bouton logout

Variante acceptée : squash (ou s / f). fixup est idéal car il fusionne sans ouvrir d'éditeur supplémentaire pour fusionner les messages.

Validation Finale de la Séquence "Git Masterclass"

À l'issue de ces 3 séances, les apprenants maîtrisent la triade complète : 1. La mécanique locale (états, commits, logs), 2. La collaboration d'équipe (workflows et protection), et 3. L'autonomie opérationnelle (résolution d'erreurs et sauvetage d'historique).

Guide Formateur • Git Masterclass Page 2 / 2