Când vorbim de versionare pentru cod și software în general, utilitarul de facto în 2024 este încă git. Dar nu a fost întodeauna așa. Cei care își amintesc înainte ca acesta să devină stabil și popular foloseam svn, mercurial sau cvs. Eu îmi amintesc cu nostalgie de vremea când foloseam Tortoise SVN1.
În acest articol o să vă spun și despre alternative la Git ca sistem de versionare, dar și despre câteva unelte care vă pot ușura interacțiunea cu git din linia de comandă:
Gitu
Încă de la versiunea 2, interfața cli cu care vine git este destul de bună, dar nu chiar intuitivă. Iar pentru unele acțiuni rulezi aceleași comenzi repetitiv. Apoi pentru cazurile în care faci un log sau diff este extrem de utilă o interfață grafică.
Gitu este un utilitar din linia de comandă, inspirat de Magit - extensia pentru Emacs, care îți permite să execuți o serie de comenzi folosind macros - combinații de taste. Acesta nu înlocuiește git, dar te ajută să sari peste comenzi repetitive, să vizualizezi istoricul și diff-urile cu o interfață și oferă sugestii pentru acțiuni în funcție de context.
Din păcare suportul pentru WSL2 are câteva bug-uri și nu am reușit să îl instalez cu cargo, dar îl recomand pentru simplitate și portabilitate.
Sapling
Una dintre criticile menționate des la adresa git, este că e dificil de scalat - la miloane de fișiere și mii de dezvoltatori. Google de exemplu, în mod faimos, folosește un sistem intern de versionare menținat pe forumuri ca Piper, care din păcate nu este open source. Cel puțin Meta au decis să publice codul sistemului lor de versionare - Sapling. Codul pentru componenta de client, este disponibil pe Github sub GPL.
Sunte multe de spus despre acest SCM, dar pentru a ține acest articol în limitele unei email voi nota următoarele:
Acesta diferă fundamental de git, ca mod de operare, dar totodată oferă interoperabilitate cu git și GitHub. Îți dă posibilitatea să trimiți un pull request direct din cli, și să vizualizezi un log detaliat per branch. Tototadă acesta descurajează branch-uri cu denumiri sugestive și încurajează folosirea PR-urilor în loc, ca feature branches. Saplin nu are un staging area. Poți face un commit ca și cu git, iar acesta se va aplica la toate fișierele urmărite. Poți ascunde sau ”undo” commit-uri publice cu un nou commit și vine cu o interfață web care oferă un istoric interactiv (smartlog).
Smartlog, oferă o serie de avantaje peste git log
, pe lângă componenta vizuală, îți oferă posibilitatea de a muta commit-uri (rebase) sau da checkout (goto) pe alt branch.
Din păcare serverul sapling nu este open source, în consecință singura modalitate de a-l adopta este folosind interoperabilitatea cu github.
Jujutsu
JJ este un sistem dezvoltat recent, în limbajul Rust, a cărui misiune principală este să decupleze layer-ul de stocare de cel de control al versiunilor. În acest fel, fiind mult mai ușor de scalat.
O altă şchimbare notabilă față de git, este că jj consideră copia în lucru (working-copy) ca fiind un commit, eliminând astfel erorile tipice operațiilor de checkout sau pull din git atunci când avem modificări pe working-copy. Practic toate operațiile în jj, au afect asupra unui commit. Poate părea contraintuitiv, însă rezultatul este că poți face mai multe versiuni locale pe branch-uri diferite de exemplu și să le testez fără a fi blocat de nevoia de a crea efectiv un commit. Git în acest scenariu te va alerta: ”atenție să nu pierzi vreun fișier” - e nevoie să faci un commit înainte de checkout. Pe când JJ te lasă să schimbi branch-ul, eventual poți adăuga noi modificări iar când ești gata ”salvezi” acel commit sau îl adaugi la cel precedent cu squash.
Mai sunt câteva diferențe legate de ramuri (branches), și de conflicte, dar dacă vi se pare interesant vă recomand să citiți mai multe pe pagina proiectului. Partea cea mai bună este că suportă repository-uri .git și deci poate fi folosit în paralel cu sistemul de versionare.
Mențiuni notabile:
Referințe: