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

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?

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.

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.

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.

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.