Jakie są zalety korzystania z rozgałęziania jako programisty solo?

Po pierwsze, wiem, że zadawano wiele pytań dotyczących VCS jako programisty solo, ale często są one zbyt szerokie. Dotyczy to tylko rozgałęzienia, a mimo to zostało oznaczone jako duplikat ... rzekomy duplikat jest ponownie oznaczony jako kolejny duplikat innego pytania, które jest zbyt szerokie i nie dotyczy konkretnie rozgałęziania. W ten sposób moje pytanie jest wyjątkowe.

Jakie są zalety korzystania z rozgałęziania jako programisty solo? Często widziałem, że jest to zalecane nawet w kontekście solo-dev, ale o ile widzę, poza wykorzystaniem „głównego” pnia do programowania i rozgałęzianiem się pod działający, gotowy do wydania kod, nie rozumiem, w jaki sposób Mógłbym wykorzystać moc rozgałęziania (na przykład, aby podzielić nowe funkcje na segmenty) bez nadmiernego komplikowania całego procesu programowania.

Korzyści są w większości takie same jak w przypadku grup programistów. Korzystając z gałęzi głównej zawsze gotowej do wydania i gałęzi funkcji do opracowywania nowych funkcji, zawsze można zwolnić jednostkę główną. Znajdź ważny błąd podczas pracy nad funkcją? Przełącz gałąź, napraw, zwolnij, przełącz z powrotem i kontynuuj rozwój.

A może jest to projekt hobby i po prostu lubisz trochę popracować nad tą funkcją i trochę tego, gdy nastrój cię uderza. Zasadniczo naśladujesz wieloosobowy zespół, skracając czas.

Domniemane rozgałęzienia, które DVCS wykonują na klonach, oznaczają, że formalne rozgałęzienia w autorytatywnym repozytorium mniej dotyczą koordynowania ludzi, a bardziej koordynowania kierunków rozwoju, a nawet jedna osoba może zrobić wiele z nich.

Długotrwały rozwój

Rozgałęzienie dla jednoosobowego zespołu byłoby przydatne w przypadku długotrwałej funkcji programistycznej, która w przeciwnym razie nie pasowałaby do twojego cyklu wydawniczego.

Możesz wziąć oddział za wielomiesięczną zmianę obejmującą i nadal być w stanie przesyłać codzienne poprawki błędów lub zmiany z głównego oddziału w regularnych odstępach czasu.

Ma to tę przewagę nad „przełącznikami” w jednej gałęzi, że twoja główna gałąź jest zawsze w stanie do wdrożenia i masz gwarancję, że nic w funkcji długotrwałego działania nie miało wpływu na inny, wcześniej przetestowany kod.

Funkcje eksperymentalne

Gałąź może być również przydatna w przypadku funkcji, które możesz chcieć prototypować, ale które mogą nigdy nie znaleźć się we wdrożonym kodzie. Wykonanie ich na gałęzi, którą ostatecznie wyrzucę, oznacza, że ​​nigdy nie niepotrzebnie zanieczyszczasz swoją główną bazę kodu.

Używam go do krytycznej konserwacji strony. Jestem jedynym programistą, ale mam master, rozwijam i wydaje oddziały.

Mój proces pracy przy konfiguracji witryny wygląda następująco:

1. Zrób działającą gałąź główną. Wykonaj wstępne zatwierdzenie.

2. Kasa rozwoju oddziału. Nic nie rób, rozwijaj funkcje jako bufor testowy do łączenia w master.

3. Oddział wydania zamówienia. Zakoduj swój problem, kiedy to się skończy, wciągnij go w programowanie, sprawdź, czy pojawią się jakieś problemy, scal konflikty itp. Napraw je.

Kiedy wystarczająca liczba problemów zostanie połączona w programistę dla jednej wersji, a programistyka została przetestowana pod kątem stabilności, pull develop w master.

   Master
     |
   Develop  - E
   / |  \  \
 A   B   C  D

W ten sposób otrzymujesz pełną kolekcję testową, w której możesz testować stabilność, problemy itp. Bez ryzyka zranienia Mistrza i wycofania zatwierdzeń, jeśli były szkodliwe.

Ponadto, wykorzystując poszczególne oddziały do ​​zatwierdzenia, możesz „zostawić” pracę, którą już wykonałeś, zacząć od nowa na czymś innym, aby rozwiązać pilniejszy problem i wprowadzić go wcześniej.

W prawdziwym życiu zazwyczaj mam jedną gałąź wydania, i rozwijam ją, a następnie opanowuję. Czasami jest to żmudne, ale przynajmniej raz na dwa miesiące muszę rzucić pracę przy kropli kapelusza, ponieważ ktoś miał pomysł, że muszę zrobić RightNow ™ i w ten sposób mogę szybko wrócić do stanu podstawowego, spraw a potem kontynuuj, gdzie byłem. Zwłaszcza w przypadku dużych projektów, które trwają wiele tygodni, jest to godność, że mogę szybko zmieniać oddziały.

Rozważmy następujący scenariusz: zawsze pracować na głównej gałęzi i trzeba AwesomeCodeThing ™ w pracach, które opuszcza oddział magistra w otwartej chirurgii serca i YugeBug ™ wyskakuje że wymaga pilnej utrwalacze inaczej tysięcy użytkowników będą skarżyć do was o BigProblems ™
The jedynym sposobem na szybkie rozwiązanie problemu w takim scenariuszu,

1. sprawdź swoje poprzednie zobowiązania,
2. zobacz, kiedy było ostatnie stabilne zatwierdzenie (przeklinanie jest opcjonalne)
3. przywróć do tego zatwierdzenia
4. zrób naprawę, wypchnij naprawę do produkcji
5. rozwiąż wszystkie konflikty i problemy, które teraz próbujesz przywrócić do stanu AwesomeCodeThing ™
6. poddaj się, płacz i zacznij pracę od nowa. (opcjonalnie)

Jeśli korzystasz z oddziałów:

1. Mistrz kasy
2. utwórz oddział UrgentFix ™ i napraw rzeczy
3. pociągnij UrgentFix ™ do mistrza
4. naciskać na produkcję
5. Scal mistrza do opracowania
6. Scalanie przekształca się w AwesomeCodeThing ™
7. weź piwo i kontynuuj pracę.

Gałęzie ułatwiają pracę nad wieloma funkcjami jednocześnie, co może być bardzo pomocne, gdy priorytety zmieniają się w trakcie projektu.

Powiedz, że zdecydowałeś, że funkcja jest teraz ważniejsza. Być może pilnie potrzebujesz załatać krytyczny błąd w systemie na żywo. Możesz pracować z klientem nad wieloma funkcjami przez długi czas i możesz chcieć demonstrować postępy każdej funkcji osobno. Być może właśnie przeczytałeś o paskudnym exploicie zero-dniowym i chcesz się nim zająć, zanim wspomniany klient o nim przeczyta.

Jeśli używasz rozgałęzień dla każdej funkcji / poprawki, zwykle łatwiej, czystsze i szybsze będzie izolowanie i wdrażanie tych modyfikacji niż używanie jednego rozgałęzienia do wszystkiego. Odnosi się to do tego, czy jesteś jedynym programistą, czy członkiem zespołu.

Jeśli chodzi o rzeczywisty proces, uważam, że git flow działa dobrze. Ściągawka Git Flow Daniela Kummera to świetny zasób, na który warto spojrzeć, nawet jeśli nie używasz gita.

Jak wspomniano w innych plakatach, zalety są zasadniczo podobne do pracy w zespołach: zdolność do samodzielnego opracowywania i testowania funkcji, utrzymywania oddzielnej gałęzi głównej dla poprawek / wdrożeń produkcyjnych, eksperymentowania.

Dla mnie osobiście zazwyczaj pracuję w trybie mistrza, jeśli znam obszar, nad którym pracuję bardzo dobrze, to tylko dodaje koszty ogólne do gałęzi, ponieważ i tak po prostu je scalę.

Jednak jeśli mam żadnego wahania o zmianach Robię będę oddział i tylko PR / scalić raz oddział zachowuje się zgodnie z oczekiwaniami i na ogół jest w pełni przetestowane. W ten sposób, jeśli odkryję problem, dla którego wycofanie jest najlepszym sposobem działania, jest to pojedynczy zatwierdzenie zamiast całej serii (nigdy nie pamiętam składni wycofania serii zatwierdzeń, ale pojedyncza jest łatwa).