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

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?

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.

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.

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

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.

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.

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.

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!