Ne-am obișnuit cu Git. Ce urmează?

Ne-am obișnuit cu Git. Ce urmează?

Una din marile probleme în firmele mici/medii era lipsa completă a versionării. SVN, Git, Hg, orice. Lipsea sau, în cel mai bun caz, se întâmpla cu foarte mari rețineri. Nu o dată am văzut commituri cu zeci de schimbări mari, fără nici o legătură între ele.

Ori s-au schimbat obiceiurile, ori am început eu să mă învârt în alte cercuri, dar lucrurile au început să se schimbe, pentru că foarte, foarte rar am avut proiecte legacy fără un repo setat.

La proiecte noi am instaurat rapid reguli de editare pentru fișiere: tot timpul se întâmplă pe Git și nu au comentat foarte mulți :D

Ce urmează?

Am învățat de foarte mult timp un lucru foarte interesant: calculatoarele sunt excelente la rulat task-uri repetitive. Și nici nu se supără! Prin urmare, tot ce se poate automatiza, se automatizează:

  • Compilarea Sass, JS? Mix;
  • Înlocuire string-uri (e.g. versiune în composer.json)? Un task Gulp;
  • Formatare și lint pentru cod? Hooks;
  • etc

Deploy

Un alt task repetitiv este deployment. În foarte multe locuri asta se întâmplă pe FTP și constă în aceiasi pași, repetați din nou și din nou: selectezi fișierele, le transferi, aștepți.

Eu am început să migrez tot ce înseamnă deploy în CI. Până acum am folosit GitlabCI, Bitbucket Pipelines și Circle CI și, fără a putea spune că unu-i mai bun decât celălalt, pot spune că e al dracului de util. La fiecare push se face deploy. Sau, dacă ai o aplicație desktop, la fiecare push se compilează aplicația.

Branching

Branch-urile sunt un subiect taboo pentru mulți. Nu facem, nu folosim, am citit noi că SVN era nasol, deci Git e la fel, deci nu. Doar că am început să folosesc un sistem de branching foarte complicat la prima vedere, dar foarte simplu în realitate: Git Flow.

Solo Dev

Git Flow este overkill. Nu sunt necesare 4 branch-uri, două sunt suficiente: master și dev. În cazuri excepționale (e.g. aștepți informații de la client, ai un hotfix) poți face încă un branch, dar, de cele mai multe ori cele două sunt suficiente: pe master este produsul final, cel ce este în producție, pe dev este cel la care lucrezi. Versiunea următoare, ca să zic așa.

Echipă

În echipă, Git Flow este the shit. Sau, dacă nu ăsta, măcar o variantă (e.g. Github Flow).

Pe scurt, regulile sunt: niciodată nu faci commit pe master sau pe dev, tot timpul faci un branch nou și lucrezi pe el. Ca mai sus, master înseamnă producția.

6 Comentarii

iuliancalin a scris

Să presupunem că faci un site, o aplicație, ceva care necesită cod scris de mana, de la început până la sfârșit. Îl scri perfect, fara buguri, scris cel mai corect cod scris vreodată.
Necesită revizuire, corectare, update etc?
De ce ar fi nevoie de corectări?

Adaugă un comentariurăspuns pentru

Link-urile în context sunt binevenite. Comentariile fără nume/email valid sunt șterse.
PS: Comentariul NU este editabil.

Acest sit folosește Akismet pentru a reduce spamul. Află cum sunt procesate datele comentariilor tale.

Site-ul blog.iamntz.com utilizează cookie-uri. Continuarea navigării presupune acceptarea lor. Mai multe informații.

windows apple dropbox facebook twitter