Scroll to top
en pl

Git vs Perforce – co wybrać


Radoslaw Kosiec - 3 czerwca 2019 - 0 comments

Zespoły IT wciąż poszukują idealnego rozwiązania, które uszczęśliwi deweloperów i równocześnie będzie wspierać DevOps. Na pewno odbyło wiele debat na temat używania Git’a czy Perforce’a do zarządzania kodem źródłowym. Decydenci mają wiele możliwości do rozważenia. W tym artykule przedstawimy szczegółowo różnice między Git i Perforce.

Różnica między Git i Perforce

Każdy zespół ma inne wymagania i potrzeby. Git może być dobrym wyborem dla jednego zespołu, a Perforce lepszym systemem kontroli wersji dla innego.

Natywny, open-source’owy Git działa świetnie. Sprawdza się to szczególnie w przypadku projektów, przy których pracuje niewielka liczba deweloperów, a cykl release’ów jest szybki, np. tworzenie stron internetowych.

Wykorzystanie enterprise’owego systemu kontroli wersji od Perforce również jest dobrym wyborem. Doskonale sprawdza się to w przypadku dużych zespołów, które pracują nad kompleksowymi projektami obejmującymi różne assety. Dla przykładu, przy tworzeniu gier rozwiązania Perforce mogą zintegrować wszystkie zasoby cyfrowe (digital assets), takie jak: pliki binarne, pliki projektowe, a jednocześnie zachować je w bezpiecznym miejscu.

Porównanie Perforce vs Git

Przyjrzyjmy się niektórym kluczowym różnicom.

Model scentralizowany vs rozproszony

Git jest rozproszony

Dzięki rozproszonemu modelowi Git, programiści pobierają na swój komputer kod źródłowy wraz z pełną historią wersji. Mogą wprowadzać zmiany lokalnie, co znacząco przyspiesza commity, diffy i mergowanie.

Zespół programistów, z których każdy ma własną kopię repozytorium, musi koordynować między sobą udostępniane zmiany. Firma może mieć również problemy z bezpieczeństwem. Każdy deweloper posiada kopię repozytorium na swoim komputerze, co może utrudniać zarządzanie. Dlatego coraz więcej zespołów korzysta ze scentralizowanego modelu Git. Zmiany, które mają stać się częścią projektu, przesyłane są jako pull request lub merge request do gałęzi master. Odbywa się to na dedykowanym serwerze Git, a nie na konkretnej stacji roboczej programisty.

Uprawnienia Git są przypisywane na poziomie repozytorium, dlatego zespoły, mające wymagania związane z bezpieczeństwem, zazwyczaj dzielą swoje projekty na kilka repozytoriów. Dzięki temu programiści mają dostęp tylko do potrzebnych repozytoriów. To upraszcza audyt, jednak po rozbiciu projektu zespoły muszą zmagać się z zależnościami między repozytoriami.

Perforce jest scentralizowany

Helix Core – kontrola wersji od Perforce ma model scentralizowany.
Przechowywanie wszystkiego w jednym miejscu zapewnia programistom stały dostęp do najnowszej wersji projektu. Bez względu na miejsce pobytu dewelopera, może on zatwierdzić wszystkie zmiany na centralnym serwerze. Poprawia to również komunikację, ponieważ progres pracy jest widoczny dla innych członków zespołu, podczas gdy status pracy Git jest przechowywany tylko w lokalnym repozytorium.

Scentralizowany model znacznie upraszcza współpracę przy kodowaniu oraz w razie potrzeby zapewnia możliwość ponownego wykorzystania kodu. Mimo że Helix Core jest scentralizowany, to bezpiecznie obsługuje zdalne witryny przy pomocy replik i serwerów proxy. To znacznie poprawia wydajność, ponieważ większość działań jest wykonywana lokalnie.

Wydajność

Kiedy Git jest szybszy

Lokalne commity, diffy i mergowanie mogą być szybsze w Git. Jednak przy pushowaniu i pullowaniu, zmniejsza się wydajność repozytorium, a to przekłada się na spadek produktywności.

Kiedy Perforce jest szybszy

Helix Core został zbudowany z myślą o szybkości i skalowalności. Może obsługiwać miliony transakcji, miliardy plików i pamięci. Programiści mogą szybko i łatwo sprawdzić, czy na swojej stacji roboczej mają najnowszą wersję pliku. Dodatkowo oprogramowanie Perforce obsługuje duże pliki binarne z wyłącznym blokowaniem. Zapobiega to sytuacji, w której dwóch programistów próbuje pracować nad tym samym elementem.

Dzięki architekturze Perforce Federated zespoły pracujące zdalnie doświadczają lokalnej wydajności przy dużych operacjach typu clone/pull/build. Może to zmniejszyć znaczną część oczekiwania WAN z tradycyjnym Git.

Zarządzanie dużymi plikami/binariami

Duże pliki i artefakty binarne są częścią rozwoju projektu. Mogą być wynikiem kompilacji i być danymi wejściowymi do testów. Dla niektórych branż, takich jak tworzenie gier, są one integralną częścią całego procesu. Musisz być w stanie połączyć pracę artysty i dewelopera, aby uzyskać satysfakcjonujący produkt końcowy.

Git oferuje LFS

Git próbuje rozwiązać ten problem za pomocą LFS (Large File Storage). Jednak większość dużych zespołów przechowuje swoje assety binarne przy użyciu takich narzędzi jak Nexus lub Artifactory. Oznacza to, że nie istnieje jedno miejsce do przechowywania wszystkich danych. Dodatkowe narzędzia mogą komplikować również proces budowania.

Perforce przechowuje wszystko w jednym repozytorium

W Helix Core artefakty są przechowywane obok kodu źródłowego i innych assetów nie będących kodem. Te artefakty mogą być rejestrowane jako część tej samej listy zmian jako powiązany kod źródłowy. Przechowywanie wszystkiego w jednym serwerze znacząco ułatwia pracę. Dzięki temu administratorzy nie muszą zarządzać dodatkowymi licencjami i integracjami.

Branching

Oba narzędzia – Git i Perforce – oferują lightweight branching, ale inaczej śledzą rozgałęzienia.

Gałęzie w Git

Gdy w Git tworzony jest branch, możesz natychmiast rozpocząć nad nim pracę. Po wprowadzeniu zmian jesteś gotowy do commita – możesz wtedy mergowac lub zrobić rebase. Jednak mergowanie do lokalnej kopii gałęzi głównej nie jest tym samym co pushowanie zmian do centralnego repozytorium.

W przypadku, gdy wielu programistów pracuje nad tym samym plikiem i próbują go pushować równocześnie,  mogą pojawić się konflikty. Dlatego zawsze ważne jest pobieranie najnowszych zmian z serwera przed mergowaniem. Jednak jeśli nad projektem pracuje kilkudziesięciu programistów, może to być bardzo czasochłonne.

Jeśli występuje zależność między repozytoriami, to trzeba skoordynować konflikty scalania w wielu repozytoriach. To może być trudne, szczególnie w przypadku gdy Twój zespół cały czas się powiększa, a razem z nim rośnie liczba repozytoriów.

Gałęzie w Perforce

W Helix Core gałęzie są tworzone na poziomie hierarchii plików. Członkowie zespołu mogą wybierać określone pliki i przesyłać je z powrotem do repozytorium. Helix Core daje wgląd programistom w to nad czym pracują inni. Dzięki możliwości przypisywania uprawnień do poziomu plików, administratorzy mogą chronić najważniejsze pliki.

Perforce Streams to dobry sposób na rozgałęzienia i mergowanie. System ten upraszcza konfigurację obszaru roboczego i pomaga zespołom prowadzącym. Deweloperzy mogą łatwo przełączać się między strumieniami (gałęziami) i równie łatwo mogą sprawdzić jak są propagowane zmiany. Podobnie jak w przypadku Git, podczas przesyłania zmian do głównej gałęzi nadal mogą wystąpić konflikty, ale są one łatwe do zarządzania. Zaletą Helix Core jest widoczność postępu prac oraz zaawansowane powiadomienia o potencjalnych konfliktach mergowania.

Ponadto skalowalność Helix Core pozwala programistom na przesyłanie potencjalnie dużej listy zmian w ramach jednej akcji, które wpływają na wiele komponentów. Może to znacznie ograniczyć problemy z zależnościami kodu, np. zależności repozytorium w Git. Dodatkowo zmiany te są łatwe w śledzeniu i zarządzaniu.

A więc po co używać Git?

Jest wiele dobrych powodów, dla których zespoły często używają systemu kontroli wersji Git.

Jak napisaliśmy wcześniej, rozwiązuje on najbardziej podstawowy problem z kontrolą wersji. Pozwala deweloperom na jednoczesną pracę nad tym samym kodem, bez jego powielania.

Jest szybki w opera lokalnych. Git jest systemem kontroli wersji często wykorzystywany przez początkujących programistów na studiach, dlatego większość zna polecenia Git, takie jak: clone, commit i push. Plusem jest to, że nic nie kosztuje.

Git dla dużych przedsiębiorców

W ciągu ostatnich kilku lat wiele firm zaczęło zarabiać na oprogramowaniu open source. GitLab, GitHub i Atlassian wykorzystali do tego Git. Dodali przejrzysty interface użytkownika, code reviews, możliwość zarządzania wieloma repozytoriami oraz integrację potoków z Git.

Każdy z dostawców Git jest bardziej popularny wśród indywidualnych użytkowników pakietów bezpłatnych niż  klientów korporacyjnych, którzy korzystają z płatnych systemów kontroli wersji.

GitLab, Atlassian i GitHub nie zawsze sprawdzą się w rozwoju oprogramowania dla przedsiębiorstw. Architektura Git okazała się trudna do skalowania w tym środowisku.

Kiedy używać Perforce (Helix Core)

Perforce jest odpowiednim wyborem dla użytkowników, którzy posiadają:

  • duże bazy kodu,
  • niekodowane zasoby, takie jak pliki binarne lub grafika,
  • zależność między kodami, szczególnie między komponentami,
  • rozległe ponowne wykorzystanie kodu, takie jak artefakty,
  • rozproszone geograficznie zespoły.

Są to elementy, w których Perforce zdecydownie przoduje. To dlatego, że ten rodzaj kontroli wersji został zaprojektowany dla dużych zespołów, z dużymi bazami kodów i złożonym środowiskiem programistycznym.

Related posts