Obsługa standardu git flow
nie jest idealna, jeśli zespół biznesowy chce kontrolować, które funkcje są dostępne w następnym wydaniu. Ale będziesz mieć ten sam problem z innymi mechanizmami rozgałęziania.
Domyślną strukturą dla git flow
jest utworzenie gałęzi funkcji dla każdej nowej funkcji. Po zakończeniu budowania (i testowania) nowej funkcji scalasz gałąź z powrotem w gałąź rozwijania, a następnie usuwa gałąź funkcji. Następnie funkcja zostanie uwzględniona w następnym wydaniu.
Jeśli funkcja nie powinna być zawarta w następnym wydaniu, nie powinieneś scalać gałęzi funkcji z powrotem w gałąź rozwijania. To najlepszy sposób, aby upewnić się, że nie zostanie uwzględniony. Zapobiega to także tworzeniu przez innych programistów kodu, który używa (lub w inny sposób wymaga) nowej funkcji.
Nie polecam wybierania wiśni. Po pierwsze, funkcja może (i często będzie) mieć wiele zatwierdzeń i łatwo jest o niej zapomnieć. Po drugie, jeśli funkcja B używa kodu dodanego w funkcji A, a kierownictwo chce zwolnić element B bez zwalniania funkcji A, prawdopodobnie okaże się, że funkcja B jest zepsuta. A te zależności nie zawsze są łatwe do wykrycia.
Ma sens, że kierownictwo chce nadać priorytet nowym funkcjom, ale każda funkcja powinna zostać ponownie połączona z gałęzią rozwijania wkrótce po jej ukończeniu (i przetestowaniu).
hmm, w jaki sposób ta odpowiedź pomaga rozwiązać problem, o którym wspomina użytkownik, o możliwości wybrania, które funkcje zostały faktycznie wydane? – pal4life
'git checkout master; git merge feature1 feature2 feature3 feature4' - czyż nie jest to potrzebne? Użytkownik wybiera funkcje, które mają zostać zwolnione, łącząc te gałęzie. Nie zwalniasz funkcji, która nie jest połączona z gałęzią główną. – aragaer
Sugerujesz więc, aby po prostu scalić z masterem funkcję, która ma zostać wydana i pozostawić funkcję, która nie zostanie wydana tylko w gałęzi operacji? – pal4life