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

Perforce

20 lipca 2017 • 45 min czytania

    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

    Krótkie przypomnienie – co to jest Git?

    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.

    Trudności i rozwiązania w pracy z Gitem

    Workflow

    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:

    1. początek stanowi gałąź główna
    2. tworzenie nowej gałęzi
    3. wprowadzanie zmian
    4. powrót do gałęzi głównej
    5. scalenie modyfikacji
    6. usunięcie zbędnej gałęzi.

    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).

    Struktura git-flow

    Domyślna struktura Git-flow

    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.

    Workflow – dobre praktyki

    • Określ swoją strategię rozgałęziania z wyraźnymi etapami i jasnymi warunkami przejścia. Najlepiej zautomatyzuj przepływ kodu tak bardzo, jak to tylko możliwe.
    • Określ rewizję jako integralną część swojej strategii. Interdyscyplinarna kolaboracja jest kluczowa w nowoczesnym rozwoju produktu.
    • Wyposaż wszystkie scenariusze w narzędzia dostosowane do ich konkretnych potrzeb, aby zmaksymalizować produktywność i łatwość użytkowania.

    Zasoby

    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.

    Jakie może być rozwiązanie?

    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.

    Zasoby – dobre praktyki

    • Przechowuj wszystkie zasoby w jednym miejscu, najlepiej w jednym narzędziu do kontroli wersji. Jeśli tego nie zrobisz, a zdecydujesz się używać Gita, pomyśl o adaptacji „monorepo” (pojedynczego, dużego repozytorium – ze wszystkimi opisanymi wcześniej konsekwencjami używania takiego repozytorium z Gitem) zamiast opierać się na narzędziach, które podzielą Twoją własność intelektualną.
    • Używaj takiego pakietu zarządzania Gitem, który poradzi sobie ze wszystkimi plikami, w tym z zasobami cyfrowymi – nie tylko z kodem źródłowym.
    • Określ strategię archiwizacji starszych zasobów dopasowaną do strategii rozgałęziania, aby utrzymywać porządek i łatwość użycia repozytoriów.

    Continuous Delivery

    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:

    • tak jak większość systemów rozproszonych, Git domyślnie pobiera wszystkie wersje plików podczas operacji klonowania (w tym przypadku można wykorzystać operację Git Shallow clone, która pozwoli pobrać tylko najnowsze zatwierdzenia, a nie całą historię repozytorium),
    • Git nie wspiera klonowania wąskiego (tj. przy użyciu tylko potrzebnych plików, zamiast wszystkich).

    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.

    Continuous Delivery – dobre praktyki

    • Używaj klonowania płytkiego, aby otrzymać tylko ostatnie wersje plików i staraj się używać systemu zarządzania Gitem który wspiera klonowanie wąskie. Dzięki temu znacząco zmniejszysz obciążenie serwera.
    • Wybierz właściwy cykl buildów dla Twoich projektów. Build raz na godzinę lub dzień zamiast przy każdym wgraniu nowych plików może być konieczny.
    • Zautomatyzuj łączenie kodu i zwiększ jego częstotliwość do maksimum. W ten sposób będziesz mógł wykryć problemy z integracją zanim się one nawarstwią i zapchają przepływ kodu.

    Niezawodność

    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.

    Niezawodność – dobre praktyki

    • Kopie zapasowe są dobre, ale plan odtwarzania awaryjnego jest lepszy. Stwórz taki plan, bilansujący akceptowalne straty z kosztami, i regularnie go sprawdzaj.
    • Podczas wyboru systemu zarządzania Gitem, szukaj takiego, który zapewni zarówno klastrowanie, jak i wysoki poziom dostępności, dzięki czemu wszyscy będą mogli pracować, nawet gdy padnie sprzęt (np. Bitbucket lub GitLab – tutaj przeczytasz o porównaniu tych rozwiązań).

    Bezpieczeństwo

    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

    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.

    GitLab dodawanie dostępów

    Przyznawanie dostępów w GitLab

    Bezpieczeństwo w codziennej pracy

    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.

    Bezpieczeństwo – dobre praktyki

    • Upewnij się, że Twoja struktura branchy nie tylko pasuje do workflow, ale również dzieli zasoby zgodnie z potrzebami zabezpieczeń.
    • Wybierz taki system zarządzania Gitem, który dostarcza możliwość kontroli dostępu o maksymalnym rozdrobnieniu, a także zapewnia na czas aktywne monitorowanie akcji użytkownika, aby oznaczyć i zaraportować budzące wątpliwości zachowanie, zanim zostaniesz narażony na utratę własności intelektualnej.
    • Jeśli gałęzie nie wystarczą, zawczasu zorganizuj zasoby w taki sposób, by krytyczne ze względów bezpieczeństwa pliki trzymać razem, co ułatwi później definiowanie ograniczeń dostępu.

    Zarządzanie repozytoriami

    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ć.

    Zarządzanie repozytoriami – dobre praktyki

    • Przed doborem rozwiązania weź pod uwagę, ile czasu zespół DevOps może przeznaczyć na zarządzanie repozytoriami.
    • Jeśli to możliwe, zbadaj możliwość wykorzystania narzędzi i technik “zarządzania” wysokopoziomowymi komponentami.
    • Używaj systemu zarządzania Gitem, który pozwoli maksymalnie unikać zjawiska Git sprawl albo przynajmniej zakulisowo zajmie się tym problemem.

    Widoczność

    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.

    Widoczność – dobre praktyki

    • Dokładnie określ swoje priorytety informacyjne i najważniejsze metryki. Kieruj się nimi, wybierając system zarządzania Gitem.
    • Pomyśl, do jakiego stopnia rozwiązanie, które wybierasz, wywoła Git sprawl. W razie potrzeby rozważ dobór narzędzi i technik do agregacji danych.
    • Wybierz dostawcę, który oferuje coś więcej niż tylko zarządzanie Gitem, zwłaszcza jeżeli potrzebujesz dedykowanych metryk lub szerokiego wsparcia dla integracji z innymi narzędziami.
    Operations Dashboard GitLab

    Widok operacji w GitLab

    Ukryte koszty

    Konieczność nauki

    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.

    Environments Dashboard GitLab

    Widok środowisk w GitLab

    Zabezpieczenia

    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.

    Koszty skali

    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.

    Ukryte koszty – dobre praktyki

    • Pamiętaj o tym, by właściwie oszacować umiejętności mniej technicznych członków zespołu i wyposażyć ich w odpowiednie narzędzia, ewentualnie proste w obsłudze wtyczki do aplikacji, których używają na co dzień.
    • Ostrożnie dysponuj dostępem do treści repozytorium, szczególnie dla zewnętrznych współpracowników.

    Wnioski

    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.

    Jesteś zainteresowany systemami kontroli wersji? Dowiedz się wiecej o Perforce Helix lub przeczytaj o narzędziach do obsługi repozytorium Git, takich jak Bitbucket i GitLab.

    Przeczytaj o rozwiązaniach DevOps:

    [contact-form-7 404 "Not Found"]