Pamiętajcie o swoich mamach.
Witajcie moi drodzy,
Kolejny wpis, trochę słabo nie dodać wpisu o gicie na blogu testerskim, tak więc jest wpis o gicie.
Zacznijmy od tego w jaki sposób można przechowywać np. program ?
Jako folder nazwa programu a w środku foldery wersja1, wersja 2, trzy, dziesięć itp. Do tego główny folder programu byłby podzielony na wersje np. beta, alfa i stabilna. Do tego głównie powstały systemy kontroli wersji, ale też aby zapewnić multi-dostęp, niezależnie od systemu operacyjnego czy np. miejsca jeśli łączymy się VPNem.
A teraz przykłady do czego można wykorzystać systemy kontroli wersji.
Takim przykładem może być np. plik pracy magisterskiej plus np. źródła.
Zaczynamy pracę wrzucamy np. 5 plików ‘wysyłamy’, potem możemy takie repozytorium odtworzyć na innym komputerze, ‘pobrać’ wszystkie zmiany, a później coś dodać swojego i znów ‘wysłać’.
To oczywiście w cudzysłowie, zaraz też skrótowo opiszę pewne operacje, słowa kluczowe.
Systemy kontroli wersji dzielą się na komercyjne jak i darmowe.
A rodzaje to lokalne, rozproszone oraz scentralizowane.
Lokalne to plik – wersja1,wersja2,wersja3 pliku itp.
Scentralizowane, to centrala, która jeśli ‘padnie’ to kaput.
Jest to mniej popularna metoda kontroli wersji.
I zostaje ten najbardziej znany i lubiany rodzaj, do którego należy omawiany w tym wpisie GIT czyli systemy rozproszone kontroli wersji.
Rozproszone mają największą zaletę w postaci tego, że każdy kto ‘pobrał’ repozytorium, może w razie padnięcia serwera gita, przyczynić się do jego ewentualnego ‘odtworzenia’. Więcej o rodzajach możecie przeczytać w internecie, jednakże moje wpisy to zajawka i nie ma tu czasu na taką nudną teorię, do dzieła jedziemy !!! 😀
Jakie git posiada najlepsze cechy ?
Multiplatformowy – linux, mac, windows.
Obsługa z konsoli / terminalu lub klienta GUI.
Liczne integracje ze innym oprogramowaniem np. IDE chociażby popularny Inteljji Idea. Odnogi czyli branche, przy klonowaniu domyślnie pobieramy całą historię jest to jednocześnie wada i zaleta, mamy do dyspozycji wszystkie ‘wersje’ plików.
Dobra piszę tak w cudzysłowach, czas na wyjaśnienie co jest czym, a więc komendy czyli praktyka-teoria.
Ale zanim to zrobię musicie pobrać git oraz opcjonalnie git extension, ale lepiej mieć niż nie mieć.
Pobieracie instalujecie stąd
https://git-scm.com/downloads
Na początku domyślna instalacja wystarczy.
Instalacja środowiska GIT – Windows
Odpalamy instalator pobrany z linku https://git-scm.com/download/win
Wybieramy albo 64 albo 32bity.
Weryfikacja poprawności instalacji GITa
Git Extensions – najpopularnszy GUI do GITa na Windowsa
http://gitextensions.github.io/ – klikamy niebieski przycisk download lub link : https://github.com/gitextensions/gitextensions/releases/tag/v3.3.1
Uruchomienie git extensions – pogadanki vs cmd
https://sourceforge.net/projects/kdiff3/files/latest/download
Musimy pobrać program wyżej, który rozwiąże oba problemy.
Klikamy na pierwszy czerowny wpis w opcjach i w mergetool i difftool, dla obu wybieramy kdiff3 i klikamy okej.
Może nie trzeba było tego robić, ale później jeśli byście np. testowali coś to narzędzie do rozwiązywania konfliktów i mergowania jest potrzebne.
Wracamy do teorii gita
Dobra czas na teorie :
Repozytorium git – czyli miejsce pod jakim adresem znajdują się nasze pliki i tutaj od razu przykład albo to może być na githubie albo na gicie np. u nas lub na przykład w pracy, musi być to oczywiście użyte jako serwer. Generalnie komenda git init tworzy nowe repozytorium.
Więcej tutaj – > https://git-scm.com/docs/git-init
Wracamy do repozytorium.
Spójrzmy na tą stronę – > https://github.com/android/sunflower/
A więc pożądane przez nas repozytorium znajduje się pod konkretnym linkiem, na screenie nie widać całego a więc url do tego przykładu to :
https://github.com/android/sunflower.git
Zawsze z końcówką .git
Np. pracują w firmie możemy mieć np. aplikacja.lokalna:8080/repozytorium.git
git clone – komeda, która klonuje / kopiuje nam repozytorium na nasz komputer, w wybranym folderze lub przez cmd / git bash w aktualnym folderze.
Możemy clonować z githuba, ale musimy podawać nasze dane do konta lub też wybrać start – clone repository
Opcja git clone dostępna jest też pod prawym przyciskiem myszy
Znów mają już przykładowe repozytorium wracamy do teorii w praktyce.
Teoria w praktyce, praktyka z teorią 😀
Checkout – > ustawienie stanu plików lokalnych na dany branch lub commit.
Branch – > gałąź najprostsza, najbardziej znana stabilna (stable) i testowa (beta)
Jeśli np. tester ma testować na stabilnej checkoutuje na stable, jeśli na testowej to się checkoutuje na beta.
Warto też zaznaczać opcje force, aby różne zmiany (śmieci) nasze lokalne podczas testów zostały resetowane, mi często się zdarzało, że jakieś śmieci psuły mi aplikacje i nie wiedziałem czy to błąd czy to coś u mnie.
Dlatego w moim małym skrypcie do przełączania się między branachami czyszczeniu itp. zastosowałem między innymi wspomanianą flagę –force.
Kolejna opcja to pull czyli pobranie ‘dostępnych’ commitów i tutaj trzeba powiedzieć po podziale branchy jeszcze raz.
Główny podział branchy to branche na komputerze – zazwyczaj domyślny master będzie jako jedyny od razu czyli tam w sekcji branches.
Zaś remotes są wszystkie inne dostępne w ramach całego repo.
Mamy wszystkie pliki i foldery w momencie clona na naszym dysku, ale dopóki się nie checkoutujemy do danego brancha / commita, doputy nie będziemy mieć stworzonej sekcji lokalnej dla tego brancha. Widzimy mamy tylko branches – master.
Klikamy dwa razy na, któryś inny z remotes.
Kolejna opcja potrzebna dla testerów to git fetch git pull.
Nazwabrancha lub git fetch –all
Git fetch –all pobiera wszystkie nowe zmiany ze wszystkich branchów
Fetch nazwabranach pobiera wszystkie nowe zmiany z danego brancha, z remote – porównuje, czy nasz najnowszy lokalny commit jest np. starszy niż ten te, które są dostępne w remote branchach czyli w zdalnym repozytorium.
https://www.it-swarm.dev/pl/git/jaka-jest-roznica-miedzy-git-pull-git-fetch/958499689/
Git pull – to taki git fetch + git merge, więc generalnie, jeśli jesteś testerem manualnym i tylko pobierasz najnowsze rzeczy, działasz między branachami i nic nie pushujesz i commitujesz, nie musisz używać pulla wystarczy fetch.
Tutaj cmd resztę komend itp. musicie sobie poszukać sami, nie bądź leniem, poczytaj zobacz co dane polecenie robi.
Odpal cmd nawet wpisz git –help poczytaj manual.
Jest wiele źródeł nauki gita, no co ja mogę polecić ?
No oficjalną dokumentacje dostępną pod tym adresem
https://git-scm.com/doc
Jest to pierwsza część wpisu w następnym opowiem o merge, pushowaniu, też tutaj już nie wspomniałem o reset hard i różnicy między checkoutem a resetem, to też przedstawię.
Pokażę troche na linuxie przykładów oraz inne rzeczy, które mi przyjądą do głowy np. może jak działać z hasłami, kluczami.
Jeśli znajdę jakiś przykład to pokażę różne inne rzeczy o których tutaj nawet nie wspomniałem.
Aby uzyskać więcej repo do testów możecie wpisać w google :
windows app site:github.com
W tym wpisie to już koniec, do następnego.
I pamiętajcie o 26 maja czyli dniu mamy, nie zapominajcie o szacunku do swoich jak i kogoś mam, nie tylko w ten jeden dzień, ale w całym roku 🙂
I pamiętajcie myjcie rączki, trzymajcie się miłego ! 😀