Tutoriel Git Bisect
La commande GIT BISECT fournit un moyen d'accélérer le processus de détection de bogue. Il vous permet de déterminer le problème plus rapidement. Avec Git Bisect, vous pouvez définir une gamme de validations que vous soupçonnez avoir le code problématique, puis utiliser des méthodes d'élimination binaire pour trouver le début du problème. Trouver des bugs deviennent plus rapides et plus faciles.
Préparez un exemple et exécutons quelques cas de test pour voir comment cela fonctionne.
Exemple de configuration
Dans notre exemple, nous créerons un test.fichier txt et ajoutez une nouvelle ligne au fichier avec chaque validation. Après 16 commits, l'état final du fichier ressemblera à ceci:
Voici mon bon code 1
Voici mon bon code 2
Voici mon bon code 3
Voici mon bon code 4
Voici mon bon code 5
Voici mon bon code 6
Voici mon bon code 7
Voici mon bon code 8
Voici mon mauvais code 1 <-- BUG INTRODUCED HERE
Voici mon mauvais code 2
Voici mon mauvais code 3
Voici mon mauvais code 4
Voici mon mauvais code 5
Voici mon mauvais code 6
Voici mon mauvais code 7
Voici mon mauvais code 8
Voici mon mauvais code 9
Dans l'exemple ci-dessus, le bogue est entré dans le code après 8 commits. Nous avons continué à développer le code même après avoir introduit le bogue.
Vous pouvez créer un dossier appelé my_bisect_test et utiliser les commandes suivantes à l'intérieur du dossier pour créer l'exemple de situation:
git init
Echo "Voici mon bon code 1"> Test.SMS
git add -a && git commit -m "mon commit 1"
Echo "Voici mon bon code 2" >> Test.SMS
git add -a && git commit -m "mon engagement 2 (v1.0.0) "
Echo "Voici mon bon code 3" >> Test.SMS
git add -a && git commit -m "mon engagement 3"
Echo "Voici mon bon code 4" >> Test.SMS
git add -a && git commit -m "mon engagement 4"
Echo "Voici mon bon code 5" >> Test.SMS
git add -a && git commit -m "mon engagement 5 (v1.0.1)"
Echo "Voici mon bon code 6" >> Test.SMS
git add -a && git commit -m "mon engagement 6"
Echo "Voici mon bon code 7" >> Test.SMS
git add -a && git commit -m "mon engagement 7 (v1.0.2) "
Echo "Voici mon bon code 8" >> Test.SMS
git add -a && git commit -m "mon engagement 8"
Echo "Voici mon mauvais code 1"> Test.SMS
git add -a && git commit -m "mon engagement 9"
Echo "Voici mon mauvais code 2" >> Test.SMS
git add -a && git commit -m "mon engagement 10"
Echo "Voici mon mauvais code 3" >> Test.SMS
git add -a && git commit -m "mon engagement 11"
Echo "Voici mon mauvais code 4" >> Test.SMS
git add -a && git commit -m "mon engagement 12 (v1.0.3) "
Echo "Voici mon mauvais code 5" >> Test.SMS
git add -a && git commit -m "mon engagement 13"
Echo "Voici mon mauvais code 6" >> Test.SMS
git add -a && git commit -m "mon engagement 14"
Echo "Voici mon mauvais code 7" >> Test.SMS
git add -a && git commit -m "mon engagement 15 (v1.0.4) "
Echo "Voici mon mauvais code 8" >> Test.SMS
git add -a && git commit -m "mon engagement 16"
Vérification de l'historique
Si vous regardez l'histoire des commits, vous voyez ce qui suit:
$ git journal
Commit 3023B63EB42C7FADC93C2DD18B532A44A0A6888A
Auteur: Zak H
Date: dimanche 31 décembre 23:07:27 2017 -0800
Mon engagement 17
Commissez 10ef0286d6459cd5dea5038a54edf36fc9bfe4c3
Auteur: Zak H
Date: dim 31 décembre 23:07:25 2017 -0800
Mon engagement 16
Commit 598D4C4ACAEB14CDA0552B6A92AA975C436D337A
Auteur: Zak H
Date: dimanche 31 décembre 23:07:23 2017 -0800
Mon engagement 15 (v1.0.4)
Commit B9678B75AC93D532EED22EC2C6617E5A9D70FE7B
Auteur: Zak H
Date: dimanche 31 décembre 23:07:21 2017 -0800
Mon engagement 14
Commit EB3F2F7B0EBEDB732ECB5F18BEE786CD3CBBB521
Auteur: Zak H
Date: dimanche 31 décembre 23:07:19 2017 -0800
Mon engagement 13
Commit 3CB475A4693B704793946A878007B40A1FF67CD1
Auteur: Zak H
Date: dimanche 31 décembre 23:07:17 2017 -0800
Mon engagement 12 (V1.0.3)
Commit 0419A38D898E28C4DB69064478ECAB7736700310
Auteur: Zak H
Date: dimanche 31 décembre 23:07:15 2017 -0800
Mon engagement 11
Commissez 15BC59201AC1F16AEAA233EB485E81FAD48FE35F
Auteur: Zak H
Date: dimanche 31 décembre 23:07:13 2017 -0800
Mon engagement 10
Commissez A33E366AD9F6004A61A468B48B36E0C0C802A815
Auteur: Zak H
Date: dimanche 31 décembre 23:07:11 2017 -0800
Mon engagement 9
Commit EAD472D61F516067983D7E29D548FC856D6E6868
Auteur: Zak H
Date: dimanche 31 décembre 23:07:09 2017 -0800
Mon engagement 8
Commit 8995D427668768AF88266F1E78213506586B0157
Auteur: Zak H
Date: dimanche 31 décembre 23:07:07 2017 -0800
Mon engagement 7 (V1.0.2)
engager be3b341559752e733c6392a16d6e87b5af52e701
Auteur: Zak H
Date: dimanche 31 décembre 23:07:05 2017 -0800
Mon engagement 6
Commit C54B58BA8F73FB464222F30C90AA72F60B99BDA9
Auteur: Zak H
Date: dimanche 31 décembre 23:07:03 2017 -0800
Mon engagement 5 (v1.0.1)
Commit 264267111643EF5014E92E23FD2F306A10E93A64
Auteur: Zak H
Date: dimanche 31 décembre 23:07:01 2017 -0800
Mon engagement 4
Commit CFD7127CD35F3C1A55EB7C6608ECAB75BE30B208
Auteur: Zak H
Date: dimanche 31 décembre 23:06:59 2017 -0800
Mon engagement 3
Commit 3F90793B631DDCE7BE509C36B0244606A2C0E8ADAD
Auteur: Zak H
Date: dimanche 31 décembre 23:06:57 2017 -0800
Mon engagement 2 (v1.0.0)
Commit CC163ADB8A3F7B7B52411DB2B3D8BAB9B7FB191E
Auteur: Zak H
Date: dimanche 31 décembre 23:06:55 2017 -0800
Mon engagement 1
Même avec seulement une poignée de commits, vous pouvez voir qu'il est difficile d'identifier l'engagement qui a commencé le bogue.
Trouver le bug
Utilisons Git Log -online pour voir une version plus nettoyée de l'historique de la validation.
$ Git Log --Oneline
3023b63 mon engagement 17
10ef028 mon engagement 16
598d4c4 mon engagement 15 (v1.0.4)
b9678b7 mon validation 14
eb3f2f7 mon validation 13
3CB475A Mon validation 12 (V1.0.3)
0419a38 mon validation 11
15BC592 Mon engagement 10
a33e366 mon validation 9
eAd472d mon comist 8
8995d42 Mon engagement 7 (V1.0.2)
be3b341 mon validation 6
C54B58B mon validation 5 (V1.0.1)
2642671 Mon engagement 4
cfd7127 mon validation 3
3F90793 Mon validation 2 (V1.0.0)
CC163Ad mon validation 1
Nous voulons trouver la situation où la ligne «Voici mon mauvais code 1 <- BUG INTRODUCED HERE” entered the picture.
Situation 1
Supposons que nous nous souvenions que notre code était bon jusqu'à V1.0.2 Et nous voulons vérifier à partir de ce moment jusqu'au dernier engagement. Nous commençons d'abord la commande BISECT:
$ git bissect start
Nous fournissons la bonne limite et la mauvaise limite (aucun hachage signifie le dernier code):
$ git bissect bon 8995d42
$ git bissect bad
Sortir:
Bisecting: 4 révisions laissées à tester après cela (environ 2 étapes)
[3CB475A4693B704793946A878007B40A1FF67CD1] Mon engagement 12 (V1.0.3)
La commande BISECT a trouvé le point central de notre plage définie et a automatiquement déplacé le code pour commettre 12. Nous pouvons tester notre code maintenant. Dans notre cas, nous allons sortir le contenu du test.SMS:
$ test de chat.SMS
Sortir:
Voici mon bon code 1
Voici mon bon code 2
Voici mon bon code 3
Voici mon bon code 4
Voici mon bon code 5
Voici mon bon code 6
Voici mon bon code 7
Voici mon bon code 8
Voici mon mauvais code 1 <-- BUG INTRODUCED HERE
Voici mon mauvais code 2
Voici mon mauvais code 3
Voici mon mauvais code 4
Nous voyons que l'état du test.TXT est à l'état post-bug. C'est donc en mauvais état. Nous avons donc informé la commande BISECT:
$ git bissect bad
Sortir:
Bisecting: 2 révisions laissées à tester après cela (environ 1 étape)
[A33E366AD9F6004A61A468B48B36E0C0C802A815] Mon engagement 9
Il déplace notre code pour commettre 9. Nous testons à nouveau:
$ test de chat.SMS
Sortir:
Voici mon bon code 1
Voici mon bon code 2
Voici mon bon code 3
Voici mon bon code 4
Voici mon bon code 5
Voici mon bon code 6
Voici mon bon code 7
Voici mon bon code 8
Voici mon mauvais code 1 <-- BUG INTRODUCED HERE
Nous voyons que nous avons trouvé le point de départ du bug. Le commit «A33E366 My Commit 9» est le coupable.
Enfin, nous avons tout remis à la normale par:
$ git bissect réinitialiser
Sortir:
La position de tête précédente était A33E366… mon engagement 9
Changé de succursale «maître»
Situation 2
Dans le même exemple, essayons une situation où un autre développeur commence par la prémisse que le bug a été introduit entre V1.0.0 et v1.0.3. Nous pouvons recommencer le processus:
$ git bissect start
$ git bissect bon 3f90793
$ git bissect bad 3cb475a
Sortir:
Bisecting: 4 révisions laissées à tester après cela (environ 2 étapes)
[8995D427668768AF88266F1E78213506586B0157] Mon validation 7 (V1.0.2)
BISECT a déplacé notre code pour commettre 7 ou V1.0.2. Exécutons notre test:
$ test de chat.SMS
Sortir:
Voici mon bon code 1
Voici mon bon code 2
Voici mon bon code 3
Voici mon bon code 4
Voici mon bon code 5
Voici mon bon code 6
Voici mon bon code 7
Nous ne voyons aucun mauvais code. Alors, faites savoir à Git BISECT:
$ git bissect bon
Sortir:
Bisecting: 2 révisions laissées à tester après cela (environ 1 étape)
[A33E366AD9F6004A61A468B48B36E0C0C802A815] Mon engagement 9
Il nous a poussés à commettre 9. Nous testons à nouveau:
$ test de chat.SMS
Sortir:
Voici mon bon code 1
Voici mon bon code 2
Voici mon bon code 3
Voici mon bon code 4
Voici mon bon code 5
Voici mon bon code 6
Voici mon bon code 7
Voici mon bon code 8
Voici mon mauvais code 1 <-- BUG INTRODUCED HERE
Nous avons de nouveau trouvé le commit qui a introduit le bogue. C'était le commit «A33E366 My Commit 9». Même si nous avons commencé avec la portée de suspicion différente, nous avons trouvé le même bug en quelques étapes.
Réinitialisons:
$ git bissect réinitialiser
Sortir:
La position de tête précédente était A33E366… mon engagement 9
Changé de succursale «maître»
Conclusion
Comme vous pouvez le voir à partir de l'exemple, Git Bisect nous permet de déterminer un problème plus rapidement. C'est un excellent outil pour améliorer votre productivité. Au lieu de traverser toute l'histoire des commits, vous pouvez adopter une approche plus systématique pour déboguer.
Une étude plus approfondie:
https: // git-scm.com / docs / git-bistect
https: // git-scm.com / book / en / v2 / git-tools-debugging-with-git