From a7ea65e967b68865d3f0d033cc8f28b438fa40b3 Mon Sep 17 00:00:00 2001 From: Ekaitz Zarraga Date: Tue, 31 May 2022 17:23:05 +0200 Subject: subtree, rerere, debugging --- 2.md | 84 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 84 insertions(+) diff --git a/2.md b/2.md index f1c5061..eefea1e 100644 --- a/2.md +++ b/2.md @@ -564,3 +564,87 @@ definitzen dute. Aukerek algoritmoa konfiguratzen dute. ## Subtree-ak +Subtree-ak beste proiektu bat gure proiektuaren barruan sartzeko mekanismo bat +dira. Azpiproiektua adar independente batean kudeatzen da: beste remote bat +moduan hasierazten da, baina adar berri batean sartu, beste adarrekin +zerikusirik ez duena. + +- `git read-tree` azpiproiektua irakurri eta beste adar baten azpidirektorio + moduan hasiarazteko +- `git merge -Xsubtree` erabiltzen da *subtree*aren adarra proiektuan + arazo barik mergeatzeko +- `git diff-tree` azpiproiektuaren aldaketak aztertzeko, `diff` normal bat ez + dabil + +*Ez da asko erabiltzen, *Submodule*ak gehiago erabiltzen dira. Gehiago ikasteko, +liburua irakurri.* + +## Rerere: Reuse Recorded Resolution — I + +Konfliktoak nola konpondu ditugun erregistratzeko sistema bat da, gero Gitek +konfliktoak automatikoki ebazteko kriterio berdina erabiltzen. Adibide baten +bitartez: + +1. Testing adarra mergeatzen konfliktoak daude +2. Konfliktoak konpontzen dira +3. Testak txarto doaz +4. Mergea desegin behar da +5. Testak konpondu behar dira +6. Mergea berriro egin => konflikto berdinak berriro konpondu behar dira + +`rerere`-ren bitartez lehenengo mergearen konfliktoen ebazpena gorde daiteke. +Horrela, mergea berriro aplikatzerakoan ez da konfliktoa berriro ebatzi behar, +automatikoki aurretik gordetako ebazpena erabiltzen delako. + +## Rerere: Reuse Recorded Resolution — II + +- `git config --global rerere.enabled true` +- `git rerere status` *rerere*ren egoera ikusteko +- `git rerere diff` *rerere*k aplikatuko lituzken aldaketak ikusteko +- `git add` + `git commit` egiterakoan ebazpena gordetzen da: + `"Recorded resolution"` +- `git reset --hard HEAD^` eta mergea berriro egiterakoan konfliktoak + automatikoki konpontzen dira: + `"Resolved with previous resolution"` +- `git checkout --conflict=merge ` eginda konfliktoa berreskuratu + daiteke, `rerere`a aktibatu gabe +- `git rerere` egiten berriro mergeatu daiteke automatikoki + + +## Gitekin debuggeatzen + +- `git blame` fitxategi baten aldaketak zein commitean sartu diren ikusi + daiteke. `^`-ekin hasten diren lerroak hasieratik aldatu gabeko lerroak dira. + `-C` aukerarekin mugitutako zatiak aurkitu daitezke[^move] + +[^move]: Gitek ez ditu mugimenduak gordetzen baina fitxategien zatiak aztertu + eta mugimenduak kalkulatu ditzake + +- `git bisect` [bisekzio metodoa][bisect] erabiliz erroreak aurkitzeko tresna + oso interesgarria. Bisekzio metodoa: + - Bi commit hartu: bat erroreduna eta bestea errore gabea + - Erdiko puntuan commit bat hartu: errorea badauka, errorea sartu zuen + commita commit honen eta errore gabeko commitaren artean dago. Errorea ez + badago, commit honen artean eta commit erroredunaren artean dago. + - Beste puntu bat hartu eta jarraitu tartea txikitzen commita aurkitzen den + arte. + +[bisect]: https://en.wikipedia.org/wiki/Bisection_method + + +## Gitekin debuggeatzen: `git bisect` + +Bisekzio metodoa aplikatzeko workflowa + +1. `git bisect start` bisekzio metodoa hasi +2. `git bisect bad` oraingo commita txarra da +3. `git bisect good ` commit hau ona da +4. `git bisect good/bad` oraingo commita ona edo txarra da. Gitek + hurrengo commita aukeratzen du: + `"Bisecting, N revisions left to test"` +5. `git bisect reset` hasierara bueltatu + +Automatizatu daiteke: `git bisect run ` + +- Komandoak `0` bueltatu behar du testa ondo badoa eta beste edozer errorea + badago -- cgit v1.2.3