Folosește cineva Pull/Merge Requests la proiecte interne? Dacă da, câți oameni lucrează la proiectul respectiv?
Eu nu il folosesc. Ma tot gandesc sa il introduc, inca am retineri.
Da, folosim noi. Suntem vreo 10 oameni cred, proiecte destul de multe.
@Catalin_Banu: câti oameni sunt implicați? La proiectele la care lucrez eu, rar sunt implicați mai mult de doi-trei oameni (cu tot cu mine) iar PR-uri mi se par prea peste mână…
noi folosim. echipe de 4-6-8 oameni. primul proiect la care l-am folosit a fost un succes pentru noi - proiect extrem de complex, dat in productie inainte de deadline, feature complete si de 1 luna si jumatate nu a fost nevoie sa rezolvam niciun bug.
Totusi, ce am folosit noi este o combinatie intre git flow si gitlab flow pe care il prezinta ei acolo. am descoprit ca e foarte important ca merge request-urile si review-urile sa se faca pe bune si sa nu se merge-uiasca nimic pana cel care merge-uieste nu a inteles complet ce se intampla in cod-ul din PR. Pe langa tot flow-ul, noi am mai descoperit util sa ai un tester care stie programare si care poate sa arunce un ochi pe fiecare feature branch in parte. plus teste automate care sa ruleze la fiecare merge.
Acum, daca te uiti la descrierea sistemului pe care il folosim noi, o sa para overkill si e prea posibil sa fie, asa ca nu cred ca e o solutie care sa fie potrivita tuturor proiectelor. La noi, totusi, e necesara pentru ca, intr-un proiect, e calitate uber alles.
PS: e foarte tare tool-ul din gitlab care, la un merge request iti arata diferentele dintre codul pe care vrei sa il merge-uiesti si codul unde vrei sa merge-uiesti.
2 Likes
BTW, ce parere aveti de fork si commit doar in master in loc de diferitele metode de branching in git ?
Google, Facebook, Microsoft au un singur master la proiecte si toti programatorii fac pull request direct la el. Doar ca exista o varianta stabila si o varianta experimentala, repo-uri diferite.
Eu zic ca probabil cel mai important lucru cand lucrezi remote e sa ai o singura sursa de adevar, adica sa ma uit la master si sa stiu cu ce am deaface la o conferinta pe skype, altfel putem vorbi o ora si tot nu stim ce si cum pana nu ne uitam la cine ce a facut in realitate.
+1 e o idee buna if you can get away with it. Proiecte mai mici sau proiecte in care ai controlul asupra sistemului (deci componente server-side sau aplicatii consume) se preteaza foarte bine si e IMO cel mai curat si simplu mod de a lucra.
Dar daca ai un proiect enterprise, unde unii clienti sunt pe versiunea 2.7.x, iar altii pe 2.10.y, si niciunul nu are timp de upgradat la 2.15.z, care e versiunea curenta, trebuie sa mentii si branch-uri pentru versiunile respective (deci nu doar tag-uri) si din cand in candi mai cherry-pick-uiesti un bug-fix ca sa obtii 2.7.(x+1) si 2.10.(y+1) pentru diversii clienti.
4 Likes
Git !== Agile. Mutam thread-ul?
Sunt curios unde faci stage.
Un branch stage, devel te ajuta sa centralizezi mai multe commit-uri pentru a pregati urmatoarea versiune.
Adica pe ce branch poti sa centralizezi commit-urile si sa faci un demo?
La Google cred ca smecheria este ca CI-ul stie sa ruleze si fork-uri sau mai multe fork-uri combinate … Aveti link ceva?
2 Likes