git-bisect - En ligne dans le Cloud

PROGRAMME:

Nom

git-bisect - Utilisez la recherche binaire pour trouver le commit qui a introduit un bogue

SYNOPSIS

jet couper en deux

DESCRIPTION

La commande prend différentes sous-commandes et différentes options selon la sous-commande :

git bisect start [--term-{old,good}= --term-{nouveau,mauvais}= ]
[--pas de caisse] [ [ ...]] [--] [ ...]
git bisect (mauvais|nouveau) [ ]
git bisect (bon|vieux) [ ...]
termes git bisect [--term-good | --terme-mauvais]
git bisect sauter [( | )...]
git bisect reset [ ]
git bisect visualiser
git bisect replay
journal bisect de git
git bisect run ...
aide de git bisect

Cette commande utilise un algorithme de recherche binaire pour trouver quel commit dans l'historique de votre projet
introduit un bug. Vous l'utilisez en lui indiquant d'abord un "mauvais" commit connu pour contenir
le bogue, et un "bon" commit connu avant l'introduction du bogue. Alors git
bisect sélectionne un commit entre ces deux points de terminaison et vous demande si le commit sélectionné
est « bon » ou « mauvais ». Il continue à réduire la plage jusqu'à ce qu'il trouve le commit exact
qui a introduit le changement.

En fait, git bisect peut être utilisé pour trouver le commit qui a changé tout propriété de votre
projet; par exemple, le commit qui a corrigé un bogue, ou le commit qui a causé un benchmark
performances à améliorer. Pour soutenir cet usage plus général, les termes « ancien » et « nouveau » peuvent
être utilisé à la place de « bon » et « mauvais », ou vous pouvez choisir vos propres termes. Voir section
"Conditions alternatives" ci-dessous pour plus d'informations.

Basic couper en deux commandes: début, mal, Bien
Par exemple, supposons que vous essayez de trouver le commit qui a cassé une fonctionnalité qui était
connu pour fonctionner dans la version v2.6.13-rc2 de votre projet. Vous démarrez une session bisect en tant que
suit:

$ git bissect start
$ git bisect bad # La version actuelle est mauvaise
$ git bisect good v2.6.13-rc2 # v2.6.13-rc2 est connu pour être bon

Une fois que vous avez spécifié au moins un mauvais et un bon commit, git bisect sélectionne un commit
au milieu de cette plage d'historique, le vérifie et génère quelque chose de similaire à
ce qui suit:

Bissection : 675 révisions restantes à tester après cela (environ 10 étapes)

Vous devez maintenant compiler la version extraite et la tester. Si cette version fonctionne
correctement, tapez

$ git bissecte bien

Si cette version est cassée, tapez

$ git bisect mauvais

Ensuite, git bisect répondra avec quelque chose comme

Bissection : 337 révisions restantes à tester après cela (environ 9 étapes)

Continuez à répéter le processus: compilez l'arbre, testez-le, et selon qu'il est bon
or bad run git bisect good ou git bisect bad pour demander le prochain commit qui a besoin
test.

Finalement, il n'y aura plus de révisions à inspecter et la commande s'imprimera
une description du premier mauvais commit. La référence refs/bisect/bad sera laissée pointée
à ce commit.

Couper en deux réinitialiser
Après une session de bissection, pour nettoyer l'état de bissection et revenir à la tête d'origine,
lancez la commande suivante :

$ git bisect réinitialiser

Par défaut, cela renverra votre arbre au commit qui a été extrait avant git
début de bissectrice. (Un nouveau démarrage git bisect fera également cela, car il nettoie l'ancienne bissection
Etat.)

Avec un argument facultatif, vous pouvez revenir à un autre commit à la place :

$ git bisect reset

Par exemple, git bisect reset bisect/bad vérifiera la première mauvaise révision, tandis que git
bisect reset HEAD vous laissera sur le commit de bissection actuel et évitera de basculer
s'engage du tout.

Autre conditions
Parfois, vous ne cherchez pas le commit qui a introduit une casse, mais plutôt un
commit qui a provoqué un changement entre un autre état "ancien" et un état "nouveau". Par exemple,
vous recherchez peut-être le commit qui a introduit un correctif particulier. Ou vous pourriez être
à la recherche du premier commit dans lequel les noms de fichiers du code source ont finalement tous été convertis
à la norme de nommage de votre entreprise. Ou peu importe.

Dans de tels cas, il peut être très déroutant d'utiliser les termes « bon » et « mauvais » pour désigner « le
état avant le changement" et "l'état après le changement". Ainsi, à la place, vous pouvez utiliser le
termes « ancien » et « nouveau », respectivement, à la place de « bon » et « mauvais ». (Mais notez que vous
ne peut pas mélanger « bon » et « mauvais » avec « ancien » et « nouveau » en une seule session.)

Dans cette utilisation plus générale, vous fournissez à git bisect un "nouveau" commit possédant une propriété
et un "ancien" commit qui n'a pas cette propriété. Chaque fois que git bisect vérifie un
commit, vous testez si ce commit a la propriété. Si c'est le cas, marquez le commit comme "nouveau" ;
sinon, marquez-le comme "ancien". Lorsque la bissection est terminée, git bisect rapportera quel
commit a introduit la propriété.

Pour utiliser "old" et "new" au lieu de "good" et bad, vous devez exécuter git bisect start sans
commits comme argument, puis exécutez les commandes suivantes pour ajouter les commits :

git bissecter vieux [ ]

pour indiquer qu'un commit était antérieur à la modification recherchée, ou

git bisect nouveau [ ...]

pour indiquer que c'était après.

Pour obtenir un rappel des termes actuellement utilisés, utilisez

termes git bisect

Vous pouvez obtenir uniquement l'ancien (respectivement nouveau) terme avec git bisect term --term-old ou git
terme bissectrice --term-good.

Si vous souhaitez utiliser vos propres termes au lieu de "mauvais"/"bon" ou "nouveau"/"ancien", vous pouvez
choisissez les noms que vous aimez (à l'exception des sous-commandes bisect existantes comme reset, start, ...) en
commencer la bissection en utilisant

git bisect start --term-old --term-nouveau

Par exemple, si vous recherchez un commit qui a introduit une régression des performances, vous
Pourrait utiliser

git bisect start --term-old fast --term-new lent

Ou si vous recherchez le commit qui a corrigé un bogue, vous pouvez utiliser

git bisect start --term-new fixed --term-old cassé

Ensuite, utilisez git bisect et git bisect au lieu de git bisect good et
git bisect mauvais pour marquer les commits.

Couper en deux visualiser
Pour voir les suspects restants actuellement dans connard, exécutez la commande suivante pendant le
processus de bissection :

$ git bisect visualiser

view peut également être utilisé comme synonyme de visualize.

Si la DISPLAY la variable d'environnement n'est pas définie, jet enregistrer est utilisé à la place. Vous pouvez également donner
les options de ligne de commande telles que -p et --stat.

$ git vue en deux --stat

Couper en deux enregistrer et couper en deux rejouer
Après avoir marqué les révisions comme bonnes ou mauvaises, exécutez la commande suivante pour montrer ce qui a
été fait jusqu'à présent :

$ git diviser le journal

Si vous découvrez que vous avez fait une erreur en spécifiant le statut d'une révision, vous pouvez
enregistrez le résultat de cette commande dans un fichier, modifiez-le pour supprimer les entrées incorrectes et
puis exécutez les commandes suivantes pour revenir à un état corrigé :

$ git bisect réinitialiser
$ git bisect rejoue ce fichier

Éviter vers les tests a commettre
Si, au milieu d'une séance bissectrice, vous savez que la révision suggérée n'est pas une bonne
un à tester (par exemple il échoue à construire et vous savez que l'échec n'a rien
à voir avec le bogue que vous poursuivez), vous pouvez sélectionner manuellement un commit à proximité et tester cela
un à la place.

Par exemple :

$ git bisect good/bad # le tour précédent était bon ou mauvais.
Bissection : 337 révisions restantes à tester après cela (environ 9 étapes)
$ git bisect visualize # oops, ce n'est pas intéressant.
$ git reset --hard HEAD~3 # essayez 3 révisions avant quoi
# a été suggéré

Puis compilez et testez la révision choisie, puis marquez la révision comme bonne ou mauvaise
de la manière habituelle.

Couper en deux sauter
Au lieu de choisir vous-même un commit à proximité, vous pouvez demander à Git de le faire pour vous en
en émettant la commande :

$ git bisect skip # La version actuelle ne peut pas être testée

Cependant, si vous sautez un commit adjacent à celui que vous recherchez, Git ne pourra pas
pour dire exactement lequel de ces commits était le premier mauvais.

Vous pouvez également ignorer une plage de commits, au lieu d'un seul commit, en utilisant la notation par plage.
Par exemple :

$ git bisect sauter v2.5..v2.6

Cela indique au processus bisect qu'aucun commit après la v2.5, jusqu'à et y compris la v2.6, ne devrait
être testé.

Notez que si vous souhaitez également ignorer le premier commit de la plage, vous devez émettre le
commander:

$ git bisect sauter v2.5 v2.5..v2.6

Cela indique au processus bisect que les commits entre v2.5 et v2.6 (inclus) doivent être
sauté.

Coupe down bissection by donnant plus paramètres à couper en deux Commencer
Vous pouvez encore réduire le nombre d'essais, si vous savez quelle partie de l'arbre est
impliqué dans le problème que vous traquez, en spécifiant des paramètres de chemin lors de l'émission
la commande de démarrage bisect :

$ git bisect start -- arch/i386 include/asm-i386

Si vous connaissez à l'avance plus d'un bon commit, vous pouvez réduire l'espace de bissectrice en
en spécifiant tous les bons commits immédiatement après le mauvais commit lors de l'émission du
commande de démarrage bisect :

$ git bisect start v2.6.20-rc6 v2.6.20-rc4 v2.6.20-rc1 --
# v2.6.20-rc6 est mauvais
# v2.6.20-rc4 et v2.6.20-rc1 sont bons

Couper en deux courir
Si vous avez un script qui peut dire si le code source actuel est bon ou mauvais, vous pouvez
bisect en lançant la commande :

$ git bisect exécute les arguments my_script

Notez que le script (my_script dans l'exemple ci-dessus) doit se terminer avec le code 0 si le
le code source actuel est bon/ancien, et sort avec un code entre 1 et 127 (inclus),
sauf 125, si le code source actuel est mauvais/nouveau.

Tout autre code de sortie annulera le processus bisect. Il est à noter qu'un programme qui
se termine via exit(-1) laisse $? = 255, (voir le sortie(3) page de manuel), car la valeur est
haché avec & 0377.

Le code de sortie spécial 125 doit être utilisé lorsque le code source actuel ne peut pas être testé. Si
le script se termine avec ce code, la révision en cours sera ignorée (voir git bisect skip
dessus). 125 a été choisi comme la valeur sensée la plus élevée à utiliser à cette fin, car 126
et 127 sont utilisés par les shells POSIX pour signaler un état d'erreur spécifique (127 est pour la commande pas
trouvé, 126 est pour la commande trouvée mais pas exécutable - ces détails n'ont pas d'importance, car ils
sont des erreurs normales dans le script, en ce qui concerne l'exécution bisect).

Vous pouvez souvent constater que lors d'une session bisect vous souhaitez avoir des modifications temporaires
(par exemple s/#define DEBUG 0/#define DEBUG 1/ dans un fichier d'en-tête, ou "révision qui n'a pas
ce commit a besoin de ce correctif appliqué pour contourner un autre problème que cette bissection n'est pas
intéressé par") appliqué à la révision testée.

Pour faire face à une telle situation, après l'intériorité jet couper en deux trouve la prochaine révision à tester,
le script peut appliquer le correctif avant la compilation, exécuter le test réel et décider ensuite
si la révision (éventuellement avec le correctif nécessaire) a réussi le test, puis rembobiner l'arborescence
à l'état vierge. Enfin, le script doit se terminer avec le statut du test réel pour
laissez la boucle de commande git bisect run déterminer le résultat final de la session bisect.

OPTIONS

--pas de paiement
Ne retirez pas le nouvel arbre de travail à chaque itération du processus de bissection.
Au lieu de cela, mettez simplement à jour une référence spéciale nommée BISECT_HEAD pour faire pointer sur le
commit qui devrait être testé.

Cette option peut être utile lorsque le test que vous effectueriez à chaque étape ne
nécessite un arbre extrait.

Si le référentiel est nu, --no-checkout est supposé.

EXEMPLES

· Bisectez automatiquement une version cassée entre la v1.2 et HEAD :

$ git bisect start HEAD v1.2 -- # HEAD est mauvais, v1.2 est bon
$ git bisect run make # "make" construit l'application
$ git bisect reset # quitte la session bisect

· Bissecter automatiquement un échec de test entre l'origine et HEAD :

$ git bisect start HEAD origin -- # HEAD est mauvais, l'origine est bonne
$ git bisect run make test # "make test" builds et tests
$ git bisect reset # quitte la session bisect

· Bissecter automatiquement un cas de test cassé :

$ chat ~/test.sh
#!/ Bin / sh
faire || exit 125 # cela ignore les builds cassés
~/check_test_case.sh # le scénario de test réussit-il ?
$ git bisect start HEAD HEAD~10 -- # le coupable fait partie des 10 derniers
$ git course bissectrice ~/test.sh
$ git bisect reset # quitte la session bisect

Ici, nous utilisons un script personnalisé test.sh. Dans ce script, si make échoue, nous sautons le
commit actuel. check_test_case.sh doit quitter 0 si le scénario de test réussit, et quitter 1
autrement.

Il est plus sûr si test.sh et check_test_case.sh sont en dehors du référentiel pour
empêcher les interactions entre les processus bisect, make et test et les scripts.

· Bissecter automatiquement avec des modifications temporaires (hot-fix) :

$ chat ~/test.sh
#!/ Bin / sh

# modifier l'arborescence de travail en fusionnant la branche hot-fix
# et ensuite tenter une compilation
si git merge --no-commit hot-fix &&
a prendre une
puis
# exécuter un test spécifique au projet et signaler son état
~/check_test_case.sh
statut=$?
d'autre
# dire à l'appelant que ce n'est pas testable
statut=125
fi

# annuler le tweak pour permettre un retournement propre au prochain commit
git réinitialiser --hard

# contrôle de retour
quitter $statut

Cela applique les modifications d'une branche hot-fix avant chaque exécution de test, par exemple en cas
votre environnement de build ou de test a changé de sorte que les anciennes révisions peuvent nécessiter un correctif qui
les plus récents l'ont déjà fait. (Assurez-vous que la branche hot-fix est basée sur un commit qui est
contenu dans toutes les révisions que vous divisez, de sorte que la fusion n'entraîne pas
trop, ou utilisez git cherry-pick au lieu de git merge.)

· Bissecter automatiquement un cas de test cassé :

$ git bisect start HEAD HEAD~10 -- # le coupable fait partie des 10 derniers
$ git bisect run sh -c "make || exit 125; ~/check_test_case.sh"
$ git bisect reset # quitte la session bisect

Cela montre que vous pouvez vous passer d'un script d'exécution si vous écrivez le test sur un seul
ligne.

· Localisez une bonne région du graphe de l'objet dans un référentiel endommagé

$ git bisect start HEAD [ ... ] --no-checkout
$ git bisect run sh -c '
BON=$(git for-each-ref "--format=%(objectname)" refs/bisect/good-*) &&
git rev-list --objects BISECT_HEAD --not $GOOD >tmp.$$ &&
git pack-objects --stdout >/dev/null
RC=$ ?
rm -f tmp.$$
tester $rc = 0'

$ git bisect reset # quitte la session bisect

Dans ce cas, lorsque jet couper en deux courir se termine, bisect/bad fera référence à un commit qui a
au moins un parent dont le graphe atteignable est entièrement traversable dans le sens requis
by jet un jeu objets.

· Recherchez un correctif au lieu d'une régression dans le code

$ git bissect start
$ git bisect new HEAD # le commit actuel est marqué comme nouveau
$ git bisect old HEAD~10 # le dixième commit à partir de maintenant est marqué comme ancien

ou à l'adresse suivante :

$ git bisect start --term-old cassé --term-new corrigé
$ git bisect corrigé
$ git bissecte la tête cassée ~ 10

Obtenir vous aider
Utilisez git bisect pour obtenir une brève description de l'utilisation, et git bisect help ou git bisect -h pour
obtenir une longue description d'utilisation.

Utilisez git-bisect en ligne en utilisant les services onworks.net