Po co używać żądań ściągania zamiast scalania

Jaka jest zaleta korzystania z żądań ściągania zamiast zwykłego scalania gałęzi bez głównego? Szczególnie w zespole, w którym wszyscy programiści mają pełny dostęp do master.

Żądania ciągnięcia przewidują czeki i salda, nawet jeśli każdy może naciskać na opanowanie.

Największą zaletą jest to, że dają one możliwość przeglądu kodu. Osoba odpowiedzialna za wykonanie ściągania może spojrzeć na kod i testy oraz upewnić się, że spełnia wszelkie wytyczne organizacji lub zespołu. Istnieją również inne powody do przeglądu kodu - edukacja, znajdowanie wad lub ulepszeń, szkolenie zespołu w systemie, zapewnianie testerom białego pola widzenia systemu.

Jeśli osoba wykonująca ściąganie zna architekturę systemu, może upewnić się, że zmiany pasują do architektonicznej wizji systemu, zwłaszcza jeśli cały zespół może nie mieć wizji długoterminowej.

Rozwijanie nawyku korzystania z próśb ściągania może również pomóc zespołowi, jeśli zdecydujesz w przyszłości, że cały zespół nie powinien mieć dostępu do mistrza. Jeśli Twój zespół powiększy się, a zwłaszcza jeśli masz członków zespołu, którzy są nowi w produkcie i / lub nowi w Git, nieudzielenie im dostępu do mistrza może być bezpieczniejsze dla integralności produktu.

Po wykonaniu zarówno rozgałęzień funkcji, jak i forksów + wniosków o ściągnięcie uważam, że wnioski o ściągnięcie oferują niewielką przewagę, gdy wszyscy rozwijacie się w tym samym zespole lub firmie

Oferują dobry mechanizm i interfejs do przeglądania kodu, ale także komplikują i spowalniają cały proces „kończenia pracy”. Zwłaszcza jeśli masz wiele małych funkcji, każda czeka na sprawdzenie, scalanie, a następnie wszystkie pozostałe są ponownie scalane z masterem, aby pobrać zmiany itp. Jeśli masz duże funkcje, trudno je sprawdzić, więc jesteś uwikłany .

Powiedziawszy, że możesz wykonywać żądania ściągania między oddziałami w tym samym repozytorium. Nie musisz widelec ani mieć różnych uprawnień.

Dodatkowo musisz wziąć pod uwagę całą metodologię i przepływ pracy. Czy masz również system biletowy, CI, automatyczne testy akceptacyjne itp? Czy recenzje kodu zapewniają istotną pojedynczą kontrolę przed wprowadzeniem kodów, czy są to tylko ćwiczenia z pieczątką, które są zbędne w wyniku innych kontroli w toku pracy?

Istnieje spostrzeżenie zwane prawem Conwaya, które stwierdza:

organizacje, które projektują systemy ... są zobowiązane do tworzenia projektów będących kopiami struktur komunikacyjnych tych organizacji.

Co to ma wspólnego z żądaniami ściągania? Żądania ściągania są głównym kanałem komunikacji na krytycznym skrzyżowaniu kodu. Zapewniają one możliwość przeglądu, zautomatyzowanego testowania i ulepszenia, zanim kod przejdzie do kolejnych etapów testowania i produkcji, w których zmiany te są znacznie trudniejsze do wycofania się i marnują znacznie więcej czasu.

Podobnie, prawo Conwaya sugeruje, że jeśli chcesz mieć architekturę mikrousługową z wyraźnie oddzielonymi obszarami autonomicznej odpowiedzialności i dobrze zdefiniowanymi interfejsami, wówczas kanały komunikacji Twojej organizacji powinny odzwierciedlać architekturę, którą chcesz osiągnąć. Oznacza to, że małe zespoły po 5–10 osób powinny mieć bezpośredni dostęp do dowolnej mikrousługi, a każda osoba spoza tego zespołu powinna zostać poproszona o wykonanie polecenia ściągnięcia. Zapewnia to, że osoby najbardziej zaznajomione z mikrousługą to osoby, które przeglądają i doradzają w tej sprawie.

Kiedy masz dużą organizację, w której wszyscy mają bezpośredni dostęp do wszystkich miejsc, kanały komunikacji o najmniejszym oporze przygotowują cię do stworzenia dużej kuli błotnej architektury.

Prośby odciągania wydają się być ciężarem tylko wtedy, gdy nie oddasz niczego w zamian. Pracowałem w środowiskach, w których nie mogę nic zrobić przez tydzień, ponieważ kompilacja jest zawsze zepsuta, i pracowałem w środowiskach, w których ktoś wysyła żądanie ściągnięcia i nawet nie muszę go sprawdzać, ponieważ się zepsuł kompilacja CI i mówię wam, są warte każdej sekundy wysiłku.

Karl Bielefeldt ma dokładnie rację. Dodałbym: chodzi o jakość.

W wielu (większości?) Sklepach nie ma formalnych procesów rządzących rozwojem, co powoduje: „Pracowałem w środowiskach, w których nie mogę nic zrobić przez tydzień, ponieważ kompilacja jest zawsze zepsuta i pracowałem w środowiskach, w których ktoś wysyła żądanie ściągnięcia i nawet nie muszę go sprawdzać, ponieważ zepsuł kompilację CI, i mówię wam, są warte każdej sekundy wysiłku. ”

To naprawdę jest warte wysiłku.

Do przeglądu kodu używamy żądań ściągnięcia - żaden kod nie powinien zostać scalony z główną gałęzią programistyczną (w naszym przypadku zwykle „rozwija się”, ale czasami „nadrzędny”) bez wcześniejszego przetworzenia. Nie egzekwujemy tego za pomocą kontroli repozytorium, ale to dlatego, że nie musimy - nasi programiści są wystarczająco dojrzali, aby nie nadużywać tego procesu.