Czy w GitHub można oprzeć gałąź operacji na innej gałęzi operacji?

22

Używamy GitHub Flow w naszym projekcie i przez większość czasu otwieramy nową gałąź funkcji od master , wykonujemy tam trochę pracy, otwieramy PR, przeglądamy kod i łączymy z powrotem w master .

Jednak moja obecna praca zależy od innej kwestii, nad którą pracuję feature-branch-A. Czy koszerne jest tworzenie mojej gałęzi z tej innej gałęzi, czy jest to sprzeczne z duchem GitHub Flow?

Alternatywą byłoby oparcie mojej gałęzi na master i scalenie zmian z feature-branch-A(często).

Która opcja jest preferowana w przepływie GitHub?

Borek Bernard
źródło

Odpowiedzi:

24

Oto przepływ pracy, który śledzę, gdy rozgałęziam się z gałęzi funkcji:

  1. Utwórz feature-branch-Bzfeature-branch-A
  2. Pracować nad feature-branch-B
  3. Jeśli feature-branch-Apo rozgałęzieniu zostaną dodane kolejne zatwierdzenia , dokonaj bazowania feature-branch-Bnafeature-branch-A
  4. Zakończ pracę feature-branch-Bi poczekaj, aż feature-branch-Azostanie scalony master.
  5. Gdy feature-branch-Ajest włączony do master, rebase feature-branch-Bnamaster
  6. Połącz się feature-branch-Bwmaster

Postępując zgodnie z powyższym obiegiem pracy, okaże się, że rozgałęziłeś się masterpo feature-branch-Ascaleniu. Nie musisz czekać, aż feature-branch-Apołączenie zostanie scalone, aby rozpocząć pracę feature-branch-B. Dostaniesz jednak czystą historię bez skomplikowanych drzew.

geoji
źródło
To była dokładnie odpowiedź, której szukałem! Zaoszczędziłeś mi bólu głowy związanego z rozwiązywaniem tego, dzięki!
Vance Palacio
Nie rebase już opublikowane commits
Sebi2020
8

Myślę, że jest to całkowicie w porządku, jeśli utworzysz tę funkcję w innej funkcji.

Ale nie rób tego często. Widzę jednego programistę, który to zrobił, i tydzień lub dwa wyrzucił 10 PR za połączenie. To było całkowicie wyczerpujące dla innych członków do przeglądu i trudne do połączenia. Staraj się nie robić drzew w git. Pomaga to w dzieleniu na błędy.

Ladislav Prskavec
źródło
7

Kluczową rzeczą, do której git-flow miał się odnieść, była umiejętność rozumienia roli danej gałęzi oraz tego, z czym rozgałęzia się i łączy.

Idealnie wszystkie gałęzie łączą się z powrotem w linię kodową, z której zostały scalone. Zazwyczaj jest to połączenie z linią główną (w git-flow to jest dev). Uwzględnij gałęzie i połącz z dev, zwolnij gałęzie i scal z dev (z dodatkowym scaleniem master). Poprawki rozgałęziają się i łączą z master (z tym dodatkowym połączeniem z powrotem do dev).

Każda linia kodowa rozgałęzia się i łączy z powrotem do swojego elementu nadrzędnego. Linia kodu może pobrać kod z innych linii kodu w dowolnym momencie, jeśli jest to konieczne.

Jeśli gałąź z gałęzi funkcji to „Chcę zbadać ten sposób rozwiązania problemu w tej gałęzi funkcji” - doskonale. Rozgałęzia się z gałęzi funkcji, zatwierdza część kodu i scala z powrotem do gałęzi funkcji (lub jest odrzucany).

  1. gałąź z funkcji
  2. zbadać pomysł
  3. scal do funkcji

To, czego chcesz jednak uniknąć, to coś, co wygląda:

  1. odgałęzienie od wymaganej funkcji
  2. pracować nad kodem
  3. scal z dev, gdy wymagana funkcja zostanie zakończona
  4. sprawdź funkcjonalność (i dodatkowe zatwierdzenia) w gałęzi funkcji
  5. połączyć z dev

Powodem jest to, że początek i koniec się nie zgadzają - nieco trudniej jest zrozumieć, co to jest i było. Nie jest to niemożliwe, ale sprawia, że ​​ktoś potrzebuje nieco więcej czasu, aby zrozumieć jego rolę.

Jeśli jednak jest to nowa funkcja, która zależy od kodu, który nie został jeszcze znaleziony w dev, przepływ powinien wyglądać następująco:

  1. oddział z dev
  2. połączyć z wymaganą funkcją
  3. pracować nad kodem
  4. scal z dev, gdy wymagana funkcja zostanie zakończona
  5. sprawdź funkcjonalność (i dodatkowe zatwierdzenia) w gałęzi funkcji
  6. połączyć z dev

Zauważ, że zaczyna się od odgałęzienia od dev i kończy scaleniem z dev.

To powiedziawszy, prawdopodobnie najlepszą rzeczą do zrobienia jest uniknięcie łączenia jednej funkcji do drugiej. Rozgałęź tę funkcję, rób wszystko, co jest potrzebne ... i czekaj.

  1. oddział z dev
  2. pracować nad kodem
  3. scal z dev, gdy wymagana funkcja zostanie zakończona
  4. sprawdź funkcjonalność (i dodatkowe zatwierdzenia) w gałęzi funkcji
  5. połączyć z dev

Zapewnia to najbardziej stabilny zestaw gałęzi i kodu.

Coś, co należy wziąć pod uwagę w przyszłych pracach, to mieć funkcję publikowania niezbędnych interfejsów do współdziałania z innymi funkcjami - nawet jeśli kod implementacji nie jest kompletny. Zostałoby to połączone z dev, a następnie wymagana funkcja mogłaby działać z tych interfejsów, podobnie jak funkcja przyszłości. To prawdopodobnie pozwoliłoby na dalszy rozwój funkcji przyszłej (kodowanie w stosunku do interfejsów, testowanie w stosunku do kodów pośredniczących, które implementują interfejsy), niż gdyby musiał czekać na scalenie wymaganej funkcji.


źródło
W trzecim zestawie kroków wadą jest to, że krok 1 musi zawierać trochę „fałszywego zatwierdzenia”. W mojej sytuacji nie mam nic przydatnego do zatwierdzenia, dopóki się required-featurenie połączy.
Borek Bernard
Nadal wskazuję na to jako jeden z moich ulubionych artykułów na temat rozgałęziania: Zaawansowane strategie rozgałęziania SCM . Chociaż koncentruje się na scentralizowanym systemie kontroli wersji, pomysły na role, które przedstawia dokładnie odwzorowują na git-flow.
A jeśli chodzi o atrapę manekina, to właśnie tam jest ten ostatni akapit. Przydałaby się funkcja, która działała i kończyła się jako „zapewnia interfejsy do robienia rzeczy”. Wtedy zarówno wymagana funkcja, jak i funkcja przyszłości mogłyby zadziałać z tych interfejsów. Podczas gdy wymagane funkcje działały na implementację interfejsów, przyszłe funkcje byłyby w stanie je usunąć i wykonać testy przeciwko nim - czekając na połączenie wymaganej funkcji z programistą.
Zastanawiasz się, jak zły jest twój drugi zestaw kroków. Czy w praktyce jest problem, że gałąź nie ma „tego samego” początku i końca? Nie sądzę, żeby to mnie zbytnio martwiło, ale może to poważny bałagan?
Borek Bernard
Jest to kwestia jasnego opisania za pośrednictwem gałęzi, zatwierdzenia i scalenia historii, która gałąź jest gałęzią nadrzędną. W ramach git-flow powinieneś podążać za systemem opisanym w gałęziach funkcji git flow . Gałąź funkcji rozgałęzia się z gałęzi programistycznej i łączy się z powrotem w celu opracowania. Kiedy zaczniesz rozgałęziać z innych gałęzi funkcji, staje się mniej jasne, jaka jest rola tej gałęzi. Zachęcam do czekania na zakończenie wymaganej funkcji, jeśli nie możesz teraz postępować bez kodu.
1

Gałąź funkcji jest zwykle uważana za mniej stabilną niż pień (develop / master), więc prawdopodobnie poddasz się bardziej podstawowym zmianom niż normalnie, jeśli oprzesz swoją pracę na jednym.

Ponadto, choć normalnie jest to niezadowolone, jeśli gałąź została wypchnięta, nierzadko osadzanie gałęzi funkcji na gałęzi nadrzędnej, aby uzyskać lepszą historię, ale byłoby to bardziej skomplikowane, gdyby zwisały z niej dodatkowe gałęzie, więc „zasadniczo tworzą nowe ograniczenia dla właściciela oddziału nadrzędnego, a także potencjalne bóle głowy dla siebie.

To powiedziawszy, nie ma ścisłej reguły przeciwko temu. W końcu to tylko wzorce i najlepsze praktyki.

Edycja: pominięto część twojego pytania. Scalenie gałęzi funkcji z własną, opartą na masterie, tak naprawdę nie pozwala uniknąć wyżej wymienionych problemów i może stworzyć jeszcze bardziej skomplikowaną historię.

Tak więc, gdybym był w twoich butach i mógłbym odroczyć pracę, dopóki funkcja a nie zostanie wykonana, lub zrób coś innego, zrobiłbym to.

axl
źródło