Ćwiczenia z Git cz. 2 Stany plików W programie git wyróżniamy trzy rodzaje plików: pliki aktualne, pliki zmodfyikowane pliki nieśledzone. Po wykonaniu poleceń git add i git commit w rezpozytorium zostaje zapisana zawartość każdego pliku i może być odzyskana. Pliki takie nazywa się plikami aktualnymi (ang. unmodified). Jeżeli do jakiegoś pliku wprowadzimy zmiany to zwartość pliku w obszarze roboczym i repozytorium będzie się różnić. Takie pliki nazywamy zmodyfikowanymi (ang. modified). Natomiast jeśli od ostatniej rewizji utworzymy nowe pliki to nazywają się one plikami nieśledzonymi. Indeksowanie Polecenie git add -A dodaje pliki, które mają być uwzględnione w następnej rewizji, w tym przykładzie będą uwzględnione wszystkie pliki. Polecenie: git commit -m "komunikat..." tworzy rewizję, która obejmuje wszystkie pliki. Możemy oczywiście określić tylko jeden plik, który będzie uwzględniony w następnej rewizji. Pliki, które zostają objęte operacją git commit nazywa się plikami zaindeksowanymi (ang. staged), natomiast pliki zmodyfikowane, które nie zostały zaindeksowane nazywamy niezaideksowanymi (ang. unstaged). A co jeśli chcemy usunąć plik z obszaru roboczego, który został zapisany w jednej z rewizji. Po usunięciu z obszaru roboczego należy plik zaindeksować i wykonać rewizję. Aby zaindeksować plik należy wydać komendę git add jakisplik Cały proces możemy porównać do robienia zakupów. Indeksacji plików może odpowiadać wtedy sporządzenie listy produktów. Mamy je już zapisane na kartce ale jeszcze ich fizycznie nie mamy kupionych. Dopiero polecenie git commit tworzy nam rewizję i w podanej analogii będzie odpowiadać mu zakup produktów.
Możliwe stany plików można odczytać na diagramie poniżej Plik Nieśledzony Śledzony Niezmodyfikowany Zmodyfikowany Aktualny Zmodyfikowany Zaindeksowany Niezaideksowany Pracując w rezpotorium Gita mamy 3 obszary: obszar roboczy folder projektu bez katalogu.git repozytorium katalog.git, gdzie znajduje się baza danych rewizji ineks: - baza danych plików zaindeksowanych (ang. index lub staging area) czyli przygotowanych do kolejnej rewizji znajdująca się w pliku.git/index. Jeszcze raz o komendzie git add Do tej pory w komendzie git add stosowalismy przełącznik A oznaczał indeksakcję wszystkich plików (nowych, starych i usuniętych). Możemy jednak dodawać nazwy katalogów i nazwy plików do tej komendy jeżeli chcemy dodać tylko wybrane katalogi i pliki. Stosować możemy też w nazwach plików i katalogów znaki specjalne: * - zastępuje dowolny ciąg znaków? zastępuje dowolny jeden znak np. git add *.txt git add folder/* git add nowy/fold* git add *.t?t Inne pożyteczne przełączniki git add: git add. obejmuje pliki z przestrzeni roboczej (obejmuje pliki nowe; nie obejmuje plików zmodyfikowanych ani usuniętych).
git add --update. obejmuje pliki z bazy danych (te, które były już śledzone, lecz zostały zmodyfikowane lub usunięte; nie obejmuje plików nowych). git add --all. obejmuje wszystkie pliki [1, poz. 66,2 / 370]. Jeszcze raz o komendzie git commit Komenda git commit zapisuje do rewizji zaindeksowane pliki. Komendę używaliśmy w formacie: git commit -m "Opis rewizji" Do komendy możemy dodać przełącznik a który uwzględnia pliki śledzone chodź nie zaindeksowane a prawidłowa składnia dwóch komend: git add. git commit -a -m "komunikat..." Natomiast jeśli użyjemy tylko komendy git commit to uruchomi nam się skojarzony edytor, w którym należy wprowadzić opis rewizji. Jeśli mamy zainstalowanego gitpada to powinien uruchomić się windowsowy notatnik. Tam wpisujemy opis rewizji a zapisanie i zamknięcie notatnika powoduje dokończenie procesu rewizji. Poleceniem git log możemy sprawdzić czy rewizja została dodana na listę Polecenie git rm Aby zaindeksować usunięty plik stosujemy komendę: git rm [nazwa-pliku] Podany plik powinien być aktualny. Komenda wykonuje domyślnie dwie operacje: Usuwa plik z przestrzeni roboczej jeśli jeszcze w niej jest, Indeksuje plik (w indeksie jest informacja że przy następnej rewizji plik ma być usuniety). Gdybyśmy chcieli usunąć jedynie indeksację plików a nie sam plik z obszaru roboczego możemy użyć przełącznika - - cached np. git rm --cached [nazwa-pliku] Wówczas przy następnej rewizji plik zostanie usunięty z repozytorium ale fizycznie pozostanie w obszarze roboczym. W ten sposób możemy postępować z plikami, które np. zawierają hasła.
Zmiany nazwy pliku git mv stara-nazwa nowa-nazwa Plik o nazwie stara-nazwa musi istnieć w obszarze roboczym. Polecenie nie tylko zmieni nazwę ale również zaindeksuje plik. Zmianę nazwy pliku czy usuwanie pliku może być wykonane przy użyciu standardowych operacji dyskowych ale wówczas należy pamiętać, że takie pliki stają się niezaindeksowane, więc jeśli od razu wydamy komendę git commit to nie będą w niej uwzględnione. Jeśli więc ręcznie usuwamy pliki należy użyć komendy: git add A Sprawdzanie statusu Na koniec pracy powinniśmy sprawdzić status by się upewnić, że zapisane zostały wszystkie pliki: git status s Przełącznik s powoduje, że powyższe polecenie drukuje wyłącznie informacje o wykonanych zmianach bez komentarzy. Zad. 1 Utwórz nowy folder cw2 i utwórz w nim nowe repozytorium git init. Utwórz plik 1.txt Stan zapamiętaj w repozytorium. Utwórz folder dwa i dodaj do niego pliki x.txt, y.txt, z.txt Zapisz stan w repozytorium Stwórz katalog trzy z plikami x.txt, y.txt i x.txt (możesz skopiować katalog dwa, można użyć do tego komendy: cp -r dwa trzy Stwórz rewizję. Usuńmy teraz wszystkie pliki x.txt i zatwierdźmy zmiany: git rm */x.txt Na koniec sprawdźmy jakie mamy rewizje: git log Możesz uruchomić również okno: gitk Oznaczanie stanu plików Wydając polecenie
git status s możemy sprawdzić status plików. Pliki zawierają dwa znaki: pierwszy oznacza indeks drugi obszar roboczy. Utworzymy teraz nowy plik i sprawdzimy jego status otrzymamy efekt:?? plik.txt Zaindeksujemy plik: $ git add -A warning: LF will be replaced by CRLF in plik.txt. The file will have its original line endings in your working directory. jakula@drzewa MINGW64 /cw2 (master) $ git status -s A plik.txt Usuwamy plik plik.txt i sprawdzamy status $ rm plik.txt jakula@drzewa MINGW64 /cw2 (master) $ git status -s D plik.txt Podsumowując oznaczenia stanów plików: A plik dodany (ang. added); D plik usunięty (ang. deleted); R plik o zmienionej nazwie (ang. renamed); M zmodyfikowany (ang. modified) Mogą istnieć stany dwuliterowe (mieszane) np. jeśli utworzymy nowy plik dodamy go od obszaru tymczasowego i usuniemy. Repozytoria zwykła i surowe Repozytorium Gita tworzymy poleceniami: git init git clone Takie repozytorium zawiera: obszar roboczy,
bazę danych rewizji (zawiera się w podfolderze.git) indeksu Jeżeli chcemy synchronizować pracę w grupie programistów wystarczy nam tylko baza danych rewizji. Zatem możemy utworzyć rezpozytorium, które będzie się składać wyłącznie z takiej bazy. Takie repozytorium nazywamy surowym (ang. bare). Repozytoria składające się z obszaru roboczego, bazy danych rewizji oraz indeksu nazywamy repozytoriami zwykłymi. Aby utworzyć repozytoria surowe używamy komend: git init --bare git clone --bare Zwykłe repozytoria są wykorzystywane do codziennej pracy natomiast repozytoria surowe są udostępniane w sieci. W projektach grupowych uczestnicy mogą przesyłać swoje rewizje oraz pobierać rewizje innych uczestników. Porównanie Repozytorium zwykłe baza danych git indeks obszar roboczy Zad. 2 Repozytorium surowe baza danych git Utwórz repozytorium surowe i sprawdź zawartość folderu repozytorium. Wykorzystamy do tego komendę: git init --bare nazwa_katalogu Zostanie utworzony nowy katalog. Listing z zadania. Zostaną utworzone dwa repozytoria: jakula@drzewa MINGW64 / (master) $ ls bin/ dev/ git-cmd.exe* p2/ README.portable webpage/ cmd/ etc/ LICENSE.txt proba/ tmp/ cw2/ git-bash.exe* mingw64/ proc/ usr/ jakula@drzewa MINGW64 / (master) $ mkdir zad2 jakula@drzewa MINGW64 / (master) $ ls bin/ dev/ git-cmd.exe* p2/ README.portable webpage/ cmd/ etc/ LICENSE.txt proba/ tmp/ zad2/ cw2/ git-bash.exe* mingw64/ proc/ usr/
jakula@drzewa MINGW64 / (master) $ cd zad2 jakula@drzewa MINGW64 /zad2 (master) $ git init --bare zad2 Initialized empty Git repository in F:/git/zad2/zad2/ jakula@drzewa MINGW64 /zad2 (master) $ ls zad2/ jakula@drzewa MINGW64 /zad2 (master) $ git init --bare zad3 Initialized empty Git repository in F:/git/zad2/zad3/ jakula@drzewa MINGW64 /zad2 (master) $ Tworzenie plików o nazwa takich jak polecenia gita Jeżeli chcemy utworzyć pliki o nazwach wykorzystujących polecenia lub przełączniki gita musimy użyć specjalnego symbolu - - Oddziela on polecenie od nazwy pliku Przykład 1 Chcemy nazwać plik nazwą --verbose (jest to przełącznik polecenia). Tworzymy plik pod nazwą --verbose. Następnie wydajemy polecenie git add -- --verbose Zad. 3 Stwórz repozytorium, które będzie w kolejnych rewizjach zawierało pliki: --all -A -status -mv Listing dla pliku all
jakula@drzewa MINGW64 /zad2/dziwne_pliki (master) $ git init Initialized empty Git repository in F:/git/zad2/dziwne_pliki/.git/ jakula@drzewa MINGW64 /zad2/dziwne_pliki (master) $ echo "Ala ma kota"> --all jakula@drzewa MINGW64 /zad2/dziwne_pliki (master) $ dir --all jakula@drzewa MINGW64 /zad2/dziwne_pliki (master) $ git add -- --all warning: LF will be replaced by CRLF in --all. The file will have its original line endings in your working directory. jakula@drzewa MINGW64 /zad2/dziwne_pliki (master) Ignorowanie plików Czasami jest potrzebne byśmy pewnych plików nie umieszczali w repozytorium lub jest to niemożliwe np. jeśli w publikowanych kodach nie chcemy umieszczać haseł, plików konfiguracyjnych itd. przy kompilowaniu powstają pliki binarne i nie ma potrzeby umieszczania ich w repozytorium, czasem z w projektach nie możemy umieszczać pewnych plików ze względu na prawa autorskie. Możemy poradzić sobie z tym, że indeksujemy tylko wybrane pliki ale to dobrze działa przy małej ilości plików przy dużej chcielibyśmy użyć uproszczonej wersji modelu: git add -A git commit -m "..." no i polecenia do zwracania statusu tez może nie działać prawidłowo. Możemy sobie z problemem poradzić na dwa sposoby: 1. Wykluczone pliki wyszczególniamy w pliku.gitignore (plik będzie zawarty w repozytorium możemy go również utworzyć globalnie dla wszystkich repozytoriów użytkownika). 2. Wykluczone pliki wyszczególniamy w pliku.git/info/exclude (plik nie będzie zawarty w repozytorium i należy go utworzyć dla każdego repozytorium osobno). W pliku.gitignore zapisujemy pliki, które będą ignorowane przykładowa reguła:
/sciezka_do/pliku/jakis_plik.txt Zapisując pliki, które mają być ignorowane możemy używać znaków * i? Mogą one posłużyć do utworzenia reguł ignorowania plików powstałych podczas kompilacji np. *.[oa] *~ *.exe Możemy zastosować identyczne reguły we wszystkich repozytoriach. Najpierw należy utworzyć plik.gitignore w dowolnym katalogu. Potem wydajemy polecenie: git config --global core.excludesfile C:\git\konfiguracja\.gitignore Polecenie to doda następującą regułę konfiguracyjną w globalnym pliku.gitconfig: [core] excludesfile = C:\\git\\konfiguracja\\.gitignore Od tej pory pliki wymienione w pliku C:\git\konfiguracja\.gitignore. będą ignorowane we wszystkich projektach. Mamy teraz do czynienia z plikami: ignorowanymi zawierają się w przestrzeni roboczej ale są wykluczone przez reguły zawarte w pliku.gitignore lub.git/info/exclude. i nie są śledzone a Git nie zgłasza komunikatów o zmianach ich treści. ignorowanymi to pliki, które występując w przestrzeni roboczej ale nie występują w repozytorium ani w indeksie. A polecenie git status uwzględnia takie pliki oznaczając je znakami?? Uwaga! Jeśli repozytorium zawiera pliki ignorowane to usunięcie zawartości obszaru roboczego skutkuje utratą tych plików i nie zostaną one przywrócone nawet poleceniem: git reset --hard Zad. 4 Tworzymy folder Zad4 i tworzymy nowe repozytorium oraz pliki config/user.cfg config.ini Chcemy dodać regułę do ignorowania: /config jakula@drzewa MINGW64 / (master) $ mkdir zad4 jakula@drzewa MINGW64 / (master) $ cd zad4 $ git init
Initialized empty Git repository in F:/git/zad4/.git/ $ mkdir config $ cd config jakula@drzewa MINGW64 /zad4/config (master) $ vi user.cfg jakula@drzewa MINGW64 /zad4/config (master) $ cd.. $ vi config.ini $ git status -s?? config.ini?? config/ $ vi.gitignore $ git status -s??.gitignore?? config.ini?? config/ $ vi config.ini $ git status -s??.gitignore?? config.ini?? config/ $ vi.gitignore $ git status -s??.gitignore?? config/
$ cd.git jakula@drzewa MINGW64 /zad4/.git (GIT_DIR!) $ cd info jakula@drzewa MINGW64 /zad4/.git/info (GIT_DIR!) $ dir exclude jakula@drzewa MINGW64 /zad4/.git/info (GIT_DIR!) $ vi exclude jakula@drzewa MINGW64 /zad4/.git/info (GIT_DIR!) $ cd.. jakula@drzewa MINGW64 /zad4/.git (GIT_DIR!) $ cd.. $ dir config config.ini $ git status -s??.gitignore $ Co należy wpisać w pliku exclude jest na obrazku poniżej.
Zad. 5 Stwórz katalog Zad5 zainicjuj tam repozytorium. Dodaj w dowolny sposób pliki, które zwykle zostają utworzone przy kompilacji. W odpowiednim miejscu dodaj pliki, które powstają przy kompilacji (podpowiedź jest w pliku exclude albo wykorzystaj wcześniejsze informacje). Stwórz program typu Hello world w dowolnym języku kompilowanym i skompiluj go. Sprawdź poleceniem git status czy aby na pewno dodatkowe pliki nie będą brane pod uwagę i wykonaj commit. Zad. 6 Utwórz folder Zad6. Utwórz plik Read.me i wykonaj pierwsza rewizję. Dodaj plik: db.ini.dist (który będzie plikiem z fałszywymi danymi dostępu do bazy danych). Wykonaj drugą rewizję. Dodaj plik db.ini (który ma zawierać nasze prywatne dane dostępu do bazy danych można zmyślić) oraz.gitignore w którym zapisz db.ini. Sprawdź status. Plik db.ini ma nie trafić do rewizji. Wykonaj ostatnią rewizję. Znaczniki Służą do oznakowania wersji programu. Wyróżniamy znaczniki (ang. tags) lekkie(ang. annotated tags) i opisane (ang. annotated tags). Zawartość znaczników Znaczniki opisane zawierają Znaczniki lekkie zawierają dane autora Znaczniki lekkie zawierają wyłącznie datę utworzenia skrót SHA-1 rewizji. komentarz skrót SHA-1 rewizji, którą wskazują. Zaleca się stosowanie znaczników opisanych. Znaczniki opisane zapisywane są w bazie danych.git w postaci rewizji a lekkie są zapisywane w plikach tekstowych w folderze.git/refs/tags Jak tworzymy znaczniki opisane? Składnia: git tag -a NAZWA -m KOMENTARZ Przykład: git tag -a v3.4.5 -m "Wydanie wersja 3.4.5" Jak dodajemy znacznik, który dotyczy konkretnej rewizji? Składnia: git tag -a NAZWA -m KOMENTARZ SHA-1 Przykład: git tag -a v6.7.8 -m "Wydanie ver. 6.7.8" xxyyzzxx Uwaga! Znacznik musi być unikatowy. Jak tworzymy znaczniki lekkie? Składnia: git tag NAZWA
Przykład: git tag v1.0 Jak dodajemy znacznik, który dotyczy konkretnej rewizji? Składnia: git tag NAZWA SHA-1 Przykład: git tag v1.1 aabbccdd Jak usunąć znacznik? git tag -d NAZWA Jak sprawdzić dostępne znaczniki? git tag Jak sprawdzić znaczniki z datami utworzenia? git log --tags --simplify-by-decoration --pretty="format:%ai %d" lub jeśli pracujemy w konsoli bash, można posortować według dat komendą: git log --tags --simplify-by-decoration --pretty="format:%ai %d" sort Jak wyszukać ostatni znacznik? - znaczniki opisane git describe - znaczniki opisane i lekkie git describe --tags Jak wyświetlić szczegółowe dane o znaczniku? git show s NAZWA Przykład: $ git show -s v1.0.0 O co chodzi z numeracją wersji oprogramowania? Numeracja oprogramowania może być dana liczbą całkowitą lub rzeczywistą albo zestawieniem kilku liczb całkowitych. Wówczas każda liczba (oddzielona najczęściej kropką ) ma swoje znaczenie: Major (numer główny) oznacza wersje programu bazujących na tych samych założeniach, mechanizmach, czasem zmiana wiąże się z porzuceniem starej wersji programu i napisaniem programu od nowa Minor (numer dodatkowy) oznacza kolejne etapy rozwoju w ramach tej samej wersji np. napisanie funkcji na nowo, zmiana istniejącej funkcji itd., Release (numer wydania) najczęściej związany z poprawą błędów, dodawaniem łatek, dokładania kolejnych fragmentów kodu do repozytorium.
czasami Build (w przypadku tzw. nightly-build) nightly- build oznacza przebudowanie projektu nocą. Różne są sposoby oznakowania wersji kodu, czasem nie stawia się kropki między znakiem minor a realease a w niektórych aplikacjach np. w GNOME praktykuje się że parzyste numery minor oznaczają wersje stabilne a nieparzyste jako wersje rozwojowe. Czasem w nazwach wersji pojawia się litera v a czasem jej nie ma. Do czego potrzebujemy znaczników? Znaczniki możemy użyć w poleceniach gdzie występuje klucz SHA-1 np w poleceniach git checkout i git reset Zad. 7 Skopiuj repozytorium jquery (lub wykorzystaj je gdy to już zrobiłeś w poprzednim ćwiczeniu). Wykonaj działania: - Sprawdź dostępne znaczniki. git tag - Sprawdź dostępne znaczniki wraz z datami utworzenia git log --tags --simplify-by-decoration --pretty="format:%ai %d" - Przywróć pliki do wersji 1.4 git checkout 1.4 - Sprawdź dostępne znaczniki - Sprawdzamy szczegóły wybranego znacznika git show -s 2.2.1 Zad. 8 W poprzednim zadaniu sprawdź jakie jest najnowsze dostępne wydanie i wykorzystując znacznik sprawdź jakie modyfikacje w tym wydaniu wprowadzono Zad. 9 Utwórz repozytorium, które będzie zawierało trzy rewizje. W każdej utwórz po jednym pliku i do każdej rewizji dodaj znacznik według numeracji v1.0. Czy można wygenerować skompresowaną wersję projektu? Tak i do tego użyjemy komendy git archive : git archive --format=zip --output=nazwa-pliku SHA-1 Przykład: git archive --format=zip --output=last_commit.zip b8dd Uwaga: Plik skompresowany będzie miał dokładnie taką nazwę jaką wpiszemy w poleceniu. Jeśli więc nie dodamy rozszerzenia to go nie będzie. Możemy użyć również znaczników do oznaczania rewizji do skompresowania: Przykład:
git archive --format=zip --output=drugie_archiwum.zip v1.0.0 Natomiast jeśli wydamy polecenie: git archive --format=zip v1.0.1 To wyświetli nam się treść archiwum. Zad. 10 Wykorzystując poprzednie rewizje stwórz archiwum wybierając: - odcisk SHA, - znacznik. Sprawdź czy podane pliki zostały utworzone, sprawdź zawartość archiwum. Literatura [1] Włodzimierz Gajda, Git Rozproszony system kontroli wersji, ebook, Helion, luty 2013 [2] Scott Chacon, Ben Straub, Pro Git book, strona www, https://git-scm.com/book/pl/v1/pierwszekroki, dostęp 6.05.2017 [3] Wikipedia, Numeracja wersji oprogramowania, strona www, https://pl.wikipedia.org/wiki/numeracja_wersji_oprogramowania, dostęp 26.05.2017