Kaip veikia interaktyvus rebase?

Question

Accepted Answer

**Interaktyvus rebase** (`git rebase -i`) leidžia **perrašyti, perorderin,ti, sujungti, redaguoti arba ištrinti commit'us** — valant jūsų commit'ų istoriją prieš ją dalijantis. Tai galingas įrankis grynai, loginei istorijai sukurti iš sumaišyto darbo-eigoje-esančio commit'ų.: ## Pradedant interaktyvų rebase ```bash git rebase -i HEAD~4 # interactively rebase the last 4 commits git rebase -i # rebase commits after # → opens an editor listing the commits with actions to apply ``` ## Veiksmai ```text pick abc123 Add login form # keep the commit as-is squash def456 Fix typo # COMBINE into the previous commit (merge messages) fixup ghi789 Fix another typo # combine into previous, DISCARD this message reword jkl012 Add validation # keep the commit but EDIT its message edit mno345 Refactor auth # PAUSE to amend the commit (change content) drop pqr678 Debug logging # DELETE this commit entirely # reorder lines to REORDER commits ``` Jūs redaguojate sąrašą — pasirinkdami veiksmą per commit'ą (ir perorderin,dami linijas perordinate commit'us) — tada Git jas atkartoja atitinkamai. ## Įprasti panaudojimai ```text ✓ SQUASH multiple WIP commits into one clean commit ("wip", "fix", "oops" → one good commit) ✓ REWORD bad commit messages ✓ REORDER commits into a logical sequence ✓ DROP unwanted commits (debug code, mistakes) ✓ SPLIT a commit (via edit) into smaller commits → Result: a clean, logical history instead of messy development commits. ``` ## Auksinė taisyklė vis dar galioja ```text ⚠️ Interactive rebase REWRITES history (new commit hashes): → only do it on LOCAL, UNPUSHED commits — never on shared/public history → typical use: clean up your feature branch BEFORE pushing/opening a PR ``` ## Kodėl tai svarbu Supratimas apie interaktyvų rebase yra vertingas **grynai commit'ų istorijos sutvarkymui**, todėl tai naudinga praktinė žinios profesionaliam Git darbui. Kūrimo metu commit'ai dažnai būna sumaišyti — work-in-progress commit'ai su žinutėmis kaip „wip, „fix typo, „oops, debug commit'ai ir nelogine tvarka — o **interaktyvus rebase** leidžia jums **tai išvalyti prieš dalijantis**: sujedina kelis sumaišytus commit'us į grynai loginius, perrašo blogus pranešimus, perorderin,ja commit'us į prasmingą seką, ištrina nepageidaujamus commit'us (kaip debug kodą), ir dalina commit'us — transformuodamas sumaišytą kūrimo istoriją į grynai loginę, peržiūrėtiną seką. Tai svarbu, nes gryna commit'ų istorija (kaip aprašyta gerose commit praktikose) palengvina kodo peržiūrą, istoriją suprantamesnę, ir derinimą (per bisect) veiksmingesnį — todėl gebėjimas sutvarkyti prieš kitiems matant jūsų darbą yra profesionalios Git praktikos savybė. Supratimas apie **veiksmus** (pick, squash, fixup, reword, edit, drop, ir perordrin,imas) ir **įprastus panaudojimus** (ypač WIP commit'ų sujungimas, labai dažnas poreikis) yra praktinė vėsybė. Kritiškai, **auksinė rebasing taisyklė vis dar galioja** — interaktyvus rebase perrašo istoriją (naujos hešų), todėl jį reikia daryti tik **vietiniuose, neišsiųstuose commit'uose** (niekada dėl dalintos istorijos), su tipiniu panaudojimu būdant feature branch'o valymą *prieš* išsiuntimą arba pull request'o atidarymo. Būtent gryna, loginė commit'ų istorija yra vertinga bendradarbiavimui ir palaikomumui, o kūrimas natūraliai gamina sumaišytus commit'us, kuriuos interaktyvus rebase gali išvalyti prieš dalijantis (saugiai, vietiniuose commit'uose), supratimas apie interaktyvų rebase — veiksmus, įprastus panaudojimus kaip sujungimas, ir saugumo taisyklę — yra vertinga, praktiškai svarbi Git žinios profesionaliam kūrimui, galingas įrankis grynai, peržiūrėtinam istorijai pateikti, kuri išskiria apdairų Git naudotojų, naudojamą reguliariai darbui poliravus prieš jį dalijantis su komanda.