Git, czyli kontrolujemy zmiany

System kontroli wersji jest najważniejszym narzędziem pracy zespołu programistycznego. Jeśli w Twoim projekcie nie używacie jeszcze gita, tylko SVNa, lub – co gorsza – nie używacie niczego, czas na zdecydowane zmiany!

Możliwości, jakie oferuje git są bardzo duże, przez co nie zamierzam się na nich skupiać w poniższym artykule. W przypadku jeśli na Twoim projekcie używacie innego systemu kontroli wersji, zachęcam do przesiadki. Ułatwi to pracę w kilka osób nad tymi samymi plikami, pozwoli zdefiniować kilka wersji wdrożeniowych, oraz generalnie uprości codzienną pracę. Dodatkowo, w przypadku chęci zmiany pracy za jakiś czas, wiedza na temat tego jak pracować z gitem będzie dużym atutem.

Chciałbym tutaj raczej poruszyć kwestie tego, w jaki sposób możemy zarządzać zmianą i przygotowywać wiele wydań jednocześnie. Często jest tak, że mamy kod produkcyjny, dodatkowo rozwijamy kilka dużych funkcjonalności i nie chcemy, aby te zmiany się ze sobą przenikały. Z podpowiedzią, jak robić to dobrze przychodzą nam strategie tworzenia branchów w gicie.

Najczęściej spotykane to GitFlow, GitHub Flow, GitLab Flow i One Flow. Szczegółowych ich opis znaleźć można tutaj. Ze swojego doświadczenia do pracy z Oraclem polecam GitFlow, jest on w pełni dostosowany pod potrzeby większości projektów. Po więcej detali i bardzo dobre wyjaśnienie jak tego używać odsyłam tutaj.

Ze swojej strony nie zachęcam do wymyślania czegoś na nowo. Większość naszych wymagań jest pokryta przez któreś z głównych podejść. Są one bardzo dobrze udokumentowane i łatwo jest znaleźć przykłady zachowań. Przed wyborem polecam jednak szczegółowo przemyśleć podstawowe wymagania. Warto skupić się na tym, jak będzie wyglądać wdrażanie pilnych poprawek na produkcję oraz jak będzie wyglądał codzienny development. Zadbanie o te rzeczy na samym początku pozwoli na łatwiejszą i przyjemniejszą pracę w przyszłości.