Żądanie ściągnięcia a żądanie scalenia
Odpowiedzi:
Funkcja „żądania scalenia” GitLab jest równoważna funkcji „żądania ściągnięcia” GitHub . Oba sposoby służą do pobierania zmian z innej gałęzi lub rozwidlenia do gałęzi i łączenia zmian z istniejącym kodem. Są przydatnymi narzędziami do przeglądania kodu i zarządzania zmianami.
Artykuł z GitLab omawia różnice w nazywania funkcji:
Żądania scalania lub pobierania są tworzone w aplikacji do zarządzania git i proszą wyznaczoną osobę o połączenie dwóch oddziałów. Narzędzia takie jak GitHub i Bitbucket wybierają żądanie ściągania nazwy, ponieważ pierwszym ręcznym działaniem byłoby ściągnięcie gałęzi funkcji. Narzędzia takie jak GitLab i Gitorious wybierają żądanie scalenia nazwy, ponieważ jest to ostateczna czynność wymagana od cesjonariusza. W tym artykule będziemy się do nich odnosić jako żądania scalenia.
„Żądania scalenia” nie należy mylić z git mergepoleceniem. git pullPolecenia „pull request” nie należy mylić z poleceniem. Oba gitpolecenia są używane w tle zarówno w żądaniach ściągania, jak i scalania, ale żądanie scalania / ściągania odnosi się do znacznie szerszego tematu niż tylko te dwa polecenia.
Są to ta sama funkcja
Żądania scalania lub pobierania są tworzone w aplikacji do zarządzania git i proszą wyznaczoną osobę o połączenie dwóch oddziałów. Narzędzia takie jak GitHub i Bitbucket wybierają żądanie ściągania nazwy, ponieważ pierwszym ręcznym działaniem byłoby ściągnięcie gałęzi funkcji. Narzędzia takie jak GitLab i Gitorious wybierają żądanie scalenia nazwy, ponieważ jest to ostateczna czynność wymagana od cesjonariusza. W tym artykule będziemy się do nich odnosić jako żądania scalenia.
Z mojego punktu widzenia oznaczają to samo działanie, ale z różnych perspektyw:
Pomyśl o tym, Alice dokonuje pewnych zmian w repozytorium A, które zostało opracowane z repozytorium Boba B.
Kiedy Alice chce „scalić” swoje zmiany w B, tak naprawdę chce, aby Bob „wyciągnął” te zmiany z A.
Dlatego z punktu widzenia Alicji jest to „żądanie scalenia”, podczas gdy Bob postrzega je jako „żądanie ściągnięcia”.
Istnieje subtelna różnica w zakresie zarządzania konfliktami. W przypadku konfliktów żądanie ściągnięcia w Github spowoduje zatwierdzenie scalenia w gałęzi docelowej . Po znalezieniu konfliktu w Gitlab dokonane modyfikacje będą dotyczyły scalania w gałęzi źródłowej .
Zobacz https://docs.gitlab.com/ee/user/project/merge_requests/resolve_conflicts.html
„GitLab rozwiązuje konflikty, tworząc zatwierdzenie scalania w gałęzi źródłowej, które nie jest automatycznie łączone z gałęzią docelową. Umożliwia to sprawdzenie zatwierdzenia scalenia i przetestowanie go przed scaleniem zmian, zapobiegając niezamierzonym zmianom wchodzącym do gałęzi docelowej bez przeglądania lub przerywania kompilacja ”.
GitLab 12.1 (lipiec 2019) wprowadza różnicę:
„ Scal prośby o poufne informacje ”
Podczas omawiania, planowania i rozwiązywania problemów poufnych, takich jak luki w zabezpieczeniach, może być szczególnie trudne dla projektów typu open source, ponieważ repozytorium Git jest publiczne.
Od 12.1 możliwe jest teraz rozwiązywanie poufnych problemów w projekcie publicznym w ramach usprawnionego przepływu pracy za pomocą przycisku Utwórz poufne żądanie scalenia, który pomaga utworzyć żądanie scalenia w prywatnym rozwidleniu projektu.
Patrz „ Zagadnienia poufne ” z wydania 58583 .
Podobna funkcja istnieje w GitHub, ale polega na utworzeniu specjalnego prywatnego widelca, zwanego „ poradnikiem bezpieczeństwa opiekuna ”.
Jak wspomniano w poprzednich odpowiedziach, oba służą prawie w tym samym celu. Osobiście lubię git rebase i prośbę o scalenie (jak w gitlab). Odciąża recenzenta / opiekuna, upewniając się, że podczas dodawania żądania scalenia gałąź funkcji zawiera wszystkie najnowsze zatwierdzenia wykonane w gałęzi głównej po utworzeniu gałęzi funkcji. Oto bardzo przydatny artykuł szczegółowo wyjaśniający rebase: https://git-scm.com/book/en/v2/Git-Branching-Rebasing