Guia
Git i control de versions en equip
Git resol el «qui va canviar què i quan». El que no resol sol és com es coordina un equip al seu voltant: això és una convenció que cal decidir i escriure.
Darrera actualització:
Gairebé cap equip té un problema amb Git com a eina. El problema és l'absència d'acord: cadascú fa branques a la seva manera, les revisions depenen de qui estigui de guàrdia i ningú sap amb seguretat què hi ha a producció. Aquesta guia recull les decisions que convé tancar i per què.
Triar un model de branques
Hi ha dues famílies raonables i una que gairebé sempre sobra. Trunk-based: tothom integra a main diverses vegades al dia, darrere de *feature flags* si cal, i es publica des d'aquí. GitFlow: branques de llarga vida (develop, release/*, hotfix/*) amb un ritual de promoció entre elles.
- Equip petit (2–8) que desplega sovint: trunk-based amb branques de vida curta (hores o un parell de dies).
- Producte amb versions numerades, diverses suportades alhora, o certificacions per versió: GitFlow o una variant.
- La branca que viu setmanes sense integrar-se no és una estratègia, és deute: el *merge* serà car i arriscat.
Pull requests que serveixen per a alguna cosa
Una *pull request* és una unitat de revisió, no un abocament de dues setmanes de feina. Com més petita, més honesta és la revisió: per sobre de 400 línies, qui revisa aprova per cansament.
- Un canvi per PR, amb una descripció de quin problema resol i com provar-lo.
- La branca surt de
mainactualitzat i es reintegra en qüestió de dies, no de setmanes. - La CI (tests, lint, build) passa abans de demanar revisió humana, no després.
- Almenys una aprovació d'algú que no sigui l'autor, i que aquesta persona pugui de debò dir que no.
Revisió de codi: què mirar
La revisió no és un control d'estil —això ho fa un *linter* automàtic—. És una conversa sobre si el canvi és correcte, si és la solució més simple i si algú més el podrà mantenir. Comentar el nom d'una variable mentre s'escola un problema de concurrència és perdre el temps de tothom.
Versionat i publicacions
Etiqueta cada publicació (git tag) amb versionat semàntic i un registre de canvis generat a partir dels missatges de *commit*. Així, quan alguna cosa es trenca a producció, la pregunta «què va entrar en aquesta versió?» es respon en deu segons i no reconstruint l'historial a mà.
Preguntes freqüents
El que ens solen preguntar
Trunk-based o GitFlow?
Trunk-based si desplegues sovint i no mantens diverses versions alhora; GitFlow si tens versions numerades suportades en paral·lel. En cas de dubte, trunk-based amb branques de vida curta dona menys problemes.
És obligatori revisar totes les pull requests?
Sí, encara que la revisió pugui ser ràpida. El valor no és només detectar errors: és que més d'una persona conegui cada part del codi i que ningú sigui punt únic de fallada.
Com de gran pot ser una pull request?
Com a norma, per sota de 400 línies de canvi real. Per sobre, la qualitat de la revisió cau en picat. Si un canvi és inevitablement gran, divideix-lo en diversos PR encadenats.
Cal un missatge de commit amb format?
Ajuda molt. Amb Conventional Commits pots generar el registre de canvis i decidir el número de versió de manera automàtica, i l'historial es torna llegible.
Serveis relacionats
Guies relacionades
Continuar llegint
Següent pas
Mitja hora ben invertida
Explica'ns el problema en una trucada curta. En sortim amb una primera orientació de per on aniria i què implicaria, sense compromís i sense presentació comercial.