Explication détaillée des exemples de rebase pour l'apprentissage de Git

Cet article vous apporte des connaissances pertinentes sur Git, qui présente principalement les problèmes liés au rebase et le rebase peut être directement compris comme un changement de base. La branche de fonctionnalité est une branche basée sur B de la branche principale. La base de la fonctionnalité est B. J'espère que cela sera utile à tout le monde.

Étude recommandée : "Tutoriel d'apprentissage Git"

Cet article utilise l'exemple le plus simple pour vous aider à maîtriser rapidement le principe et l'utilisation du rebase

1 Soumettre un diagramme de nœuds

Tout d'abord, faites l'expérience du rebase via un simple. soumettre un diagramme de nœuds Que faites-vous

Deux branches master et feature, où feature est la branche extraite de master au point de soumission B

Il y a un nouveau commit M sur master, et il y a deux nouveaux commits C et D sur feature

Ceci Basculez vers la branche feature et exécutez la commande suivante, ce qui équivaut à fusionner la branche master dans la branche feature (le scénario de cette étape peut être comparé au fait que nous développons notre propre branche feature depuis un certain temps de temps et sont prêts à l'extraire de la branche principale principale) Découvrez les dernières modifications)

git checkout featuregit rebase master

//这两条命令等价于git rebase master feature

L'image ci-dessous montre le diagramme du nœud de validation après le rebase, expliquez son principe de fonctionnement :

• fonctionnalité : branche à rebaser , branche actuelle
• master : branche de base, branche cible

Explication officielle (Si vous ne comprenez pas, vous pouvez lire directement le paragraphe suivant) : Lors d'une opération de rebase, git extraira les modifications sur la branche à rebaser à partir de l'ancêtre commun des deux branches, puis pointer la branche à rebaser vers la base Le dernier commit de la branche, et enfin appliquer les modifications qui viennent d'être extraites à l'arrière du dernier commit de la branche de base. .

Expliqué avec des exemples : Lors de l'exécution de git rebase master sur la branche de fonctionnalité, git extraira les modifications sur la branche de fonctionnalité à partir de l'ancêtre commun B de master et featuer, c'est-à-dire que les deux commits C et D sont extraits en premier . Pointez ensuite la branche de fonctionnalité vers le dernier commit de la branche principale, qui est M. Enfin, les C et D extraits sont connectés à M, mais ce processus consiste à supprimer les C et D d'origine et à générer de nouveaux C' et D'. Leur contenu de soumission est le même, mais l'identifiant de validation est différent. Feature pointe naturellement vers D’ à la fin.

Explication populaire (importante !!) : le rebase peut être directement compris comme un changement de base. La branche de fonctionnalité est une branche extraite de B de la branche principale et la base de la fonctionnalité est B. Et si master a un nouveau commit après B, cela équivaut à utiliser le nouveau commit sur master comme nouvelle base de la branche de fonctionnalités. L'opération réelle consiste à enregistrer les soumissions de la fonctionnalité après B, puis à supprimer les soumissions originales, puis à rechercher le dernier emplacement de soumission du maître, puis à connecter les soumissions enregistrées (nouveau nœud avec un nouvel identifiant de validation), de sorte que la base de la branche des fonctionnalités est tout à fait Yu est devenue M au lieu du B original. (Notez que s'il n'y a pas de nouveaux commits sur le maître après B, alors le B d'origine sera toujours utilisé comme base. L'opération de rebase est équivalente à invalide. Pour le moment, il n'y a fondamentalement aucune différence avec git merge. Le seul la différence est que git merge aura un enregistrement supplémentaire de soumission d'opération de fusion)

L'exemple ci-dessus peut être résumé dans le scénario de travail réel suivant : Zhang San a extrait le code de B pour le développement et l'a soumis deux fois jusqu'à présent, et l'a développé en D ; Li Si l'a également extrait de B et l'a développé, il l'a soumis à M puis l'a fusionné dans le tronc principal. À ce moment-là, Zhang San voulait extraire le dernier code, il a donc exécuté git rebase master sur la branche feature, c'est-à-dire rebasé la branche master puisque Li Si avait développé et fusionné le tronc plus tôt, cela équivaut à Zhang San. sur la base de la dernière soumission de Li Si, M a été développé.

---

2. Exemple de soumission git réel

L'enregistrement de soumission est construit selon le diagramme ci-dessus, comme le montre la figure ci-dessous : (ABM est la ligne de branchement principale, ABCD est la ligne de branchement de fonctionnalité. Ici, la couleur principale change et débourse. Cela n'affecte pas la compréhension, sachez simplement que cela signifie deux branches et deux lignes !)

À ce stade, exécutez git rebase master sur la branche de fonctionnalité

Une fois le rebase terminé, ABCD est le embranchement de fonctionnalité d'origine, ABMC'D' C'est la nouvelle embranchement de fonctionnalité et ABM est l'embranchement principal (pas de changement)

---

3. Scénarios d'utilisation recommandés

Il y a tellement de choses à faire, mais ceci est en fait la chose la plus importante. Différentes entreprises et différentes situations ont différents scénarios d'utilisation, mais dans la plupart des cas, les recommandations sont les suivantes :

1. Lorsque vous extrayez le dernier code d'une branche publique, utilisez rebase, c'est-à-dire git pull -r ou git pull --rebase, mais un inconvénient est qu'après le rebase, je ne sais pas quelle branche ma branche actuelle a été extraite en premier de. Parce que la base a changé. (Pour cette raison, la plupart des entreprises n'utilisent pas le rebase et utilisent essentiellement la fusion. Bien qu'il y ait un enregistrement de soumission dénué de sens « Fusionner… vers… », au moins elles peuvent savoir qui a fait quoi)
2. Lors de la fusion de code dans un fichier public. branche, utilisez la fusion. (Si vous utilisez rebase, alors si d'autres développeurs veulent voir l'historique de la branche principale, ce ne sera pas l'historique d'origine. L'historique a été falsifié par vous. Par exemple, Zhang San et Li Si ont tiré le développement d'une branche commune. Le nœud Zhang San a d'abord terminé le développement et en a soumis deux. Ensuite, la fusion a eu lieu, et Li Si l'a ensuite développé et rebasé (notez que Li Si doit passer à la branche principale, puis exécuter git rebase, puis git pull vers la branche distante. fin), alors la nouvelle soumission de Li Si devient la nouvelle de Zhang San. La nouvelle base soumise, à l'origine la soumission de Li Si était la dernière, mais la dernière soumission a montré que c'était celle de Zhang San à la place, et tout s'est mal passé)

Apprentissage recommandé : " Tutoriel Git"

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!