7.10 Mga Git na Kasangkapan - Pagdebug gamit ang Git

Kung ikaw ay sumusubaybay ng isang bug sa iyong code at gusto mong malaman kapag ito ay ipinakilala at bakit, ang annotation ng file ay madalas na iyong pinakamahusay na kasangkapan. Ito ay nagpapakita sa iyo kung anong commit ang huling binago sa bawat linya ng anumang file. Kung nakikita mo na ang pamamaraan na iyon sa iyong code ay buggy, maaari mong i-annotate ang file gamit ang git blame para malaman kung anong commit ang responsable para sa pagpapakilala sa linyang iyon.

Ang mga sumusunod na halimbawa ay gumagamit ng git blame para matukoy kung anong commit at nag-commit ang responsable para sa mga linya sa itaas na antas na Linux kernel na Makefile at, higit pa, gumagamit ng -L na opsyon upang paghigpitan ang output sa annotation ng mga linya 69 hanggang 82 sa file na iyon:

Pansinin na ang unang patlang ay ang bahagyang SHA-1 ng commit na huling nabago sa linyang iyon. Ang sunod na dalawang mga patlang ay mga nakuhang halaga mula sa commit na iyon — ang pangalan ng may-akda at ang petsa ng pag-akda sa pag-commit na iyon — kaya madali mong makita kung sino ang nagbago sa linya at kung kailan. Pagkatapos ay may kasunod na bilang ng linya at ang nilalaman ng file. Tandaan din ang ^1da177e4c3f4 na commit na mga linya, na kung saan ang ^ na prefix ay nagtatakda ng mga linya na pinakilala ang paunang commit sa repositoryo at mayroong hindi nabago mula noon. Ito ay isang nakakalito, dahil ngayon ay makikita mo ang hindi bababa sa tatlong iba’t ibang pamaraan sa na ginagamit ni Git ang ^ sa pagbago ng isang commit na SHA-1, ngunit iyan ang ibig sabihin dito.

Isa pang cool na bagay tungkol sa Git ay hindi ito makasubaybay ng file na tahasang pagpapalit ng pangalan. Ito ay nagtatala sa mga snapshot at sinusubukang tingnan kung ano ang ipinahiwatig sa binago na pangalan, pagkatapos sa katotohanan. Isa sa interesadong mga tampok nito ay maaari kang magtanong para malaman ang lahat ng mga uri ng kilos ng code din. Kung ikaw ay papasa sa -C hanggang git blame, ang Git nag-aaral ng file na iyong ina-annotate at sinusubukang malaman kung saang mga snippet ng code na nasa orihinal na dumating kung sila ay nakopya mula kung saan. Halimbawa, sabihin natin na ikaw ay nag-refactor ng isang file na pinangalanan na GITServerHandler.m sa maramihang mga file, isa na ang GITPackUpload.m. Sa pamamagitan ng pagsisisi ng GITPackUpload.m na may -C na opsyon, maaari mong makikita kung saan mga seksyon ng code na orihinal na nagmumula:

Ito ay talagang kapaki-pakinabang. Karaniwan, ikaw ay makakakuha nang isang orihinal na commit kung saan kinopya mo ito ang code na higit pa, dahil iyon ang unang pagkakataon na iyong hinawakan ang mga linya sa file na ito. Sinasabihan ka ni Git ang orihinal na commit na iyong sinulat ang mga linyang iyon, kahit na ito ay nasa ibang file.

Pag-annotate ng file ay tumutulong kung alam mo kung saan ang issue ay nagsisimula. Kung hindi mo alam kung ano ang breaking, at nagkakaroon ng dose-dosena o daan-daan na mga commit mula ng iyong huling estado na kung saan alam mo ang code ay gumagana, malamang na mababalik ka sa git bisect para sa tulong. Ang bisect na utos ay gumagawa ng isang binary na paghahanap sa pamamagitan ng iyong commit na kasaysayan upang tumulong na tukuyin nang mas mabilis hangga’t maaari na kung saan ang commit ay ipinakilala ang isyu.

Sabihin natin na ikaw ay naka-push na isang release sa iyong code sa isang produksyon na environment, ikaw ay makakuha ng mga bug report tungkol sa isang bagay na hindi nangyayari sa iyong development environment, at ikaw ay hindi makaiisip kung paano ang code ay gumagawa ng ganoon. Bumalik ka sa iyong code, at parang may nangyari na maaari kang gumawa uli ng isyu, ngunit hindi mo matukoy kung ano ang nangyari. Kaya mo mag-bisect sa code upang matukoy. Una ikaw ay magpatakbo sa git bisect start para umpisahan ito, at pagkatapos ay ikaw ay gumamit ng git bisect bad para sabihan ang sistema na ang kasalukuyang commit na ikaw ay nandoon ay nabasag. Pagkatapos, dapat mong sabihin ang bisect kapag ang huling kilalang magandang estado ay, gumagamit ng git bisect good <good_commit>:

Naisip ni Git na mga 12 na mga commit ay dumating sa pagitan ng commit na iyong minarkahan bilang ang huling mabuting commit (v1.0) at ang kasalukuyang masamang bersyon, at ito ay sinusuri ang gitna para sayo. Sa puntong ito, maaari kang magpatakbo ng iyong pagsubok upang makita kung ang isyu at umiiral sa commit na ito. Kung ito ay gumagawa, pagkatapos ito ay ito pay pinakilala minsan bago ang gitnang commit; kung hindi ito gumagawa, kaya ang problema ay ipinakilala minsan pagkatapos ng gitnang commit. Iyon pala ay walang isyu dito, at ikaw ay nagsasabi ni Git sa pamamagitan ng pag-type ng git bisect good at ipagpatuloy ang iyong paglalakbay:

Ngayon ikaw ay nasa ibang commit, sa gitna sa pagitan sa iyong nasubukan na at ang iyong masamang commit. Maaari kang magpatakbo sa iyong pagsubok muli at tignan na ang commit na ito ay nasira, kaya sabihan ang Git sa pamamagitan ng git bisect bad:

Ang commit na ito ay mabuti, at ngayon ang Git ay maroong lahat ng mga impormasyon na kung saan ang isyu ay ipinakilala. Sinasabi nito sa iyo na ang SHA-1 sa unang masamang commit at nagpakita ng maraming commit na impormasyon at kung saan ang mga file ay nabago sa pag-coomit para matukoy ang nagyayari na maaaring mayroong ipinakilala sa bug na ito:

Kaya tapos ka na, dapat kang magpatakbo ng git bisect reset upang i-reset ang iyong HEAD sa kung nasaan ka nag-umpisa, o ikaw ay nagtapos ng isang kakaibang estado:

Ito ay isang makapangyarihang kasangkapan na maaaring makatulong para tingnan ang daan-daang mga commit para sa ipinakilalang bug sa minuto. Sa katunayan, kung mayroon kang isang script na lumabas sa 0 kung ang proyekto ay mabuti o hindi-0 kung ang proyekto ay masama, maaari kang buong mag-awtomatiko sa git bisect. Una, ikaw ay muling magsasabi nito na ang scope sa bisect sa pamamagitan ng pagbibigay ng kilalang masama at mabuting mga commit. Maaari mong gawin ito sa pamamagitan sa paglista sa kanila na gamit ang bisect start na utos kung gusto mo, paglista ng kilalang masamang commit muna at ang kilalang magandang commit sa pangalawa:

Sa paggawa ay awtomatikong nagpapatakbo ng test-error.sh sa bawat checked-out na commit hanggang ang Git ay makakita sa unang sirang commit. Maaari ka ding magpatakbo ng ibang bagay na tulad ng make o make tests o anumang mayroon kang napapatakbo ng awtomatiko para susubukan para sa iyo.