„Mam problemy z repo..”, „Nie mogę wypushować zmian”, „Sprawdziłeś PR na bitbucket’cie?”
– to tylko kilka przykładów z codziennych rozmów między programistami. Kod źródłowy jest bardzo ważną, jeśli nie najważniejszą częścią produktów IT- dosłownie tworzy aplikacje.

Wszystko, nad czym pracuje więcej niż jedna osoba musi mieć dedykowane, wspólne miejsce do przechowywania. Uprawnione osoby mają do niego dostęp i mogą wprowadzać zmiany. Przykładem mogą być tutaj Google Docs lub sharepoint online, gdzie wspólnie w kilka osób edytujemy ten sam dokument tekstowy i tak nasza praca jest łączona w jedną całość.

Podobnie jest z programistami, oni również w zespole pracują nad jedną bazą kodową i tę bazę trzeba gdzieś umieścić. W przypadku arkuszy Google są one trzymane w chmurze Google’a, przestrzeni dyskowej, którą Google udostępnia swoim użytkownikom. Jak jest w przypadku programistów? Gdzie oni trzymają swój kod?

Repozytorium

Odpowiedzią jest repozytorium (często skracane do 'repo’). To tam przechowywany i utrzymywany jest kod. Utworzenie repozytorium umożliwiają systemy kontroli wersji (ang. SVC- System Version Control). Pozwalają one m. in. na śledzenie zmian w plikach należących do repozytorium, a także rozwiązywanie konfliktów, przy łączeniu dwóch różnych wersji w jedną całość. Co to oznacza dla programistów?

Odnieśmy się do sytuacji dobrze nam znanych. Wyobraźcie sobie, że wspólnie z kolegą pracujecie nad prezentacją w Powerpoint, którą chcecie przedstawić w najbliższych dniach Waszemu klientowi. Najpierw jedno z Was rozpoczyna edycję dokumentu w chmurze, natomiast drugie chcąc otworzyć dokument otrzymuje tylko opcję 'read only’ do odczytu. Może pobrać lokalnie dokument i tam go zedytować, później pozostaje Wam jednak kwestia połączenia tych dwóch wersji, uwspólnienia zmian, rozwiązania pomiędzy nimi konfliktów.

Podobne wyzwania stoją przed programistami. Baza kodowa w repozytorium jest zazwyczaj bardzo duża. Nieustannie mierzą się więc oni z różnymi wyzwaniami:

• konieczność uwzględnienie w całej bazie kodowej wszelkich zmian nazw plików lub elementów kodu
• potrzeba połączenia wersji lokalnej z komputera programisty (’zmergowania’ od angielskiego słówka 'merge’ – łączyć) z wersją na serwerze
• możliwość sprawdzenia części kodu dopisanej przez danego programistę, tak aby nie trzeba było przeglądać od razu całej bazy kodowej
• możliwość przetestowania wersji, która właśnie ma zostać dołączona w odosobnieniu, aby nie dopuścić do zepsucia wersji głównej
• cofnięcie zmian na wypadek, gdyby okazało się, że ich dołączenie spowodowało kłopoty…

… i wiele wiele innych 😉

Git i SVN

Istnieje wiele różnych systemów kontroli wersji. Jednymi z najbardziej popularnych są Git i SVN (skrót od pełnej nazwy- Subversion). Ich wewnętrzne zasady działania bardzo się od siebie różnią, nie jest to dla nas jednak w tym momencie istotne. Najważniejsze, abyśmy zapamiętali, że zarówno one jak i inne systemy kontroli wersji pozwalają na śledzenie zmian i utrzymywanie bazy kodowej. Git powstał w 2005-tym roku i jest o kilka lat młodszy od systemu SVN. Z obserwacji tendecji na rynku obecnie SVN powoli odchodzi do lamusa, a niejako naturalnym wyborem staje się Git.

Github, Bitbucket, Gitlab?

Powiedzieliśmy już sobie, czym jest jest Git i SVN, mamy już gdzie trzymać kod i wydawałoby się, że to programistom powinno wystarczyć. Tymczasem w parze z Gitem występują często kolejne pojęcia- Github, Bitbucket, Gitlab.. Aby je wyjaśnić musimy wiedzieć, że: Git sam w sobie jest tylko programem. Chcąc z niego korzystać, musimy go gdzieś uruchamiać. Oczywiście moglibyśmy to robić na lokalnym fizycznym komputerze jednego z programistów, ale wówczas dostęp do niego byłby utrudniony i programiści musieliby kopiować wersje kodu lokalnie między sobą (*chyba, że ktoś pracuje nad kodem sam i chce zaryzykować jego utratę w momencie, gdy jego laptop ulegnie uszkodzeniu lub zostanie skradziony 😉 ). Potrzebny jest nam więc serwer, na którym moglibyśmy uruchomić Gita. Jeśli jednak chcielibyśmy go utrzymywać samodzielnie, musielibyśmy zająć się również przygotowaniem całej infrastruktury, na co większość firm nie ma czasu i pieniędzy.

Z pomocą przychodzą rozwiązania chmurowe, dzięki którym nie musimy się o to wszystko martwić. Podobnie jak na dysku Google’a możemy przechowywać pliki, tak Github, Bitbucket czy Gitlab dają nam Gita w chmurze. Są to rozwiązania, które dla użytkowników indywidualnych w zastosowaniach niekomercyjnych są darmowe, za rozszerzone wersje do użytku komercyjnego trzeba jednak z reguły płacić.

Trudno powiedzieć, która z tych platform jest najlepsza- wszystko zależy od indywidualnych preferencji. Z pewnością różnią się one oferowanymi funkcjonalnościami – przykładowo do niedawna na githubie w wersji darmowej prywatne repozytoria nie były dostępne. Wiele z nich posiada również pluginy do integracji z innymi systemami, jak m. in. z Jirą. Dzięki temu mapowanie określonych porcji zmian w kodzie na konkretne zadania może funkcjonować automatycznie. Warto również wiedzieć, że Gitlab, to nie tylko system kontroli wersji, ale także cała platforma wsparcia dla infrastruktury ze zintegrowanym systemem ciągłej integracji zmian (ang. Continues Integration).

Jak wygląda CV programisty?

Na koniec jeszcze jedna dygresja- czy widzieliście kiedyś CV programisty? Jeśli tak, prawie na pewno był w nim również zawarty link do Github’a czy Bitbucket’a. Jest to link do kodu przygotowanego przez tego programistę, jego swoista wizytówka. Chcąc zatrudnić grafika prosimy o portfolio. Od projektanta wnętrz oczekujemy możliwości obejrzenia jego gotowych projektów. Podobnie jest również z programistami! Aplikując do pracy chcą oni przedstawić swój kod, w CV zamieszczają więc link do ich osobistego repozytorium. Jeśli któryś z kandydatów przesyła Wam kod w formie .zip’a zapytałabym, co jest tego przyczyną, czyżby nie umiał go umieścić w repozytorium?