Jak korzystać z Git? 8 przepisów na sukces

Artykuł zaktualizowany 19.11.2020

Popularność Gita w projektach open source wzrosła, prześcigając SVNy czy TFSy. Sprawne wdrożenie tego systemu nie jest jednak proste i wymaga odpowiedniego przygotowania. W praktyce adaptacja Gita może oznaczać trudne kompromisy pomiędzy preferencjami dewelopera a potrzebami firmy. Co to dokładnie jest Git, jakie może nieść wyzwania w przedsiębiorstwie i jak bezproblemowo wdrożyć pracę w tym systemie?

Z perspektywy zespołu praca z rozproszonym systemem kontroli wersji (DVCS) jest bardziej skomplikowana niż praca z systemem centralnym. To właśnie poziom skomplikowania jest źródłem większości obecnych barier, przeszkadzających w szerszym użyciu takich systemów.

Gartner

Zanim przejdziemy do opisu dobrych praktyk, uporządkujmy wiedzę na temat Gita. Co to za oprogramowanie? Git jest rozproszonym systemem kontroli wersji, służy więc do kontrolowanego wprowadzania zmian w projekcie. Dzięki nieustannemu rejestrowaniu zmian zachodzących w projekcie system umożliwia szybkie wychwycenie problemów i zapewnienie lepszej jakości nowych wersji. Git pozwala na zarówno pracę indywidualną, jak i rozwijanie oprogramowania przez kilku specjalistów jednocześnie. Umożliwia też przeglądanie historii, przez co wykrycie, w którym miejscu kodu pojawił się błąd, jest szybkie również przy pracy zespołowej. To także sposób na prosty powrót do poprzednich porzuconych pomysłów.

W odróżnieniu od centralnych systemów wersjonowania Git nie dysponuje jednym, głównym repozytorium kodu. Rozproszona kontrola powoduje, że repozytoriów Git jest tyle, ilu jest członków zespołu, a każdy z deweloperów lokalnie ma dostęp do pełnych źródeł projektu i historii zachodzących zmian. Taka swoboda może zarówno sprzyjać kreatywności, jak i powodować trudności z ustrukturyzowaniem pracy. Swoboda w tworzeniu gałęzi wymaga pewnego usystematyzowania zarządzania projektem.

Oczywistym powodem, dla którego przedsiębiorstwa wykorzystują Gita, jest upodobanie deweloperów do jego rozproszonego przepływu pracy, nawet jeśli rzadko używa się modelu całkowicie rozproszonego. Programiści przy pracy często muszą zmieniać wątki, a lekkie, lokalne branchowanie, jakie wspiera Git, bardzo w tym pomaga. To właśnie sposób obsługi branchy jest ważną, wyróżniającą cechą Gita. Jak jednak zarządzać złożonością, którą wprowadza Git, gdy spojrzy się na temat z perspektywy szerszej niż pojedynczy komputer? Jak należy dzielić się gałęziami eksperymentalnymi z innymi członkami zespołu? Kiedy zawartość tych gałęzi powinna być zmerge’owana na powrót z głównym branchem?

Jednym z rozwiązań jest Git-flow. Metoda Git-flow odpowiada na potrzebę automatyzacji pracy z Gitem. Tworzenie gałęzi to nieodłączny element pisania kodu w tym systemie. Schemat działania, niezależnie od tego, czy rozwijamy nowe funkcjonalności, czy naprawiamy błędy, jest taki sam:

Te powtarzające się działania wymagają automatyzacji, którą zapewnia metoda Git-flow. Wprowadza ona określoną strukturę gałęzi w repozytorium, z których każda ma przypisane zadanie (Master to gałąź produkcyjna, Hotfix służy do poprawek, Release to gałąź wydania, Develop – gałąź rozwojowa, a Feature jest gałęzią funlcjonalności).

Narzędzia takie, jak GitSwarm, GitHub, GitLab lub Bitbucket wprowadzają proste procesy skupione wokół operacji pull request, które mogą dostarczyć pewnych odpowiedzi. Najlepszym momentem na rozwiązanie tych problemów jest czas przed wdrożeniem Gita przez zespoły. Próby zmian w procesie już po rozpoczęciu pracy oraz aktualizacja historii rewizji jest bardziej skomplikowane i wymaga większego nakładu pracy i czasu.

Popularna zasada obowiązująca przy pracy w metodykach zwinnych głosi, że należy przechowywać całą własność intelektualną w tym samym miejscu, jedynym źródle prawdy (ang. single source of truth). Okazuje się jednak, że interdyscyplinarny charakter zespołów i wymagań projektowych lawinowo zwiększa liczbę i rozmiar zasobów w typowym projekcie. Kod źródłowy to często jedynie kropla w cyfrowym morzu w porównaniu z dokumentacją, grafiką, modelami, dźwiękiem, wideo, a nawet całymi środowiskami maszyn wirtualnych (VM) służącymi do testów i wdrożeń.

Ten rodzaj ekspansji oznacza poważne wyzwanie przy adaptacji Gita w przedsiębiorstwie, ponieważ jego mechanizmy wewnętrzne ograniczają maksymalny praktyczny rozmiar repozytorium do 1 lub 2 GB (chociaż takie ograniczenia rozwiązuje np. Bitbucket przez FLS). Nawet repozytoria daleko mniejsze niż ten limit mogą mieć problemy z wydajnością, jeśli typ i rozmiar zasobów oraz wykonywane komendy temu sprzyjają. Wykonanie choćby prostej komendy blame na repozytorium z dużymi zasobami binarnymi może boleśnie unaocznić ten problem. Co więcej, tego rodzaju zasoby są tworzone przez projektantów lub artystów, którym może brakować umiejętności technicznych, w związku z czym nie użyją oni wiersza poleceń Gita, nawet jeśli mogłoby to pomóc im w pracy. Nasza strategia zarządzania Gitem powinna określać, jak współpracownicy, będący technicznymi laikami, mają przechowywać swoją pracę, jak zarządzać tymi plikami razem z kodem źródłowym w Gicie i jak zebrać razem właściwe wersje wszystkich plików w naszym systemie produkcji i wydawania. Będzie to przydatne chociażby w pracy w branży Game Dev, gdzie niezbędne jest przechowywanie dużych plików multimedialnych.

Najpopularniejsze sposoby zarządzania dużymi zasobami cyfrowymi to przeniesienie dużych plików poza repozytorium Git lub podzielenie zasobów pomiędzy kilka repozytoriów, magicznie połączonych przez DevOps-ów dla celów produkcyjnych, testowania, wydawania i innych zadań. Narzędzia takie jak git-annex i Git LFS mogą pomóc przenieść zasoby cyfrowe poza repozytorium. Wpłynięcie na moduły zależne Gita wraz z zestawem autorskich skryptów umożliwi ujarzmienie zjawiska rozwlekania zasobów pomiędzy repozytoriami (tzw. Git sprawl). Tutaj należy uważać jednak na możliwe kolejne problemy związane z tworzeniem kopii zapasowych czy też dystrybucją treści pomiędzy oddziałami firmy. Jeśli to tylko możliwe, przedsiębiorstwo powinno szukać systemu umożliwiającego czerpanie korzyści z rozproszonej kontroli wersji (DVCS), ale przechowującego wszystkie zasoby w jednym miejscu.

Przepływ pracy i typ zasobów tworzonych przez Twoich pracowników może być różny, ale końcowy produkt zawsze musi być przetestowany i zintegrowany z maksymalnym wykorzystaniem automatyzacji. Automatyzacja w połączeniu z architekturą Gita może znacząco obciążyć system, tak więc wcześniejsze planowanie jest konieczne, aby uzyskać sensowną wydajność systemów Continuous Delivery.

Powszechnie używaną praktyką w CD jest build i testowanie na aktualnej kopii wszystkich plików. Jednak w przypadku używania Gita można w ten sposób łatwo przeciążyć serwery. Dzieje się tak z dwóch powodów:

Podsumowując, przy klonowaniu repozytorium Git dostajemy domyślnie wszystkie wersje wszystkich plików.

Powyższe problemy z reguły nie mają znaczenia w projektach małych, średnich i open source, ale mogą okazać się przeszkodami nie do pokonania w dużych projektach spotykanych w przedsiębiorstwach. Sama liczba operacji łączenia przy dużej liczbie gałęzi produkcyjnych może okazać się przysłowiową “skórką od banana” na drodze projektu. Git zachęca deweloperów do rozgałęziania wszystkich zadań lub feature’ów. Sama wielkość repozytoriów może jednk skutecznie uprzykrzać życie developerom poprzez długie czasy klonowania lub długie czasy synchronizacji lokalnego repo z repo zdalnym.

Nawet najlepsze narzędzie jest bezużyteczne, jeśli nie działa. To stwierdzenie jest prawdziwe zwłaszcza w warunkach przedsiębiorstwa, które często musi pracować przez całą dobę, na całym świecie. Git został zbudowany z myślą o prostych systemach plików, a większość systemów zarządzania Gitem jest zbudowana bezpośrednio na jego podstawowej wersji. Spełnienie wymagań przedsiębiorstwa dotyczących wysokiej dostępności i odtwarzania awaryjnego (disaster recovery) może stanowić duże wyzwanie.

Większość systemów zarządzających Gitem oferuje usługi takie, jak tworzenie kopii zapasowych i snapshotów, co jest dobrą pierwszą linią obrony. Niektóre systemy zwiększają poziom dostępności dzięki czuwającym maszynom wirtualnym, przy użyciu różnych środków do odzwierciedlania zmian pomiędzy systemami plików, czy też zamiany serwerów, jeśli zajdzie taka konieczność. Nie zmienia to jednak faktu, że jeśli potrzebujemy skalowalności typu dial-a-load w połączeniu z wysoką dostępnością, nasz wybór jest znacznie ograniczony.

Pamiętajmy też o tym, że o ile sklonowanie repozytorium dla bezpieczeństwa może wydawać się łatwe, to w przypadku Gita będziemy klonować całe repozytorium. To podejście nie stanowi problemu w małych i średnich projektach, jednak duże projekty zjadają przepustowość sieci, dyski i czas. Jeśli nasze zasoby mierzy się czymś większym niż megabajty, musimy szczegółowo przyjrzeć się poziomowi niezawodności, jaki oferuje nasz system zarządzania Gitem.

Git zapewnia jedynie ograniczony poziom bezpieczeństwa, oferując solidne uwierzytelnianie, jednak kompletnie ignorując autoryzację. To podejście sprawdza się świetnie, jeśli chcesz tylko upewnić się, że każdy wgrywający zmiany jest tym, za kogo się podaje, ponieważ jego tożsamość jest weryfikowana poprzez cyfrowe podpisy. Co jednak w sytuacji, gdy chcesz ograniczyć dostęp do konkretnego repozytorium, brancha czy pliku zawierającego tajemnice przedsiębiorstwa? Git niestety nie oferuje niczego, co odpowiadałoby tym potrzebom, co stanowi główny powód istnienia tylu systemów zarządzania nim. Nie są one jednak na równym poziomie, jeśli chodzi o zapewnienie bezpieczeństwa.

Systemy zarządzania Gitem z reguły oferują łatwe tworzenie użytkowników i grup, a także ograniczanie dostępu do projektu (czytaj: repo) tymi sposobami. Co więcej, z reguły dostarczają one niewielkie zestawy ról, do których możemy przypisać różne pozwolenia. Niektóre (np. GitLab) rozszerzają pozwolenia również na gałęzie, umożliwiając ograniczenie dostępu tym, a nie innym użytkownikom. Najlepsze rozwiązania oferują zróżnicowany poziom monitoringu i śledzenie wzorów użytkowania.

Pomyśl także o swoich potrzebach dotyczących audytu oraz rejestrowania operacji. W środowisku o podwyższonym poziomie bezpieczeństwa lub regulacji może istnieć konieczność prowadzenia stałego zapisu, określającego kto dokonał zmian, kiedy, i w jakim celu. Standardowy Git pozwala na sporą elastyczność przy nadpisywaniu historii albo nawet zupełnym ukrywaniu zmian. Jeśli możliwość pełnego audytu jest dla Ciebie istotna, szukaj narzędzia do kontroli wersji, które oferuje niezawodny, bezpieczny zapis.

Wykorzystując wyłącznie Gita, pamiętaj o przestrzeganiu najwyższych zasad uważności. Przypisuj uprawnienia do każdego repozytorium i przyznawaj dostępy tylko tym programistom, którzy go potrzebują. Używaj bezpiecznego magazynu kluczy, np. Vault, żeby zapewnić dostęp do repozytorium Git, kiedy system wymaga tego poza kontrolą deweloperów. Pamiętaj też o dokładnym sprawdzaniu konfiguracji ustawień dostępu – w przeciwnym wypadku możesz narazić się na wyciek danych.

Potrzeba posiadania systemu zarządzania repozytoriami zależy w dużym stopniu od ograniczeń naszego systemu zarządzania Gitem. Jeśli wybierzemy system, który nie radzi sobie z zasobami cyfrowymi, dużą liczbą plików czy też dużym całkowitym rozmiarem repozytorium, Git sprawl będzie się pojawiać. Git sprawl można też łatwo wywołać, jeżeli proces jest mocno oparty o buildy z komponentów. Duża liczba niezależnie tworzonych i wersjonowanych komponentów może spowodować problemy z modułami zależnymi Gita, jeśli nasz system zarządzania nie oferuje innego mechanizmu. Git sam w sobie raczej ułatwia mapowanie zewnętrznych repozytoriów między sobą, ale trzeba wcześniej poradzić sobie z doborem dedykowanych narzędzi, metodyk, i zawarciem pewnych kompromisów.

Niezależnie od przyczyny, im bardziej podzielimy nasze zasoby, tym więcej problemów napotkamy przy ich łączeniu w celach produkcyjnych, testowych i dla innych zadań. Eksplozja liczby repozytoriów Git będzie oznaczać ból głowy dla DevOps-ów w pełnym wymiarze godzin, dlatego trzeba ostrożnie je rozplanować, a potem utrzymywać.

Kwestia, którą Git sam w sobie kompletnie ignoruje, a systemy zarządzania niewiele mu w niej pomagają, to potrzeba pełnej, transparentnej widoczności wszystkich etapów linii produkcyjnej. Większość systemów zarządzania Gitem zapewnia dashboardy zestawiające wszystkie projekty, dashboardy do indywidualnych projektów, a nawet garść przydatnych statystyk. Wiele z nich dostarcza także proste narzędzie do śledzenia problemów lub zdolność do integracji z zewnętrznymi narzędziami do zarządzania cyklem życia aplikacji (ALM).

Jeśli jednak nie wybierzesz dostawcy, który zapewni również pozostałe elementy kompletnego rozwiązania, prawdopodobnie będziesz musiał samodzielnie tworzyć wtyczki, skrypty i inne mechanizmy integracyjne. Wspomniany wcześniej Git sprawl komplikuje sprawę jeszcze bardziej – z oczywistych powodów, łatwiej analizować dane z monorepo niż z setek albo tysięcy repozytoriów.

Często pomijanym kosztem adaptacji i użytkowania Gita jest konieczność nauki. Powszechne wdrażanie Gita w firmach może dać złudzenie, że system wystarczy tylko pobrać i można zaczynać pracę. Deweloperzy na ogół uważają jednak, że nauka Gita jest trudnym zadaniem. Tym większe trudności z korzystaniem z systemu mogą mieć osoby z mniejszym zapleczem technicznym. Na szczęście istnieje kilka sposobów na ułatwienie nauki Gita. Świetnymi GUI dla Gita są wspomniane już systemy, jak Bitbucket czy GitLab, umożliwiające pracę osobom nietechnicznym. Z kolei nakładki graficzne, takie jak Tortoise, są wielce przydatne np. przy mergowaniu.

Serwisy hostingowe Gita często umożliwiają “zabezpieczanie” repozytoriów poprzez różne uprawnienia, a nawet chronią poszczególne branche, dopuszczając do pushowania tylko konkretne grupy. Niewiele jednak oferuje kontrolę do pojedynczego pliku i uprawnienia granularne, jakie znamy z centralnych systemów. Każdy, kto ma dostęp do repozytorium, ma też z reguły dostęp do wszystkiego w środku. Oznacza to, że restrykcje dostępu do własności intelektualnej wiążą się z dzieleniem repozytorium, wzmacniając tym samym zjawisko Git sprawl. Konieczność zabezpieczeń jest więc kolejnym ukrytym kosztem Gita, szczególnie w przypadku, gdy korzystamy z tak popularnego obecnie outsourcingu. Jednoczesne ograniczanie dostępu do contentu stanowiącego własność intelektualną i umożliwienie pracy zewnętrznemu zespołowi może znacząco wpłynąć na wydajność projektów.

Git, niestety, nie był projektowany z myślą o jakiejkolwiek skalowalności. Pierwotny Git nie wykorzystuje maksymalnie hardware’u, więc rozszerzanie o kolejne procesory lub kości pamięci nie pomoże w uzyskaniu pionowego efektu skali. Większość serwisów hostingowych próbuje sobie z tym poradzić poprzez nałożenie webowego front-edu na pierwotnego Gita, pozostawiając rozwiązanie problemu samej naturze aplikacji webowych, które potrafią asynchronicznie przetworzyć większą liczbę zapytań. Ten sposób jest tak dobry jak system plików, którego używamy, gdyż Git w całości się na nim opiera. Warto wiedzieć jednak, że unikatowy system przechowywania Gita pozostawia wiele do życzenia w momencie, gdy repozytoria zwiększają rozmiary. Problem ten udało się częściowo rozwiązać, tworząc szereg nakładek i zmian workflow, tak aby pozostawić duże pliki poza systemem kontroli wersji, łącząc je w robocze foldery. Narzędzia takie, jak git-annex i Git LFS potrafią uprościć ten proces.

Rozpatrzyliśmy osiem kluczowych aspektów, w ktorych Git może być problemem w przedsiębiorstwie. Przy korzystaniu z tego systemu ważne jest, aby być świadomym jego niedoskonałości i znać sposoby na radzenie sobie z nimi. Innym rozwiązaniem jest skorzystanie z alternatywy wobec Gita dopasowanej do potrzeb firmy, ale nadal oferującej możliwości lubiane przez deweloperów. Jeśli jednak zdecydujesz się na wdrożenie Gita, dobre praktyki zawarte w tym poradniku powinny pomóc Ci w planowaniu i wyborze optymalnego systemu zarządzania Gitem, minimalizując liczbę problemów.