Des dizaines d'images animées vous expliquent comment fonctionne Git

git merge, git rebase, git reset, git revert, git fetch, git pull, git reflog... Savez-vous quelles tâches effectuent ces commandes git ? Si vous êtes toujours confus, ne manquez pas cet article. Dans cet article, Lydia Hallie, une consultante en logiciels de 21 ans familière avec JavaScript, TypeScript, GraphQL, Serverless, AWS, Docker et Golang, présente intuitivement le processus de travail de ces commandes git couramment utilisées sous forme d'animations, en vous assurant que vous ne les oublierez jamais.

Bien que Git soit un outil très puissant, la plupart des gens seraient d'accord avec moi si je disais que Git est un cauchemar à utiliser. Je trouve très utile lorsque je travaille avec Git de la visualiser dans ma tête : lorsque j'exécute une commande spécifique, comment ces branches interagiront-elles et comment cela affectera-t-il l'historique ? Pourquoi mes collègues pleurent-ils lorsque j'effectue un redémarrage brutal sur master, que je force le push vers la branche d'origine et que je supprime notre dossier .git ?

Je pensais que créer des exemples visuels de certaines des commandes Git les plus couramment utilisées et les plus utiles serait un cas d'utilisation parfait ! La plupart des commandes que je décrirai ci-dessous ont des paramètres facultatifs : vous pouvez utiliser ces paramètres pour modifier le comportement de la commande correspondante. Et mon exemple ne couvrira que le comportement par défaut de la commande et n'ajoutera pas (ou n'en ajoutera pas trop) de configuration facultative !

Fusionner

Il est pratique d'avoir plusieurs branches pour isoler les différentes nouvelles modifications les unes des autres et également pour garantir que vous n'apportez pas accidentellement des modifications involontaires au code de production. Modifications de code permissives ou brisées . Mais une fois ces changements approuvés, nous devons les déployer sur notre branche de production !

Une façon d'incorporer des modifications d'une branche à une autre consiste à effectuer une fusion git. Git peut effectuer deux types de fusions : avec avance rapide et sans avance rapide. Vous ne pourrez peut-être pas faire la différence maintenant, mais examinons les différences dans un instant.

Avance rapide (—ff)

La fusion rapide peut être effectuée lorsque la branche actuelle n'a pas de commits supplémentaires par rapport à la branche que nous souhaitons fusionner. Git est paresseux et essaiera d’abord l’option la plus simple : l’avance rapide ! Ce type de fusion ne crée pas de nouveaux commits, mais fusionne les commits de la branche que nous fusionnons directement dans la branche actuelle.

Parfait ! Désormais, toutes les modifications que nous avons apportées sur la branche dev sont fusionnées dans la branche master. Alors, que signifie pas d’avance rapide ?

Pas d'avance rapide (—no-ff)

Si votre branche actuelle n'a aucun commit par rapport à la branche que vous souhaitez fusionner, c'est bien, mais très malheureusement la réalité est rarement comme ça ! Si nous validons des modifications sur la branche actuelle qui ne se trouvent pas dans la branche que nous voulons fusionner, git effectuera une fusion sans avance rapide.

Lors de la fusion sans avance rapide, Git créera un nouveau commit de fusion sur la branche actuellement active. Le commit parent de ce commit pointe vers cette branche active et pointe également vers la branche que nous souhaitons fusionner !

Pas grave, fusion parfaite ! Désormais, toutes les modifications que nous avons apportées sur la branche dev sont fusionnées dans la branche master.

Conflits de fusion

Bien que Git soit assez doué pour décider comment fusionner des branches et comment ajouter des modifications aux fichiers, il ne prend pas toujours cette décision entièrement tout seul. Lorsque les deux branches que nous voulons fusionner ont des modifications différentes sur la même ligne de code dans le même fichier, ou qu'une branche supprime un fichier et que l'autre branche modifie le fichier, Git ne sait pas quoi choisir.

Dans ce cas, Git vous demandera quelle option vous souhaitez conserver ? Supposons que dans les deux branches, nous modifions la première ligne du README.md.

Si nous voulons fusionner dev avec master, il y aura un conflit de fusion : voulez-vous que le titre soit Hello ou Hey ! ?

Lorsque vous essayez de fusionner ces branches, Git vous montrera où se produisent les conflits. Nous pouvons supprimer manuellement les modifications que nous ne souhaitons pas conserver, enregistrer les modifications, ajouter à nouveau le fichier modifié et valider les modifications.

Terminé ! Bien que les conflits de fusion soient souvent ennuyeux, ils ont du sens : Git ne devrait pas avoir à deviner quels changements nous souhaitons conserver.

Rebasing

Nous venons de voir que vous pouvez appliquer des modifications d'une branche à une autre en exécutant git merge. Une autre façon d’incorporer les modifications d’une branche à une autre consiste à effectuer un rebase git.

git rebase copiera les commits de la branche actuelle vers la branche spécifiée.

Parfait, maintenant nous avons tous les changements sur la branche master sur la branche dev.

Il existe une différence majeure entre le rebasage et la fusion : Git n'essaie pas de déterminer quels fichiers conserver ou non. La branche que nous rebasons contient toujours les modifications les plus récentes que nous souhaitons conserver ! De cette façon, nous ne rencontrons aucun conflit de fusion et conservons un historique Git agréable et linéaire.

L'exemple ci-dessus montre le rebasage sur la branche master. Cependant, dans les projets plus importants, vous n’avez généralement pas besoin de le faire. git rebase modifie l'historique du projet lors de la création de nouveaux hachages pour les commits copiés.

Si vous développez une branche de fonctionnalités et que la branche principale a été mise à jour, le rebasage est très utile. Vous pouvez obtenir toutes les mises à jour sur votre branche, ce qui évite les conflits de fusion à l'avenir.

Rebase interactif

Avant d'effectuer un rebase pour les commits, nous pouvons les modifier ! Nous pouvons utiliser le rebasage interactif pour accomplir cette tâche. Le rebasage interactif est utile lorsque vous êtes sur la branche que vous développez actuellement et que vous souhaitez modifier certains commits.

Sur le commit que nous rebasons, nous pouvons effectuer les 6 actions suivantes :

• reword : modifier les informations du commit

• edit : modifier ce commit ; ​​

• squash : fusionner le commit dans le commit précédent ;

• fixup : fusionner le commit dans le commit précédent, sans conserver le message de journal du commit

• exec : à chaque exécution ; la commande que nous voulons rebaser sur le commit ; ​​

• drop : supprime le commit.

Génial ! De cette façon, nous avons un contrôle total sur nos commits. Si vous souhaitez supprimer un commit, supprimez-le simplement.

Si vous souhaitez fusionner plusieurs commits ensemble pour obtenir un historique de commit clair, ce n'est pas un problème !

Le rebase interactif vous donne beaucoup de contrôle lors du rebasage, même sur la branche actuellement active.

Resetting

Cette commande est utilisée lorsque nous ne voulons pas les modifications soumises précédemment. Il s'agit peut-être d'un commit WIP ou peut-être d'un commit qui a introduit un bug, auquel cas vous devez effectuer une réinitialisation de git.

git reset nous permet de ne plus utiliser les fichiers sur le bureau actuel et nous permet de contrôler où HEAD doit pointer.

Réinitialisation logicielle

Une réinitialisation logicielle déplacera HEAD vers le commit spécifié (ou l'index du commit par rapport à HEAD) sans supprimer les modifications ajoutées après ce commit !

Supposons que nous ne voulions pas conserver le commit 9e78i, qui ajoute un fichier style.css, et que nous ne voulions pas non plus conserver le commit 035cc, qui ajoute un fichier index.js. Cependant, nous souhaitons conserver les fichiers style.css et index.js nouvellement ajoutés ! Il s’agit d’un cas d’utilisation parfait pour une réinitialisation logicielle.

Après avoir tapé git status, vous verrez que nous avons toujours accès à toutes les modifications apportées sur les commits précédents. C'est génial, cela signifie que nous pouvons corriger le contenu de ces fichiers et les soumettre à nouveau plus tard !

Réinitialisation matérielle

Parfois, nous ne voulons pas conserver les modifications introduites par un commit spécifique. Contrairement à une réinitialisation logicielle, nous ne devrions plus jamais avoir besoin d’y accéder. Git devrait simplement réinitialiser l'état global directement à l'état avant une validation spécifique : cela inclut même les modifications que vous avez apportées dans le répertoire de travail et sur les fichiers intermédiaires.

Git a ignoré les modifications introduites par 9e78i et 035cc et a réinitialisé l'état à l'état d'ec5be.

Reverting

Une autre façon d'annuler les modifications est d'effectuer git revert. En effectuant une opération de restauration sur un commit spécifique, nous créons un nouveau commit contenant les modifications annulées.

Supposons qu'ec5be ajoute un fichier index.js. Mais ensuite nous avons découvert que nous n'avions plus besoin des changements introduits par ce commit. Ensuite, restaurez la soumission ec5be !

Parfait ! Le commit 9e78i annule les modifications introduites par le commit ec5be . git revert est utile pour annuler un commit spécifique sans modifier l'historique de la branche.

Cherry-picking

Lorsqu'une branche spécifique contient un commit dont notre branche active a besoin, nous effectuons une sélection sur ce commit ! Lors de la sélection d'un commit, nous créons un nouveau commit sur la branche active qui contient les modifications introduites par le commit sélectionné.

Supposons que le commit 76d12 sur la branche dev ajoute une modification au fichier index.js et que nous souhaitons l'intégrer dans la branche master. Nous ne voulons pas de la branche de développement entière, juste de ce commit !

Maintenant, la branche master contient les modifications introduites par 76d12.

Récupération

Si vous disposez d'une branche Git distante, telle qu'une branche sur GitHub, vous pouvez utiliser la récupération lorsque la branche distante contient des commits que la branche actuelle n'a pas. Comme lorsqu'une autre branche est fusionnée ou que votre collègue propose une solution rapide.

En exécutant git fetch sur cette branche distante, nous pouvons obtenir ces modifications localement. Cela n'affecte en rien votre branche locale : fetch télécharge simplement les nouvelles données.

Maintenant, nous pouvons voir toutes les modifications depuis le dernier push. Les nouvelles données sont désormais locales et nous pouvons décider quoi en faire.

Pulling

Bien que git fetch puisse être utilisé pour obtenir les informations distantes d'une branche, nous pouvons également effectuer git pull. git pull est en fait deux commandes combinées en une seule : git fetch et git merge. Lorsque nous extrayons les modifications de la source, nous récupérons d'abord toutes les données comme git fetch, puis les dernières modifications sont automatiquement fusionnées dans la branche locale.

Super, nous sommes désormais parfaitement synchronisés avec la branche distante et disposons également de toutes les dernières modifications !

Reflog

Tout le monde fait des erreurs, mais c'est bien de faire des erreurs ! Parfois, vous pouvez avoir l'impression d'avoir complètement corrompu votre dépôt git, ce qui vous donne envie de le supprimer entièrement.

git reflog est une commande très utile qui permet d'afficher le journal de toutes les actions effectuées. Cela inclut les fusions, les réinitialisations, les rétablissements, essentiellement toutes les modifications que vous apportez à votre branche.

Si vous faites une erreur, vous pouvez facilement la refaire en réinitialisant HEAD en fonction des informations fournies par le reflog !

Supposons que nous n’ayons pas réellement besoin de fusionner la branche d’origine. Lorsque nous exécutons la commande git reflog, nous pouvons voir que le statut de ce dépôt était à HEAD@{1} avant la fusion. Ensuite, nous effectuons une réinitialisation de git et redirigeons HEAD vers l'emplacement de HEAD@{1}.

On voit que la dernière action a été poussée au reflog.

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!