Jaki jest najlepszy proces weryfikacji kodu w przypadku korzystania z GIT? Mamy zewnętrznego dostawcę GIT (Unfuddle) i mamy ograniczenia dotyczące wykorzystania zasobów – więc nie możemy mieć dedykowanych zdalnych repozytoriów dla każdego dewelopera.

Aktualny proces:

  • Mamy mieć serwer GIT z gałęzią master, do której wszyscy zobowiązują się
  • Programiści pracują z lokalnego master lustra lub lokalna gałąź funkcji
  • Programiści wysyłają na serwer „s master gałąź
  • Programiści proszą o sprawdzenie kodu przy ostatnim zatwierdzeniu

Problem:

  • Każdy błąd w przeglądzie kodu jest już w stanie głównym, zanim zostanie złapany.
  • Gorzej, zwykle ktoś spala kilka godzin próbując aby dowiedzieć się, co się stało …

Tak więc chcielibyśmy

  • dokonać przeglądu kodu PRZED dostarczeniem go do „wzorca”.
  • Mieć proces, który działa z globalnym zespołem (bez przeglądów przez ramię !)
  • coś, co nie wymaga, aby indywidualny programista był przy biurku / komputerze być zasilany, aby ktoś inny mógł zdalnie sterować i n (usuń ludzką zależność, deweloperzy wracają do domu w różnych strefach czasowych)

Używamy TortoiseGIT do wizualnej reprezentacji listy zmienionych plików, porównywania plików itp. Niektórzy z nas wpadają do Powłoka GIT, gdy GUI nie wystarcza, ale najlepiej byłoby, gdyby przepływ pracy był prosty i oparty na GUI (chcę, aby narzędzie zniosło wszelkie obciążenia, a nie moi deweloperzy).

Komentarze

  • Czy przed zatwierdzeniem wykonujesz testy jednostkowe?
  • @GuyCoder: W większości tak.
  • Jeśli Twój host nie zapewnia przeglądu kodu możliwości, zdobądź lepszego gospodarza. Przyjrzyj się Gerritowi i zobacz, czy możesz znaleźć hosta, który to zapewnia.

Odpowiedź

A Prostym, ale skutecznym modelem jest model GitHub pull request , w którym współtwórcy przesyłają żądania „proszę scalić w moim kodzie”. Opiekun przegląda zestawy zmian i decyduje, czy wymagają one więcej pracy, czy też nadają się do scalenia. Następnie może połączyć się z główną gałęzią. Osoby zatwierdzające generalnie nie mogą przesyłać bezpośrednio do gałęzi głównej (można to dostosować do własnych upodobań, zezwalamy na bezpośrednie wprowadzanie zatwierdzeń „drugorzędnych”).

Komentarze

  • Mamy zgrany zespół 7 profesjonalnych programistów (w porównaniu z anonimowymi współpracownikami) na całym świecie, więc każdy może przesyłać bezpośrednio do naszego zdalnego mistrza. Chociaż jest to ' link + intro zamiast samodzielnych odpowiedzi, które preferuję, w tym przypadku ma to sens. Świetne napisanie pod linkiem, dzięki!
  • @Sid Z zespołem składającym się z 3 osób nie ' nie pozwoliłbym im wszystkim przejść do mistrzostwa.
  • Pull requesty są również dostępne w Rhodecode i Atlassian Stash
  • @Andrew: Dlaczego nie? Istnieje wiele problemów, które można wygenerować, kierując pracę całych zespołów przez wąski punkt. Można je wszystkie złagodzić, ale w niektórych sytuacjach bardziej odpowiednia jest pojedyncza struktura poleceń i kontroli.

Odpowiedź

Git to rozproszony system kontroli wersji: nie miej tylko jednego repozytorium z jedną gałęzią!

Możesz skonfigurować wiele repozytoriów – jedno dla każdego programisty – a drugie, które jest repozytorium głównym. Gdy jedna z ich gałęzi jest gotowa do scalenia, programista żąda scalenia, a jego zmiany są pobierane z gałęzi / repozytorium do głównego.

Zanim scalenie faktycznie nastąpi, recenzent może pobrać zmiany do ich środowisko i przejrzyj je przed wprowadzeniem ich do opanowania.

Dodatkową zaletą jest to, że w ten sposób programista może mieć dowolną liczbę gałęzi, nazwanych dowolnie, bez przeszkadzania sobie nawzajem lub nawet żeby tak często widzieć swoje brudne pranie.

Naucz się też żargonu: przez „Devs zobowiązują się do głównej gałęzi serwera” masz na myśli, że przesłać swoje zmiany do mastera?

Komentarze

  • tak, push ich praca. Nie możemy ' mieć unikalnych zdalnych repozytoriów na serwerze GIT, ponieważ płacimy hostingowi GIT i naliczają opłaty za repozytorium. Czy chodziło Ci o posiadanie wielu zdalnych oddziałów na programistę? A kiedy mówisz the reviewer can pull the changes into their environment, jakie dokładnie polecenia GIT (lub przepływ TortoiseGIT) masz na myśli?
  • Nie, mam na myśli wiele repozytoriów; po jednym na programistę i w tym repozytorium mogą mieć dowolną liczbę gałęzi. Jeśli chodzi o pull, nie ' nie wiem, jakie polecenie byłoby w TortoiseGIT – ale polecenie to git pull . To ' jest przeciwieństwem wypychania – pobierasz zmiany ze zdalnego repozytorium, aby zaktualizować swoje środowisko pracą, którą mogliby wykonać inni deweloperzy.
  • Wiem git pull 🙂 …Poprosiłem o pełną składnię, aby sprawdzić system repozytoriów / gałęzi / tagów pod kątem wypychania / ściągania, do którego się odnosisz. W tej chwili git pull i tak ' jest tuż obok remote: master – co powoduje problemy. W każdym razie linki Stevena ' były świetne. Dzięki
  • Do wszystkich celów praktycznych w tym przypadku gałąź w hostowanym repozytorium jest taka sama, jak inne repozytorium.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *