Ponowne użycie połączonego oddziału, dobra praktyka?

Obecnie tworzyłem nowy oddział za każdym razem, gdy muszę dodawać nową funkcję do mojej aplikacji.

Kiedy moja funkcja jest skończona i funkcjonalna, łączę ją z gałęzią master.

Ale później, kiedy muszę zaktualizować tę funkcję (jak ulepszenie), czy lepiej jest utworzyć nową gałąź, czy też muszę zmienić bazę poprzedniej wersji na master, czy aktualizacja następnie łączy się ponownie?

Na przykład mam gałąź o nazwie modeling-member w aplikacji Ruby on Rails. Później muszę dodać atrybuty do modelu członka (który został utworzony w tej gałęzi). Co powinienem zrobić? Zrewolucjonizuj tę gałąź za pomocą wzorca, zaktualizuj model i połącz go ponownie lub po prostu utwórz nową gałąź?

Utwórz nowy oddział, ponieważ:

• W nowym oddziale jest mniej prawdopodobne, że wystąpią konflikty scalania, gdy skończysz i chcesz scalić go w master. Niewiele rzeczy jest bardziej podatnych na błędy niż rozwiązywanie konfliktów scalania.

• Ta funkcja mogła przejść kilka zmian i aktualizacji od czasu jej oryginalnej implementacji, przez co oryginalna gałąź była całkowicie przestarzała. Jedynym sposobem na zaktualizowanie go jest połączenie master z gałęzią funkcji ... w tym momencie rozgałęziasz master w niepotrzebnie skomplikowany sposób.

• Jeśli tylko dla uproszczenia, zwykle dobrym pomysłem jest taki sam przepływ pracy w przypadku aktualizacji, poprawek błędów i nowych funkcji. Dotyczy to rozgałęzień, recenzji kodu, użycia narzędzia do śledzenia błędów i praktycznie wszystkiego innego. Różnica między aktualizacją istniejącej funkcji, dodaniem nowej funkcji a naprawieniem błędu jest często subiektywna.

Użyj nowego oddziału.

W przypadku nazewnictwa można rozważyć użycie formatu wewnętrznego, że ten_work jest rozszerzeniem lub zmianą na ten_work

Na przykład możesz nazwać drugą gałąź

modeling-member--attributes

z - sygnalizującym, że nazwa po lewej stronie jest oryginalną gałęzią

Zajmujemy się nieco podobnym problemem, ponieważ używamy numerów biletów Jira do nazw oddziałów. Czasami jest trochę pracy dla tego samego biletu. Czasami zmiany bazy danych nie można przywrócić. W takich przypadkach używamy na przykład oryginalnej gałęzi SEND-123 i drugiej gałęzi jako SEND-123a

Jeśli chcesz zapisać tylko zatwierdzenia ze scalenia w systemie głównym i używasz github, możesz użyć „Widelca” do każdej nowej funkcji i wykonać żądanie ściągnięcia i zaakceptować żądanie ściągnięcia po wykonaniu każdej nowej funkcji.

Nie polecam pracy na starych gałęziach, ponieważ konflikty można uzyskać, łącząc je z głową mistrza i oczywiście nie jest to konieczne ...