Care este cel mai bun proces pentru revizuirea codului atunci când se utilizează GIT? Avem un furnizor extern de GIT (Unfuddle) și avem limite de utilizare a resurselor – deci nu putem avea depozite la distanță dedicate pentru fiecare versiune.
Procesul actual:
- Noi au un server GIT cu o
masterramură la care se angajează toată lumea - Dev-urile funcționează în oglinda locală
mastersau ramură de caracteristici locale - Devs push to server „s
masterbranch - Devs solicită revizuirea codului la ultima comitere
Problemă:
- Orice eroare în revizuirea codului este deja în stăpânire până la momentul în care este surprinsă.
- Mai rău, de obicei cineva a ars câteva ore încercând pentru a afla ce s-a întâmplat …
Așadar, ne-ar plăcea
- Să facem o revizuire a codului ÎNAINTE de livrare în „master”.
- Aveți un proces care funcționează cu o echipă globală (nu există recenzii peste umăr )
- ceva care nu necesită ca un dezvoltator individual să fie la biroul / mașina sa să fie alimentat astfel încât altcineva să poată distanța i n (eliminați dependența umană, dezvoltatorii merg acasă la diferite fusuri orare)
Folosim TortoiseGIT pentru o reprezentare vizuală a unei liste de fișiere modificate, diferind fișiere etc. Unii dintre noi intrăm într-un GIT shell atunci când interfața grafică nu este suficientă, dar în mod ideal ne-ar plăcea ca fluxul de lucru să fie simplu și bazat pe interfața grafică (vreau ca instrumentul să ridice orice sarcină, nu dev-urile mele).
Comentarii
- Faceți test de unitate înainte de a vă angaja?
- @GuyCoder: În general, facem acest lucru.
- Dacă gazda dvs. nu furnizează revizuirea codului capacitate, obțineți o gazdă mai bună. Aruncați o privire la Gerrit și vedeți dacă puteți găsi o gazdă care să o furnizeze.
Răspuns
A modelul simplu, dar eficient este modelul GitHub pull request , în care contribuitorii solicită fișierul „vă rugăm să fuzionați în codul meu”. Un întreținător examinează seturile de modificări și decide dacă au nevoie de mai multă muncă sau dacă sunt potrivite pentru fuzionare. Apoi, el poate fuziona în ramura principală. În general, autorilor nu li se permite să treacă direct către filiala principală (acest lucru poate fi personalizat după gusturile dvs., permitem angajamentelor „minore” să intre direct).
Comentarii
- Avem o echipă strânsă de 7 dezvoltatori profesioniști (față de colaboratori anonimi) la nivel global, așa că este sigur să îi lăsăm pe fiecare să treacă direct la stăpânul nostru la distanță. Deși ' este un link + intro vs un răspuns independent pe care îl prefer, în acest caz are sens. Scriere extraordinară la link, mulțumesc!
- @Sid Cu o echipă de 3, nu le-aș permite ' să-i las pe toți să împingă la master.
- Solicitările de extragere sunt disponibile și în Rhodecode și Atlassian Stash
- @Andrew: De ce nu? Există multe probleme care pot fi generate prin canalizarea întregii echipe care funcționează printr-un punct de sufocare. Toate acestea pot fi atenuate, dar o structură de comandă și control cu un singur punct este mai potrivită pentru unele situații decât pentru altele.
Răspuns
Git este un sistem de control al versiunilor distribuite: nu aveți o singură repo cu o ramură!
Puteți configura mai multe depozite – unul pentru fiecare dezvoltator – și altul care este repo master. Când una dintre sucursalele lor este gata să fie fuzionată, dezvoltatorul solicită o fuziune, iar modificările lor sunt extrase din filiala / repo în master.
Înainte ca acea fuziune să se întâmple, examinatorul poate trage modificările în mediul înconjurător și examinați-le înainte de a le împinge să stăpânească.
Avantajele adăugate sunt că în acest fel un dezvoltator poate avea cât mai multe ramuri pe care le dorește, numite orice spune că vrea, fără a se interfera unul cu celălalt sau chiar a avea pentru a ne vedea atât de mult rufele murdare.
De asemenea, învățați lingo-ul: prin „Devs commit to server” s master branch ”vrei să spui că ei împingeți modificările lor la master?
Comentarii
- da, ei
pushmunca lor. Nu putem ' să avem depozite unice de la distanță pe serverul GIT, deoarece plătim un host GIT și acestea se încarcă pe fiecare depozit. V-ați referit la mai multe ramuri la distanță per dezvoltator? Și când spuithe reviewer can pull the changes into their environmentla ce comenzi GIT exacte (sau fluxul TortoiseGIT) vrei să spui? - Nu, vreau să spun că au mai multe depozite; una pentru fiecare dezvoltator, iar în acel depozit pot avea câte ramuri doresc. În ceea ce privește
pull, nu ' nu știu care ar fi comanda în TortoiseGIT – dar comanda este git pull . ' este opusul unei apăsări – trageți modificări din depozitul de la distanță pentru a vă actualiza mediul cu lucrări pe care ar fi putut să le facă alte dispozitive. - Știu
git pull🙂 …Ceream sintaxa completă pentru a inspecta sistemul repo / branch / tag pentru push / pulls la care făceați referire. În acest moment,git pulloricum, ' este la distanță: master – ceea ce cauzează problemele. Oricum, legăturile lui Steven ' au fost grozave. Mulțumim - Pentru toate scopurile practice, în acest caz, o sucursală din repo-ul găzduit este la fel ca o altă repo.