banner bloomnet

Czym jest repozytorium kodu strony?

Dlaczego utrzymanie kodu strony jest tak ważne? W jakich sytuacjach repozytorium jest szczególnie przydatne? Czym charakteryzują się najpopularniejsze systemy kontroli wersji, czyli Git i SVN? Jak używać GitHub? Oto podstawowe zagadnienia dotyczące repozytorium, czyli tego jakże ważnego narzędzia każdego programisty.

Czym jest repozytorium kodu strony?

Nawet jeśli na co dzień nie zajmujesz się w swojej firmie sprawami programistycznymi, warto abyś wiedział, co to jest repozytorium. Ta wiedza przyda się też oczywiście tym, którzy stawiają swoje pierwsze kroki w pisaniu kodu.     

Mówiąc obrazowo, repozytorium to lek na chaos, jaki może pojawiać się w trakcie pracy nad projektem.

W przeszłości kod strony był tworzony i zapisywany lokalnie przez kilku programistów, a następnie przesyłany i dopiero wtedy łączony w całość. Z dzisiejszej perspektywy, taki tryb pracy - delikatnie mówiąc - nie był najwygodniejszy. Po pierwsze, była to trochę marudna robota, a po drugie, wiązało się z nią sporo niedogodności, np. trudna synchronizacja poszczególnych elementów kodu i generalnie słabsza kontrola nad całym procesem. 

Jak działa repozytorium  

Tymczasem repozytorium jest miejscem, w którym zachowuje się całą historię zmian kodu, nad którym jednocześnie może pracować nawet kilku programistów. Dzięki temu każdy z nich może w wygodny sposób pracować nad własnymi poprawkami, bez strachu, że wprowadzi niepoprawną zmianę i nie będzie mógł wrócić do pierwotnej wersji. 

Najważniejsze zalety repozytorium to: 

  • śledzenie pełnej historii zmian pojawiających się w plikach (dokładnie odpowiadają za to systemy kontroli wersji, o których szerzej za chwilę),
  • wgląd do wcześniej wprowadzonych zmian i możliwość sprawdzenia, kiedy je utworzono (wraz z wyszczególnieniem, kto odpowiada za konkretne zmiany),
  • kiedy w projekt zaangażowanych jest kilka osób, zmiana tych samych plików nie spowoduje ich nadpisania,
  • możliwość cofania zmian (wszystkich lub w pojedynczym pliku),
  • możliwość szybszego rozwiązania ewentualnego konfliktu w projekcie,
  • kiedy chcemy tworzyć nowe funkcjonalności, możemy pracować nad nimi "na boku" tworząc tzw. gałąź (branch),
  • możliwość sprawnego przeprowadzania testów,
  • możliwość wykonania kopii zapasowej (klonowanie),
  • znacznie lepsza komunikacja w zespole.  

Repozytorium to po prostu podstawa. Jak pisze Włodzimierz Gajda w książce "Git. Rozproszony system kontroli wersji", praca nad niemal każdym projektem wymaga dziś współdziałania wielu osób, które często pracują z dala od siebie. W takich warunkach łatwo o błąd, nadpisanie ważnego pliku czy przypadkowe powielenie danych. 

- Mały projekt po takiej wpadce da się jeszcze uratować, ale większy można wyrzucić do kosza. Chyba, że od momentu jego inicjalizacji używamy narzędzia odpowiedzialnego za właściwą synchronizację danych, czyli systemu kontroli wersji - podkreśla autor. 

Najpopularniejsze systemy kontroli wersji 

Obecnie chyba żadna duża realizacja nie obejdzie się bez wykorzystania systemów kontroli wersji (VCS), które porządkują projekt i ułatwiają współpracę programistom.

Wyróżnia się trzy podstawowe typy systemów kontroli wersji: lokalne, scentralizowane i rozproszone. Przy wyborze konkretnego VCS-a, należy oczywiście kierować się funkcjonalnościami, jakimi charakteryzować się będzie nasz projekt. Wybór narzędzi jest dość szeroki, ale zdecydowanie najbardziej znanymi systemami kontroli wersji są Git i Subversion (SVN). 

Zacznijmy od stworzonego w 2001 r. SVN, który ma strukturę scentralizowaną. Co to znaczy? Główną różnicą pomiędzy scentralizowanym a rozproszonym systemem kontroli jest to, że w scentralizowanym wszystkie dane są "magazynowane" tylko na centralnym serwerze. Dla porównania, w rozproszonym dane trzymane są w lokalnej kopii każdego pracownika, dzięki czemu nawet w przypadku awarii głównego serwera kopie repozytoriów cały czas są u wszystkich uczestników projektu.

Tak więc jedną z wad Subversion jest to, że nie rozwiązuje on problemu awarii: jeśli coś stanie się z serwerem, wszystkie dane mogą zostać utracone. Ale Subversion to oczywiście także zalety. Wśród nich należy wymienić przede wszystkim:

  • w scentralizowanej architekturze mamy lepszą przejrzystość historii zmian,
  • branche są przechowywane na serwerze, a więc nie musimy martwić się o kopie zapasowe,
  • istnieje możliwość dodania uprawnień do subfolderów.  

W ostatnich latach palmę pierwszeństwa wśród systemów wersjonownia kodu dzierży jednak młodszy Git (został stworzony w 2005 r.).

Należy podkreślić, że każdy katalog kontrolowany przez ten system jest w pełni funkcjonalnym repozytorium. Aby korzystać z takiego repozytorium, nie jest więc wymagane połączenie z głównym serwerem (możliwość pracy w trybie offline), bo i tak zawsze mamy dostęp do pełnej historii zmian wszystkich plików. Git jest systemem rozproszonym

To przydatne narzędzie przede wszystkim przy projektach, w których konieczne jest monitorowanie wielu zmian plików, nadawanie im różnych wersji itd. Git pozwala nie tylko tworzyć repozytoria, ale też umożliwia deweloperom edycję wielu plików jednocześnie, zarządzanie wersjami, tworzenie rozgałęzień projektu, łączenie projektu z innymi, generowanie dokładnych statystyk z życia projektu itd.

Ci, którzy wybierają Git, podkreślają, że zapewnia on przede wszystkim bardziej dynamiczną i elastyczną pracę z repozytorium, niż dzieje się to w przypadku SVN.   

Do najważniejszych cech systemu Git należy zaliczyć:

  • rozproszoną, bardziej odporną na usterki architekturę sieci,
  • większą wydajność podczas pracy przy dużych projektach,
  • możliwość pracy offline,
  • dobre wsparcie dla rozgałęzionego procesu tworzenia oprogramowania,  
  • wsparcie dla protokołów sieciowych: HTTP(S), FTP, rsync, SSH, 
  • więcej opcji podczas scalania branchy,
  • z racji tego, że z systemu Git korzysta bardzo wielu programistów, łatwiej jest współpracować z innymi.

Git i popularne serwisy hostingowe 

Przy systemie Git warto jednak zatrzymać się na dłużej. A konkretnie przy platformach hostingowych z repozytorium, które są przeznaczone właśnie dla projektów programistycznych wykorzystujących ten system. 

GitHub - o ile sam Git jest narzędziem do zarządzania historią kodu źródłowego, tak GitHub jest usługą służącą do hostowania repozytoriów i udostępniania ich innym członkom zespołu. Jak działa GitHub? Na najwyższym poziomie organizacji znajdują się konta osób lub organizacji i to właśnie w ramach tych profili można tworzyć repozytoria. Te mogą być publiczne lub prywatne. Oferta uwzględnia nieograniczoną wielkość repozytorium oraz nielimitowane, darmowe repozytoria prywatne.  
  
Bitbucket - produkt umożliwiający zespołom planowanie projektów, współpracę w zakresie tworzenia kodu, testowanie go i wdrażanie w jednym miejscu. Bitbucket zapewnia więc jedną lokalizację do planowania i realizacji projektu. Maksymalnie do 5 użytkowników na zespół w darmowym pakiecie, wielkość repozytorium to z kolei 2 GB. 

GitLab - sieciowy menedżer repozytorium Git wyposażony m.in. w wiki i funkcje śledzenia błędów. Wielkość repozytorium do 10 GB, nielimitowana liczba prywatnych repozytoriów oraz liczba użytkowników w ramach repozytorium.

Pojęcia, które warto znać

Na koniec przygotowaliśmy słownik podstawowych pojęć, które pozwolą zrozumieć istotę działania repozytoriów i systemów kontroli wersji: 

Commit - wysyłanie do repozytorium zmian dokonanych w kodzie,

Branch – odgałęzienie pozwalające na bezkolizyjną pracę wielu członkom zespołu równocześnie. Każdy może pracować na swoim branchu i dopiero po zakończeniu pracy scalić zmiany z innymi programistami pracującymi przy projekcie,

Tip – najnowszy commit w danym branchu,

Checkout - proces, w którym pobiera się pliki z repozytorium i tworzy kopie lokalną,  

Merge - proces scalania zmian pochodzących z różnych źródeł. Scalanie gałęzi pobocznych (branch) z główną gałęzią projektu (trunk),  

Conflict - konflikt, do którego dochodzi w momencie, kiedy kilku członków zespołu próbuje np. dokonać zmian w tym samym miejscu kodu. Systemy kontroli wersji wykrywają takie sytuacje, 

Update – aktualizacja lokalnego repozytorium,

Pull – pobranie/wysłanie zmian z/do innego repozytorium,

Fork - kopia repozytorium,

Log – informacja testowa do wprowadzonej zmiany,

Working area - miejsce, w którym robimy zmiany w kodzie (w tym miejscu są widoczne wszystkie, jeszcze nie commitowane zmiany), 

Staging area – miejsce, do którego wrzucamy kod, który później stanie się commitem.

 

A to z kolei podstawowe komendy wykorzystywane w systemie Git:

git init - tworzy nowe repozytorium w bieżącym katalogu,

git status - wyświetla aktualny status w bieżącym katalogu,

git add . - dodaje zmiany we wszystkich plikach z bieżącego katalogu do staging area,

git add sciezka_do_pliku - dodajemy jeden plik lub katalog do staging area,

git commit -m "nazwa naszego commita” - tworzymy commita z wcześniej dodanych zmian,

git remote add origin https://github.com/nasze-repo/repo.git - wskazujemy z jakiego zdalnego repozytorium chcemy korzystać,

git push origin master - wysyłamy zmiany na wskazane repozytorium, czyli "origin" i branch "master",

git branch - lista branchy,

git checkout -b test - utworzenie i wejście na nowy branch test.

***

Jak widać, bez repozytorium ani rusz. Szczególnie w złożonych projektach, które wymagają zaangażowania większej liczby programistów. 

Korzystanie z repozytoriów i systemów kontroli wersji pozwala na zachowanie pełnej historii kodu strony oraz pracę bez ryzyka, że wprowadzone w nim poprawki wymażą wcześniejsze wersje. To także szansa na szybsze rozwiązanie ewentualnego konfliktu w projekcie i lepsza komunikacja w zespole.

Źródła:własne, WebChef's, github.com, bitbucket.org, subversion.apache.org, gitlab.com