Git : Merge vs Rebase

GitIntroduction3BTS

Lien vers le PDF

Deux façons d’intégrer une branche dans une autre :

• Merge : fusionne les historiques, peut créer un commit de merge.
• Rebase : réécrit l’historique pour le rendre linéaire.

---

Merge (Fusion)

Principe : on combine les changements d’une branche dans une autre. Si les deux branches ont divergé, Git crée un commit de merge qui relie les deux historiques.

Avantages

• Sûr : ne réécrit pas l’historique existant.
• Conserve les vrais chemins des branches (traçabilité).
• Adapté aux projets collaboratifs/publics.

Inconvénients

• Historique parfois plus verbeux (commits de merge).
• Lecture moins linéaire si beaucoup de petites branches.

Exemples

# Fusion simple (fast-forward possible)
git checkout main
git merge feature-abc

---

Rebase (Rebasage)

Principe : on “décroche” les commits de la branche, on la place sur une base plus récente, puis on rejoue ces commits un par un pour obtenir un historique linéaire.

Avantages

• Historique propre et linéaire.
• Parfait pour nettoyer sa branche avant PR/MR.

Inconvénients

• Réécrit l’historique : dangereux si la branche est déjà partagée.
• Peut générer plusieurs conflits successifs à résoudre.

Exemples

# Se remettre à jour sur main sans créer de commit de merge
git checkout feature-abc
git rebase main

# En cas de conflit :
# 1) corriger les fichiers, puis :
git add <fichier>
git rebase --continue

# Abandonner le rebase en cours
git rebase --abort

---

Quand utiliser quoi ?

Situation	Recommandation
Projet collaboratif/public (branche partagée)	Merge (pas de réécriture d’historique)
Travail seul sur une branche locale	Rebase (historique propre et linéaire)
Avant d’ouvrir une PR/MR	Rebase sur main pour éviter un commit de merge inutile
Fusion finale vers main	Merge (traçabilité de l’intégration)

 

---

Rappel : PR / MR sont des abréviations très utilisées avec Git :

• PR = Pull Request

  • Terme utilisé sur GitHub (et aussi Bitbucket).

  • C’est une demande de fusion : on propose d’intégrer les changements d’une branche dans une autre (souvent main).

  • On peut y faire des commentaires, demander des modifications, et valider avant le merge.

• MR = Merge Request

  • Terme utilisé sur GitLab (et aussi Azure DevOps).

  • C’est exactement le même principe qu’une Pull Request, mais le nom change.

Règles simples à retenir

• Ne rebase pas une branche déjà poussée et utilisée par d’autres (tu casserais leur historique local).
• Utilise merge pour intégrer des branches partagées, c’est plus sûr.
• Utilise rebase pour nettoyer ta propre branche avant de la partager.
• En cas de conflit pendant un rebase, enchaîne : git status → corriger → git add → git rebase --continue.

---

Résumé express

• Merge = historique préservé, plus verbeux → idéal en équipe.
• Rebase = historique propre, réécriture → idéal en local avant PR.
• Règle d’or : Merge pour collaborer, Rebase pour nettoyer.

Difficultés courantes quand on travaille à plusieurs sur GitHub

Ce tableau résume les principaux problèmes rencontrés par les équipes et les bonnes pratiques pour les éviter.

🚧 Difficulté	⚡ Exemple concret	✅ Bonne pratique / Solution
Conflits de fusion	Deux élèves modifient la même ligne dans app.py → Git affiche <<<<<<< HEAD	Faire git pull --rebase régulièrement Communiquer sur qui modifie quoi Utiliser les outils intégrés (VS Code / PyCharm / GitHub) pour résoudre les conflits
Mauvaise gestion des branches	Tout le monde travaille sur main, mélange de code instable	Créer une branche par fonctionnalité : feature/login Ne pas travailler directement sur main Fusionner via Pull Request
Confusion merge vs rebase	Un étudiant fait un rebase sur une branche partagée et casse l’historique	Pour débuter, préférer merge Utiliser rebase seulement pour nettoyer l’historique avant un push Ne pas réécrire une branche déjà partagée
Push rejeté (branche en retard)	Message : “rejected – fetch first”	Faire git pull --rebase origin main avant de push Lire les messages Git (ils donnent souvent la commande à lancer)
Commits peu clairs	Message : “update” ou “fix bug”	Rédiger des messages explicites : feat: ajout du formulaire de login Décrire les PR clairement (ce qui change, pourquoi)
Permissions mal configurées	Un étudiant supprime la branche main par erreur	Activer la protection de la branche main Exiger validation d’une PR avant merge
Pas de tests avant merge	Code cassé intégré sur main	Tester localement avant push Ajouter un pipeline CI/CD (GitHub Actions) pour lancer les tests automatiquement
Mises à jour oubliées	Un élève code sans faire de pull → conflit massif au moment du push	Faire git fetch + git pull régulièrement Synchroniser avant chaque nouvelle fonctionnalité

Astuce : Pull souvent, écris des messages de commit clairs, travaille sur des branches et utilise toujours une Pull Request pour intégrer ton code.

 

Comprendre la différence entre merge et rebase

Objectifs pédagogiques

• Savoir travailler à deux sur un même projet GitHub.
• Observer les différences d’historique entre un merge et un rebase.
• Savoir quand utiliser l’un ou l’autre.

Mise en place du projet

1. Étudiant A crée un nouveau dépôt sur GitHub appelé tp-merge-rebase.
2. Ajoute un fichier README.md avec le contenu :

   # TP Git – Merge vs Rebase

3. Pousse ce dépôt sur GitHub et ajoute Étudiant B comme collaborateur.
4. Les deux clonent le dépôt :

   git clone https://github.com/<votre_nom>/tp-merge-rebase.git
   cd tp-merge-rebase

Création de deux branches en parallèle

Étudiant A :

git checkout -b feature-A
echo "Fonction A - ligne 1" > fonctionA.txt
git add fonctionA.txt
git commit -m "feat: ajout fonction A"
git push origin feature-A

Étudiant B :

git checkout -b feature-B
echo "Fonction B - ligne 1" > fonctionB.txt
git add fonctionB.txt
git commit -m "feat: ajout fonction B"
git push origin feature-B

MERGE : intégrer la branche A dans main

git checkout main
git pull origin main
git merge feature-A
git push origin main

→ Allez sur GitHub et observez l’historique : vous verrez un commit de merge qui garde les deux historiques séparés.

REBASE : intégrer la branche B proprement

git checkout feature-B
git pull origin main      # récupère les modifs de A
git rebase main           # réécrit l’historique de B au-dessus de main

Si Git signale des conflits, résolvez-les :

git add <fichiers_conflits>
git rebase --continue

Poussez ensuite la branche rebasée (attention au --force) :

git push --force origin feature-B

Créez ensuite une Pull Request pour fusionner feature-B → main.
La PR sera « propre » : commits linéaires, sans commit de merge.

Observation de l’historique

git log --oneline --graph --all

→ Vous verrez que :

• La branche A (merge) a ajouté un commit de fusion.
• La branche B (rebase) s’est placée directement au-dessus de main sans commit de merge.

Visualisez avec un outil graphique : Git Graph (VS Code) ou l’onglet Git de PyCharm.

Discussion / Conclusion

• Merge : préserve l’historique complet, pratique en équipe mais peut produire beaucoup de commits de merge.
• Rebase : historique plus propre et linéaire, mais à éviter sur des branches déjà partagées (risque de casser le travail des autres).

 

Comprendre la différence entre merge et rebase avec Visual Studio Code

Préparation du projet

1. Étudiant A crée un nouveau dépôt GitHub : tp-merge-rebase-vsc.
2. Ajouter un fichier README.md avec :

   # TP Git – Merge vs Rebase avec Visual Studio Code

3. Inviter Étudiant B comme collaborateur sur GitHub.
4. Cloner le dépôt depuis Visual Studio Code :
   • Ouvrir VSC → Ctrl + Shift + P (ou Cmd + Shift + P sur Mac) → taper Git: Clone.
   • Coller l’URL du dépôt GitHub.
   • Ouvrir le dossier cloné dans VSC.

---

Création de deux branches

Étudiant A :

# Créer la branche
git checkout -b feature-A
# Créer un fichier
echo "Fonction A - ligne 1" > fonctionA.txt
# Commit
git add fonctionA.txt
git commit -m "feat: ajout fonction A"
# Push
git push origin feature-A

Étudiant B :

git checkout -b feature-B
echo "Fonction B - ligne 1" > fonctionB.txt
git add fonctionB.txt
git commit -m "feat: ajout fonction B"
git push origin feature-B

---

MERGE avec Visual Studio Code

1. Étudiant A retourne sur main (clic bas gauche sur le nom de la branche → choisir main).
2. Menu Git → Pull pour être à jour.
3. Menu Git → Merge Branch… → choisir feature-A.
4. Un commit de merge est créé automatiquement. Poussez sur GitHub.

→ Allez sur GitHub et observez l’historique : un commit de merge apparaît.

---

REBASE avec Visual Studio Code

1. Étudiant B reste sur feature-B.
2. Menu Git → Pull (Rebase) pour mettre sa branche au niveau de main.
3. Si Git signale des conflits, VSC affiche des boutons :
   Accept Current Change / Accept Incoming Change / Accept Both Changes.
4. Résolvez, enregistrez, cliquez sur « + » pour ajouter les fichiers corrigés, puis Continue Rebase</strong.
5. Une fois terminé, poussez la branche (VSC proposera Force Push : acceptez).

→ Créez ensuite une Pull Request pour feature-B.
L’historique sera linéaire (pas de commit de merge).

---

Visualiser les différences

git log --oneline --graph --all

• La branche A (merge) a ajouté un commit de fusion.
• La branche B (rebase) s’est placée directement au-dessus de main sans commit de merge.

💡 Astuce : installez l’extension Git Graph pour visualiser l’historique graphique dans VSC.