git-bisect - Online în cloud

PROGRAM:

NUME

git-bisect - Utilizați căutarea binară pentru a găsi commit-ul care a introdus o eroare

REZUMAT

merge împărţi în două

DESCRIERE

Comanda preia diferite subcomenzi și opțiuni diferite în funcție de subcomandă:

git bisect start [--term-{vechi,bun}= --term-{nou, rău}= ]
[--no-checkout] [ [ ...]] [--] [ ...]
git bisect (rău|nou) [ ]
git bisect (bine|vechi) [ ...]
termeni git bisect [--term-bun | --termen-rău]
git bisect skip [( | )...]
git bisect reset [ ]
git bisect vizualiza
git bisect replay
git bisect log
git bisect run ...
git bisect ajutor

Această comandă folosește un algoritm de căutare binar pentru a găsi ce comite din istoricul proiectului
a introdus un bug. Îl folosești spunându-i mai întâi un commit „reu” despre care se știe că conține
bug-ul și o comitere „bună” despre care se știe că este înainte ca eroarea să fie introdusă. Apoi git
bisect alege un commit între aceste două puncte finale și vă întreabă dacă commit-ul selectat
este „bun” sau „rău”. Continuă să restrângă intervalul până când găsește comiterea exactă
care a introdus schimbarea.

De fapt, git bisect poate fi folosit pentru a găsi commit-ul care s-a schimbat Orice proprietatea dvs
proiect; de exemplu, commit-ul care a remediat un bug sau commit-ul care a cauzat un benchmark
performanța de îmbunătățit. Pentru a sprijini această utilizare mai generală, termenii „vechi” și „nou” pot
poate fi folosit în locul „bun” și „rău”, sau vă puteți alege proprii termeni. Vezi secțiunea
„Termeni alternativi” de mai jos pentru mai multe informații.

pachet de bază împărţi în două comenzi: începe, rău, bine
De exemplu, să presupunem că încercați să găsiți commit-ul care a rupt o caracteristică care a fost
cunoscut că funcționează în versiunea v2.6.13-rc2 a proiectului dumneavoastră. Începi o sesiune bisect ca
urmează:

$ git bisect start
$ git bisect bad # Versiunea curentă este proastă
$ git bisect good v2.6.13-rc2 # v2.6.13-rc2 este cunoscut a fi bun

Odată ce ați specificat cel puțin un commit rău și unul bun, git bisect selectează un commit
în mijlocul acestui interval de istorie, îl verifică și scoate ceva similar cu
următoarele:

Bisecție: 675 de revizuiri rămase de testat după aceasta (aproximativ 10 pași)

Acum ar trebui să compilați versiunea verificată și să o testați. Dacă acea versiune funcționează
corect, tastați

$ git bisect bun

Dacă versiunea respectivă este defectă, tastați

$ git bisect rău

Apoi git bisect va răspunde cu ceva de genul

Bisecție: 337 de revizuiri rămase de testat după aceasta (aproximativ 9 pași)

Continuați să repetați procesul: compilați arborele, testați-l și în funcție de dacă este bun
sau bad run git bisect good sau git bisect bad pentru a cere următoarea comitere care are nevoie
de testare.

În cele din urmă, nu vor mai rămâne revizuiri de inspectat, iar comanda va fi tipărită
o descriere a primei comiteri proaste. Refs/bisect/rea de referință va fi lăsată îndreptată
la acel comite.

Împărţi în două reseta
După o sesiune de bisectare, pentru a curăța starea de bisectare și a reveni la HEAD inițial,
lansați următoarea comandă:

$ git bisect resetare

În mod implicit, acest lucru va returna arborele dvs. la commit care a fost verificat înainte de git
început bisect. (O nouă pornire git bisect va face, de asemenea, asta, deoarece curăță vechea bisectie
stat.)

Cu un argument opțional, puteți reveni la un alt commit:

$ git bisect resetare

De exemplu, git bisect reset bisect/bad va verifica prima revizuire proastă, în timp ce git
resetarea bisecției HEAD vă va lăsa pe comiterea bisecțiunii curente și va evita comutarea
se angajează deloc.

Alterna termeni
Uneori nu cauți comiterea care a introdus o rupere, ci mai degrabă a
commit care a provocat o schimbare între o altă stare „veche” și stare „nouă”. De exemplu,
s-ar putea să căutați commit-ul care a introdus o anumită remediere. Sau ai putea fi
căutând primul commit în care numele fișierelor din codul sursă au fost în sfârșit convertite
conform standardului de denumire al companiei dvs. Sau orice.

În astfel de cazuri, poate fi foarte confuz să folosiți termenii „bun” și „rău” pentru a face referire la „cel
stare înainte de schimbare" și "stare după schimbare". Deci, în schimb, puteți utiliza
termenii „vechi” și, respectiv, „nou”, în locul „bun” și „rău”. (Dar rețineți că dvs
nu se poate amesteca „bine” și „rău” cu „vechi” și „nou” într-o singură sesiune.)

În această utilizare mai generală, oferiți git bisect cu un „nou” commit care are o anumită proprietate
și un „vechi” commit care nu are acea proprietate. De fiecare dată când git bisect verifică a
commit, testați dacă acel commit are proprietatea. Dacă da, marcați commit-ul ca „nou”;
în caz contrar, marcați-l ca „vechi”. Când bisectia este finalizată, git bisect va raporta care
commit a introdus proprietatea.

Pentru a folosi „vechi” și „nou” în loc de „bun” și rău, trebuie să rulați git bisect start fără
commit ca argument și apoi rulați următoarele comenzi pentru a adăuga commit-urile:

git bisect old [ ]

pentru a indica faptul că un commit a fost înainte de modificarea căutată sau

git bisect new [ ...]

pentru a indica că a fost după.

Pentru a primi un memento al termenilor utilizați în prezent, utilizați

termeni git bisect

Puteți obține doar termenul vechi (respectiv nou) cu termenul git bisect --term-old sau git
bisect termen --term-bun.

Dacă doriți să folosiți proprii termeni în loc de „rău”/„bun” sau „nou”/„vechi”, puteți
alegeți orice nume vă place (cu excepția subcomenzilor bisect existente, cum ar fi reset, start, ...) prin
incepand bisectia folosind

git bisect start --term-old --termen-nou

De exemplu, dacă sunteți în căutarea unui commit care a introdus o regresie a performanței, dvs
ar putea folosi

git bisect start --term-old rapid --term-new slow

Sau dacă căutați commit-ul care a remediat o eroare, ați putea folosi

git bisect start --term-new fixed --term-old rupt

Apoi, utilizați git bisect și git bisect în loc de git bisect bun și
git bisect bad pentru a marca comiterile.

Împărţi în două imagina
Pentru a vedea suspecții rămași în prezent în gitk, lansați următoarea comandă în timpul
proces de bisectie:

$ git bisect vizualiza

vizualizarea poate fi folosită și ca sinonim pentru vizualizare.

În cazul în care DISPLAY variabila de mediu nu este setată, merge log este folosit în schimb. De asemenea, puteți da
opțiunile din linia de comandă, cum ar fi -p și --stat.

$ git bisect view --stat

Împărţi în două log și împărţi în două reda
După ce ați marcat revizuirile ca bune sau rele, lansați următoarea comandă pentru a arăta ce are
s-a facut pana acum:

$ git jurnal bisect

Dacă descoperiți că ați făcut o greșeală în specificarea stării unei revizuiri, puteți
salvați rezultatul acestei comenzi într-un fișier, editați-l pentru a elimina intrările incorecte și
apoi lansați următoarele comenzi pentru a reveni la o stare corectată:

$ git bisect resetare
$ git bisect reluează acel fișier

evitând de testare a comite
Dacă, în mijlocul unei sesiuni de bisect, știi că revizuirea sugerată nu este bună
unul de testat (ex. nu se construiește și știi că eșecul nu are nimic
de a face cu bug-ul pe care îl urmăriți), puteți selecta manual un commit din apropiere și îl puteți testa
unul in schimb.

De exemplu:

$ git bisect bun/rău # runda anterioară a fost bună sau rea.
Bisecție: 337 de revizuiri rămase de testat după aceasta (aproximativ 9 pași)
$ git bisect vizualiza # oops, asta este neinteresant.
$ git reset --hard HEAD~3 # încercați 3 revizuiri înainte de ce
# a fost sugerat

Apoi compilați și testați revizuirea aleasă și apoi marcați revizuirea ca bună sau rea
în maniera obișnuită.

Împărţi în două sări
În loc să alegeți singur un commit din apropiere, puteți cere lui Git să o facă pentru dvs
emiterea comenzii:

$ git bisect skip # Versiunea curentă nu poate fi testată

Cu toate acestea, dacă omiteți un commit adiacent celui pe care îl căutați, Git nu va putea
pentru a spune exact care dintre acele comite a fost primul rău.

De asemenea, puteți sări peste o serie de comiteri, în loc de o singură comitere, folosind notația interval.
De exemplu:

$ git bisect skip v2.5..v2.6

Acest lucru îi spune procesului bisect că nu ar trebui să fie comise după v2.5, până la și inclusiv v2.6
să fie testat.

Rețineți că, dacă doriți, de asemenea, să omiteți primul commit al intervalului, veți emite fișierul
comanda:

$ git bisect skip v2.5 v2.5..v2.6

Aceasta îi spune procesului bisect că commit-urile dintre v2.5 și v2.6 (inclusiv) ar trebui să fie
sărit.

Tăiere jos împărţire în două by oferindu- mai mult parametrii la împărţi în două Începe
Puteți reduce și mai mult numărul de încercări, dacă știți ce parte a copacului este
implicat în problema pe care o urmăriți, prin specificarea parametrilor căii la emitere
comanda de pornire bisect:

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

Dacă știți în prealabil mai multe comite bune, puteți restrânge spațiul bisect
specificarea tuturor comiterilor bune imediat după comiterea proastă la emiterea
comandă de pornire bisect:

$ git bisect start v2.6.20-rc6 v2.6.20-rc4 v2.6.20-rc1 --
# v2.6.20-rc6 este rău
# v2.6.20-rc4 și v2.6.20-rc1 sunt bune

Împărţi în două alerga
Dacă aveți un script care poate spune dacă codul sursă actual este bun sau rău, puteți
bisectează prin lansarea comenzii:

$ git bisect rulează argumentele my_script

Rețineți că scriptul (my_script în exemplul de mai sus) ar trebui să iasă cu codul 0 dacă
codul sursă actual este bun/vechi și ieșiți cu un cod între 1 și 127 (inclusiv),
cu excepția 125, dacă codul sursă curent este prost/nou.

Orice alt cod de ieșire va anula procesul de bisectare. De remarcat că un program care
se termină prin exit(-1) lasă $? = 255, (vezi ieşire(3) pagină manuală), după cum este valoarea
tocat cu & 0377.

Codul de ieșire special 125 ar trebui utilizat atunci când codul sursă curent nu poate fi testat. Dacă
scriptul iese cu acest cod, revizuirea curentă va fi omisă (vezi git bisect skip
de mai sus). 125 a fost aleasă drept cea mai mare valoare sensibilă de utilizat în acest scop, deoarece 126
și 127 sunt utilizate de shell-urile POSIX pentru a semnala starea de eroare specifică (127 este pentru comandă nu
găsit, 126 este pentru comanda găsită, dar nu executabilă - aceste detalii nu contează, deoarece acestea
sunt erori normale în script, în ceea ce privește rularea bisectului).

Este posibil să descoperiți adesea că în timpul unei sesiuni de bisect doriți să aveți modificări temporare
(de ex. s/#define DEBUG 0/#define DEBUG 1/ într-un fișier antet sau „reviziune care nu are
acest commit are nevoie de acest patch aplicat pentru a rezolva o altă problemă pe care această bisecție nu este
interesat de") aplicat revizuirii testate.

Pentru a face față unei astfel de situații, după interior merge împărţi în două găsește următoarea revizuire de testat,
scriptul poate aplica patch-ul înainte de compilare, poate rula testul real și apoi poate decide
dacă revizuirea (eventual cu patch-ul necesar) a trecut testul și apoi derulează arborele
la starea curată. În cele din urmă, scriptul ar trebui să iasă cu starea testului real
lăsați bucla de comandă git bisect run să determine rezultatul eventual al sesiunii bisect.

OPŢIUNI

--no-checkout
Nu verificați noul arbore de lucru la fiecare iterație a procesului de bisectare.
În schimb, actualizați doar o referință specială numită BISECT_HEAD pentru a-l face punct spre
commit care ar trebui testat.

Această opțiune poate fi utilă atunci când testul pe care l-ați efectua în fiecare pas nu o face
necesită un copac verificat.

Dacă depozitul este gol, se presupune --no-checkout.

EXEMPLE

· Divizează automat o construcție ruptă între v1.2 și HEAD:

$ git bisect start HEAD v1.2 -- # HEAD este rău, v1.2 este bun
$ git bisect run make # "make" construiește aplicația
$ git bisect reset # ieși din sesiunea bisect

· Divizați automat o eșec de testare între origine și HEAD:

$ git bisect start HEAD origin -- # HEAD este rău, originea este bună
$ git bisect run make test # „face test” build-uri și teste
$ git bisect reset # ieși din sesiunea bisect

· Divizează automat un caz de testare spart:

$ pisica ~/test.sh
#!/ Bin / sh
face || ieșirea 125 # aceasta omite versiunile rupte
~/check_test_case.sh # testul trece?
$ git bisect start HEAD HEAD~10 -- # vinovat este printre ultimii 10
$ git bisect run ~/test.sh
$ git bisect reset # ieși din sesiunea bisect

Aici folosim un script personalizat test.sh. În acest script, dacă make eșuează, omitem
comiterea curentă. check_test_case.sh ar trebui să iasă din 0 dacă testul trece și să iasă din 1
in caz contrar.

Este mai sigur dacă atât test.sh, cât și check_test_case.sh sunt în afara depozitului
preveniți interacțiunile dintre procesele bisect, make și testare și scripturi.

· Bisecție automată cu modificări temporare (hot-fix):

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

# ajustați arborele de lucru prin îmbinarea ramurii de remediere la cald
# și apoi încercați o construcție
if git merge --no-commit hot-fix &&
face
apoi
# rulați testul specific proiectului și raportați starea acestuia
~/check_test_case.sh
stare=$?
altfel
# spuneți apelantului că acest lucru nu poate fi testat
stare=125
fi

# anulați modificarea pentru a permite trecerea curată la următoarea comitere
git reset --hard

# controlul de întoarcere
ieșiți din $status

Acest lucru se aplică modificărilor dintr-o ramură de remediere rapidă înainte de fiecare rulare de testare, de exemplu, în caz
mediul dvs. de construcție sau de testare s-a schimbat, astfel încât versiunile mai vechi ar putea avea nevoie de o remediere care
cele mai noi au deja. (Asigurați-vă că ramura de remediere rapidă se bazează pe un commit care este
conținute în toate revizuirile pe care le împărțiți în două, astfel încât îmbinarea să nu aibă loc
prea mult sau utilizați git cherry-pick în loc de git merge.)

· Divizează automat un caz de testare spart:

$ git bisect start HEAD HEAD~10 -- # vinovat este printre ultimii 10
$ git bisect run sh -c "make || exit 125; ~/check_test_case.sh"
$ git bisect reset # ieși din sesiunea bisect

Acest lucru arată că puteți face fără un script de rulare dacă scrieți testul pe un singur
linia.

· Localizați o regiune bună a graficului obiect într-un depozit deteriorat

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

$ git bisect reset # ieși din sesiunea bisect

În acest caz, când merge împărţi în două alerga termina, bisect/bad se va referi la un commit care are
cel puțin un părinte al cărui grafic accesibil este complet traversabil în sensul cerut
by merge împacheta obiecte.

· Căutați o remediere în loc de o regresie în cod

$ git bisect start
$ git bisect new HEAD # comiterea curentă este marcată ca nouă
$ git bisect old HEAD~10 # a zecea comitere de acum este marcată ca vechi

sau:

$ git bisect start --term-old broken --term-new fix
$ git bisect fix
$ git bisect rupt HEAD~10

Noțiuni de bază ajutor
Utilizați git bisect pentru a obține o scurtă descriere a utilizării și git bisect help sau git bisect -h to
obțineți o descriere lungă de utilizare.

Utilizați git-bisect online folosind serviciile onworks.net