Git Podstawowe pojęcia, instalacja i konfiguracja

Transkrypt

1 Git Podstawowe pojęcia, instalacja i konfiguracja System kontroli wersji (system kontroli rewizji) ułatwia synchronizację plików projektu przez wszystkich uczestników. Git rozproszony system kontroli wersji. Zalety Gita lokalność; kontrola spójności danych; optymalizacja pod kątem rozgałęziania; fakt, że jest to system rozproszony; wydajność [1, Calibre poz. 10,6 / 370]. Repozytorium Repozytorium to folder, którego zawartość jest kontrolowana przez Git. Taki folder może zawierać nie tylko kod źródłowy programu ale również pliki takie jak strona www czy nawet plik tekstowy. W repozytorium znajduje się specjalny podfolder.git gdzie zapisywane są szczegółowe dane o śledzonych plikach. Commit czyli zatwierdzanie zmian Git nie zatwierdza zmian automatycznie, zatem jeśli uznamy, że wprowadzone przez nas zmiany są istotne i wymagają zapisania musimy sami wykonać zatwierdzenie zmian. Jednak jeśli nie wprowadzimy żadnej zmiany to Git nie pozwoli na zatwierdzenie zmian. Wykonanie operacji zatwierdzania powoduje zapisanie rewizji. Każda rewizja składa się m.in. z: identyfikatora rewizji, danych osoby wykonującej rewizję, daty i godziny wykonania rewizji, identyfikatorów poprzednich rewizji, informacji o zmodyfikowanych plikach i katalogach [1, Calibre poz. 12,2 / 370]. Uwaga! Po angielsku rewizja i operacja zatwierdzania mają jeden wspólny termin: commit. Możemy przywrócić stan projektu odpowiadającego dowolnej rewizji. Praca grupowa Na serwerze znajduje się repozytorium, które jest współdzielone. Uczestnicy projektu tworzą lokalną kopię repozytorium, na której pracują i dla której robią rewizje. Potem mogą zmiany przesłać na serwer i ewentualnie poczekać na zatwierdzenie administratora (jest to zależne od konfiguracji). Po zatwierdzeniu rewizji przez administratora, stają się one widoczne dla innych uczestników projektu. Git pozwala na sprawdzenie różnic między pomiędzy dwoma rewizjami.

2 Hosting projektów Git darmowy dla projektów o otwartym kodzie. jest darmowy również dla projektów prywatnych Literatura w Internecie Skąd można ściągnąć klienta Gita? Uwaga! Dostępna jest wersja portable, którą można zainstalować na nośniku zewnętrznym np. na pendrivie (na starym 1GB instaluje się około 30 minut). Uruchamianie wersji portable: Trzeba wejść do katalogu i uruchomić aplikację git-cmd.exe lub git-bash.exe Obydwie pozwalają na wykonywanie poleceń Gita. Pierwsza to jest wiersz poleceń, który od razu uruchamia się w odpowiednim katalogu aby można było bezpośrednio wykonywać polecenia Gita. Jako wiersz poleceń będzie obsługiwał inne polecenia windowsowe. Drugi jest odpowiednikiem na linuxa i pozawala na wykonywanie poleceń linuxowych np. Przydatne polecenia Git git help <nazwa polecenia> Zad. 1 Zainstaluj wersję portable na pendrivie lub innym nośniku zewnętrznym Zad. 2 Sprawdź wersję wykonując polecenie: git --version Podstawowa konfiguracja klienta Git Zad. 3 Sprawdź obecne ustawienia wydając polecenie git config -l

3 Pracę nad repozytorium należy zacząć od ustalenia danych o autorze. Służą do tego komendy: git config --global user.name "Imie Nazwisko" git config --global user. you@example.com Zaleca się by w przypadku gdy imię i nazwisko zawiera znaki diakrytyczne wykonywać ją w środowisku bash Zad. 4 Wykonując odpowiednie komendy ustal imię i nazwisko autora repozytorium. Domyślnym edytorem dla Gita jest edytor vi ale można też zainstalować GitPada, który wykorzysta z windowsowego notepada lub innego ulubionego edytora (musi być tylko skojarzony z plikami txt). Link do GitPada: Tworzenie repozytorium Repozytorium, w skrócie repo, to projekt prowadzony w systemie Git. Nowe repozytoria możemy tworzyć na dwa sposoby: inicjalizując nowy projekt, klonując istniejące repozytorium [1, poz. 31,0 / 370]. Inicjalizacja nowego repozytorium Służy do tego komenda: git init Wydajemy ją w folderze, który jest przeznaczony na projekt. Jeśli komendę błędnie wydamy można usunąć folder.git. Zad. 5 Stwórz swój folder i utwórz w nim nowe repozytorium Gita. Klonowanie repozytorium Służy do tego komenda: git clone [adres] która tworzy w bieżącym katalogu kopię repozytorium o podanym adresie: Przykład 1 Chcemy utworzyć kopię repozytorium. Możemy wykorzystać stronę:

4 i wybrać jakieś repozytorium jeżeli teraz skopiujemy i wydamy komendę: git clone [tu wklej skopiowany adres] zacznie się proces klonowania jak na zdjęciu poniżej: Jeśli dodamy na końcu polecenia. to spowoduje to utworzenie kopii repozytorium w bieżącym folderze, bez kropki będzie utworzony podfolder jquery (jak na zdjęciu). Zad. 6

5 W poprzednio utworzonym projekcie utwórz kopię projektu JQuery. Sprawdź liczbę plików projektu, liczbę osób biorących udział w tworzeniu projektu oraz liczbę rewizji. Na koniec sprawdź rozmiar plików. Komendy służące do wykonania ostatnich poleceń to: sprawdzenie uczestników projektu: git shortlog -s -n liczba uczestników projektu: git shortlog -s n wc -l Liczba plików projektu: find. -type f -print grep -v -E '/\.git/' wc -l liczba rewizji podanych w wymaganym okresie: git log --pretty=oneline --since=" " --until=" " wc -l liczba rewizji: git log --pretty=oneline wc -l rozmiar pliku sprawdzamy komendą du, przełącznik h powoduje wyświetlanie w bardziej czytelnej formie Zad. 7 (do domu) du.git h Uzupełnij tabelkę: Jquery Jądro linuxa Symfony Ruby on rails Dojo Liczba uczestników Liczba plików Liczba rewizji Rozmiar całego repozytorium Rozmiar folderu.git Adresy pod którymi można znaleźć repozytoria: jądro linuxa: symfony

6 Ruby on rails Dojo Badanie historii projektu: Wykorzystujemy do tego komendę: git log Do przewijania wyników tej komendy można użyć spacji i Q (strzałka w górę i w dół też działa). Uwaga! Jeśli chcemy zakończyć działanie dowolnej komendy wystarczy wpisać ctrl+c. Za pomocą parametru - -pretty możemy zmieniać format wyświetlania np. wydając polecenie: git log --pretty=oneline uzyskamy wyświetlanie informacji w jednej linijce. Inne wartości parametru pretty: short, medium, full fuller, raw format Jak używać przełączników i filtrować dane znajdziemy pod adresem: Aby znaleźć informacje o 5 ostatnich rewizjach należy użyć polecenia: git log -5 Natomiast aby wydrukować 3 ostatnie rewizje wykonane przez podanego autora można użyć komendy: Zad. 8 git log -3 --author=richard Do utworzonego wcześniej sklonowanego repozytorium wybierz jednego autora i sprawdź dla niego liczbę dokonanych przez niego rewizji. Jeżeli np. dla repozytorium jquery chcemy sprawdzić ile rewizji wykonał autor Richard to możemy wpisać komendę:

7 git log --pretty=oneline --author=richard wc -l Wizualizacja historii projektu Do wizualizacji historii projektu służy program Git gui. Aby go uruchomić w danym repozytorium należy wpisać: git gui Jeżeli teraz chcemy wyświetlić dane o jquery to wybieramy z menu repository ->Visualize Master s History. To samo możemy uzyskać jeśli w repozytorium nad którym pracujemy wpiszemy komendę: gitk Możemy teraz przejrzeć różne informacje o tym kto i kiedy dokonał zmian oraz czego one dotyczyły a także inne informacje. Obszar roboczy Cała zawartość projektu poza folderem.git nazywa się obszarem roboczym. Jeżeli chcesz sprawdzić zawartość katalogu użyj komendy ls lub dir (inne potrzebne instrukcje pod linuksem można znaleźć pod adresem: ) Stan plików w obszarze roboczym można przywrócić do stanu jaki miały w ostatniej rewizji. Służy do tego komenda: git reset --hard Jeśli usuniemy pliki z obszaru roboczego to powyższa komenda pozwoli nam na ich przywrócenie Np. w repozytorium jquery skasujemy wszystkie pliki komendą

8 rm * i wystarczy użyć komendy do przywracania stanu z ostatniej rewizji i pliki pojawiają się na dysku. Uwaga! Komendy kasujące np. rm czy rmdir należy używać ostrożnie i tylko wtedy gdy jest to naprawdę potrzebne. Możemy też przywrócić wersje z określonej rewizji. Każda rewizja ma odcisk SHA-1 i jeśli wpiszemy kilka pierwszych znaków to możemy przywrócić stan z rewizji oznaczonej SHA-1. Ogólna składnia komendy: git reset --hard [SHA-1] Przykład (wymyślony SHA): git reset --hard aabbcc Polecenie do sprawdzania wprowadzonych zmian: git status Zad. 9 Skopiuj repozytorium np. html5 i skasuj wszystkie pliki i foldery oprócz folderu.git. Sprawdź status wprowadzonych zmian. Następnie odtwórz zawartość obszaru roboczego by odpowiadała ostatniej rewizji i sprawdź status ponownie. Stan plików w obszarze roboczym można też przywrócić za pomocą komend: git checkout f git checkout f [SHA-1] Powyższe komendy nie wpływają na pliki, które zostały właśnie utworzone. Zad. 10 Utwórz nowe pliki w poprzednim repozytorium. Sprawdź status. Tworzenie rewizji i przywracanie stanu plików Tworzenie rewizji Dwa kroki są potrzebne by pracować w systemie Git: 1. Modyfikacja plików i folderu projektu 2. Zapamiętywanie stanu projektu w postaci rewizji (commit) Aby wykonać rewizję (czyli zapisać bieżacy stan wszystkich plików w folderze roboczym z ang. snapshot) należy użyć komend: git add -A git commit -m "Krótki opis rewizji..."

9 Równoważnie można użyć: git add. git commit a -m "komunikat..." Następujące operacje są sobie równoważne: git add A git add --all Zad. 11 (ćw 5.1 z książki [1]). Stwórz następującą strukturę katalogów i plików a następnie wykonaj rewizję (commit): strona-www css js skrypty.js style.css index.html Listing działań służących rozwiązaniu tego zadania: jakula@drzewa MINGW64 / (master) $ dir bin dev git-bash.exe LICENSE.txt p2 tmp proc cmd etc git-cmd.exe mingw64 proba README.portable usr jakula@drzewa MINGW64 / (master) $ cd proba jakula@drzewa MINGW64 /proba (master) $ mkdir strona-www jakula@drzewa MINGW64 /proba (master) $ cd strona-www $ mkdir css $ cd css $ vi style.css $ dir

10 style.css $ mkdir js $ cd js jakula@drzewa MINGW64 /proba/strona-www/css/js (master) $ vi skrypty.js jakula@drzewa MINGW64 /proba/strona-www/css/js (master) $ cd.. $ vi index.html $ dir js style.css $ vi index.html $ dir index.html js style.css $ cd.. $ dir css $ git init Initialized empty Git repository in F:/git/proba/strona-www/.git/ $ git add -A warning: LF will be replaced by CRLF in css/index.html. The file will have its original line endings in your working directory. warning: LF will be replaced by CRLF in css/js/skrypty.js.

11 The file will have its original line endings in your working directory. warning: LF will be replaced by CRLF in css/style.css. The file will have its original line endings in your working directory. $ git commit -m "Pierwsza rewizja - a" [master (root-commit) 0ba78f1] Pierwsza rewizja - a 3 files changed, 4 insertions(+) create mode css/index.html create mode css/js/skrypty.js create mode css/style.css $ Następnie samodzielnie dodaj odpowiednie pliki jak w strukturze poniżej i wykonaj kolejną rewizję (commit): strona-www css js skrypty.js style.css index.html print.css README.TXT Ponownie dokonaj zmian zgodnie ze strukturą poniżej i wykonaj kolejną rewizję (commit): strona-www css js skrypty.js style.css index.html print.css README.TXT strony strona1.html strona2.html strona3.html strona4.html strona5.html Aby sprawdzić historię zmian użyj komendy:

12 git log Przywracanie stanu plików do dowolnej rewizji: Wykorzystujemy do tego komendę: git checkout [SHA-1] gdzie SHA-1 to pierwsze numery odcisku wybranej rewizji np. chcemy przywrócić stan z drugiej rewizji z poprzedniego zadania. Musimy sprawdzić oznaczenie SHA np. przez komende git log Listing działania: $ git log commit d3d562be8e653d2fed3c9991d7023c7548c24f34 Author: Urszula Gałązka <jakula@matman.uwm.edu.pl> Date: Sat May 6 15:24: Trzecia rezwizja -c commit 0f5c29cc7ef96d877380c2d92da4507fb57f9ab4 Author: Urszula Gałązka <jakula@matman.uwm.edu.pl> Date: Sat May 6 15:12: Druga rezwizja -b commit 0ba78f1061f8e9ec96b89e1d473958d5940b74ec Author: Urszula Gałązka <jakula@matman.uwm.edu.pl> Date: Fri May 5 19:16: Pierwsza rewizja - a $ git checkout 0f5c Note: checking out '0f5c'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example:

13 git checkout -b <new-branch-name> HEAD is now at 0f5c29c... Druga rezwizja -b MINGW64 /proba/strona-www ((0f5c29c...)) Bieżącą gałąź możemy sprawdzić poleceniem: git branch Listing z przykładu: jakula@drzewa MINGW64 /proba/strona-www ((0f5c29c...)) $ git branch * (HEAD detached at 0f5c29c) master Jeśli teraz wydamy polecenie: git checkout master to wrócimy do ostatniej rewizji a polecenie: git branch da efekt podobnie jak na listingu: jakula@drzewa MINGW64 /proba/strona-www ((0f5c29c...)) $ git checkout master Previous HEAD position was 0f5c29c... Druga rezwizja -b Switched to branch 'master' $ git branch * master Zad. 12 Wykorzystując strukturę plików i rewizję z poprzedniego przykładu przywróć rewizję pierwszą a potem ostatnią. Użyj do tego oznaczenia SHA. Zad. 13 Jeśli jeszcze nie masz sklonowanego repozytorium jquery to je sklonuj i przywróć je do stanu z pierwszej rewizji wykonanej w 2013 roku. Należy najpierw sprawdzić rewizje z roku 2013 np używając komendy poniżej ograniczamy wyświetlanie do 5 znaków i z wybranego zakresu czasowego.

14 git log -5 --abbrev-commit --abbrev=5 --pretty=format:"%h %cd" --since=" " -- until=" " Parametr: --pretty=format:"%h %cd" zawiera znaczniki formatujące. Inne znaczniki to: %H SHA-1; %h skrócone SHA-1; %an nazwa autora; %ae adres autora. Zad. 14 Sklonuj repozytorium Symfony 2 i przywróć je do stanu z pierwszej rewizji wykonanej przez użytkownika l3l0. Możemy użyć polecenia: git log --abbrev-commit --abbrev=4 --pretty=format:"%h %cd %an" --author=l3l0 do sprawdzenia a potem odpowiednio użytego polecenia git checkout Zmiana nazwy i przenoszenie repozytorium Na folderze w którym jest repozytorium gita możemy wykonywać operację zmiany nazwy i przenoszenia katalogu bez utraty zmian. Zad. 15 Wykorzystując katalog strony-www z wcześniejszych ćwiczeń zmień jego nazwę na webpage a następnie przenieś katalog do innego katalogu. Sprawdź czy te zmiany wpłynęły lub nie na rezpozytorium np. wykonując polecenia: git status git log Rezygncja z repozytorium Wystarczy usunąć folder.git. Uwaga! Tracimy w ten sposób historię projektu. A ponowne wydanie komendy git init zainicjuje repozytorium ale nie będzie przywrócona stara historia.

15 Jeżeli projekt jest bardziej złożony będzie potrzebne użycie bardziej złożonej komendy, która pozwoli usunąć historię ze wszystkich części projektu. Jest to komenda: find. -name.git -type d -exec rm -fr {} \; Literatura [1] Włodzimierz Gajda, Git Rozproszony system kontroli wersji, ebook, Helion, luty 2013 [2] Scott Chacon, Ben Straub, Pro Git book, strona www, dostęp