Hvad er den bedste proces til kodegennemgang, når du bruger GIT? Vi har en ekstern GIT-udbyder (Unfuddle) og har begrænsninger på ressourceforbrug – så vi kan ikke have dedikerede eksterne lagre til hver enhed.

Nuværende proces:

  • Vi have en GIT-server med en master -gren, som alle forpligter sig til
  • Devs arbejder fra det lokale master spejl eller et lokal funktionsgren
  • Devs skubber til server “s master gren
  • Devs anmoder om kodegennemgang ved sidste forpligtelse

Problem:

  • Enhver fejl i kodegennemgang er allerede i master, når den er fanget.
  • Værre, normalt har nogen brændt et par timer på at prøve for at finde ud af, hvad der skete …

Så vi vil gerne

  • At foretage kodegennemgang FØR levering til “master”.
  • Har en proces, der fungerer med et globalt team (ingen over skulderen anmeldelser!)
  • noget, der ikke kræver, at en individuel dev skal være ved sit skrivebord / maskine at blive tændt, så en anden kan fjerne i n (fjern menneskelig afhængighed, devs går hjem i forskellige tidszoner)

Vi bruger TortoiseGIT til en visuel repræsentation af en liste over filer, der er ændret, forskellige filer osv. Nogle af os falder ind i en GIT-shell, når GUI ikke er nok, men ideelt set vil vi gerne have, at workflowet skal være enkelt og GUI-baseret (jeg vil have værktøjet til at løfte enhver byrde, ikke mine devs).

Kommentarer

  • Gør du enhedstest, inden du forpligter dig?
  • @GuyCoder: For det meste gør vi det.
  • Hvis du er vært, giver ikke kodeanmeldelse kapacitet, få en bedre vært. Se på Gerrit, og se om du kan finde en vært, der leverer den.

Svar

A Enkel, men effektiv model er GitHub pull-anmodning -modellen, hvor bidragsydere arkiverer “bedes du flette i min kode” -anmodninger. En vedligeholder gennemgår ændringssættene og beslutter, om de har brug for mere arbejde, eller om de er egnede til sammenlægning. Han kan derefter fusionere ind i mestergrenen. Forpligtere har generelt ikke lov til at skubbe direkte til mastergrenen (dette kan tilpasses efter din smag, vi tillader “mindre” forpligtelser at gå direkte ind).

Kommentarer

  • Vi har et tæt team på 7 professionelle devs (vs anonyme bidragydere) globalt, så det er sikkert at lade hver enkelt direkte skubbe til vores fjernmester. Selvom det ' er et link + intro vs et enkeltstående svar, som jeg foretrækker, i dette tilfælde giver det mening. Stor skrivning ved link, tak!
  • @ Sid Med et team på 3 ville jeg ikke ' ikke lade dem alle skubbe for at mestre.
  • Pull-anmodninger er også tilgængelige i Rhodecode og Atlassian Stash
  • @Andrew: Hvorfor ikke? Der er mange problemer, der kan genereres ved at trække hele holdets arbejde gennem et choke-punkt. Disse kan alle afhjælpes, men en enkeltpunkts kommando- og kontrolstruktur er mere egnet til nogle situationer end andre.

Svar

Git er et distribueret versionskontrolsystem: behøver ikke kun en repo med en gren!

Du kan oprette flere repositories – en til hver udvikler – og en anden, der er masterreposen. Når en af deres filialer er klar til at blive flettet, anmoder udvikleren om en fletning, og deres ændringer trækkes fra deres filial / repo til masteren.

Før den sammenfletning faktisk sker, kan korrekturlæseren trække ændringerne ind i deres miljø og gennemgå dem, før de skubber dem til at mestre.

Ekstra fordele er, at denne måde en udvikler kan have så mange grene, som de vil, navngivet hvad de siger, de vil, uden at blande hinanden eller endda have for at se hinandens snavsede vasketøj så meget.

Lær også lingo: ved “Devs forpligter sig til serverens mesterfilial” mener du, at de push deres ændringer til master?

Kommentarer

  • ja, de push deres arbejde. Vi kan ' t have unikke fjernopbevaringssteder på GIT-serveren, fordi vi betaler en GIT-vært, og de opkræver pr. Arkiv. Mente du, at du havde flere eksterne filialer pr. Udvikler? Og når du siger the reviewer can pull the changes into their environment hvilke nøjagtige GIT-kommandoer (eller TortoiseGIT-flow) mener du?
  • Nej, jeg mener, at der er flere arkiver; en pr. udvikler, og i det arkiv kan de have så mange grene, som de vil. Hvad angår pull, ved jeg ikke ' ikke, hvad kommandoen ville være i TortoiseGIT – men kommandoen er git pull . Det ' er det modsatte af et skub – du trækker ændringer fra det eksterne lager for at opdatere dit miljø med arbejde, som andre devs muligvis har gjort.
  • Jeg ved git pull 🙂 …Jeg bad om den fulde syntaks for at inspicere repo / branch / tag-systemet for push / pulls, du henviste til. Lige nu gør vi git pull alligevel, det ' er lige ved fjernbetjening: master – hvilket forårsager problemerne. Under alle omstændigheder var Steven ' s links store. Tak
  • Til alle praktiske formål i dette tilfælde er en gren i den hostede repo bare den samme som en anden repo.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *