W karierze dewelopera może zdarzyć się sytuacja, w której będzie trzeba pracować nad projektem korzystającym z rozwiązań, które są ciągle rozwijane i wymagana jest ścisła kontrola wersji zarówno plików bazowych projektu oraz tych dodatkowych. Przykładowo, zespół A pracuje nad rozwojem pluginu udostępniającego konkretne rozwiązanie dla WooCommerce, a zespół B nad trzeba sklepami, które powinny z niego korzystać. Oba projekty są w fazie rozwoju, dlatego system kontroli ich wersji będzie odgrywał kluczową rolę. Jak w takim wypadku zarządzać rozwojem takich projektów?
Problem
Bardzo nieefektywnym byłoby ręczne zarządzanie takimi projektami poprzez odzwierciedlanie w infrastrukturze sklepów każdej zmiany zachodzącej w pluginie. Generuje to dużo dodatkowej pracy oraz potencjalnych problemów, szczególnie w trakcie intensywnego rozwoju obu projektów.
Pewnym rozwiązaniem jest wprowadzenie systemu automatycznych aktualizacji, ale do tego wymagana byłaby określona infrastruktura, której zwykle w fazie początkowego rozwoju jeszcze nie ma. Dodatkowo może to generować problem z wersjonowaniem – czasem ze względu na specyficzne problemy wymagany będzie downgrade pluginu do określonej działającej wersji.
Jeśli zespoły są małe, a zmiany w obu projektach nie są duże, taka opcja może się sprawdzić, ale niestety nie będzie to dobry wybór w przypadku bardziej skomplikowanych sytuacji. Z pomocą przychodzi narzędzie git submodules, które umożliwia obsługę repozytorium w innym repozytorium rozdzielając je między sobą. Commity wykonywane w głównym repozytorium są odseparowane repozytorium skonfigurowanego jako podmoduł.
Jak to działa?
Informacje o konfiguracji podmodułów przechowywane są w pliku .gitsubmodules, dlatego przy inicjalizacji środowiska musimy zadbać o poprawne prawa dostępu do wszystkich repozytoriów wspomnianych w tym pliku.
W momencie gdy wykonujemy commit w repozytorium bazowym, wysyłana jest również informacja o stanie repozytorium podmodułu, a dokładniej – hash commita, który był wybrany. Przykładowo posiadając /wp-content/plugins/woocommerce-plugin skonfigurowany jako podmoduł, repozytorium bazowe nie widzi plików i zmian w nich wewnątrz tego katalogu, a jedynie informacje o aktualnym commicie wybranym w podmodule. W momencie gdy zajdzie zmiana w podmodule i zmienimy aktualnie wybrany commit, taka informacja zostanie zauważona przez repozytorium bazowe i będzie możliwa do zatwierdzenia.
-Subproject commit 69cd54bdd44fe3deec8f20adbf3375732bec17a8
+Subproject commit 1746f83ded1bdd269db5029a3c79b785f5aacc57Dzięki takiemu rozwiązaniu, zarządzanie zmianami i utrzymywanie ich stanu jest znacznie ułatwione. Mamy dokładną kontrolę nad tym, który commit z podmodułu powinien być wykorzystywany przez kod bazowy projektu, a wszelkie zmiany w infrastrukturze są natychmiastowo widoczne.
Podsumowanie
Narzędzie jest niezwykle przydatne w przypadku projektów o podobnej architekturze jak wyżej. Możliwości jest o wiele więcej, dlatego zalecanym jest zapoznanie się z oficjalną dokumentacją, która pozwala na dokładniejsze zrozumienie zasad działania aby maksymalnie wykorzystać je na swoja korzyść.
Dodaj komentarz