Dla kogo ten krótki poradnik?
Ano dla takich delikwentów jak ja, co to długo szerokim łukiem omijali ten temat. Nie jestem absolutnie ekspertem tylko początkującym użytkownikiem tego systemu i chcę podać tu podstawy, takie aby można było zacząć korzystać z możliwości Gita i poszerzać swoje umiejętności w posługiwaniu się tym narzędziem. Tu będą tylko podstawy podstaw i to w pierwszej części ograniczone do lokalnego korzystania z tego systemu.
Źródła wiedzy
Przy nauce i pisaniu tego poradnika korzystałem (i korzystam nadal) z różnych źródeł, które poniżej są wymienione, a w różnych miejscach poradnika odwołuję się do źródła, z którego czerpałem treści lub ilustracje.
Internet:
- strona: https://git-scm.com/
- szybki „tutorial”: https://try.github.io/levels/1/challenges/1 - szybki tutorial interaktywny gdzie poza podstawową znajomością angielskiego nie potrzebujesz nic nawet instalować GITa na swoim komputerze, a możesz przekonać się jak to działa
- dokumentacja: https://git-scm.com/doc
- downloads: https://git-scm.com/downloads - instalki dla różnych systemów
- „Pro Git” Scott Chacon & Ben Straub, kapitalna książka online: https://git-scm.com/book/en/v2 - można ją też ściągnąć w różnych formatach, jest też pierwsze wydanie w języku polskim ale tylko online https://git-scm.com/book/pl/v1
- „Git – rozproszony system kontroli wersji” – Włodzimierz Gajda http://helion.pl/ksiazki/git-rozproszon ... gitroz.htm - dodam że książka jest warta każdej wydanej złotówki – polecam!
- Git. Leksykon kieszonkowy - Richard E. Silverman http://helion.pl/ksiazki/git-leksykon-k ... gitlek.htm
- „Kontrola wersji z systemem Git. Narzędzia i techniki programistów” - Jon Loeliger, Matthew McCullough http://helion.pl/ksiazki/kontrola-wersj ... m#format/e
- „GitHub. Przyjazny przewodnik” - Peter Bell, Brent Beer http://helion.pl/ksiazki/github-przyjaz ... github.htm
Git – co to jest?
Git jest „rozproszonym system kontroli wersji” (DVCS - Distributed Version Control System), który śledzi wszystkie zmiany dokonywane na pliku lub wielu plikach i umożliwia przywołanie dowolnej wcześniejszej wersji. Nie musimy się zastanawiać co i gdzie zmieniliśmy, nie musimy się martwić jeśli coś pójdzie nie tak, zawsze możemy wrócić do wcześniejszej wersji. Oczywiście należy dbać o przestrzeganie nieskomplikowanych reguł jakie narzuca ten system.
Co oznacza „rozproszony”? W takich systemach DVCS (Git, Mercurial, Bazaar lub Darcs) „klienci” nie dostają dostępu jedynie do najnowszych wersji plików ale w pełni kopiują całe repozytorium. Gdy jeden z serwerów, używanych przez te systemy do współpracy, ulegnie awarii, repozytorium każdego klienta może zostać po prostu skopiowane na ten serwer w celu przywrócenia go do pracy.1)
Schemat rozproszonego systemu kontroli wersji 2)
Jeśli ktoś myśli, że Git ma zastosowanie tylko w pracy programistów, to jest w dużym błędzie, tak samo jeśli myśli, że to tylko służy pracy zespołowej przy projektach umieszczonych gdzieś tam na zdalnych serwerach. Choć Git stosowany jest głównie do pracy nad kodem, to można używać go z powodzeniem do realizacji różnego rodzaju projektów, jak np.: pisanie takich poradników jak ten właśnie (już to od razu wrzucam do systemu ), tworzenie dokumentacji konstrukcyjnej czy produkcyjnej dowolnego wyrobu, projektowanie modeli do drukowania 3D i co nam tylko przyjdzie do głowy. Nie musimy również pracować w zespole wystarczy, że lokalnie na swoim komputerze zainstalujemy system kontroli wersji i będziemy cieszyć się z jego możliwości. Git śledzi zmiany plików w obrębie konkretnego folderu. Nie ma znaczenia, czy folder ten zawiera kod źródłowy programu czy coś innego. Folder, którego zawartość jest kontrolowana przez Git, nazywany jest „repozytorium” (repository). Repozytoria zawierają specjalny podfolder o nazwie .git, w którym zapisywane są szczegółowe dane o śledzonych plikach 3). Taki folder możemy przenosić, zmieniać mu nazwę i nie utracimy nadzoru nad umieszczonymi w nim plikami dopóki nie skasujemy podfolderu o nazwie .git.
Słowniczek pojęć
Co mnie na początku odrzucało od tematu Gita? - nie rozumiałem używanych pojęć typu „brancze”, „forki”, „komity” (branch, fork, commit) itp. używanych w różnych materiałach czy to w Internecie czy dokumentacji, odrzucała mnie również linuksowa otoczka, praca na konsoli itd. (bo nie lubimy się z wzajemnością z linuksem). No weźmy taki przykład (gdzieś w internecie znaleziony):
„NIGDY nie należy rebase’ować commitów, które zostały już gdzieś wypchnięte! Warto usuwać branche źródłowe używane do rebasowania jeżeli nie będą one już potrzebne.”
Konia z rzędem temu, kto dopiero się uczy i pojmie o co autorowi chodzi
Na siłę próbowałem, to jakoś po polsku zinterpretować, przyporządkować polskie nazwy i zrozumieć sens, co jak wiadomo w przypadku angielskiego słownictwa przyjętego w informatyce czy programowaniu nie zawsze jest szczęśliwe. Nie wiedziałem jak to sobie poukładać i odnieść do funkcji jakie ma git spełniać. Może zaczynałem od mało przyjaznych materiałów? Dlatego może na początek krótka interpretacja takich zwrotów, pojęć.
- repository (repozytorium) - „repository” czyli „a place, building, or receptacle where things are or may be stored”, można więc powiedzieć, że jest swego rodzaju archiwum, przechowalnia itp. dla naszego projektu. Ale przecież nie będziemy robić zamieszania i używać tego typu określeń, po prostu używamy słowa „repozytorium” lub „repo”. Repozytorium oznacza po prostu folder, którego zawartość jest kontrolowana przez Git. Repozytoria zawierają specjalny podfolder .git, w którym zapisywane są szczegółowe dane o śledzonych plikach. I tu pojawiają się różne niuansiki mówiące np. że folder, w którym jest projekt, to nie repozytorium tylko katalog projektu („working directory”), natomiast repozytorium (lokalne) tego projektu znajduje się wewnątrz katalogu projektu. Ale intuicyjnie wiemy o co chodzi .
- - local repository (repozytorium lokalne) - repozytorium lokalne na naszym komputerze, znajdujące się wewnątrz katalogu projektu, inaczej możemy też to zapamiętać, jako repozytorium, w którym wydajemy komendy Gita.
- remote repository (repozytorium zdalne) – znajduje się na jakimś serwerze np. GitHub lub na swoim własnym (jak ktoś ma). - branch (gałąź) - gałąź bądź odgałęzienie, można śmiało pozostać przy polskim określeniu gałąź (pamiętając, że to „branch”). Ale co to jest? Gałąź lub jak kto woli odgałęzienie stanowi podstawowy środek tworzenia oddzielnej linii rozwojowej w naszym projekcie. Odgałęzienie tworzy odnogę umożliwiającą odejście od pewnego zwartego stanu pierwotnego i prowadzenie prac w wielu kierunkach jednocześnie w celu uzyskania różnych wersji projektu. Odgałęzienie może obejmować fazę rozwojową, taką jak prototyp, wersja beta, stabilna lub niedorobiona itp. 4)
- commit (rzecz.: rewizja, czas.: zatwierdzać zmiany, wykonywać rewizję) – rewizja czy też zatwierdzanie zmian – ta operacja służy do zatwierdzania wprowadzonych zmian w nadzorowanym projekcie, nie jest robiona automatycznie musimy sami zainicjować tę operację. W uproszczeniu można powiedzieć, że jest to zapisanie stanu wszystkich nadzorowanych plików i folderów w danej chwili (chwili wykonania polecenia commit). Wykonanie operacji zatwierdzania (commit) powoduje zapisanie rewizji (commit, revision). Jak widać w języku angielskim używane jest jedno słowo „commit” po polsku można by to wyrazić jako „operacja zatwierdzania” oraz „rewizja”.
- fork (rozdwajać się, rozdzielać się) – to jest właśnie jeden z takich terminów, któremu ciężko jednoznacznie w języku polskim przypisać odpowiednik (mówię o sobie). Generalnie w przypadku Git’a i odnosi się to do działań w serwisach takich jak github.com czy bitbucket.org (czyli serwerach Git), a oznacza tworzenie własnego repozytorium (w tych serwisach) na zasadzie sklonowania istniejącego już tam jakiegoś projektu, czyli w zasadzie jest to takie rozgałęzienie istniejącego projektu (dokładny klon repozytorium głównego tegoż klonowanego projektu).
- pull (ciągnąć) - tu bardziej należy to pojęcie rozciągnąć na polecenie „git pull” i oznacza wówczas pobranie aktualnego stanu repozytorium z serwera do własnego już istniejącego lokalnego repozytorium tego projektu.
- push (pchać) – i tu też bardziej należy to pojęcie rozciągnąć na polecenie „git push” i oznacza wówczas przesłanie własnego aktualnego stanu repozytorium na serwer (czyli odwrotnie do pull).
- working directory(obszar roboczy) - dodałem to pojęcie żeby uporządkować nieco co to repo co projekt itd., obszar roboczy, to po prostu zawartość folderu projektu z wyłączeniem podfolderu o nazwie .git czyli po prostu repozytorium danego projektu składa się z obszaru roboczego oraz folderu o nazwie .git
… to na razie tyle pojęć jak coś jeszcze mi przyjdzie do głowy to uzupełnię.
Instalacja Git w systemie Windows
No to przyszedł czas na instalację systemu Git na komputerze. Instalacji Git w systemie Linuks nie opisuję, bo nie lubię się z linuksem. Ale o dziwo w przypadku Git’a wolę pracę z wiersza poleceń niż poprzez nakładki graficzne, poza tym jak się opanuje obsługę z konsoli, to niezależnie od systemu pracuje się wtedy tak samo.
- ściągamy sobie plik instalacyjny z http://git-scm.com/downloads
tutaj każdy sobie wybiera to co dla niego jest najbardziej odpowiednie – ja oczywiście Windows 64bit i zapisuje sobie w odpowiednim dla swojego „widzimisię” folderze. - uruchamiamy ściągnięty przed chwilą plik instalacyjny i kolejno „Next” aż do szczęśliwego „Finish” – ja nie zmieniam ustawień domyślnych (widać wszystko na kolejnych obrazkach)
- No i proszę bardzo, mamy już zainstalowanego Git’a. Po zainstalowaniu klienta Git w systemie Windows pojawi się specjalna konsola Gita. Przypomina ona wiersz poleceń Windows. Jak się o tym łatwo przekonać ? No np. otworzyć dowolny folder i kliknąć PPM (Prawy Przycisk Myszki) ukaże się nam menu kontekstowe na obrazku jak niżej.
wystarczy teraz wybrać „Git Bash Here” aby w tym folderze otworzyła nam się konsola podobna do Windowsowego wiersza poleceń (cmd.exe)
po wpisaniu polecenia „git –version” już biało na czarnym przekonamy się że mamy Git’a i jeszcze odczytamy jaka to wersja.
Dlaczego konsola, a nie jakieś graficzne środowisko? Praca w programie Git za pośrednictwem konsoli uniezależnia nas od dostawcy usług hostingowych takich jak np. github.com, który daje swoje narzędzie jak https://desktop.github.com/ ale wtedy to wyklucza korzystanie z własnego serwera shh czy z bitbucket.org. Konsola daje pełną niezależność.
Podstawowa konfiguracja klienta Git
No jest zainstalowana nowa zabawka ale co dalej? Trzeba by może najpierw ustawić jakąś konfigurację. Na początek warto sprawdzić jaka w ogóle konfiguracja klienta Git jest domyślnie ustawiona. W tym celu należy w znany już sposób uruchomić konsolę i wpisać polecenie
git config -l
i wtedy w konsoli zobaczymy
warto zwrócić uwagę na dwie pozycje zakreślone na obrazku powyżej na czerwono, to nazwa użytkownika i jego email, warto wprowadzić dane identyfikacyjne gdyż wtedy wszystkie rewizje w repozytorium zawierają dane identyfikacyjne autora.
Jak to zrobić? Wystarczy w konsoli wpisać komendy
git config --global user.name „Imię Nazwisko”
git config --global user.email twoj_adres_email
Sprawdźmy w znany już sposób konfigurację, czy mamy swoje dane wprowadzone
Jeżeli polecenie git config zostanie wydane bez --global to dane ustawienia zostaną zapisane tylko w repozytorium, w którym konsola była otwarta i w którym to polecenie zostało wpisane.
W Windows (od Windows 7 w górę) komenda git config --global zapisuje powyższe dane konfiguracyjne w pliku .gitconfig znajdującym się w C:\Users\twoje_konto\. Wiedza gdzie ten plik się znajduje przyda się nieco później, jak będziemy chcieli zrobić sobie skróty komend konsolowych (żeby ułatwić sobie życie). Warto wiedzieć, że plik ten można również edytować w windowsowym notatniku, należy tylko pamiętać o kodowaniu UTF-8.
Domyślny edytor tekstu
Jak się okaże niebawem to pewne polecenia Git (jak np. commit)wymagają edytora tekstu. Oczywiście, co to może być w linuksie za edytor, to ani nie chcę myśleć. Natomiast aby w Windows edytorem takim był poczciwy Notatnik to należy wykonać następujące kroki:
- ściągnąć ze strony https://github.com/github/GitPad spakowany plik Gitpad.zip
i zapisać w dogodnym dla siebie folderze - następnie rozpakować i uruchomić program Gitpad.exe uruchomi się konsola i pojawi się monit o domyślny edytor, zatwierdzić i mamy swój domyślny edytor tekstu w systemie Git
..... ciąg dalszy być może nastąpi.
----------------------------------------------------------------------------------------------------------------------------------------------------------
Źródła zaznaczonych w ten sposób 1) w tekście cytatów i/lub obrazków:
1) na podstawie „Pro Git” - Scott Chacon & Ben Straub
2) rysunek z „Pro Git” - Scott Chacon & Ben Straub
3) na podstawie „Git – rozproszony system kontroli wersji” – Włodzimierz Gajda
4) na podstawie „Kontrola wersji z systemem Git. Narzędzia i techniki programistów” - Jon Loeliger, Matthew McCullough