Git : rebase ou merge
Deux façons d'intégrer une branche : merge, qui garde l'historique fidèle avec un commit de fusion, et rebase, qui rejoue les commits pour un historique linéaire ; la règle d'or, le rebase interactif, le squash et pull --rebase.
- 25 cartes
- 4 thèmes
- Gratuit
Le programme, thème par thème
Le poids de chaque thème suit celui que lui donne l'examen.
- Notions
- Questions
- Ranger et relier
- Mises en situation
Quelques cartes du deck
git merge : de quoi s'agit-il ?
Voir la réponse
Commande qui réunit deux branches en gardant leurs commits tels quels ; si les deux ont avancé, elle crée un commit à deux parents.
Aucun commit existant n'est modifié : l'historique raconte ce qui s'est vraiment passé, au prix d'un graphe qui se ramifie.
Pourquoi un commit rebasé change-t-il d'empreinte ?
- Son parent a changé : c'est un nouveau commit qui porte les mêmes modifications
- Git renumérote tous les commits de la branche à chaque rebase pour garder leur ordre
- Le rebase ajoute au message de chaque commit une mention de l'opération
- L'empreinte dépend de la date de la dernière synchronisation avec le distant
Voir la réponse
Son parent a changé : c'est un nouveau commit qui porte les mêmes modifications
L'empreinte est calculée à partir du contenu, du message, de l'auteur, des dates et du parent. Rejouer un commit sur une autre base change le parent, donc l'empreinte, même si le diff est identique.
Après un rebase, chaque commit rejoué a une nouvelle …, parce que son … a changé.
Voir la réponse
Après un rebase, chaque commit rejoué a une nouvelle empreinte, parce que son parent a changé.
L'empreinte dépend du parent : même contenu, même message, mais un parent différent donne un commit différent. C'est pourquoi le rebase est une réécriture d'historique.
Commit de fusion : de quoi s'agit-il ?
Voir la réponse
Commit qui a deux parents, un sur chacune des branches réunies, et qui marque le point où elles se rejoignent.
Quand la branche de destination n'a pas bougé, Git avance simplement son pointeur (fast-forward) et ne crée aucun commit de fusion, sauf avec l'option --no-ff.
Après un rebase d'une branche partagée et un git push --force, un collègue voit ses commits apparaître en double. Quelle est la cause ?
- Il a les anciens commits, le rebase en a créé de nouveaux
- Le push --force copie chaque commit une seconde fois sur le serveur distant
- Git garde les deux versions de chaque fichier modifié par deux personnes
- Son dépôt local est corrompu et doit être recloné
Voir la réponse
Il a les anciens commits, le rebase en a créé de nouveaux
Son historique contient encore les anciens commits ; en tirant, Git voit des commits différents qui portent les mêmes modifications et les réunit. La solution : ne pas rebaser une branche partagée, et si c'est fait, prévenir l'équipe pour que chacun repose son travail sur la nouvelle branche.