Żądanie ściągnięcia a żądanie scalenia

Jaka jest różnica między żądaniem Pull a żądaniem Scal.

W Github jest to żądanie ściągnięcia, a na przykład w GitLab to żądanie scalenia ... Czy istnieje różnica między nimi obiema?

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.

- https://about.gitlab.com/2014/09/29/gitlab-flow/

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