Module Technique 3 — Git avancé

0.0.1 🎯 Objectifs d’apprentissage

1. Maîtriser les stratégies de branching (Git Flow, trunk-based)
2. Choisir entre merge et rebase selon le contexte
3. Résoudre des conflits de merge sereinement
4. Créer des Pull Requests et pratiquer le code review
5. Utiliser les tags pour versionner tes releases

📚 Prérequis : Git de base (add, commit, push, pull)

⏱️ Temps estimé : 3 heures

---

1 Stratégies de branching

1.1 Git Flow

gitGraph
    commit id: "init"
    branch develop
    commit id: "dev-1"
    branch feature/model
    commit id: "feat-1"
    commit id: "feat-2"
    checkout develop
    merge feature/model id: "merge-feat"
    branch release/v1
    commit id: "rel-fix"
    checkout main
    merge release/v1 id: "v1.0" tag: "v1.0"
    checkout develop
    merge release/v1

Git Flow : branches principales et de support

Branche	Rôle	Durée de vie
main	Code en production	Permanente
develop	Intégration des features	Permanente
feature/*	Développement d’une fonctionnalité	Temporaire
release/*	Préparation d’une release	Temporaire
hotfix/*	Correction urgente en production	Temporaire

1.2 Trunk-based development

Plus simple : tout le monde travaille sur main avec des branches très courtes (< 1 jour).

💡 Point clé

Pour un projet solo ou une petite équipe data, le trunk-based est souvent plus adapté. Git Flow est conçu pour des équipes nombreuses avec des releases planifiées.

---

2 Merge vs Rebase

2.0.0.1 🔀 Git Merge

git checkout main
git merge feature/model

• Crée un commit de merge
• Préserve l’historique complet
• Non destructif
• Historique plus “branchu”

2.0.0.2 ↗️ Git Rebase

git checkout feature/model
git rebase main

• Réécrit l’historique
• Historique linéaire et propre
• Plus risqué (ne jamais rebaser des commits publiés)
• Idéal avant une PR

⚠️ Règle d’or

Ne jamais rebaser des commits qui ont déjà été poussés et partagés avec d’autres. Le rebase réécrit l’historique — si quelqu’un a basé son travail sur tes commits, ça créera des conflits.

---

3 Résolution de conflits

3.1 Quand surviennent les conflits ?

Un conflit arrive quand deux branches modifient la même ligne du même fichier.

$ git merge feature/pricing
Auto-merging models/pricing.py
CONFLICT (content): Merge conflict in models/pricing.py
Automatic merge failed; fix conflicts and then commit the result.

3.2 Comment les résoudre ?

Le fichier en conflit contient des marqueurs :

<<<<<<< HEAD
def calculer_prime(exposition, frequence):
    return exposition * frequence * 1.15
=======
def calculer_prime(expo, freq, marge=0.10):
    return expo * freq * (1 + marge)
>>>>>>> feature/pricing

Tu choisis quelle version garder (ou combines les deux), supprimes les marqueurs, puis commites.

---

4 Pull Requests et Code Review

4.1 Workflow PR

flowchart LR
    A[Créer branche] --> B[Développer]
    B --> C[Push]
    C --> D[Ouvrir PR]
    D --> E[Code Review]
    E --> F{Approuvé ?}
    F -->|Oui| G[Merge]
    F -->|Non| B

Workflow d’une Pull Request

# Créer et pousser une branche
\(</span> git checkout -b feature/sinistralite-model<br> <span class="comment"># ... développement ...</span><br> <span class="prompt">\) git add . && git commit -m “feat: add frequency model”
\(</span> git push -u origin feature/sinistralite-model<br><br> <span class="comment"># Créer la PR avec GitHub CLI</span><br> <span class="prompt">\) gh pr create –title “Add frequency model” –body “GLM Poisson pour la fréquence”

---

5 Tags et releases

# Créer un tag annoté
git tag -a v1.0.0 -m "Release initiale du modèle de tarification"

# Pousser le tag
git push origin v1.0.0

# Lister les tags
git tag -l "v1.*"

Convention de versionnement sémantique : vMAJEUR.MINEUR.PATCH

---

Synthèse

5.0.1 🎯 Les 5 points essentiels

1. Git Flow pour les grands projets, trunk-based pour les petites équipes
2. Merge préserve l’historique, rebase le linéarise — Choisir selon le contexte
3. Ne jamais rebaser des commits publics
4. Les PR structurent la collaboration — Code review = qualité
5. Les tags marquent les versions — Versionnement sémantique

---

Auto-évaluation

Question 1 : Quand utiliser merge vs rebase ?

Réponse : Merge pour intégrer une branche dans main (préserve l’historique). Rebase pour mettre à jour ta branche de feature avec les derniers changements de main (historique propre). Ne jamais rebaser des commits déjà partagés.

Question 2 : Comment résoudre un conflit de merge ?

Réponse : Ouvrir le fichier en conflit, choisir la bonne version entre les marqueurs <<<<<<< et >>>>>>>, supprimer les marqueurs, puis git add et git commit.

Question 3 : Quelle est la différence entre un tag léger et un tag annoté ?

Réponse : Un tag léger est juste un pointeur vers un commit. Un tag annoté (git tag -a) contient un message, l’auteur et la date. Pour les releases, toujours utiliser des tags annotés.

Question 4 : Pourquoi faire du code review via des PR ?

Réponse : Pour attraper les bugs avant qu’ils n’arrivent en production, partager la connaissance du code dans l’équipe, maintenir la qualité et la cohérence du code, et documenter les décisions techniques.

---

← Retour à la Semaine 3 Voir la Fiche de travail →