Hva er den beste prosessen for kodegjennomgang når du bruker GIT? Vi har en ekstern GIT-leverandør (Unfuddle) og har begrensninger på ressursbruk – så vi kan ikke ha dedikerte eksterne lagringssteder for hver enhet.
Gjeldende prosess:
- Vi ha en GIT-server med en
master-gren som alle forplikter seg til - Devs fungerer av det lokale
masterspeilet eller lokal funksjonsgren - Devs push to server «s
masterbranch - Devs request code review on last commit
Problem:
- Enhver feil i kodegjennomgang er allerede i mester når den blir fanget.
- Verre, vanligvis har noen brent noen timer å prøve for å finne ut hva som skjedde …
Så vi vil
- Gjør kodegjennomgang FØR levering til «master».
- Ha en prosess som fungerer med et globalt team (ingen over skulderen vurderinger!)
- noe som ikke krever at en individuell person skal være ved skrivebordet / maskinen å bli slått på slik at noen andre kan fjernstyre i n (fjern menneskelig avhengighet, devs går hjem i forskjellige tidssoner)
Vi bruker TortoiseGIT for en visuell fremstilling av en liste over endrede filer, forskjellige filer osv. Noen av oss kommer til en GIT shell når GUI ikke er nok, men ideelt sett vil vi at arbeidsflyten skal være enkel og GUI-basert (jeg vil at verktøyet skal løfte belastningen, ikke mine devs).
Kommentarer
- Gjør du enhetstest før du forplikter deg?
- @GuyCoder: Det gjør vi for det meste.
- Hvis du ikke gir kodevurdering evne, få en bedre vert. Ta en titt på Gerrit, og se om du finner en vert som gir den.
Svar
A Enkel, men effektiv modell er GitHub pull-forespørsel -modellen, der bidragsytere arkiverer «vennligst slå sammen i koden min». En vedlikeholder vurderer endringssettene og bestemmer om de trenger mer arbeid, eller om de er egnet for sammenslåing. Deretter kan han fusjonere inn i mestergrenen. Forpliktelser har generelt ikke lov til å skyve direkte til hovedgrenen (dette kan tilpasses din smak, vi tillater «mindre» forpliktelser å gå direkte inn).
Kommentarer
- Vi har et stramt team på 7 profesjonelle utviklere (mot anonyme bidragsytere) globalt, så det er trygt å la hver enkelt presse direkte til vår eksterne mester. Selv om det ' er en lenke + intro vs et frittstående svar som jeg foretrekker, er det i dette tilfellet fornuftig. Stor oppskrivning på link, takk!
- @ Sid Med et team på 3 ville jeg ikke ' ikke la dem alle presse for å mestre.
- Pull-forespørsler er også tilgjengelige i Rhodecode og Atlassian Stash
- @Andrew: Hvorfor ikke? Det er mange problemer som kan genereres ved å trakte hele teamets arbeid gjennom et choke-punkt. Disse kan alle avbøtes, men en enkelt punkts kommando- og kontrollstruktur er mer egnet for noen situasjoner enn andre.
Svar
Git er et distribuert versjonskontrollsystem: ikke har bare en repo med en gren!
Du kan sette opp flere repositories – en for hver utvikler – og en annen som er master repo. Når en av grenene deres er klar til å bli slått sammen, ber utvikleren om en sammenslåing og endringene blir trukket fra filialen / repoen til master.
Før den sammenslåingen faktisk skjer, kan anmelderen trekke endringene inn i miljøet deres, og gjennomgå dem før du presser dem til å mestre.
Ytterligere fordeler er at på denne måten kan en utvikler ha så mange grener som de vil, kalt hva de vil si, uten å forstyrre hverandre eller til og med ha for å se hverandres skittentøy så mye.
Lær også lingo: med «Devs forplikter seg til serverens hovedgren» mener du at de push deres endringer til master?
Kommentarer
- ja, de
pushderes arbeid. Vi kan ' t ha unike eksterne lagringssteder på GIT-serveren fordi vi betaler en GIT-vert og de tar betalt per depot. Mente du at du hadde flere eksterne filialer per utvikler? Og når du sierthe reviewer can pull the changes into their environmenthvilke eksakte GIT-kommandoer (eller TortoiseGIT flow) mener du? - Nei, jeg mener har flere repositorier; en per utvikler, og på det depotet kan de ha så mange grener som de vil. Når det gjelder
pull, vet jeg ikke ' hva kommandoen ville være i TortoiseGIT – men kommandoen er git pull . Det ' er det motsatte av et trykk – du trekker endringer fra det eksterne depotet for å oppdatere miljøet ditt med arbeid andre devs kan ha gjort. - Jeg vet
git pull🙂 …Jeg ba om full syntaks for å inspisere repo / branch / tag-systemet for push / pulls du henviste til. Akkurat nå gjør vigit pulluansett, det ' er like utenfor fjernkontrollen: master – som forårsaker problemene. Uansett, Steven ' s lenker var gode. Takk - For alle praktiske formål i dette tilfellet er en filial i den vertstilte repoen akkurat det samme som en annen repo.