Un guide de la rébase interactive GIT, avec des exemples pratiques

Git Interactive Base Change: Un outil puissant pour améliorer l'efficacité de développement

Le contrôle de version git est devenu standard dans la boîte à outils des développeurs modernes. Des commandes telles que commit, push et pull sont devenues depuis longtemps la mémoire musculaire. Cependant, relativement parlant, peu de développeurs comprennent les fonctionnalités "plus avancées" dans GIT et l'énorme valeur de ces fonctionnalités! Cet article explorera l'un des outils les plus puissants de Git - "Rebase interactive".

Points de base

• Interactive Rebase est un puissant outil GIT qui permet aux développeurs de créer un historique de validation bien structuré, ce qui rend la base de code des projets plus facile à lire et à comprendre.
• Rebase interactif peut être utilisé pour modifier les anciennes informations de validation, supprimer les commits, fusionner plusieurs engagements, réorganiser les engagements, réparer les anciens engagements et fendre / rouvrir les anciens engagements pour l'édition.
• Il est important de ne pas utiliser la rebase interactive sur les validations qui ont été partagées avec des collègues du référentiel distant, car il réécrira l'historique. Au lieu de cela, vous devez l'utiliser pour nettoyer les commits locaux avant de les fusionner dans la succursale de l'équipe.
Les mécanismes de base des opérations de base interactifs incluent l'identification de la partie de l'historique de soumission à utiliser, le démarrage de la session avec la commande
• , puis la spécification de l'action requise dans la fenêtre Open Editor. git rebase -i
Rebase interactif peut être utilisé pour modifier les anciennes informations de validation, supprimer les validations inutiles et fusionner plusieurs engagements en un, optimisant et nettoyer ainsi l'historique des engagements.

Pourquoi la Rebase interactive devrait faire partie de chaque boîte à outils de développeur

En bref, il n'est pas exagéré de dire que la rebase interactive peut vous aider à devenir un meilleur développeur en vous permettant de créer un historique de validation propre et bien structuré dans votre projet.

Pourquoi un historique de soumission bien structuré est-il important? Imaginez le contraire: un historique de soumission difficile à lire, vous ne savez pas ce que les changements récents de votre collègue ont réellement fait. Il y aura de plus en plus de «coins sombres» dans des projets comme celui-ci, et vous ne connaissez que la petite partie de votre participation.

Comparez-le avec un historique de validation propre et bien structuré: il aide à rendre la base de code du projet plus lisible et et

plus facile à comprendre. C'est une partie nécessaire d'un programme sain et durable!

Que peut faire le changement de base interactif pour vous Interactive Rebase vous aide à optimiser et à nettoyer votre historique de validation. Il couvre de nombreux cas d'utilisation différents, dont certains vous permettent de faire ce qui suit:

• modifier les anciennes informations de soumission
• Supprimer la soumission
• Merger / combiner plusieurs engins
• Réorganiser la soumission
• Correction de l'ancien engagement
• Split / rouvrir vieil valide pour l'édition

Quand utiliser la rébase interactive (et quand pas!)

comme certains autres outils Git, renforcez interactivement "réécriture de l'histoire". Cela signifie que lorsque vous utilisez des opérations de rebase interactives pour faire fonctionner une série de validations, cette partie de l'histoire de la validation sera réécrite par : Le hachage SHA-1 du commit changera. Ce sont de nouveaux objets de validation, pour ainsi dire. Le fait que

nécessite une règle simple mais importante à suivre: n'utilisez pas de réprimandes interactives (ou d'autres outils pour réécrire l'historique) sur les validations que vous avez partagées avec des collègues du référentiel distant. Au lieu de cela, utilisez-le pour nettoyer vos propres commits locaux - par exemple, dans l'une de vos propres branches de fonctionnalités, puis fusionnez-les dans la branche de l'équipe.

Mécanisme de base de l'opération de base interactive

Bien que les rebases interactives puissent être utilisées pour de nombreuses choses différentes, leur flux de travail de base est toujours le même. Une fois que vous avez fermement une compréhension de ce mécanisme de base, la rebase interactive perd son atmosphère «complexe et mystérieuse» et devient un outil précieux et facile à utiliser dans votre boîte à outils.

Étape 1: Où devez-vous commencer la session?

La première question à laquelle vous devez répondre est: "Quelle partie de l'historique des engagements est-ce que je veux opérer?" Donnons un exemple pratique, supposons que nous voulons modifier les anciennes informations de validation (c'est exactement ce que nous allons faire plus tard dans la pratique).

Notre situation de départ est montrée dans la figure ci-dessous, nous modifions les anciennes informations de soumission par base de changement interactif.

Afin de pouvoir modifier les informations de validation en C2, nous devons démarrer la session de rébase interactive à son engagement parent (ou plus tôt, si vous préférez). Dans cet exemple, nous utiliserons C1 comme point de départ pour la session Rebase interactive.

Étape 2: Démarrez la session réelle!

Démarrer une session réelle est très simple:

Nous utilisons la commande

avec le drapeau

<code>$ git rebase -i HEAD~3</code>

(indique que nous voulons vraiment qu'il soit "interactif") et fournissez le validation de base (que nous avons trouvé dans la première étape ci-dessus). Dans cet exemple, j'ai utilisé

pour spécifier un engagement qui "est à la traîne derrière la tête de la tête 3 commet". Alternativement, je pourrais également fournir un hachage SHA-1 spécifique. -i git rebase Étape 3: Dites à Git ce que vous voulez faire HEAD~3

Après avoir démarré la session de rébase interactive, vous verrez une fenêtre d'éditeur où Git répertorie une série de validations - du dernier engagement jusqu'à (mais non inclus) de la validation de base que vous avez sélectionnée à l'étape 1 comme soumission de base de validation de base .

Dans cette étape, deux points doivent être prêts à se présenter à:

1. Les soumissions sont répertoriées dans l'ordre inverse! Nous nous attendons à ce que les dernières soumissions qui apparaissent en haut de apparaîtront en bas de de la liste. Ne vous inquiétez pas: votre référentiel GIT est intact! ? N'oubliez pas que nous effectuons une opération de base de changement interactive, qui nécessite que Git réapplique des engagements de l'ancien à nouveau à la fin de l'opération. Ne faites pas de modifications réelles dans cette fenêtre d'éditeur! Bien que vous puissiez être tenté de modifier les informations de validation directement dans cette fenêtre d'éditeur (après tout, c'est exactement ce que nous voulons faire ...), vous devez être patient. Ici, nous disons simplement à Git ce que nous voulons faire - plutôt que d'apporter les modifications réelles. Je vais le démontrer bientôt dans la pratique!
2. Avec cet aperçu théorique, plongeons ensemble dans certains cas pratiques!
modifier les anciennes informations de soumission

L'un des cas d'utilisation les plus populaires pour la rébase interactive est que vous pouvez modifier les anciennes soumissions par la suite. Vous savez peut-être que

vous permet également de modifier les informations soumises - mais cela ne s'applique qu'aux dernières soumissions

. Pour tout engagement plus âgé que cela, nous devons utiliser la rebase interactive!

Regardons un scénario spécifique. Vous trouverez ci-dessous une image des informations de soumission d'erreur qui doivent être corrigées. git commit --amend

Remarque: Pour une meilleure vue d'ensemble et une visualisation plus claire, j'ai utilisé le client Tower Git Desktop dans certaines captures d'écran. Vous n'avez pas besoin d'une tour pour suivre ce tutoriel.

Pour notre exemple, supposons que nous voulons modifier le message pour la soumission actuelle intitulée "Optimiser la structure de balisage dans l'index ...".

Notre première étape consiste à déterminer l'engagement de base de cette session de rebase interactive. Puisque nous devons (au moins) revenir à l'engagement parent de notre engagement "Bad Apple", nous utilisons (trois engins derrière les commits de tête, c'est-à-dire le commit intitulé "Changer les titres ...") comme point de départ pour La session:

Après avoir exécuté cette commande, votre éditeur préféré ouvrira et affichera la liste des validations que vous venez de sélectionner (en fournissant un engagement de base).

HEAD~3

<code>$ git rebase -i HEAD~3</code>

Un rappel: Bien que vous puissiez être tenté de le faire, nous ne modifierons pas les informations de soumission ici. Nous utilisons uniquement le "mot-clé d'opération"

pour marquer les lignes correspondantes de

. Dans notre cas, nous voulons remplacer le commit (ce qui signifie que nous voulons modifier les informations de la validation, mais garder le reste de l'engagement).

En fait, tous les mots clés d'action disponibles sont spécifiés au bas de cette fenêtre - il n'est donc pas nécessaire de se souvenir de quoi que ce soit!

Une fois que vous remplacez le mot-clé standard par votre mot-clé d'action préféré (qui signifie "accepter les validations telles quelles"), vous enregistrez et fermez simplement la fenêtre.

Après cela, une nouvelle fenêtre d'éditeur s'ouvrira avec les informations de validation actuelles. Enfin, nous pouvons faire ce que nous avions prévu de faire au début: modifiez ce vieux message de validation!

Après avoir apporté des modifications et enregistré et fermé la fenêtre de l'éditeur, la session de rebase interactive est terminée - nos informations de soumission ont été mises à jour! ?

Supprimer les soumissions indésirables

Interactive Rebase vous permet également de supprimer Old Commits de l'histoire dont vous n'avez pas besoin (ou ne voulez pas). Imaginez que vous incluez accidentellement un mot de passe personnel dans votre soumission récente: dans la plupart des cas, ces informations sensibles ne doivent pas être incluses dans la base de code.

N'oubliez pas non plus que le simple fait de supprimer les informations et de les recommander ne résout pas vraiment votre problème: cela signifie que le mot de passe est toujours enregistré dans le référentiel en tant qu'ancien engagement. Ce que vous voulez vraiment, c'est supprimer

ces données complètement propres à partir du référentiel! Déterminions d'abord l'engagement de base de la session de rebase interactive. Étant donné que nous devons commencer au moins avec la validation du parent du mauvais engagement, nous utilisons la «structure de balisage d'optimiser ...» comme base:

Veuillez noter que cette fois, j'ai utilisé le hachage SHA-1 spécifique dans la commande

<code>$ git rebase -i HEAD~3</code>

. Bien sûr, en plus de Commit Hash, je peux également utiliser

pour gérer cet engagement. git rebase -i HEAD~2 Après avoir exécuté cette commande, nous reverrons une liste de validation.

Cette fois, nous utilisons le mot-clé

Action pour se débarrasser des validations indésirables. Ou, dans ce cas particulier, nous pouvons simplement supprimer la ligne entière de l'éditeur. Si une ligne n'existe plus lors de l'enregistrement et de la fermeture de la fenêtre (représente un engagement), GIT supprimera l'engagement correspondant.

drop Quoi que vous choisissiez, après avoir enregistré et fermé la fenêtre de l'éditeur, la soumission sera supprimée de votre historique de référentiel!

fusionner plusieurs engins dans un

Un autre cas d'utilisation pour Rebase interactif est lorsque vous souhaitez fusionner plusieurs engins séparés

en un. Avant de plonger dans la façon de travailler, passons quelques minutes à discuter quand ou pourquoi cela peut être précieux.

D'une manière générale, faire un engagement "plus grand" (en combinant plusieurs engins en un) n'est pas une bonne stratégie dans la plupart des cas. La règle générale est de garder l'engagement aussi petit que possible, car "plus petit" signifie "plus facile à lire et à comprendre". Cependant, dans certains cas, cela a encore du sens. Voici deux exemples:

• Imaginez que vous avez remarqué quelque chose de mal avec l'ancien engagement. Vous pouvez ensuite procéder à générer un new Engagez-vous à résoudre le problème. Dans ce cas, il est logique de fusionner ces engagements en un seul: après tout, les nouveaux engins ne sont qu'un "arrêt" pour résoudre les problèmes qui n'auraient pas dû exister. En combinant ces commits, il semble qu'il n'y ait aucun problème du tout!
• Un autre exemple est lorsque vous remarquez que vous faites un peu trop détaillé. Faire de petits commits est bon, mais remplir votre histoire de validation avec de nombreux petits engrenages inutiles signifiera dépasser la cible. Les principes de base dans les deux exemples sont les mêmes: en combinant deux (ou plus) engagements qui auraient été un engagement, vous créez une histoire de validation plus propre et plus lisible!

Complétons ensemble un exemple pratique et utilisons la situation indiquée dans l'image suivante comme notre situation de départ.

Supposons que sémantiquement, il est plus logique de fusionner ces deux engagements dans un seul engagement. À l'aide de l'outil Rebase interactif, nous pouvons le faire:

Jusqu'à présent, vous vous êtes habitué à ce qui se passe: une fenêtre d'éditeur s'ouvrira avec une liste de soumissions. squash

<code>$ git rebase -i HEAD~3</code>

J'ai mentionné que dans ce cas, nous utiliserons le mot-clé de l'opération

. Il y a une chose importante à savoir sur le fonctionnement de :

Les lignes que vous avez marquées de mots clés fusionnent avec les lignes directement ci-dessus!

Cela explique pourquoi j'ai marqué la ligne 2 avec le mot-clé squash dans notre exemple. squash Après avoir enregistré et fermé cette fenêtre, une nouvelle fenêtre s'ouvrira. En effet, en combinant plusieurs commits, nous créerons bien sûr un nouvel engagement. Et cette soumission nécessite également des informations de soumission, comme toute autre soumission! squash

Ce que vous voyez dans la capture d'écran ci-dessus, c'est ce que Git a préparé pour nous: il combine les informations de soumission de l'engagement original correspondant avec certains commentaires. N'hésitez pas à supprimer les anciens messages et à recommencer - ou à les garder et à ajouter plus d'informations.

Après avoir enregistré et fermé cette fenêtre d'éditeur, nous pouvons dire fièrement: c'était deux commits distincts, mais maintenant c'est un engagement!

Utilisez les fonctions puissantes du changement de base interactif

J'espère que vous convenez que l'outil de rebase interactif de Git est très précieux! En tant que développeurs, nous devons nous efforcer d'une histoire propre et claire. C'est un facteur clé pour garder la base de code saine et facile à comprendre (pour vos coéquipiers et vous-même, après un certain temps, il s'est écoulé).

Si vous voulez en savoir plus, je recommande fortement la "Kit de premiers soins GIT". Il s'agit d'une courte collection de vidéos (gratuite) qui vous montre comment nettoyer et annuler les erreurs dans GIT.

Amusez-vous!

Git Interactive Change Base FAQ (FAQ)

Quelle est la différence entre Git Rebase et Git Merge?

Git Rebase et Git Merge sont deux façons différentes d'intégrer les changements d'une branche dans une autre. Git Merge est un moyen de combiner directement le code à partir de deux branches différentes. Il crée un nouvel engagement dans l'histoire, préservant l'ordre chronologique des commits. Git Rebase, en revanche, est un moyen de déplacer ou de combiner une série de engagements dans un nouvel engagement de base. C'est comme dire "Je veux ajouter le travail des autres sur mes changements". En d'autres termes, il vous permet de placer des modifications à la branche actuelle sur le dessus d'une autre branche.

Comment annuler la rébase Git?

Si vous souhaitez annuler la rébase Git, vous pouvez utiliser la commande git reflog pour trouver l'engagement à laquelle vous souhaitez revenir, puis utiliser la commande git reset --hard HEAD@{number}. La commande git reflog affiche une liste de chaque modification apportée à la tête, et la commande git reset vous permet de définir la tête actuelle à l'état spécifié.

Quel est le but de Git Interactive Rebase?

Git Interactive Rebase vous permet de changer de validation de diverses manières, telles que l'édition, la suppression et la compression. Vous pouvez non seulement modifier les informations de validation, mais également modifier le code réel (si vous faites une erreur). Il s'agit d'un outil puissant qui vous donne un contrôle complet sur l'historique de soumission de votre projet.

Comment utiliser la soumission de compression de base variable interactive GIT?

La compression est l'acte de fusionner plusieurs engagements dans un seul engagement. Dans GIT, vous pouvez comprimer l'engagement en utilisant la commande git rebase -i suivi par le hachage de la commission à compresser. Dans l'éditeur de texte ouvert, vous pouvez marquer l'engagement que vous souhaitez compresser en remplaçant pick par squash ou s.

Quels sont les risques d'utiliser Git Interactive Rebase?

Bien que Git Interactive Rebase soit un outil puissant, il peut être dangereux s'il est mal utilisé. Il réécrit l'histoire de la validation, ce qui peut causer des problèmes si vous avez affaire à une branche publique à laquelle d'autres sont également aux prises. Il est recommandé de l'utiliser sur des succursales locales qui n'ont pas encore été poussées.

Comment résoudre les conflits pendant la base de changement Git?

Les affrontements peuvent se produire pendant le processus de rébase. Git s'arrêtera et vous permettra de résoudre ces conflits avant de continuer. Vous pouvez corriger les modifications contradictoires en modifiant les fichiers, puis utiliser git add pour ajouter des fichiers résolus pour résoudre les conflits. Une fois que tous les conflits sont résolus, vous pouvez continuer à modifier la base en utilisant git rebase --continue.

Puis-je utiliser Git Interactive Change Base pour diviser l'engagement?

Oui, vous pouvez diviser un engagement en engagements plus petits à l'aide de Git Interactive Rebase. Ceci est très utile si vous apportez plusieurs modifications dans un seul engagement, mais décidez ensuite qu'ils devraient être séparés.

Comment modifier les informations de soumission à l'aide de la base de changement interactive GIT?

Vous pouvez modifier les informations de soumission lors de la rebase interactive. Dans la liste de soumission, remplacez pick par reword ou r pour marquer la soumission à modifier. Lorsque vous continuez, Git ouvrira un éditeur de texte pour chaque soumission marquée reword, vous permettant de modifier les informations de soumission.

Quelle est la différence entre Git Rebase et Git Pull?

Git pull est une commande qui prend des modifications d'un référentiel distant et les fusionne dans la branche actuelle. D'un autre côté, Git rebase est une commande qui déplace ou combine une série de validations dans un nouvel engagement de base. Bien que les deux commandes soient utilisées pour les modifications d'intégration, elles sont effectuées différemment.

Puis-je utiliser Git Interactive Rebase pour modifier l'ordre des validations?

Oui, vous pouvez utiliser Git Interactive Rebase pour modifier l'ordre des validations. Dans la liste des validations, vous pouvez simplement modifier l'ordre des lignes pour modifier l'ordre des commits. Ceci est très utile si vous souhaitez rendre votre histoire de validation plus logique ou plus claire.

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!