Si vous êtes dans une situation similaire et que vous ne savez pas quel changement cassé le code ou OMS sur de nombreux contributeurs possède cette bug / fonctionnalité , alors git bisect est votre moyen de sortir. Ainsi, dans cet article sur git bisect, vous apprendrez comment le ‘git bisect«Commande vient à sauvetage en détectant le premier mauvais commit qui introduit le bogue en utilisant l'algorithme de recherche binaire.
Les sujets traités dans cet article sont les suivants:
Pourquoi utiliser git bisect?
Il ne fait aucun doute que vous avez tendance à créer un certain nombre de commits pour chaque changement mineur . Dans un tel scénario, le débogage du code devient une tâche fastidieuse, car vous devez remonter manuellement dans le temps à chaque révision de l'instantané du projet afin de tester le code de travail et détecter le bogue. Maintenant, cela devient encore plus complexe lorsque vous avez le travail d’autres à inspecter sans point de départ, demander également à chacun de nettoyer ses propres erreurs ne semble pas non plus très faisable.
En cours de route, vous pouvez également créer et supprimer un certain nombre de branches «fonctionnalité» (ou correctif) dans le processus et finir par perdre du temps et des efforts tout en vous écartant de la ligne principale de développement.
Ainsi, pour éviter de tels scénarios, vous pouvez utiliser legit bisectcommande pour trouver la mauvaise révision du projet (ou snapshot) et éventuellement la corriger avec legit revertcommander.
Comment fonctionne la recherche «git bisect»?
Cette commande bissecte (divise) votre histoire entre les bien et le mauvais commettre gamme. Il pointe votre actuel projet Etat à un milieu de gamme commettre instantané. La commande git bisect passe ensuite par chaque identifiant de commit entre cette plage tandis que pause à chaque instantané pour vous permettre de tester le code . Si le bogue existe, vous déclarez le commit comme mauvais, sinon comme bien à moins que la recherche ne se termine.
Syntaxe
git bisect
Pour mieux comprendre git bisect, créons un projet qui développe le code d'une application de navigation simple à utiliser dans une voiture.
Configuration initiale du projet
Pour créer un projet qui développe le code d'une application de navigation simple à utiliser dans une voiture, vous pouvez suivre les étapes ci-dessous:
Étape 1: Créez un nouveau répertoire dans votre dossier $ HOME:
cd $ HOME mkdir my_nav_app
Étape 2: Accédez au nouveau répertoire:
cd $ my_nav_app
Étape 3: Cloner pour télécharger le projet depuis ma page GitHub:
java qu'est-ce qu'un vecteur
git clone https://github.com/divyabhushan/my_nav_app.git
Maintenant, comprenons les répertoires du projet et la disposition des fichiers, tels qu'ils sont imprimés par la commande:ls -lTR
Ensuite, voyons le journal d'historique du projet pour voir les commits que j'ai faits afin de générer ce code-
Par exemple, une simple commande git log imprime l'historique en détail, cependant, j'aime bien formater et personnaliser l'historique. Ainsi, laissez-nous définir un nom d'alias - 'hist' en utilisant le git alias commande comme indiqué ci-dessous:
git alias.hist 'log --pretty = format:'% C (jaune)% h% Creset% ad | % C (vert)% s% Creset% C (rouge)% d% Creset% C (bleu) [% an] '--graph --decorate --date = short'
Maintenant, je vais exécuter cette fonction de correction de bogue dans une branche séparée, afin de ne pas interférer avec le développement principal sur la branche «master». Pour ce faire, suivez l'ensemble de commandes ci-dessous:
- Créez une branche 'dev': [maître] $
git branch dev - Passer à la branche «dev»: $
git checkout dev - Répertoriez les journaux d'historique: [dev] $
aller hist[Remarque: commande ‘alias’ utilisée ici]
De plus, j'ai mis en évidence le dernier bon commit connu que je connais dans lequel mon script fonctionnait bien avec les résultats attendus du cas de test, cet instantané de commit est étiqueté comme v1.0.
Alors, maintenant que nous connaissons notre dernier bon commit, allons de l'avant dans cet article sur «git bisect» et testons l'application.
Tester l'application
Exécutez le script en tant que - $./scripts/myApplication.sh[premier test]
De toute évidence, l'état actuel de mon projet est Erreur , et je ne sais pas quel changement j'ai fait dans quel commit qui a introduit ce changement. Alors, dans cet article sur git bisect, voyons comment identifier le mauvais commit.
Identification du mauvais commit
Pour commencer à inspecter le mauvais commit, vous devez suivre les étapes ci-dessous:
- Démarrez la commande bisect :
git bisect start - Mentionnez le mauvais identifiant de validation:
git bisect mauvaise HEADougit bisect c5b3ca8 - Mentionnez le dernier identifiant de bon commit connu:
git bisect good v1.0ougit bisect 93859d8
Cela divise en deux la plage d'historique de commit à peu près à mi-chemin entre les bons et les mauvais commits qui nous amènent à l'ID de commit: f61a7e8
Par conséquent, la commande a extrait la version du projet telle qu'elle était dans cet ID de validation. Maintenant, allons-y et testons à nouveau notre application.
Commande pour exécuter l'application : $./scripts/myApplication.sh[test deuxième fois]
Depuis l'application passé dans ce commit, ce commit n’est certainement pas le mauvais commit. Donc, ensuite, vous devez informer la même chose à la commande bisect que - $git bisect bien
Maintenant, cela réduira encore le résultat de la recherche dans la première moitié de la plage, comme indiqué -
Testez à nouveau votre application - Commande: $./scripts/myApplication.sh[test troisième fois]
Donc, comme nous voyons une erreur comme ci-dessus, il s'agit d'un mauvais commit.
Faites savoir à la commande bisect, exécutez $git bisect mauvais
Cela réduit davantage la recherche et vous amène à la dernière révision centrale entourée de bleu: a6ac769
Donc, je teste mon application une dernière fois en utilisant la même commande: $./scripts/myApplication.sh[test quatrième fois]
Maintenant, comme l'application a de nouveau échoué, il s'agit toujours d'un mauvais commit. Alors, exécutons la commande suivante:
Exécutez la commande: git bisect mauvais
Mauvais commit trouvé
Ceci conclut le seul dernier commit restant qui est mauvais-
Vous savez donc que c'est là que le code a éclaté. Et ensuite?
Comprendre quel fichier avait le bogue
Dans ce cas, la sortie vous donne des informations minimales sur le identifiant de validation , nom de l'auteur , et le date de création avec le message de validation et le chemin qui a été modifié.
Si vous souhaitez déboguer davantage, vous devez lis la objet d'ID de validation .
Commander: git show a6ac76994b3f6c7519204f910fc787b7928cf8ef
Cela lira l'objet de validation et imprimera le message du journal et la différence textuelle.
Vous pouvez aussi bien utiliser la commande «git blame» pour analyser comment et dans quel commit chaque ligne a été modifiée par quel auteur, exécutez la commande comme:git blame code / develop_nav.sh
php parse string to array
Arrêtez la recherche
Pour arrêter la recherche, utilisez la commande suivante:
Commander: git bisect reset
Ainsi, le processus de bissection est arrêté et vous êtes de retour sur la branche à partir de laquelle vous avez commencé la recherche. Maintenant, l'étape suivante consiste à corriger ou déboguer le code.
Comment réparer / déboguer le code?
Eh bien, il existe quelques solutions de contournement que vous pouvez faire pour corriger l'état actuel du projet maintenant que vous avez identifié le commit qui a provoqué le bogue en premier lieu.
Cependant, si vous modifiez un commit sur un référentiel partagé il vaut mieux revenir le changement à l’aide du « git revert «Commande.
Tâche: Annuler les modifications apportées par le mauvais commit mentionné
Commander: git revert a6ac769
En conséquence, l'annulation des modifications apportées par ce commit a fait 2 choses:
- Il a supprimé les 3 dernières lignes ajoutées (indiquées en vert) et ajouté la ligne supprimée (indiquée en rouge). (revers de a6ac769)
- Création d'un commit supplémentaire avec les informations du message de retour
'La commande Revert facilite également le suivi de la modification que vous avez annulée depuis la validation d'origine'
Utilisez le 'montrer' commande à nouveau pour lire l'identifiant de l'objet, comme si-
Commander: git show 801f029
Maintenant, allez de l'avant et testez l'application. Il s'exécutera correctement.
Commander: $./scripts/myApplication.sh
En revanche, si vous souhaitez supprimer le mauvais commit de l'historique:
Vous pouvez utiliser le '
git reset'Commande avec le'--dur»(Bien que non recommandée dans un référentiel partagé).Découvrez une version antérieure d’un seul fichier à l’aide de l’option ‘
git checkout'Commande avec le'-«Option.
Il convient de noter que cela n'apportera des modifications qu'à votre référentiel local jusqu'à ce que vous les transmettiez à un référentiel distant. Étant donné que certaines modifications créent un nouvel identifiant d'objet de validation comme dans notre cas ci-dessus, dans de tels cas, une poussée normale vers le référentiel distant est rejetée car l'historique aurait divergé. Vous devez utiliser le ' git push 'Commande avec le'--Obliger«Option.
Mettre à jour la branche 'maître'
Alors que j'ai corrigé le bogue sur ma branche «dev», je peux maintenant fusionner ce changement avec la branche «master» également -
- passer en «maître», commande:
git checkout master - extraire les mises à jour récentes de «origin / master» à «master», commande:
git pull origin - fusionner les modifications 'dev', commande:
git merge géant
Cependant, votre fusion peut générer des conflits s'il y a plus de validations du référentiel distant. Résolvez les conflits et poursuivez la fusion.
Enfin, poussez uniquement la branche stable «master» commits vers le référentiel distant pendant que vous effectuez votre sale boulot (bogue, fonctionnalités, améliorations) uniquement sur les branches de fonctionnalités telles que «dev» dans cet exemple.
De plus, il vaut mieux adopter une logique stratégie de branchement pour rationaliser et sécuriser votre processus de workflow git.
Pour résumer, «git bisect» est une commande pratique et utile qui identifier la identifiant de validation cette introduit à faute dans votre code de fonctionnement à l'aide d'un recherche binaire par logiquement partage le commit enregistre à mi-chemin entre le bien et mauvais commettre gamme . Pour conclure, vous avez appris à détecter le commit défectueux et revenir le changement apporté par celui-ci.
De plus, aux sous-commandes «bon» et «mauvais», vous pouvez également utiliser des termes tels que nouveau et ancien pour décrire l’état de la révision. Vous pouvez exécuter la commande plusieurs fois en passant différentes sous-commandes et ID de révision / validation pour identifier différents ID de validation (she-1). Sinon, un script de test automatisé peut également être exécuté pour créer le code défectueux à l'aide de cette commande. Recherchez également une description détaillée de cette commande en exécutantgit bisect - aidesur le terminal. Donc, les gens avec cela, nous arrivons à la fin de cet article sur Git Bisect.
L'intention de DevOps est de créer des logiciels de meilleure qualité plus rapidement et avec plus de fiabilité tout en favorisant une meilleure communication et collaboration entre les équipes. Si vous êtes intrigué par cet article, c diable le par Edureka, une entreprise d'apprentissage en ligne de confiance avec un réseau de plus de 250 000 apprenants satisfaits répartis dans le monde entier. Le cours de formation à la certification Edureka DevOps aide les apprenants à comprendre ce qu'est DevOps et à acquérir une expertise dans divers processus et outils DevOps tels que Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack et GIT pour l'automatisation de plusieurs étapes dans SDLC.
Vous avez une question pour nous? Veuillez le mentionner dans la section commentaires de l'article «Git Bisect» et nous vous répondrons dans les plus brefs délais.