@CodenlynDamilola Ale
Kontrola wersji stała się ważną częścią procesu tworzenia oprogramowania. Kontrola wersji pomaga rejestrować zmiany w projekcie w czasie, dzięki czemu można później przywołać konkretne wersje. Będę mówił o GitHub.
Gdy zaczynałem jako deweloper, zacząłem używać GitHub, ponieważ wszyscy mówili, że jest to konieczne dla deweloperów, aby mieć swój kod online. Mając to na uwadze, postrzegałem to jako miejsce do przechowywania wszystkich moich projektów w przypadku awarii mojego systemu, byłbym w stanie pobrać je z powrotem.
Funny right?
Później zdałem sobie sprawę, że GitHub to coś więcej niż tylko to, jest to miejsce, gdzie mogę zobaczyć wszystkie postępy, które zrobiłem na każdym etapie budowania mojego projektu lub oprogramowania. Zdarza się również, że jest to miejsce, w którym każdy na całym świecie może przyczynić się do projektów z różnymi pomysłami.
Około połowy roku, kiedy zacząłem pracę w Microverse, zostałem wprowadzony do GitHub Flow. GitHub Flow zachęca do tworzenia feature-branches dla każdej cechy twojego oprogramowania. Kiedy uważasz, że twoje oprogramowanie lub projekt jest gotowy do oglądania lub używania, tworzysz żądanie pociągnięcia i łączysz się z gałęzią główną.
Cool right?
clone the project
do lokalnego repozytorium.
cd
do repozytorium
sprawdź gałąź, na której aktualnie jesteś
.
utwórz nową gałąź
feature branch
rozpocznij pracę nad swoją funkcją, a gdy skończysz,
add
,
commit
i
push
do gałęzi funkcji
Przejdź do swojego zdalnego repozytorium na GitHubie i utwórz pull request i połącz, gdy uznasz, że funkcja jest ukończona
W ten sposób możesz zobaczyć wszystkie funkcje, które stworzyłeś i co dodałeś w każdej fazie. W miarę postępów zdałem sobie sprawę, że gałąź główna jest przeznaczona głównie do produkcji i w momencie, gdy scalasz żądanie pociągnięcia, mówisz, że funkcja jest gotowa do użycia lub obejrzenia przez wszystkich.
To wtedy doszedłem do wiedzy, że przepływ GitHub działa idealnie dla małych projektów, ale co jeśli mam projekt z więcej niż jedną ważną cechą i używam przepływu GitHub, pośrednio mówię, że wszystkie cechy, które są scalane do gałęzi głównej są gotowe do produkcji, ale jeśli się zastanowimy, czy są?
Wypuszczanie jednej funkcji dla projektu z wieloma funkcjami nie ma sensu i właśnie tam pojawia się Git Flow. Jest on bardzo podobny do przepływu GitHub, ale wprowadza lepszy sposób pracy z kontrolą wersji.
W Git Flow tworzymy gałąź rozwojową, a następnie czynimy z niej gałąź rozwojową jako domyślną, dopóki nie będziemy gotowi do produkcji. W ten sposób wszystkie gałęzie funkcji są tworzone z gałęzi rozwojowej i scalane do gałęzi rozwojowej, gdy zostaną ukończone.
Ma to sens, prawda? Teraz mogę scalić się z gałęzią główną tylko wtedy, gdy uważam, że moje oprogramowanie jest gotowe do produkcji ze wszystkimi dodanymi funkcjami.
Po sklonowaniu repozytorium utwórz
development
gałąź
Sprawdź, na jakiej gałęzi obecnie pracujesz
Spróbuj dodać plik, może plik HTML, abyś mógł zaktualizować swoje zdalne repozytorium o gałąź rozwojową.
Przejdź do swojego zdalnego repozytorium na GitHub , przejdź do ustawień, kliknij na gałęzie i ustaw rozwój jako domyślną gałąź
Teraz, możesz tworzyć feature-branche z gałęzi
development
, tworzyć z niej pull request i scalać do gałęzi
development
.
Gdy wszystkie twoje funkcje są gotowe, wykonaj te same kroki co powyżej, uczyń master domyślnym ponownie, utwórz pull request z rozwoju do master i połącz dla produkcji.
Wiem, że to było długie czytanie, ale ufam, że do tej pory powinniśmy wiedzieć, kiedy używać przepływu GitHub lub Git Flow.
Dziękuję za przeczytanie.
Tagi
Załóż darmowe konto, aby odblokować niestandardowe doświadczenie czytelnicze.