Cum am început cu version control?

Nu-i chiar tutorial, dar eu mi-aș fi dorit să găsesc un asemenea text atunci când eram la început cu Version Control sau cu Git


Prima dată am „gustat” din beneficiile versionării când am dat de E-text editor. Ăsta a fost primul meu editor de suflet, ca să zic așa, iar una dintre funcționalități era că știa să facă undo între sesiuni. Adică închideai editorul (sau fișierul), îl redeschideai și puteai da undo ca și cum ai fi avut tot timpul fișierul în față.

A doua chestie făcută de E-text a fost să-mi introducă în flow conceptul de „branched undo”. Adică puteai da undo până la punctul X, făceai ceva, te apucai să dai undo până la punctul X-1, iar la redo apărea un popup care te întreba în ce direcție vrei să o apuci.

Aceste două funcționalități m-au făcut să ezit în a adopta un sistem de versionare, iar când am făcut-o, m-a dezamăgit din plin. Și nu pentru că era SVN, ci pentru că aveam cu totul alte așteptări de la un astfel de sistem.

Am zis că ar fi util să pun în scris toate „problemele” pe care mi le amintesc că le-am întâmpinat în acel moment.

Cum fac să fie totul real time?

Pentru că așa eram învățat, așteptările mele erau destul de… sus, ca să zic așa: voiam ca versionarea să se facă automat, la fiecare save. Ba chiar căutasem soluții pentru această „problemă”. Cum aș putea face commit la fișiere în timp real?

Evident, acum pare ridicolă această idee, dar la momentul respectiv era un blocker absolut.

Între timp am aflat că vrei să ai o anume versiune a codului, de preferat funcțională, nu TOATE versiunile…

Când faci commit?

Adițional la problema de mai sus, după ce am înțeles că nu e nevoie de commit-uri real time, am avut un alt blocaj: dacă nu e așa, atunci când fac commit? La fiecare 30 minute? Mai des? Mai rar?

Răspunsul găsit nu a fost chiar pe placul meu, ce părea a fi mai mult un koan: you make a commit every time you need one.

Oh, wow, păi și de unde știi? Nu știi, dar înveți. O să-ți dai seama că faci prea rar atunci când ai modificat 50 fișiere de la ultimul commit sau când ai lucrat toată ziua și faci commit când pleci acasă. O să-ți dai seama că faci prea des atunci când fiecare diff are una-două linii schimbate iar log-ul tău arată 84 commit-uri în ultimele 40 minute…

Atunci nu știam, dar acum aș putea spune că un commit trebuie să „îndeplinească” SRP, care în original zice așa:

A class should have only one reason to change.

adaptat ar suna:

A commit should have only one reason to be made.

Altfel spus, ai de rezolvat o problemă ce ține de autentificare, una de căutare și una de generare QR? În cazul în care nu se rezolvă toate cu o singură modificare în cod (și NU ar trebui!), ar trebui să ai cel puțin un commit pentru fiecare dintre aceste probleme.

Branching

Când am descoperit branch-urile în Git am avut alte nelămuriri absolut vitale (nu chiar…).

Cum pun toate branch-urile online?

Pentru că aveam vreo doi ani de SVN în spate, rămăsesem cu impresia că branch-urile ar trebui să stea pe server. TOATE branch-urile. Prin urmare, căutam tot felul de soluții și la această problemă (am impresia că Git a introdus de curând posibilitatea de a face push la toate branch-urile dintr-un foc)

Explicația este logică și evidentă ACUM: nu ai nevoie de asta! Branch-urile locale NU trebuie să existe și pe server decât dacă lucrează mai mulți pe acel branch (sau face parte dintr-un pull request). Altfel? Rămâne doar pe local!


Cred că am mai avut nelămuriri, dar acum zău că nu-mi aduc aminte… Voi cum ați adoptat versionarea? Ce non-probleme ați avut la început?

2 Likes

AutoVer face backup la fiecare salvare. Doar salvare de fisiere, pe disk sau prin FTP. Insa nu arata modificarile, cum face GIT-ul (nu am folosit SVN, deci nu pot compara).

Deasemenea, functioneaza si ca un backup la backup (adica in caz ca git da fail). Spre exemplu, sa zicem ca X si Y amandoi lucreaza intr-un fisier, X face commit, Y vroia sa faca commit, dar git-ul nu-i dadea voie, din cauza ca nu avea branch-ul up-to-date si, in graba, face commit fara sa faca backup manual fisierului. A pierdut Y modificarile facute? Daca nu mai are editor-ul deschis, sau daca editorul updateaza tab-ul fisierului de fiecare data cand data ultimei salvari este schimbata, atunci da, a pierdut fisierul, Exceptie facand daca a folosit AutoVer. In lucrul la birou, un backup de 10 zile ar trebui sa fie mai mult decat suficient.

Am dat de git mult mai tarziu si singurul motiv pentru care am ales git in loc de svn deoarece mai mai intrasem de cateva ori pe github inainte sa gasesc git-ul (si, implicit, inainte sa caut pe google git vs svn) pentru ca git-ul salveaza altfel datele si cica ar fi mai sigur.

Edit: Am dat de git fiindca aveam nevoie de ceva care sa-mi faca backup la fiecare salvare de fisier, deoarece database-ul cu “Last Session” din Maxthon devenea corupt dupa fiecae inchidere intr-un anumit fel a browserului. Iar acum il folosesc din cauza marimii prea mari a database-ului, care (din cauza unui overflow) sterge din ultimele elemente din lista (am cateva sute de link-uri salvate acolo, pe putin).

Exact pentru astfel de situații a fost creat git. De către nenea Linus. Care menține kenrelul de linux în git.

Nici vorbă. Nu e nevoie de nimic altceva decât de folosirea comenzilor git.

Am vrut să răspund de dimineață, dar m-am luat cu altele și am uitat complet :smiley:

Atunci când am început să lucrez cu mai mulți oameni pe Git, asta a fost o altă non-problemă: voi avea conflicte pentru orice! (de fapt știu oameni care înca nu folosesc versionare fix din acest motiv).

Doar că nu e chiar așa, Git fiind destul de deștept când vine vorba de merge, iar conflictele apar doar dacă toți editează fix același lucru.

Ai și backup la backup la backup? :slight_smile:

După primul an de Git am ajuns la concluzia că sunt șanse destul de mici să pierzi cu adevărat date (hint: git reflog).

Da, la început se întâmpla destul de des să am conflict și eram extrem de precaut: arhivam tot proiectul, încercam să rezolv conflictul, dacă nu reușeam… unzip la arhivă.

1 Like

Cum am început cu version control?

Îmi aduce aminte de o poveste de prin Cluj unde o firmă destul de cunoscută a decompilat un întreg proiect web de Java din motive ușor de imaginat. Asta era pe vremea când SVN era un moft. Noroc că aveau proiectul instalat undeva pentru testat. Au pierdut clientul până la urmă, s-a dus la altă firmă cu mizeria aia decompilata :slight_smile:

Prea mult lucru manual. Nu mai bine lasi programelul sa ruleze in fundal si il deschizi in loc de unzip, doar ca fara sa mai fie nevoie de dozip? Zic si eu. E vorba de comoditate.

@ionelmc Asta se intampla daca nu faci backup…

Eu cred că aveau backup, în același share de windows. Cineva i-a dat omorul din greșeală la tot share-ul :slight_smile:
O situație „râs cu plâns” - eu lucrând în cea de-a 2-a firma atunci.

Ca o soluţie alternativă la ceea ce ai scris sus, m-am tot gândit dacă ar exista un sistem de versionare care să aibe un feature cu care să-ţi poţi organiza ierarhic commit-urile (posibil să se poată rezolva aceasta cu branch-urile pe Git, dar am lucrat prea puţin cu acesta şi nu ştiu).

Prin organizat ierarhic mă refer

  • să-mi pot grupa mai multe commit-uri mici/incrementale într-un “commit” mai mare sau feature branch
  • acel “grup” să poate fi expandat ca un tree în history-ul centralizat
  • să poţi face diff între toate, adică şi între commit-urile mici şi între cele “mari”
  • să poţi adăuga ulterior alte commit-uri acelui “grup”

De asemenea, pe lângă cele două de mai sus mi-aş putea imagina şi un al 3-lea nivel de commit-uri temporare (mai mici decât cele incrementale), care să aibe rol strict de back-up şi să nu apară în history-view, dar să fie salvate pe server (ceva în genul shelve-urilor din TFS).

Motivele pentru care văd ca fiind util aşa ceva:

  • merge-uri simplificate, deoarece commit-urile legate de un feature sunt grupate şi nu mai trebuie căutate/filtrate + ar putea fi incluse şi bugfix-uri ulterioare (momentan folosesc, ca workaround, un feature-prefix la descirerea unui commit, cu care îmi “grupez” commit-urile)
  • structurare mai bună a commit-urilor, având diferite grade de granularitate, care cred că ar facilita viitoarele căutări
  • ar fi fezabile commit-uri foarte dese

Prefer commit-uri foarte dese:

  • atât din motiv back-up (am avut de 3 ori HDD failure şi chiar cu un sistem de versionare am pierdut modificări semnificative)
  • cât şi pentru a memora toate stadiile funcţionale (sau cel puţin compilabile) prin care am trecut pe parcursul dezvoltării unui feature
  • momentan aceste commit-uri dese le ţin în shelve-uri TFS, dar acestea nu apar în history-ul de pe branch-uri
1 Like

Chestia asta mi se pare super utilă şi în continuare în cazul unor fişiere Office.

Oare există/se poate face ceva de genul pentru fişiere Word/Excel?

Branched undo este super util în orice context, nu doar Office. Photoshop, de exemplu, are ceva de genul ăsta și funcționează acceptabil.

Fun fact: Sublime a avut probleme aproape doi ani cu banalul undo/redo, când îți făcea scroll aiurea în document atunci când apăsai undo/redo :slight_smile:

2 Likes