Vad är den bästa processen för kodgranskning när du använder GIT? Vi har en extern GIT-leverantör (Unfuddle) och har begränsningar för resursanvändning – så vi kan inte ha dedikerade fjärrförvar för varje dev.

Aktuell process:

  • Vi ha en GIT-server med en master -gren som alla åtar sig
  • Devs fungerar av den lokala master -spegeln lokal funktionsgren
  • Devs push to server ”s master branch
  • Devs begär kodgranskning vid senaste engagemang

Problem:

  • Alla fel i kodgranskning är redan i master när den fångas.
  • Värre, vanligtvis har någon bränt några timmar på att försöka för att ta reda på vad som hände …

Så, vi skulle vilja

  • Att göra kodgranskning FÖRE leverans till ”master”.
  • Ha en process som fungerar med ett globalt team (inga över axeln recensioner!)
  • något som inte kräver att en enskild person ska vara vid sitt skrivbord / maskin att startas så att någon annan kan fjärrkontrollera i n (ta bort mänskligt beroende, devs gå hem vid olika tidszoner)

Vi använder TortoiseGIT för en visuell representation av en lista med ändrade filer, olika filer etc. Några av oss faller in i en GIT-skal när GUI inte är tillräckligt, men helst skulle vi vilja att arbetsflödet ska vara enkelt och GUI-baserat (jag vill att verktyget ska lyfta alla bördor, inte mina utvecklare).

Kommentarer

  • Gör du enhetstest innan du begår?
  • @GuyCoder: För det mesta gör vi det.
  • Om din värd inte ger kodgranskning kapacitet, få en bättre värd. Ta en titt på Gerrit och se om du kan hitta en värd som tillhandahåller den.

Svar

A Enkel men effektiv modell är GitHub pull-begäran -modellen, där bidragsgivarna arkiverar ”vänligen slå i min kod” -förfrågningar. En underhållare granskar ändringsuppsättningarna och bestämmer om de behöver mer arbete eller om de är lämpliga för sammanslagning. Han kan sedan gå samman i mästergrenen. Åtagare får i allmänhet inte trycka direkt till huvudgrenen (detta kan anpassas efter din smak, vi tillåter att ”mindre” åtaganden går direkt in).

Kommentarer

  • Vi har ett tätt team med 7 professionella utvecklare (mot anonyma bidragsgivare) globalt, så det är säkert att låta var och en direkt trycka på vår fjärrmästare. Även om det ' är en länk + intro mot en fristående svar som jag föredrar, i det här fallet är det vettigt. Bra skrivning vid länk, tack!
  • @ Sid Med ett team på 3 skulle jag inte ' inte låta dem alla driva för att behärska.
  • Pull-begäranden finns också i Rhodecode och Atlassian Stash
  • @Andrew: Varför inte? Det finns många problem som kan genereras genom att kanalisera hela lagens arbete genom en choke-punkt. Dessa kan alla mildras, men en enda punkts kommando- och kontrollstruktur är mer lämplig för vissa situationer än andra.

Svar

Git är ett distribuerat versionskontrollsystem: har inte bara en repo med en gren!

Du kan ställa in flera repositories – en för varje utvecklare – och en annan som är master repo. När en av deras filialer är redo att slås samman, begär utvecklaren en sammanslagning och deras ändringar dras från sin filial / repo till mastern.

Innan den sammanslagningen faktiskt sker kan granskaren dra ändringarna till och granska dem innan de pressar dem att behärska.

Ytterligare fördelar är att på detta sätt kan en utvecklare ha så många grenar som de vill, namngivna vad de vill säga, utan att störa varandra eller ens ha för att se varandras smutsiga tvätt så mycket.


Lär dig också lingo: med ”Devs commit to serverss master branch” menar du att de push deras ändringar till master?

Kommentarer

  • ja, de push deras arbete. Vi kan ' t ha unika fjärrlager på GIT-servern eftersom vi betalar en GIT-värd och de tar ut per förvar. Menade du att du hade flera avlägsna filialer per utvecklare? Och när du säger the reviewer can pull the changes into their environment vilka exakta GIT-kommandon (eller TortoiseGIT-flöde) menar du?
  • Nej, jag menar att du har flera förvar; en per utvecklare, och i det förvaret kan de ha så många filialer som de vill. När det gäller pull vet jag inte ' vad kommandot skulle vara i TortoiseGIT – men kommandot är git pull . Det ' är motsatsen till ett tryck – du drar ändringar från fjärrförvaret för att uppdatera din miljö med arbete som andra utvecklare kan ha gjort.
  • Jag vet git pull 🙂 …Jag bad om fullständig syntax för att inspektera repo / gren / tag-systemet för push / pull du hänvisade till. Just nu gör vi git pull hur som helst, det ' är precis utanför fjärrkontrollen: master – vilket orsakar problemen. Hur som helst, Steven ' s länkar var fantastiska. Tack
  • För alla praktiska ändamål i det här fallet är en filial i den värdade repo precis samma som en annan repo.

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *