W artykule wyjaśniamy czym jest GIT i dlaczego przydaje się testerom.
Przeglądając oferty pracy dla testerów manualnych i automatycznych, często spotkasz się z wymaganiem „Znajomość narzędzia do kontrolowania systemu – GIT”. Wiele osób początkujących może zastanawiać się czym jest GIT.
Czym jest GIT?
GIT to potężne narzędzie do kontroli wersji, które ma zastosowanie nie tylko w projektach informatycznych (inaczej mówiąc Git pozwala kontrolować wprowadzane zmiany w projekcie). System ten możemy wykorzystywać zarówno w projektach humanistycznych, ścisłych, jak i również artystycznych, dlatego postanowiłam przybliżyć Wam, jak z tego użytecznego narzędzia korzystać.
Krótka historia GIT
GIT powstał w 2005 roku w wyniku wybuchowej mieszanki konfliktu, kreatywności i cofnięcia darmowych licencji BitKeeper’a dla projektów, posiadających otwarty kod źródłowy. W naszym przypadku tym projektem o otwartym kodzie źródłowym było jądro Linuksa, a osobami kreatywnymi Torvalds Linus wraz z zespołem, czyli kolejna wybuchowa mieszanka. W trybie pilnym potrzebowali oni systemu, który spełnia następujące punkty:
- jest szybki;
- ma prostą, nieprzerośniętą konstrukcję;
- jest rozproszony, powinien mieć wsparcie dla nieliniowego rozwoju;
- jest chroniony przed błędami, zarówno tymi wewnętrznymi, jak i wprowadzonymi z zewnątrz.
Idea GIT
Na początku zadajmy sobie pytanie, czym różni się GIT od innych tego typów systemów? W końcu w ogłoszeniach o pracę, albo na formach tematycznych często możemy spotkać się również z innymi systemami, np. SVN.
Różnica między innymi systemami (np. CVS, Perforce, Bazaar, Subversion) a GITem polega na sposobie przechowywania i rejestrowania zmian. Inne systemy przechowują je jako listę zmian na plikach, czyli mówiąc prościej każda zmiana przechowywana jest jako zbiór plików.
GIT natomiast zachowuje się w zupełnie inny sposób. Możemy porównać go do fotografa, który w chwili zmiany robi zdjęcie, migawkę, zawierającą mały zestaw plików.
Co to oznacza dla technicznej osoby?
W przypadku kiedy wykonasz commit albo zapisujesz stan projektu, GIT (nasz Fotograf), tworzy migawkę, na której uwieczniony jest stan wszystkich plików projektu na daną chwilę, dodatkowo przechowuje on referencję do tej migawki. Istotne jest również to, że jeżeli jakiś plik nie został zmieniony, GIT nie zapisuje go ponownie.
Czy w takim razie tracimy ten niezmieniony plik?
Nie, ponieważ GIT zamiast pliku zapisuje referencję do niego (por. ryc. 1).
Jedną z najważniejszych rzeczy w GIT jest pojęcie stanów. Wyróżniamy trzy rodzaje stanów:
- zatwierdzony – dane zostały zachowane w twojej lokalnej bazie danych, czyli jesteś bezpieczny.
- zmodyfikowany – zmieniliśmy dany plik, ale nadal nie osiągnęliśmy stanu zatwierdzony, czyli nie zapisaliśmy zmian w naszej lokalnej bazie danych.
- śledzony – zmieniliśmy dany plik, będziemy go również chcieli zatwierdzić, ale dopiero w kolejnej operacji commit.
Podstawowe komendy GIT
Jednym z częściej używanych przez juniorów komend jest komenda uzyskiwania pomocy (git help). Jeśli wiemy o jaką komendę chcemy zapytać, komenda git powinna mieć następującą formę: git help <polecenie>[note] To polecenie może mieć również dwie inne formy, które działają równoważnie: git polecenie –help oraz man git-. Osobiście jednak najczęściej spotykam się z formą wspomnianą w artykule[/note]. Na samym początku pracy, będzie to jedna z najczęściej używanych komend.
Ponadto na samym początku pracy warto sprowadzić kopię repozytorium na naszą instancję, abyśmy mogli spokojnie programować lub testować. Aby przeprowadzić operację klonowania repozytorium powinniśmy użyć komendy git clone <adres repozytorium>.
Po wykonaniu tego polecenia, każda rewizja, która została wykonana, zostanie pobrana dla każdego pliku. Oznacza to, że w przypadku katastrofy (czyli np. uszkodzenia dysku serwera) możemy przywrócić stan projektu do momentu, kiedy został on sklonowany.
Kiedy jesteśmy w szale tworzenia, może przyjść moment, że nie będziemy pewni co się zmieniło. Wówczas z pomocą przychodzi nam komenda git status, używana do sprawdzania stanu plików. Komenda Git status przyda się przede wszystkim w sytuacjach, gdy chcemy wysłać zmiany do przechowalni, ale nie chcemy przy okazji wysłać też "śmieci", które są nam kompletnie niepotrzebne.
Po tym jak komenda Git status pokaże nam zmienione pliki i jesteśmy pewni, że chcemy wysłać już nasze zmiany, używamy komendy git commit. Po wpisaniu tej komendy nasza
migawka zostanie zapamiętana. Możemy ją potem wykorzystać, np. do porównania z inną interesującą nas migawką.
Git umożliwia również pracę na gałęziach tzw. branch’ach. Aby połączyć się z branch’em musimy wykonać komendę git checkout <nazwa brach'a>. Branch’e możemy również tworzyć: git checkout –b <nazwa brancha>. [note] Operację tę możemy wykonać również używając komendy git branch. [/note]
Czasem nasze zadanie (najczęściej w przypadków testerów automatycznych) wymaga od nas wypchnięcia naszych zmian na zewnątrz, tak, aby inne osoby przyłączając się np. do naszego branch’a, mogły zobaczyć co robimy. Służy do tego polecenie git push <nazwa zdalnego reporyzytorium> <nazwa gałęzi>.
Jeśli chcemy wykorzystać główną gałąź projektu wpisujemy najczęściej: git push origin master (podczas klonowania obie nazwy są ustawiane automatycznie).
Są to komendy dosyć często używane, ale nie jedyne. GIT podsiada bardzo dużą liczbę komend, którą najczęściej poznaje się równoległe wraz ze zwiększaniem naszego testerskiego lub programistycznego doświadczenia.
GIT w pracy testera manualnego
Zanim przejdziemy do przykładu z życia, przedstawię ogólny algorytm pracy w GIT.
Algorytm pracy w GIT
Składa się on z następujących kroków:
- Dokonaj zmiany na pliku, który znajduje się w katalogu roboczym. Plik otrzyma status Zmodyfikowany, czyli zmiany nastąpiły, ale nie zostały zapisane do naszej bazy danych.
- Przenieś bieżący stan projektu do przechowalni. Nasz plik otrzyma teraz status Śledzony. Oznacza to, że przy następnej operacji commit zostanie on zapisany w lokalnej bazie danych.
- Wykonaj operację commit, aby przenieść zawartość pliku z przechowalni do katalogu GIT. [note] Wykorzystałam tutaj algorytm, który znalazłam: https://git-scm.com/book/en/v2 . Polecam zapoznać się z tym linkiem! [/note]
Przykładowe wykorzystanie GITa w pracy testera manualnego
Czasem zdarza się, że chcemy przetestować jakieś zadanie, które dostarczył nam programista na branchu.
Najpierw zanim zaczniemy pracę powinniśmy skopiować repozytorium używając komendy git clone. Teraz kiedy mamy już repozytorium, musimy połączyć się z branchem wykorzystując komendę git checkout. W tej chwili powinniśmy zobaczyć to, co stworzył programista - na naszym komputerze powinien pojawić się jego kod. Jeśli pracujemy już na danym branchu i chcemy pobrać tylko najnowsze zmiany, powinniśmy wykonać komendę git pull .
Pamiętajmy jednak, że możemy wtedy utracić nasze zmiany, których nie stashowaliśmy (nie wykonaliśmy wcześniej komendy git stash). W momencie, gdy mamy już wszystkie zmiany, możemy zbudować nasz projekt i wykonać testy na świeżutkim kodzie.
A co jeśli chcemy przeprowadzić całą procedurę operacji commit? Najpierw powinniśmy dodać wszystkie zmiany używając np. komendy: git add. (tak, ta kropka ma być w komendzie, to nie pomyłka). Następnie warto sprawdzić, czy wszystkie zmiany zostały dodane i czy nie ma żadnych nadmiarowych zmian. Tu z pomocą przyjdzie nam komenda git status.
Gdy już jesteśmy wszystkiego pewni, możemy wykonać commit: git commit –m „komentarz do commitu”. Dobrą praktyką jest tworzenie komentarzy krótkich, treściwych, po których bez problemu możemy zlokalizować commit.
W kolejnym kroku, jeśli jesteśmy pewni swojej pracy możemy wypchnąć zmiany dalej za pomocą komendy git push. Operację commit wykonuje się bardzo często.
Podsumowując
To są tylko dwa praktyczne przykłady wykorzystania powyższych komend. W ciągu dnia pracy wykorzystujemy je bardzo często, w wielu różnych sytuacjach. Warto więc
poświęcić trochę czasu na naukę narzędzia GIT, co na pewno zaprocentuje w pracy, jak i na rozmowach kwalifikacyjnych.
A jeśli dodam, że możemy kontrolować każde wprowadzone przez nas zmiany? Nie tylko w aspekcie kodu?
Okaże się, że jest to potężne narzędzie, dzięki któremu stworzymy listę zakupów, napiszemy powieść przygodową z wieloma autorami, albo stworzymy potężny system do
zarządzania ruchem powietrznym dla wielkiego lotniska.
Ogranicza nas tylko nasza wyobraźnia i umiejętności.
