Jak skonfigurować przegląd kodu za pomocą Gitlab?

85

Jak skonfigurować przegląd kodu za pomocą Gitlab? Widzę to na liście funkcji na stronie Gitlab, ale nie wydaje mi się, aby znaleźć instrukcje, jak to skonfigurować (w tym względzie jakikolwiek link do instrukcji obsługi Gitlab byłby najbardziej mile widziany).

Niektóre z moich poszukiwań wskazały, że najlepszym rozwiązaniem są „prośby o scalenie” ... ale uważam, że są one ograniczające. Wydane żądanie scalenia pokazuje wszystkie zatwierdzenia między jedną gałęzią a drugą. Wydaje mi się, że mogę przeglądać tylko różnice wygenerowane dla każdego pojedynczego zatwierdzenia. Na przykład, powiedzmy, że mam plik, który chcę przejrzeć. Jest to nowy plik, ale wprowadziłem do niego zmiany po 10 zatwierdzeniach w gałęzi deweloperskiej. Jeśli wydam prośbę o scalenie tej gałęzi deweloperskiej z integracji, widzę 10 zatwierdzeń, z których każdy pokazuje przyrostowe zmiany wprowadzone w pliku ... Chcę przejrzeć całość. To jest nowe!

Czy szczekam tutaj na niewłaściwe drzewo? Czy istnieje rzeczywiste narzędzie do przeglądania kodu, którego mogę użyć w GitLab, czy też żądania scalenia są drogą do zrobienia, a jeśli tak, to używam ich nieprawidłowo? jaki jest najlepszy sposób na skonfigurowanie odpowiedniego przeglądu kodu?

djc6535
źródło
1
GitLab 6.4 i jego widok porównawczy side-by-side mogą pomóc w przejrzeniu kodu: zobacz moją odpowiedź poniżej
VonC
Dzięki GitLab 13.1 (czerwiec 2020) masz teraz recenzje wniosków o scalenie. Zobacz moją zredagowaną odpowiedź poniżej
VonC

Odpowiedzi:

24

Uwaga: od GitLab 6.4 dostępny jest widok różnic obok siebie : patrz „ pull request 5308 ”.

(Lipiec 2013)Nie ma jednak jeszcze możliwości komentowania każdej linii, tylko na poziomie pliku.
Daniel Sokolowski wspomina w komentarzach, że komentarze Per line są teraz obsługiwane (09/2014):

Członkowie Twojego zespołu mogą komentować żądanie scalenia ogólnie lub w określonych wierszach z komentarzami do linii.

To nadal może pomóc w przeglądaniu kodu.

https://f.cloud.github.com/assets/4224518/1558702/e0fe633a-4fa3-11e3-9388-3f3e445cb6d4.png


6 lat później, dla GitLab 13.1 (czerwiec 2020) :

Scalanie recenzji próśb przeniesiono do Core

Pierwotnie wprowadzona w GitLab 11.4 jako funkcja GitLab Premium, Merge Request Reviews pozwala recenzentom na:

  • przesłać wiele komentarzy jednocześnie,
  • zmniejszenie hałasu powiadomień dla autora żądania scalenia i
  • umożliwiając bardziej spójny i usprawniony proces recenzji.

https://about.gitlab.com/images/13_1/batch_comments.png

Od czasu jej wprowadzenia ponownie oceniliśmy jego miejsce w naszym modelu cenowym opartym na nabywcach iw ramach 13.1 z radością ogłaszamy, że ta funkcja została teraz przeniesiona do GitLab Core.

Zobacz Dokumentacja i wydanie

VonC
źródło
Obsługiwane są teraz komentarze w poszczególnych wierszach: „Członkowie zespołu mogą komentować żądanie scalenia ogólnie lub w określonych wierszach z komentarzami do linii”. ( about.gitlab.com/2014/09/29/gitlab-flow )
Daniel Sokolowski
1
@DanielSokolowski Świetnie! W odpowiedzi zawarłem Twój komentarz, aby uzyskać lepszą widoczność.
VonC
9

Robię recenzje kodu w Gitlab od ponad dwóch miesięcy bez prawie żadnych tarcia. Mam setup RSS2Email do wysyłania powiadomień e-mail za każdym razem deweloper popycha nowe rewizje. Następnie używam funkcji komentarzy Gitlab dla zatwierdzeń, aby zrobić kilka komentarzy na temat przesłanego kodu.

Niestety, Gitlab nie pozwala na komentarze do samych plików, tylko w zatwierdzeniach (tak jak chyba Github). Ilekroć znajdę się w sytuacji, w której muszę skomentować coś, co przegapiłem w poprzednim zatwierdzeniu, używam narzędzia do obwiniania, aby znaleźć zatwierdzenie, które wprowadziło / zmieniło sekcję kodu do skomentowania.

Jest daleki od ideału, ale jak dotąd działa dobrze.

Herberth Amaral
źródło
1
Zamiast rss2email można by używać powiadomień Gitlab, aby otrzymywać powiadomienia o pushach.
vadipp
Mam ten sam problem / obejście. Uważam, że byłoby fajnym dodatkiem do funkcji, gdybyś mógł dodać komentarz do prawego zatwierdzenia, obwiniając konkretną linię w widoku różnic lub plików (mam na myśli przeglądanie plików lub różnic w interfejsie internetowym, a nie uruchamianie winy).
AlejandroVD
2

Możesz zobaczyć przesłany kod w Merge Request dla innego repozytorium lub w aktualnym repozytorium.
przykład http://demo.gitlab.com/diaspora/diaspora/commits/master

Następnie możesz dodawać komentarze do Replyzatwierdzonych zmian w pliku (przycisk ) lub do całego zatwierdzenia

przykład http://demo.gitlab.com/diaspora/diaspora/commit/42f47626890218a180870bc3f44ec57625b0779c

Wynikowa komunikacja to przegląd kodu . Jednak osobiście zalecam przeglądanie kodu na jednym komputerze z komunikacją twarzą w twarz, gdy tylko jest to możliwe, i używanie narzędzi do zapisywania wyników lub gdy potrzeba więcej formalności.

W przypadku pliku revue, który ma wiele zatwierdzeń, np. Http://demo.gitlab.com/diaspora/diaspora/blame/master/README.md spójrz na to, używając, blameaby zrozumieć, kto co zrobił. Jednak w tym widoku nie ma możliwości komunikowania się i dodawania komentarzy. Poleciłbym po prostu dodać zmiany jako komentarze w tym przypadku.

Paul Verest
źródło
7
Otrzymuję 404 za pierwszy, drugi i ostatni link w Twojej odpowiedzi.
Bryan Oakley,
1
Jak napisano na stronie głównej, demo.gitlab.com „TO SANDBOX - jest resetowany co godzinę”, więc wszystkie przykłady zostały usunięte. To nie jest dobry nośnik przykładów.
Uriah Blatherwick
Tak, rozważ ponowne skonfigurowanie go z odpowiednimi przykładami. Twoja odpowiedź wydaje się być ogólnie solidną radą.
dane z
0

Tak. Prośby o scalenie to sposób, w jaki przeprowadzane są wzajemne oceny.

Powinna istnieć zakładka „diff”, która pokaże zmiany wszystkich zatwierdzeń (wspomniane tutaj: http://youtu.be/DyAX8ws5OIc?t=3m2s ).

Film wyjaśnia również ładnie, w jaki sposób można go wykorzystać do recenzji.

cebula
źródło
0

Normalnym przypadkiem przeglądania kodu jest przeglądanie kodu w gałęzi przed scaleniem z wzorcem lub podobnym. Mam sytuację, w której opracowałem projekt i chcę, aby cały kod został przejrzany przez wszystkich członków zespołu.

To co zrobiłem to:

Sprawdź pierwsze zatwierdzenie, wprowadź w nim zmianę, zatwierdź i wciśnij

git co -b FIRST_COMMIT eb67f06c2b3222c0219214b176c41922bc454881
vi README.md
git add README.md
git ci -m "First commit modified so can get full diff against it"
git push --set-upstream origin FIRST-COMMIT

Sprawdź ostatnie zatwierdzenie, wprowadź w nim zmianę, zatwierdź i wciśnij

git co -b master
vi README.md
git add README.md
git ci -m "Last commit modified so can get full diff against it"
git push --set-upstream origin LAST-COMMIT

W GitLab / GitHub utwórz żądanie ściągnięcia

  • To jest jedno połączenie LAST_COMMIT z FIRST_COMMIT

Pracuje dla mnie!

HankCa
źródło
Czy to nie pozostawia cię z dwoma "śmieciowymi" gałęziami w repozytorium i bez śledzenia komentarzy w gałęzi głównej? Jeśli komentarze wymagają zmian w kodzie, czy następnie scalasz je ze wzorcem?
user2084572
Tak, będą dostępne gałęzie FIRST_COMMIT i LAST_COMMIT, które można łatwo usunąć ( git br --delete --force origin FIRST_COMMIT LAST_COMMIT; git br --delete --force FIRST_COMMIT LAST_COMMIT). Możesz użyć innej gałęzi poza wzorcem, aby wprowadzić zmiany w tym lub utworzyć osobne wydania ręcznie. A później utwórz jedną lub więcej gałęzi (np. Jedną na problem), jeśli jest zbyt dużo informacji zwrotnych.
HankCa