Gdzie idą poprawki w modelu git-flow?

W potocznie zwanych poprawkami do modelu Git-flow pojawiają się w swojej konkretnej hotfix-*gałęzi, a drobne poprawki integracyjne znajdują się tuż przed wydaniem w release-*gałęzi. Ogólne poprawki błędów z poprzedniej wersji wydają się nie mieć miejsca.

Gdzie powinny się pojawić? Czy powinni być we własnej bug-*gałęzi, która rozgałęzia się develop(podobnie jak featuregałęzie)?

git gitflow

— But
źródło

Dlaczego niekrytyczny błąd w wydanym kodzie miałby się różnić od małej funkcji w celu wywołania innego zachowania niż to, co obecnie robi aplikacja?

— Bart van Ingen Schenau

@BartvanIngenSchenau Czy polecasz je jako feature-*oddziały? Czy poprawkę dotyczącą błędnego zachowania można uznać za cechę?

— But

@ But Myślę, że Bart ma na myśli to, że powinieneś traktować je jak funkcje, niekoniecznie używając tego samego prefiksu gałęzi .

— Darkhogg

@Shoe: git-flow w każdym oddziale, z wyjątkiem master, develop, release-*czy hotfix-*jest oddział funkcja, więc można użyć dowolnego prefiks chcesz i używać innego przedrostka dla błędów. Jaka jest różnica między błędnym zachowaniem, które działa zgodnie ze specyfikacją, a błędnym zachowaniem, które odbiega od specyfikacji? W obu przypadkach jest to zachowanie błędne, ale tylko ostatni jest błędem.

— Bart van Ingen Schenau

Krótka odpowiedź: Tak, gałęzie z poprawkami błędów, które będą planowane w najbliższym wydaniu, powinny znajdować się w gałęziach funkcji. Jak nazwiesz gałęzie funkcji lub te gałęzie dla poprawek błędów, zależy od ciebie i standardów twojego zespołu, ale należy je traktować identycznie, jeśli podążasz za Gitflow.

Komentarz Barta van Ingena Schenau podnosi dobrą rację .

Gitflow ma pięć typów oddziałów: master, develop, gałęzie poprawek (z przedrostkiem hotfix-), oddziały zwalniające (poprzedzona znakiem release-, a gałęzie posiadają. masterI developgałęzie są długo działa oddziałów i nie popełnić bezpośrednio do nich. release-Gałęzie są wykonane, aby narysować linię dla konkretnej wersji, a następnie obsługa poprawek błędów między identyfikacją następnej wersji a wydaniem. hotfix-Gałęzie są przeznaczone do krytycznych, poza cyklicznych wydań do produkcji. feature-Gałęzie służą do opracowania indywidualnych funkcji dla niektórych przyszłych wydań.

Jadąc od środowisk, w których są używane PRS i oprócz indywidualnej deweloper zobowiązuje się do gałęzi funkcji, nic nie powinno być zaangażowana bezpośrednio master, developlub oddział uwalnianiu. Zapewnia to, że każda zmiana jest sprawdzana pod kątem kodu, a także zapewnia odpowiednie pokrycie testów i przekazanie testów w środowisku CI przed wprowadzeniem zmian. Byłbym przeciwny wszelkim zatwierdzeniom bezpośrednio w jednej z tych gałęzi, chociaż wydaje się, że sam Gitflow nie robi tego t mieć problemy z wprowadzaniem poprawek lub zmian przedpremierowych bezpośrednio w gałęzi wydania, a następnie wciąganiem ich do rozwoju, a następnie gałęziami funkcji.

W twoim szczególnym przypadku release-oddział nie jest odpowiednim miejscem. Oprogramowanie zostało już wydane i jest w master. Kiedy wydanie zostanie scalone w master i tam otagowane, gałąź wydania dla tego konkretnego wydania przeszła już swój cel i niekoniecznie musi już istnieć. Jeśli jesteś aktywny w czyszczeniu swoich gałęzi (które moim zdaniem powinni być wszyscy), nie jest to nawet opcja.

Jeśli poprawka nie jest krytyczna, gałąź poprawek również nie pasuje. Celem działu poprawek jest umożliwienie komuś bardzo szybkiego wprowadzenia krytycznych zmian w produkcji bez zakłócania ciągłego rozwoju. Korzystanie z nich powinno być raczej wyjątkiem niż normą dla zespołu programistów. Zasadniczo poprawki krytyczne powinny być wyjątkowym przypadkiem.

Pozostała tylko gałąź funkcji. Zauważ, że sekcja strony, do której prowadzi pytanie dotyczące gałęzi funkcji, mówi nawet, że gałęzie funkcji są „czasami nazywane gałęziami tematycznymi”. Jeśli Twoja zmiana dotyczy jakiejś nadchodzącej wersji i nie spełnia kryteriów poprawki, powinna ona znajdować się w jednej z tych gałęzi.

— Thomas Owens
źródło

Zgadzamy się, że nie powinno być bezpośrednich zobowiązań do opanowania, rozwoju lub wydania gałęzi. Ale jaki powinien być przepływ PR, gdy znajdziesz błąd w gałęzi wydania i należy go naprawić zarówno w gałęzi wydania, jak i rozwoju. Ma to swoje własne wyzwania, jeśli cała gałąź wydania nie jest jeszcze gotowa do połączenia w fazie programowania, ale poprawka powinna zostać wykonana w obu miejscach. Jeśli chcesz, mogę wysłać nowe pytanie w tej sprawie.

— SAP

@Sap Nowe pytanie byłoby dobre, ale jeśli je opublikujesz, wyjaśnij, dlaczego poprawka jest tak istotna, że należy ją połączyć w jedno i drugie - wydaje się to sugerować, że nie znaleziono krytycznego problemu przed jego wprowadzeniem develop, a nie znalezione między momentem wprowadzenia a utworzeniem gałęzi wydania i / lub że gałąź wydania istnieje od dawna. Po prostu jednak uważam, że jedynym wyborem jest wybranie typu cherry (sugeruję poprawkę i żądanie ściągnięcia do gałęzi wydania, scalenie do gałęzi wydania i wybranie rozwijania poprzez rozwijanie).

— Thomas Owens

Jeśli jest to pojedyncze zatwierdzenie, wykonaj dobrze zidentyfikowane zatwierdzenie i umieść je na gałęzi programistycznej, w przeciwnym razie utwórz gałąź funkcji.

Jest też komentarz autora git-flow, który mówi dokładnie o co pytasz: brakujące gałęzie z poprawkami # 24

— Deb
źródło

Dzięki, link, który udostępniasz, wyjaśnił mi to.

— arcseldon