[Git] [Poradnik] dla chcących poznać system kontroli wersji

Tutaj umieszczamy tematy związane z językami programowania niepasującymi do innych działów.
Regulamin forum
Temat prosimy poprzedzić nazwą języka umieszczonego w nawiasach kwadratowych np. [Pascal].
Awatar użytkownika
wojtek
Uber Geek
Uber Geek
Posty: 2204
Rejestracja: piątek 04 wrz 2015, 09:03

[Git] [Poradnik] dla chcących poznać system kontroli wersji

Postautor: wojtek » sobota 18 lut 2017, 15:29

Nie wiem czy będzie zainteresowanie więc na razie umieszczam część wprowadzającą. Jeśli będzie zainteresowanie, to będę kontynuował. Pytania i uwagi proponuje zadawać w temacie wydzielonym z tego wątku.

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:
  1. strona: https://git-scm.com/
  2. 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
  3. dokumentacja: https://git-scm.com/doc
  4. downloads: https://git-scm.com/downloads - instalki dla różnych systemów
  5. „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
Książki:
  1. „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!
  2. Git. Leksykon kieszonkowy - Richard E. Silverman http://helion.pl/ksiazki/git-leksykon-k ... gitlek.htm
  3. „Kontrola wersji z systemem Git. Narzędzia i techniki programistów” - Jon Loeliger, Matthew McCullough http://helion.pl/ksiazki/kontrola-wersj ... m#format/e
  4. „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.png

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.
  1. ściągamy sobie plik instalacyjny z http://git-scm.com/downloads
    instalacja_1.JPG

    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.
    instalacja_3.JPG
  2. 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)
    instalacja_2.JPG
    instalacja_4.JPG
    instalacja_6.JPG
    instalacja_5.JPG
    instalacja_8.JPG
    instalacja_7.JPG
    instalacja_10.JPG
    instalacja_9.JPG
    instalacja_11.JPG
    instalacja_finish.JPG
  3. 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.
    git_1.jpg

    wystarczy teraz wybrać „Git Bash Here” aby w tym folderze otworzyła nam się konsola podobna do Windowsowego wiersza poleceń (cmd.exe)
    git_3.jpg

    po wpisaniu polecenia „git –version” już biało na czarnym przekonamy się że mamy Git’a i jeszcze odczytamy jaka to wersja.
    git_2.jpg

    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
git_konfig_2.JPG

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

git_konfig_1.JPG

Sprawdźmy w znany już sposób konfigurację, czy mamy swoje dane wprowadzone
git_konfig_3.JPG


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
    edytor_1.JPG

    i zapisać w dogodnym dla siebie folderze
    edytor_2.JPG
  • 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
    edytor_3.JPG



..... 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
Nie masz wymaganych uprawnień, aby zobaczyć pliki załączone do tego posta.
Wojtek

Awatar użytkownika
wojtek
Uber Geek
Uber Geek
Posty: 2204
Rejestracja: piątek 04 wrz 2015, 09:03

Re: [Git] [Poradnik] dla chcących poznać system kontroli wersji - część 2

Postautor: wojtek » niedziela 19 lut 2017, 13:52

.... i jest ciąg dalszy

Pierwsze lokalne repozytorium

Mamy zainstalowanego Git’a, jest on skonfigurowany, konsola działa, edytor domyślny też jest, no cóż nie ma na co czekać tylko należy wreszcie nauczyć się posługiwać tym narzędziem. Ograniczamy się na razie do pracy lokalnej (tylko na swoim komputerze). Do pracy lokalnej nie są potrzebne żadne konta na githubie czy jakimkolwiek serwerze Git. Wystarczy nam konsola, którą potrafimy już wywołać. Zainstalowany Git i konsola to wszystko co jest potrzebne do obsługi lokalnych repo Git’a.
Oczywiście głównym zadaniem oprogramowania Git jest organizacja pracy grupowej nad projektem. Jedną z głównych zalet Gita jest łatwość tworzenia, przełączania i scalania gałęzi (branch). To powoduje, że wszystkie prace, także projekty jednoosobowe, można realizować z wykorzystaniem Gita. Daje on możliwość rozgałęziania prac nad projektem. Gdybyśmy jednak chcieli mieć kopię zapasową danych oraz korzystać z systemu śledzenia błędów, to wtedy warto skorzystać z serwisów github.com oraz bitbucket.org. 5)
Ale wracajmy do pracy lokalnej. Aby utworzyć nowe repozytorium można to zrealizować na dwa sposoby:
  • inicjalizując nowe repozytorium
  • klonując istniejące repozytorium
Inicjalizacja nowego repozytorium
Nowe repozytorium inicjalizujemy poleceniem git init. Na potrzeby ćwiczeń z tego poradnika trzeba sobie wyznaczyć na dysku jakąś przestrzeń w której będziemy mogli sobie tworzyć dowolne foldery naszych obszarów roboczych (working directory) i repozytoriów lokalnych. Niech będzie na początek folder o nazwie test_01 (albo jakiejkolwiek innej, wedle swojego uznania). W takim folderze klikamy PPM i otwieramy konsolę,

test_01_1.JPG

a w niej wpisujemy polecenie git init oto co się nam pokaże:

test_01_2.JPG

polecenie zostało wykonane, w folderze o nazwie test_01 został utworzony podfolder o nazwie .git, a na konsoli został wypisany tekst:

Initialized empty Git repository in D:/OneDrive/nauka_Git/test_01/.git/

oczywiście ścieżka dostępu do folderu zawierającego .git w wyniku działania komendy git init w każdym przypadku będzie inna, u mnie jest właśnie taka jak wyżej.
Warto zaznaczyć, że komenda ta nie robi nic innego tylko tworzy folder .git, który zawiera w sobie wszystkie informacje na temat powstałego właśnie repozytorium, natomiast nie dodaje z automatu żadnych plików projektu do repozytorium, nawet jakbyśmy uruchomili to polecenie w folderze zawierającym jakiś projekt to tylko powstanie folder .git, a istniejące pliki projektu nie zostaną automatycznie objęte nadzorowaniem w ramach założonego repozytorium. Do tego jest potrzebne wykonanie innego polecenia ale o tym później.

Zakładanie repozytorium poprzez klonowanie
Klonowanie jest drugą metodą tworzenia repozytorium. Tu jest jednak potrzebny dostęp do jakiegoś serwera Git udostępnionego publicznie, z którego to pobieramy kopie repozytorium jakiegoś projektu i umieszczamy na swoim dysku komputera.
Jak to zrobić? Do tego celu służy polecenie

git clone [adres] .

Jeżeli takie polecenie wydamy w wybranym folderze, w którym uruchomimy konsolę, to stworzymy w nim kopię dowolnego repozytorium dostępnego publicznie o podanym adresie. Na końcu polecenia po spacji jest „.” (kropka). To nie jest przypadek. Jeśli kropki by nie było, to w folderze, w którym uruchomiliśmy polecenie powstałby podfolder ze sklonowanym repozytorium. No to do dzieła. Stwórzmy sobie folder o jakiejś wygodnej dla siebie nazwie, ja sobie zrobię konsekwentnie folder o nazwie test_02. Teraz poszukajmy jakiegoś repozytorium dostępnego publicznie np. z serwisu github. Ja skorzystam z adresu gdzie umieszczone jest repo Arduino czyli

https://github.com/arduino/Arduino

Zobaczymy w otwartym oknie przeglądarki z prawej strony zieloną ikonę „Clone or download” należy w nią kliknąć i pokaże się nam adres który należy zapamiętać

https://github.com/arduino/Arduino.git

test_02_2.JPG


Następnie w folderze który sobie stworzyliśmy, np. test_02, w znany już sposób otwieramy konsolę (jak nie pamiętasz to patrz wyżej) i wpisujemy polecenie
git clone https://github.com/arduino/Arduino.git .

test_02_1.JPG


po kliknięciu w enter rozpocznie się klonowanie repozytorium na nasz dysk zakończone mam nadzieję sukcesem tak jak u mnie co widać poniżej (to może chwilę potrwać jak za długo to można wybrać inne repozytorium).

test_02_3.JPG


test_02_4.JPG


Na dysku tym razem mamy repozytorium i wszystkie pliki projektu. Możemy sobie sprawdzić status tego stworzonego repo przez wpisanie polecenia w konsoli (o ile nie była zamknięta a jeśli już zamknąłeś ją, to ponownie otwórz w folderze do którego sklonowane zostało repo)

git status

i w odpowiedzi możemy przeczytać, że

On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean

test_02_5.JPG


czyli jesteśmy w gałęzi głównej, wszystko jest aktualne i nie ma nic do zatwierdzania. A może chcesz zobaczyć kto pracował przy tym projekcie? No jak jesteś taki ciekawy to wpisz w konsoli polecenie

git shortlog -s -n

Wyświetli się lista (długa) przeglądanie jej możesz w każdej chili przerwać naciskając literkę „q” na klawiaturze. A jak jesteś w takim razie ciekaw (bez liczenia nazwisk) ilu uczestników brało udział w projekcie to w pisz teraz takie polecenie

git shortlog -s -n | wc -l

No gratulacje, tym sposobem zostały stworzone dwa pierwsze repozytoria dwoma różnymi sposobami. Do tego w drugim przypadku jeszcze mogłeś ciut innych informacji uzyskać. Proponuję zrobić dodatkowe ćwiczenie i wykonać klonowanie repo, jak wyżej ale tym razem z poleceniem bez kropki na końcu.

git clone https://github.com/arduino/Arduino.git

Warto zwrócić uwagę na nazwę powstałego podfolderu, w którym tym razem znajdzie się sklonowane repo.



..... 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:
5) na podstawie „Git – rozproszony system kontroli wersji” – Włodzimierz Gajda
Nie masz wymaganych uprawnień, aby zobaczyć pliki załączone do tego posta.
Wojtek


Wróć do „Inne języki programowania”

Kto jest online

Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 1 gość