Passer au contenu
GitTree

Vidéo : Fusionner ou rebaser : choisissez avec un graphique

La vidéo est lue dans le lecteur YouTube, en mode de confidentialité améliorée.

Exécutez une fusion et un rebase à partir de deux copies identiques de la même divergence, comparez les deux graphiques, les parents et les arborescences de fichiers, et apprenez la règle qui les départage : qui d'autre a déjà vos commits.

Lire la leçon complète

L'article présente toutes les étapes et commandes de la vidéo, l'exercice pratique et les questions.

Aller à la leçon

Transcription vidéo

La narration de la vidéo, repère par repère.

  1. Fusionner ou rebaser ? Le même travail peut partir deux histoires différentes.
  2. Nous exécuterons les deux à partir du même départ pointer et comparer.
  3. Votre branche a un commit. La mise à jour la branche en a une autre.
  4. Les deux sont nés du même commit, donc ni l'un ni l'autre contient l'autre.
  5. Tout d'abord, préparez la divergence et faites deux exemplaires identiques.
  6. Un test équitable nécessite les mêmes références et fichiers dans les deux exemplaires.
  7. Voici le premier exemplaire. Nous fusionnerons dans celui-ci.
  8. Et c'est le deuxième exemplaire. Nous le gardons intact pour le rebase.
  9. Cliquez avec le bouton droit sur update-main et choisissez son Commande de fusion.
  10. Sous Enregistrer sous, choisissez Toujours une fusion commettre.
  11. Choisissez Fusionner une fois et attendez le vrai résultat.
  12. Le nouveau commit a deux parents : votre commit, puis update-main's.
  13. Maintenant le deuxième exemplaire. Il y a encore les deux commits originaux.
  14. Cliquez à nouveau avec le bouton droit sur update-main et choisissez Rebase cette fois.
  15. La boîte de dialogue nomme la branche et le cible. Laissez les deux options désactivées.
  16. Rebase une fois. Git rejoue votre commit sur haut de la page principale mise à jour.
  17. Le commit rejoué a un nouveau parent, donc il obtient un nouvel identifiant.
  18. L'ancien commit n'est pas perdu : le sauvetage la branche le pointe toujours.
  19. Comparez maintenant les fichiers. La page est la pareil dans les deux exemplaires.
  20. Il en va de même pour la note d’intégration. Mêmes fichiers, histoire différente.
  21. Regardez les deux graphiques : un diamant avec un commit de fusion et une ligne droite.
  22. Alors lequel devriez-vous utiliser ? Demande à qui d'autre a vos engagements.
  23. Si d'autres en ont, fusionnez. Un rebasement réécrire leur histoire.
  24. Si les commits sont privés, le rebase est sûr et donne une ligne droite.
  25. Ni l’un ni l’autre n’améliore votre code. La règle est une question de propriété.
  26. Maintenant, prouvez-le dans le terminal. Premièrement, le parents de chaque astuce.
  27. Trois identifiants pour la copie de fusion : le commit, et ses deux parents.
  28. Deux identifiants pour la copie de rebase : le commit, et c'est un parent.
  29. Puis les arborescences de fichiers : un identifiant, imprimé deux fois. Mêmes fichiers.
  30. Mais les deux identifiants de validation diffèrent. Égal des arbres, des histoires différentes.
  31. Modifiez l'entrée : supposons que votre branche ait aucun engagement propre.
  32. Une fusion par défaut effectuerait alors une avance rapide, sans validation de fusion.
  33. Ne rebasez jamais une branche que quelqu'un d'autre l'a déjà fait.
  34. Si les arbres diffèrent, comparez les arbres de départ les réfs en premier.
  35. Ne supprimez pas un résultat pour forcer les deux à correspondre.
  36. Pratique : signaler les parents, les pièces d'identité et les arbres à partir de vos propres copies.
  37. Ensuite, réorganisez, écrasez et reformulez votre engagements locaux.

Tous les tutoriels