git rebase signifie : redéfinir le statut du référentiel de la branche ; 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 pointera la branche à rebaser vers la branche de base Le dernier commit de la branche de base, et enfin appliquer les modifications qui viennent d'être extraites à l'arrière du dernier commit de la branche de base.
L'environnement d'exploitation de ce tutoriel : système Windows 7, Git version 2.30.0, ordinateur Dell G3.
Git rebase, comme son nom l'indique, consiste à redéfinir le rôle du point de départ (base), c'est-à-dire à redéfinir le statut du référentiel de la branche.
Tout d'abord, voyons ce que fait le rebase à travers un simple diagramme de nœud de soumission
Deux branches, master et feature, où feature est la branche extraite du maître au point de soumission B
Il y en a deux. branches sur master Un nouveau commit M et deux nouveaux commits C et D sur feature
À ce moment, passez à la branche feature et exécutez la commande suivante, ce qui équivaut à fusionner la branche master dans la branche feature
git checkout feature git rebase master //这两条命令等价于git rebase master feature
L'image ci-dessous montre le rebase. Le diagramme du nœud de soumission final explique son fonctionnement :
Explication officielle : lors de l'exécution une opération de rebase, git va partir de l'ancêtre commun des deux branches, extraire les modifications sur la branche à modifier, puis pointer la branche à modifier vers le dernier commit de la branche de base, et enfin appliquer les modifications qui viennent d'être extraites à au verso du dernier commit de la branche de base.
Explication avec exemples : Lors de l'exécution de git rebase master sur la branche feature, git extraira les modifications sur la branche feature en commençant par 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. Naturellement, la fonctionnalité pointe finalement vers D’.
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. 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.
Il existe également une explication très simple. La clé de la commande rebase est en fait de comprendre la "base". git rebase
La soumission L'enregistrement est construit selon le diagramme ci-dessus, comme suit Comme le montre l'image : (ABM est la ligne de branchement principale et ABCD est la ligne de branchement de la fonctionnalité. Ici, le maître change de couleur et se ramifie. Cela n'affecte pas la compréhension. Juste sachez que cela signifie deux branches et deux lignes !)
Ceci lors de l'exécution de git rebase master sur la branche de fonctionnalité
Une fois le rebase terminé, ABCD est la ligne de branche de fonctionnalité d'origine, ABMC'D' est la nouvelle branche de fonctionnalité ligne, et ABM est la ligne secondaire principale (pas de changement)
Il y a tellement de choses à faire, mais c'est en fait la plus importante. Différentes entreprises et différentes situations ont des scénarios d'utilisation différents, mais dans la plupart des cas, les recommandations sont les suivantes :
Utilisez rebase lors de l'extraction du dernier code de la branche publique, c'est-à-dire git pull -r ou git pull --rebase, mais il y a un inconvénient à rebase. À partir de maintenant, je ne saurai plus de quelle branche ma branche actuelle a été extraite pour la première fois, car la base a changé. (Si vous utilisez la fusion, il y aura un enregistrement de validation dénué de sens "Fusionner... vers...")
Lors de la fusion de code dans une branche publique, 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)
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!