Au moins la moitié des personnes qui utilisent git ne savent pas comment utiliser rebase (même pour les fonctions de base) (cette estimation est probablement très conservatrice)
Probablement seulement la moitié de la moitié restante comprend vraiment quand rebaser correctement...
Fusionner ou rebaser n'est pas une question de choisir l'un ou l'autre. Il doit être choisi en fonction de la situation spécifique. En réalité, cette "situation spécifique" est vraiment difficile à énumérer une par une. les fonctions dans l'équipe sont relativement simples, et ils n'ont pas souvent l'occasion de les rencontrer, je ne résumerai donc ici que deux principes que chacun doit comprendre et respecter :
Lorsque vous passez de la télécommande à pull, utilisez toujours rebase (à une exception près, discutée plus tard)
Lorsque vous complétez une fonctionnalité (en supposant que vous avez ouvert une branche locale séparément) et prévoyez de la fusionner dans la branche principale, utilisez toujours merge
Les développeurs doivent comprendre que différentes stratégies de fusion peuvent ne pas affecter le résultat final du code, mais qu'elles affecteront la façon dont git enregistre l'historique des soumissions (bien que cette compréhension ne profite souvent qu'aux individus et ait peu d'impact sur eux-mêmes) ). Lorsque d'autres personnes utilisent ces historiques (comme lors d'une révision de code, ou lors d'une bisect, etc.), elles se sentiront extrêmement heureuses ou malheureuses à cause de ce que vous avez fait dans le passé.
Le deuxième point est plus facile à comprendre. Masquez les détails spécifiques du développement d'une fonction dans la branche locale et fusionnez le résultat final dans la branche principale en tant qu'enregistrement complet.
La clé est le premier point. Dans la plupart des cas, tout le monde choisira la valeur par défaut pull, qui est fetch + merge, nous verrons donc des messages d'interférence tels que Fusionner le commit xxx en xxx apparaître constamment sur le tronc. Si tout le monde fait cela pour plus de commodité, nous n'aurons jamais un arbre historique propre et beau. Au lieu de cela, nous aurons quelque chose comme ceci :
.
Si vous clonez correctement un projet qui utilise git, vous ne verrez jamais un maître désordonné comme l'image ci-dessus. Pourquoi? La réponse est : git pull --rebase. Cette commande utilisera rebase au lieu du pull par défaut pour rebaser l'arborescence de l'historique fusionné, ce qui peut éviter des enregistrements fusionnés supplémentaires en raison de l'impossibilité d'avancer rapidement.
Maintenant, la plupart des clients git permettent de définir le comportement par défaut de git pull sur --rebase, donc maîtriser cette astuce peut produire des enregistrements d'historique propres et beaux pour la plupart des opérations d'extraction quotidiennes, mais cela ne constitue pas une fin parfaite. Il existe une exception comme celle-ci :
Après avoir utilisé git merge pour terminer la fusion d'une branche de fonctionnalité avec la branche de tronc (bien sûr celle de --no-ff)
Lorsque vous exécutez git fetch, vous constatez que le tronc distant a plusieurs commits devant vous
Si vous git pull --rebase à ce moment, vous constaterez que l'enregistrement de la branche de fonctionnalités que vous venez de fusionner a disparu...
En effet, rebase ignorera les enregistrements fusionnés, donc la commande rebase aura un paramètre spécial appelé : --preserve-merges utilisé pour reconstruire les enregistrements fusionnés ignorés. Une meilleure solution que git pull --rebase consiste donc à utiliser git fetch + git rebase -p à la place.
Bien entendu, cela concerne uniquement les circonstances particulières évoquées ci-dessus. Avec la mise à jour de git, il n'est pas certain que ce problème n'existera plus un jour. Je ne rencontre généralement pas cette situation, car je fais toujours ceci :
Après avoir terminé la branche des fonctionnalités, ne fusionnez pas, mais revenez à la branche principale git pull --rebase
Si le tronc est mis à jour, rebasez le contenu mis à jour sur la branche de fonction pour pré-vérifier si ma fonction est toujours OK après avoir ajouté les modifications récentes apportées par d'autres (il peut y avoir des conflits dans ce processus, Don' Je ne me blâme pas de ne pas te le rappeler)
Une fois que tout est prêt, git fetch vérifiez à nouveau le coffre pour voir s'il y a des changements (car quelqu'un a peut-être poussé de nouveaux changements lors de la deuxième étape), s'il y a des changements, répétez la deuxième étape, sinon——
Fusionnez la branche de fonction avec le tronc, poussez-la et appelez-la un jour.
Je peux éviter l'accident mentionné ci-dessus en faisant cela. Cela semble un peu compliqué, mais en fait ce n'est pas difficile une fois que vous le connaissez. La raison la plus importante est que git rebase -p est défectueux :
.
ne peut pas être utilisé avec git pull. Une commande est divisée en deux, ce qui semble de toute façon "perdu" (même si vous pouvez écrire des scripts, il est préférable de ne pas le faire car cela vous fera parfois du mal après vous). s'y habituer)
ne peut pas être utilisé avec git pull, vous devez donc spécifier la branche cible pour le rebase, ce qui est assez ennuyeux, surtout lorsque de nombreux clients GUI ne prennent pas du tout en charge git rebase -p (j'utilise souvent des environnements CLI/Switch entre l'interface graphique en utilisant git)
ORIG_HEAD sera détruit.
ORIG_HEAD est très utile dans de nombreuses situations. Par exemple, vous pouvez utiliser git log -p -reverse ORIG_HEAD pour revoir toutes les modifications provoquées par la dernière fusion, etc. --preserve-merges lui fera perdre l'emplacement vers lequel il est censé pointer, et vous devrez d'abord trouver le hachage correct pour le remplacer, ce qui peut être un peu ennuyeux.
La réponse ci-dessus illustre enfin une chose : la complexité de la réalité dépassera toujours votre imagination lorsque vous êtes un débutant. Si vous voulez vraiment bien utiliser git, vous devez comprendre le principe de fonctionnement de git sur la base du travail quotidien. , vous pouvez lire le livre électronique du site officiel (version chinoise). Après avoir lu attentivement la section interne de git, vous saurez quelles commandes utiliser.
Point supplémentaire : si votre équipe ne se soucie pas de nombreux enregistrements de commit interférant sans importance sur la branche tronc, alors vous pouvez toujours utiliser rebase, afin qu'au moins il n'y ait pas beaucoup de forks, et que cela puisse être propre s'il est géré correctement (mais il est détaillé), l'historique des branches principales.
Pas obligatoire, mais tous les tests doivent être verts après poussée
(Nous n'avons pas de branches particulièrement longues, la plupart sont fusionnées en 2-3 jours, rarement plus d'une semaine)
Habituellement, chacun choisit en fonction de la difficulté de la fusion. S'il n'y a pas de différence, le rebase sera prioritaire... car cela semble meilleur
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Je suppose que la réalité est la suivante :
Au moins la moitié des personnes qui utilisent git ne savent pas comment utiliser rebase (même pour les fonctions de base) (cette estimation est probablement très conservatrice)
Probablement seulement la moitié de la moitié restante comprend vraiment quand rebaser correctement...
Fusionner ou rebaser n'est pas une question de choisir l'un ou l'autre. Il doit être choisi en fonction de la situation spécifique. En réalité, cette "situation spécifique" est vraiment difficile à énumérer une par une. les fonctions dans l'équipe sont relativement simples, et ils n'ont pas souvent l'occasion de les rencontrer, je ne résumerai donc ici que deux principes que chacun doit comprendre et respecter :
Lorsque vous passez de la télécommande à
pull, utilisez toujours rebase (à une exception près, discutée plus tard)Lorsque vous complétez une fonctionnalité (en supposant que vous avez ouvert une branche locale séparément) et prévoyez de la fusionner dans la branche principale, utilisez toujours merge
Les développeurs doivent comprendre que différentes stratégies de fusion peuvent ne pas affecter le résultat final du code, mais qu'elles affecteront la façon dont git enregistre l'historique des soumissions (bien que cette compréhension ne profite souvent qu'aux individus et ait peu d'impact sur eux-mêmes) ). Lorsque d'autres personnes utilisent ces historiques (comme lors d'une révision de code, ou lors d'une bisect, etc.), elles se sentiront extrêmement heureuses ou malheureuses à cause de ce que vous avez fait dans le passé.
Le deuxième point est plus facile à comprendre. Masquez les détails spécifiques du développement d'une fonction dans la branche locale et fusionnez le résultat final dans la branche principale en tant qu'enregistrement complet.
La clé est le premier point. Dans la plupart des cas, tout le monde choisira la valeur par défaut
.pull, qui estfetch + merge, nous verrons donc des messages d'interférence tels que Fusionner le commit xxx en xxx apparaître constamment sur le tronc. Si tout le monde fait cela pour plus de commodité, nous n'aurons jamais un arbre historique propre et beau. Au lieu de cela, nous aurons quelque chose comme ceci :Si vous clonez correctement un projet qui utilise git, vous ne verrez jamais un maître désordonné comme l'image ci-dessus. Pourquoi? La réponse est :
git pull --rebase. Cette commande utiliserarebaseau lieu dupullpar défaut pour rebaser l'arborescence de l'historique fusionné, ce qui peut éviter des enregistrements fusionnés supplémentaires en raison de l'impossibilité d'avancer rapidement.Maintenant, la plupart des clients git permettent de définir le comportement par défaut de
git pullsur--rebase, donc maîtriser cette astuce peut produire des enregistrements d'historique propres et beaux pour la plupart des opérations d'extraction quotidiennes, mais cela ne constitue pas une fin parfaite. Il existe une exception comme celle-ci :Après avoir utilisé
git mergepour terminer la fusion d'une branche de fonctionnalité avec la branche de tronc (bien sûr celle de--no-ff)Lorsque vous exécutez
git fetch, vous constatez que le tronc distant a plusieurs commits devant vousSi vous
git pull --rebaseà ce moment, vous constaterez que l'enregistrement de la branche de fonctionnalités que vous venez de fusionner a disparu...En effet, rebase ignorera les enregistrements fusionnés, donc la commande rebase aura un paramètre spécial appelé :
--preserve-mergesutilisé pour reconstruire les enregistrements fusionnés ignorés. Une meilleure solution quegit pull --rebaseconsiste donc à utilisergit fetch+git rebase -pà la place.Bien entendu, cela concerne uniquement les circonstances particulières évoquées ci-dessus. Avec la mise à jour de git, il n'est pas certain que ce problème n'existera plus un jour. Je ne rencontre généralement pas cette situation, car je fais toujours ceci :
Après avoir terminé la branche des fonctionnalités, ne fusionnez pas, mais revenez à la branche principale
git pull --rebaseSi le tronc est mis à jour, rebasez le contenu mis à jour sur la branche de fonction pour pré-vérifier si ma fonction est toujours OK après avoir ajouté les modifications récentes apportées par d'autres (il peut y avoir des conflits dans ce processus, Don' Je ne me blâme pas de ne pas te le rappeler)
Une fois que tout est prêt,
git fetchvérifiez à nouveau le coffre pour voir s'il y a des changements (car quelqu'un a peut-être poussé de nouveaux changements lors de la deuxième étape), s'il y a des changements, répétez la deuxième étape, sinon——Fusionnez la branche de fonction avec le tronc, poussez-la et appelez-la un jour.
Je peux éviter l'accident mentionné ci-dessus en faisant cela. Cela semble un peu compliqué, mais en fait ce n'est pas difficile une fois que vous le connaissez. La raison la plus importante est que
.git rebase -pest défectueux :ne peut pas être utilisé avec
git pull. Une commande est divisée en deux, ce qui semble de toute façon "perdu" (même si vous pouvez écrire des scripts, il est préférable de ne pas le faire car cela vous fera parfois du mal après vous). s'y habituer)ne peut pas être utilisé avec
git pull, vous devez donc spécifier la branche cible pour le rebase, ce qui est assez ennuyeux, surtout lorsque de nombreux clients GUI ne prennent pas du tout en chargegit rebase -p(j'utilise souvent des environnements CLI/Switch entre l'interface graphique en utilisant git)ORIG_HEADsera détruit.ORIG_HEADest très utile dans de nombreuses situations. Par exemple, vous pouvez utilisergit log -p -reverse ORIG_HEADpour revoir toutes les modifications provoquées par la dernière fusion, etc.--preserve-mergeslui fera perdre l'emplacement vers lequel il est censé pointer, et vous devrez d'abord trouver le hachage correct pour le remplacer, ce qui peut être un peu ennuyeux.La réponse ci-dessus illustre enfin une chose : la complexité de la réalité dépassera toujours votre imagination lorsque vous êtes un débutant. Si vous voulez vraiment bien utiliser git, vous devez comprendre le principe de fonctionnement de git sur la base du travail quotidien. , vous pouvez lire le livre électronique du site officiel (version chinoise). Après avoir lu attentivement la section interne de git, vous saurez quelles commandes utiliser.
Point supplémentaire : si votre équipe ne se soucie pas de nombreux enregistrements de commit interférant sans importance sur la branche tronc, alors vous pouvez toujours utiliser rebase, afin qu'au moins il n'y ait pas beaucoup de forks, et que cela puisse être propre s'il est géré correctement (mais il est détaillé), l'historique des branches principales.
Pas obligatoire, mais tous les tests doivent être verts après poussée
(Nous n'avons pas de branches particulièrement longues, la plupart sont fusionnées en 2-3 jours, rarement plus d'une semaine)
Habituellement, chacun choisit en fonction de la difficulté de la fusion. S'il n'y a pas de différence, le rebase sera prioritaire... car cela semble meilleur