Nettoyer l'historique avec rebase (et la règle d'or)

C'est le sujet le plus déroutant du cours, alors on va y aller doucement. Dans la leçon précédente, on a vu merge — une façon de combiner le travail d'une branche, qui laisse un commit de fusion et conserve les deux lignées telles qu'elles se sont produites. Maintenant on découvre une deuxième façon

rebase, c'est comme prendre les pages que tu as écrites et les recopier à la fin du cahier mis à jour de l'équipe — comme si tu les avais écrites là dès le début. Le résultat paraît ordonné et droit, mais ce sont de nouvelles pages. C'est pourquoi on ne recopie pas des pages déjà remises à d'autres — ils gardent les anciennes pages, et ça crée de la confusion.

git rebase: Rejoue les commits de la branche actuelle pour qu'ils commencent depuis la pointe d'une autre branche, créant ainsi un historique linéaire. Les commits originaux sont remplacés par de nouveaux commits avec de nouveaux hash.
Historique linéaire (linear history): Un historique qui est une seule ligne droite de commits, sans fourches et sans commit de fusion — chaque commit se trouve directement au-dessus du précédent.
Règle d'or (golden rule): Ne jamais rebaser des commits déjà poussés ou partagés avec d'autres. rebase réécrit les hash, donc ce n'est sûr que sur du travail local privé.
Hash de commit: L'identifiant unique de chaque commit (une empreinte). Si quelque chose dans le commit change — y compris son parent — il reçoit un nouveau hash, et devient donc un commit différent.
Rejeu (replay): L'action par laquelle rebase prend chacun de tes commits et le réapplique, un par un, par-dessus la pointe de l'autre branche — c'est ainsi que se créent les nouveaux commits.