Introducció

Git és una eina de control de versions molt potent que aporta moltes coses bones només pel fet d'utilitzar-la, i encara aporta més coses si s'utilitza de bona manera. Aquesta proposta tracta sobre utilitzar git de bona manera.

Situació actual

Ara mateix en el projecte, hi ha una estructura de git "branca per aplicació" (entre cometes, realment no és del tot veritat). Els integrants de l'equip treballen sobre cada una de les branques de l'aplicació i es va fent merge amb development cada X temps, on X pot ser més de dos setmanes.
On treballa cadascú? Una persona en les branques de backend, una persona per l'aplicació de mestre granges, dues persones per l'aplicació de dipòsits i una persona sense branca per aplicació, directament treballa sobra development.

Problemes

Tot i que sembla que s'està aprofitant git, no és del tot així. Que passa quan la persona que treballa sobre development toca un controlador general que també toquen totes les aplicacions? Que passa quan les dues persones que treballen en l'aplicació de dipòsits intenten fer push a la vegada, però han de fer pull de codi de l'altre(per poder fer push) i es creen conflictes? I per últim i més important, que passa quan es fa un merge d'una sub branca cap a development, i hi ha conflictes sobre codi que el desenvolupador de la sub branca va crear fa dos setmanes?
Tot això comporta errors o pitjor, bugs (errors que no es poden identificar a l'acte). Aquests errors són pèrdues de temps que es podrien invertir a millorar codi o fer noves funcionalitats, i per tant són diners perduts per l'empresa, ja que paguen als treballadors per arreglar coses que era responsabilitat seva fer bé.

Proposta

Tot això es pot solucionar d'una manera fàcil, però que comporta practicar git (cosa que també es MOLT bona). Millorar el flux d'interacció de dades entre development i sub branques. Això s'aconsegueix eliminant la idea de branques per aplicació, utilitzant branques per funcionalitat.
-La primera millora que això comporta és que dos o més persones poden treballar sobre la mateixa aplicació en diferents sub branques, sense perill de tenir el problema que actualment té la branca de dipòsits.
-Segon, la persona treballant sobre development, ja no podrà fer-ho. Això és bo, ja que la branca development només tindrà una única funció: Actuar de branca preMaster, és a dir, la funció de fer merge de totes les funcionalitats i comprovar que els conflictes s'han resolt adequadament. Pensant bé, el problema que té ara la branca és que tot i fer merge de totes les branques a ella, si la persona que treballa directament a development fa un push amb funcionalitats complicades, pot crear errors quan tothom pensa que no n'hi ha (tot i no acceptar aquesta proposta, és una cosa que ha de canviar si o si, és molt perillós).
-Tercer, els merge ja no seran cada molt temps. Quan una funcionalitat acaba, es fa merge. El desenvolupador que ha fet la funcionalitat pot solucionar els conflictes fàcilment, ja que té el codi molt fresc. El problema d'ara és que ja no es recorda part del codi a l'hora de fer merge.
-Quart, l'equip serà molt més flexible. No farà falta que una persona s'encarregui només d'una aplicació, les persones podran treballar sobre funcionalitats. Això comporta una cosa bona i una altra no tan bona. La primera és que una persona que en sap molt sobre un component javascript, podrà integral a totes les aplicacions sense problemes, amb branques aïllades de les altres, millorant moltíssim el temps de desenvolupament de les aplicacions. La segona és que això comporta organització com equip (tinc propostes preparades per millorar això, utilitzant metodologies àgils) i seguir les pautes marcades per la guia d'estil en totes les aplicacions per igual.
-Per últim, les millores són moltes, aquestes són les més importants, la qüestió és deixar clar que aquestes millores valen la pena.

Conclusió

Aquesta proposta comporta unes grans millores en el desenvolupament del software produït per l'equip, però també comporta unes responsabilitats.
-Primer de tot i més important, seguir les pautes marcades pels documents del repositori.
-Segon, millorar aquestes pautes i fer utilitzar una metodologia de treball perquè tothom treballi fàcilment en equip.
-Tercer, millorar l'ús de git en l'equip, realitzant més commits, més branques, més merges, etcetc... Bàsicament, utilitzar al 100% l'eina de git.
-Quart, crear una guia sobre l'ús de git per l'equip, on hi ha per exemple l'ús de comandes per facilitar la feina a tothom, o l'explicació de què una persona s'ocupa de decidir quines branques fan merge amb development, juntament amb la persona que vol fer merge de la funcionalitat (per solucionar els conflictes).
-Finalment, organització. Fonamental que en l'equip quedi molt clar que està fent cadascú i que ha d'implementar cadascú.