#GIT01-Czyli o najpopularniejszym systemie kontroli wersji, pobieranie, przykłady użycia.

Reading Time: 9 minutes
Wszystkiego najlepszego drogie mamy !!!
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.

Zostawiamy domyślne opcje
Ja tutaj zmieniam na notepad++, gdyż go posiadam i według mnie jest to najlepszy zamiennik notatnika w systemie Windows.
Zostawiamy tak jak jest.
Tutaj domyślnie openssh zostawiamy i może się to przydać.
Tu też domyślnie zostawiamy, wybór tutaj wpływa na pracę między systemową UNIX vs Windows, zostawiamy jak jest.
Zostawiamy mintty
Extra opcje też zostawiamy jak są.
I czekamy na instalacje.
Git został zainstalowany czas zweryfikować czy jest oki.

Weryfikacja poprawności instalacji GITa

Odpalamy git bash lub zaznaczoną opcje zostawiamy i klikamy next
Wpisujemy po prostu git i mamy weryfikacje
git –version wypluje nam na ekran wersje 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

Odpalamy pobrany plik .msi
Wybieramy czy instalujemy dla wszystkich czy tylko dla jednego usera
Tutaj taka instalacja typu full content czyli wszystko domyślnie zaznaczone i tak zostawiamy
Zostawiamy Openssh
Ja nie zezwalam
Instalacja zakończona czas odpalić git extensions

Uruchomienie git extensions – pogadanki vs cmd

Ja w tym tutorialu użyje english, gdyż większość użytkowników będzie używać w takim języku git extensions i potem możecie nie wiedzieć jak się tłumaczy daną polską fraze, na to co nam ktoś mówi 😀
Tak wygląda domyślny wygląd po pierwszym uruchomieniu programu.
Wchodzimy w opcje i naprawiamy rzeczy na czerwono.

https://sourceforge.net/projects/kdiff3/files/latest/download

Musimy pobrać program wyżej, który rozwiąże oba problemy.

I tyle odpalamy ponownie git extensions

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

Okno z clone jest takie same z każdego miejsca, więc bez różnicy, z którego miejsca klonujecie, bez git extensions tego wpisu do prawego przycisku myszy w folderze nie będziecie mieli, więc przydaje się nawet jeśli samego git extension używać nie będziecie używać.
Z poziomu start clonuj, po wklejeniu w repository to clone naszego przykładowego sunflowera androida nie mam destination czyli gdzie nasze repo ma się sklonować.
Zaś prawy przycisk myszy clone np. na dysku c wskazuje nam na dysk c i automatycznie podpowiada w subdirectory to create nazwę taką samą jak ma repo, które klonujemy.
Po clone czekamy na sklonowanie, długość czasu oczekiwania zależy od całościowej wielkości naszego repozytorium, które chcemy sklonować.
I już mamy nasze repo
Jeśli mamy opcje widok, ukryte elementy będziemy mieć w folderze sklonowanym katalog .git, który zawiera wszelakie informacje na temat naszego repozytorium.
Będąc w folderze, która posiada wspomniany wcześniej ukryty folder .git możemy użyć opcji gitext open repository i wtedy nasze repo otworzy się w git extensions.
Tak wygląda otwarte repozytorium tego przykładowego sunflowera

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.

Przykład checkouta.
Mamy kropkę niebieską na ustawionym branchu i właśnie do niego się zcheckoutowaliśmy.

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.

Przy checkoucie brancha, którego lokalnie nie ma domyślnie dostaniemy opcje twórz lokalny branch o nazwie i taka jak remote, klimamy checkout.
Tak wygląda struktura naszych branchy.

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 ! 😀

Napisz komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.