Quelle est la différence entre rebase et merge ?

Question

Accepted Answer

**merge** et **rebase** intègrent tous deux les modifications d'une branche dans une autre, mais ils le font différemment : merge **préserve l'historique** avec un commit de fusion, tandis que rebase **réécrit l'historique** pour créer une séquence linéaire. Comprendre la différence et quand utiliser chacun est important.

## Merge — préserve l'historique (combine)

```text
main:     A───B───C───────M     ← M is a MERGE COMMIT (two parents)
                  \       /
feature:           D───E
→ git merge feature: creates M combining the branches
  ✓ Preserves the actual history (shows the branch existed, when it merged)
  ✗ History has merge commits (can look cluttered with many merges)
```

## Rebase — réécrit pour un historique linéaire (rejoue)

```text
BEFORE:  main: A───B───C    feature: A───B───D───E
AFTER rebase feature onto main:
         main: A───B───C    feature: A───B───C───D'───E'
→ git rebase main (on feature): REPLAYS feature's commits (D,E) ON TOP of main's latest (C)
  ✓ LINEAR, clean history (no merge commits) — as if feature was built on current main
  ✗ REWRITES commits (D→D', E→E' are NEW commits with new hashes)
```

Rebase **déplace** les commits de votre branche pour qu'ils commencent à partir de la pointe d'une autre branche, créant de nouveaux commits — produisant un historique propre et linéaire.

## La règle d'or du rebasing

```text
⚠️ NEVER rebase commits that have been PUSHED/SHARED (public history):
  → rebasing rewrites commits (new hashes) → diverges from what others have
  → causes serious confusion and conflicts for collaborators
→ Rebase only LOCAL, unpushed commits. Merge for integrating shared/public branches.
```

## Quand utiliser chacun

```text
MERGE  → integrating shared branches; preserving true history; team default for merging
  features to main (often via pull requests). Safe, non-destructive.
REBASE → cleaning up LOCAL commits before sharing; keeping a feature branch up-to-date
  with main (linear); achieving clean linear history. On local/private commits only.
→ Common workflow: rebase locally to tidy up, then merge (or PR) into main.
```

## Pourquoi c'est important

Comprendre la différence entre rebase et merge est important car les deux intègrent des modifications mais avec des effets fondamentalement différents sur l'historique, et choisir correctement (et en toute sécurité) importe, donc c'est une connaissance de Git précieuse qui est également communément discutée.

La distinction fondamentale — **merge préserve l'historique** (créant un commit de fusion qui enregistre les branches combinées, gardant le véritable historique de développement) tandis que **rebase réécrit l'historique** (rejouant les commits sur la pointe d'une autre branche pour créer une séquence propre et linéaire comme si le travail avait été effectué sur le code le plus récent) — affecte l'apparence et la lisibilité de l'historique du projet.

Comprendre les compromis (merge : précis mais potentiellement encombré avec des commits de fusion ; rebase : propre et linéaire mais réécrivant les commits) aide à choisir en fonction de la question : préférez-vous une véritable histoire ou une clarté linéaire.

Le plus important, comprendre la **règle d'or du rebasing** — **ne jamais rebaser les commits qui ont été pushés/partagés** — est essentiel car rebasing réécrit les commits (leur donnant de nouveaux hashs), donc rebaser l'historique partagé diverge de ce que les collaborateurs ont, causant de sérieuses confusions et conflits ; rebase est sûr uniquement pour les commits locaux non pushés.

Cette règle de sécurité est vitale et une source commune de problèmes quand elle est violée.

Comprendre **quand utiliser chacun** (merge pour intégrer les branches partagées et préserver l'historique, souvent le défaut de l'équipe pour fusionner les features via pull requests ; rebase pour nettoyer les commits locaux avant de partager ou pour garder une branche de feature linéairement à jour — uniquement sur les commits locaux) reflète une pratique Git saine.

Puisque l'intégration des modifications est fondamentale et que le choix merge-vs-rebase (avec ses implications d'historique et de sécurité) est une décision fréquente et un sujet d'entretien, comprendre la différence — ses effets sur l'historique, la règle d'or critique, et quand utiliser chacun — est une connaissance Git précieuse et pratiquement importante qui est centrale pour maintenir un historique propre en toute sécurité et une distinction communément discutée que chaque développeur devrait maîtriser.