Progmar Marcin Załęczny

Język:

Przykłady użycia Gita

Instalacja gita w systemie Ubuntu: sudo apt-get install git

Wypisanie numeru wersji aktualnie zainstalowanego git-a: git --version

Najnowszą wersję źródeł gita można pobrać stąd: https://www.kernel.org/pub/software/scm/git/

Wypisuje kompletną listę poleceń gita: git help --all

Aby utworzyć repozytorium gita, wchodzimy do katalogu, który ma przechowywać to repozytorium i wywołujemy komendę: git init Spowoduje to utworzenie w tym katalogu podkatalogu .git tworzącego repozytorium, które jest zarządzane przez gita.

Aby dodać nowy plik (np. main.c) do repozytorium, najpierw należy wystawić go do zatwierdzenia komendą: git add main.c

Jeśli w bieżącym katalogu mamy kilka plików (np. test1.c, test2.c, test3.c), które chcemy dodać do repozytorium, to wywołujemy komendę: git add . Spowoduje to oflagowanie wszystkich nowych plików w katalogu bieżącym jako kandydatów dodania do repozytorium.

Aby zobaczyć stan zmian dla bieżącego katalogu (stan indeksu), wywołujemy polecenie: git status Jak widać w sekcji "Changes to be committed" obok każdego dodanego pliku znajduje się oznaczenie "new file:" a obok każdego zmodyfikowanegopliku jest tekst "modified:". Oznacza to, że po zatwierdzeniu zmian wszystkie nowe pliki trafią do repozytorium (main.c, test1.c, test2.c, test3.c).

Aby można było dokonywać zatwierdzeń do repozytorium, musimy podać git-owi dane użytkownika, który tych zmian dokonuje. W tym celu wykonujemy polecenia: git config --global user.email "mzaleczny@gmail.com"
git config --global user.name "Marcin Załęczny"
Informacje te zostaną zapisane w pliku ~/.gitconfig; Informacje o autorze zmian możemy także zapisać w zmiennych środowiskowych: GIT_AUTHOR_NAME i GIT_AUTHOR_EMAIL - będą one miały priorytet przed odpowiednimi ustawieniami w konfiguracji.

Teraz będziemy mogli zatwierdzić zmiany poleceniem: git commit -m "Dodanie plików main.c, test1.c, test2.c, test3.c" Po parametrze -m podajemy opis naszego zatwierdzenia, który pozwoli w przyszłości zorientować się czego dotyczyły zmiany.
Jeśli wprowadzimy zmiany do dowolnego pliku w repozytorium, to przed następnym zatwierdzeniem musimy ponownie go wystawić do zatwierdzenia, chyba że wydamy komendę: git commit --all Spowoduje to zatwierdzenie zmian we wszystkich zmodyfikowanych i istniejących już w repozytorium plików.

Aby móc podać bardziej rozbudowany opis, należy ustawić zmienną środowiskową GIT_EDITOR wskazującą edytor tekstu, który ma być używany do wprowadzania opisów zmian, np: export GIT_EDITOR=vim Żeby powyższa zmiana miała miejsce po każdym restarcie systemu, linijkę tę dodajemy do pliku ~/.profile Od tej chwili nie trzeba podawać parametru -m z opisem. Jeśli podczas commita rozmyślimy się i nie chcemy wprowadzić zmian do repozytorium musimy zapisać pusty plik lub opuścić edytor bez zapisywania zmian.

Jeśli dokonamy zmian w już zakomittowanym pliku, to żeby wysłać jego ponowne zmiany do repozytorium jednym poleceniem, musimy jawnie podać nazwę zmodyfikowanego pliku w poleceniu kommitującym, np: git commit main.c

Aby wyświetlić historię zatwierdzeń wywołujemy komendę: git log Wyświetla ono zmiany począwszy od najnowszej do najstarszej. Jest ono równoważne poleceniu: git log HEAD Jeśli chcemy wyświetlić historię od wybranego zatwierdzenia, to wydajemy komendę: git log HASH_ZATWIERDZENIA

Aby wyświetlić historię zatwierdzeń w podanym przedziale, wydajemy komendę: git log --pretty=short --abbrev-commit master~10..master~8 Wyświetli ona ósme i dziewiąte zatwierdzenie w odgałęzieniu master. Pierwsza opcja --pretty=short odpowiada za ilość wyświetlanych danych na temat każdego zatwierdzenia. Może ona przyjmować następujące wartości: oneline, short, full. Druga opcja --abbrev-commit powoduje skracanie identyfikatorów hashowych.

Jeśli chcemy wyświetlić dane na temat tylko jednego zatwierdzenia, to robimy to za pomocą opcji -1: git log -1 HASH_ZATWIERDZENIA

Aby dodatkowo wyświetlić zmiany w tym zatwierdzeniu, to wykonujemy polecenie: git log -1 -p HASH_ZATWIERDZENIA Dodatkowo możemy użyć opcji --stat w celu wyliczenia plików zmienionych w zatwierdzeniu, oraz podaniu liczby wierszy zmodyfikowanych w każdym pliku: git log -1 --pretty=short --stat HASH_ZATWIERDZENIA

Aby wyświetlić szczegóły zatwierdzenia wywołujemy komendę: git show HASH_ZATWIERDZENIA HASH_ZATWIERDZENIA jest podany w historii zatwierdzeń. Natomiast komenda: git show bez podanego hasha zatwierdzenia wyświetli szczegóły ostatniego z nich.

Bardziej kompaktowa historia zatwierdzeń wyświetlana jest po wydaniu komendy: git show-branch --more=10 Po parametrze --more podajemy maksymalną liczbę zmian.

Aby wyświetlić różnice pomiędzy dwoma zatwierdzeniami wydajemy komendę: git diff HASH_ZATWIERDZENIA_1 HASH_ZATWIERDZENIA_2 gdzie HASH_ZATWIERDZENIA_1 jest wersją wcześniejszą a HASH_ZATWIERDZENIA_2 jest wersją późniejszą.

Plik można usunąć z repozytorium i z systemu plików poleceniami: git rm test3.c
git commit -m "Usunięcie pliku test3.c"
Polecenia te nie usuną natomiast historii tego pliku w repozytorium.

Poleceniem mv natomiast zmieniamy nazwę pliku: git mv test2.c test3.c
git commit -m "Zmiana nazwy pliku test2.c"

Repozytorium klonujemy poleceniam (tworzy repozytorium rozwojowe): git clone git-folder-1 new-git-folder lub poleceniem (tworzy repozytorium czyste): git clone --bare git-folder-1 new-git-folder

Sklonowanie repozytorium zdalnego: git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-4.01.git

Pobiera ze zdalnego repozytorium obiekty i powiązane z nimi metadane: git fetch

Pobiera ze zdalnego repozytorium obiekty i powiązane znimi metadane oraz włącza zmiany do odpowiedniej lokalnej gałęzi: git pull

Przesyła obiekty i powiązane z nimi metadane do zdalnego repozytorium: git push

Wylistowanie opcji konfiguracyjnych gita: git config -l

Do ustawienia opcji konfiguracyjnej gita służy polecenie: git config --global user.name "Marcin Załęczny"

Do usunięcia opcji konfiguracyjnej gita służy polecenie: git config --unset --global user.name

Utworzenie aliasu: git config --global alias.show-graph "log --graph --abbrev-commit --pretty=oneline" Od tej pory polecenie: git show-graph będzie równoważne poleceniu: git log --graph --abbrev-commit --pretty=oneline

Wypisanie zawartości pliku o podanym hashu (SHA1): git cat-file -p 802992c4220de19a90767f3000a79a31b98d0df7

Wyszukanie pełnego hasha obiektu o podanym przedrostku: git rev-parse 802992c422

Wyświetla listę przechowywanych w repozytorium plików oraz hashy przypisanych im blobów (obiektów z treścią): git ls-files -s

Tworzy obiekt drzewa dla bieżącego indeksu: git write-tree

Wypisuje dodatkowe szczegóły danego zatwierdzenia: git show --pretty=fuller

Dodaje tag o nazwie v1.0 do commita o podanym hashu: git tag -m "Wersja 1.0" v1.0 HASH_COMMITA

Wyświetla hash (sha1) podanego pliku (dowolnego - nie musi on być już w repozytorium): git hash-object filename

Żeby zamienić plik wystawiony (poleceniem git add) na niewystawiony wykonujemy polecenie: git rm --cached plik Polecenie to w przeciwieństwie do "git rm plik" nie usuwa pliku fizycznie z dysku.

Przywrócenie pliku usuniętego w poprzednim kommicie: git checkout HEAD -- test6.c

Przywrócenie pliku usuniętego dwa kommitty temu: git checkout HEAD~2 -- test6.c

W pliku .gitignore podajemy pliki lub shellowe dopasowania dla plików, których nie chcemy dodawać do repozytorium. Można go utworzyć w dowolnym z podkatalogów i ma on zastosowanie do katalogu, w którym jest umieszczony oraz wszystkich jego podkatalogów.
W linijkach zaczynających się od znaku '#' podajemy komentarze.
Wykrzyknik na początku wiersza oznacza zanegowanie reguły po nim następującej. Ma on priorytet przed innymi regułami.

Tłumaczy dowolnej postaci nazwę zatwierdzenia (tutaj master) na identyfikator haszowy: git rev-parse master

Wyświetla wszystkie odgałęzienia o nazwie zaczynającej się na 'bug': git show-branch 'bug/*'

Tworzy nową gałąź o nazwie nazwa-galezi wychodzącą z HEAD bieżącej gałęzi: git branch nazwa-galezi

Tworzy nową gałąź o nazwie nazwa-galezi wychodzącą z zatwierdzenia o podanym hashu lub tagu: git branch nazwa-galezi zatwierdzenie

Wypisanie nazw odgałęzień tematycznych występujących w repozytorium: git branch

Wypisanie nazw odgałęzień zdalnego nadzorowania występujących w repozytorium: git branch -r

Wypisanie nazw wszystkich odgałęzień występujących w repozytorium: git branch -a

Wypisanie ostatnich zatwierdzeń dla odgałęzień tematycznych występujących w repozytorium: git show-branch

Wypisanie ostatnich zatwierdzeń dla odgałęzień zdalnego nadzorowania występujących w repozytorium: git show-branch -r

Wypisanie ostatnich zatwierdzeń danych dla wszystkich odgałęzień występujących w repozytorium: git show-branch -a

Wypisanie dwóch ostatnich zatwierdzeń dla odgałęzień tematycznych występujących w repozytorium: git show-branch --more=1

Wypisanie ostatniego zatwierdzenia dla podanego odgałęzienia: git show-branch nazwa-odgalezienia

Przełączenie się do danego odgałęzienia: git checkout nazwa-odgalezienia

Utworzenie nowej gałęzi w bieżącym miejscu i przełączenie się do niej: git checkout -b nowa_galaz

Utworzenie nowej gałęzi w podanym zatwierdzeniu i przełączenie się do niej: git checkout -b hash_zatwierdzenia nowa_galaz

Usunięcie podanego odgałęzienia, które nie jest odgałęzieniem bieżącym: git branch -d odgalezienie

Wyświetlenie różnic pomiędzy katalogiem roboczym a indeksem: git diff

Wyświetlenie różnic pomiędzy katalogiem roboczym a podanym zatwierdzeniem: git diff zatwierdzenie

Wyświetlenie różnic pomiędzy zmianami wystawionymi w indeksie a podanym zatwierdzeniem: git diff --cached zatwierdzenie

Wyświetlenie różnic pomiędzy dwoma podanymi zatwierdzeniami: git diff zatwierdzenie1 zatwierdzenie2

Włączenie podanej gałęzi do bieżącej gałęzi gita: git merge nazwa_galezi Jeśli nie ma konfliktów, to mergowanie przebiegnie automatycznie.

Po rozpoczęciu mergowania (łączenia gałęzi) możemy się z niego wycofać poleceniem: git reset --hard HEAD Przywróci ono katalog roboczy oraz indeks do stanu sprzed wywołania polecena "git merge".

Jeśli zakończono łączenie poleceniem "git commit", to jest możliwość wycofania tego łączenia poleceniem: git reset --hard ORIG_HEAD

Jeśli coś poszło nie tak z rozwiązywaniem konfliktów podczas łączenia, to można wrócić do pierwotnego stanu konfliktów poleceniem: git checkout -m

Bazę łączenia między dwoma lub więcej odgałęzieniami można uzyskać przy pomocy polecenia: git merge-base

Użycie podczas łączenia strategii resolve (domyślnie jest to strategia recursive): git merge -s resolve branch_name

Poniższe polecenie zmienia wskaźnik HEAD tak, żeby wskazywało na podane zatwierdzenie: git reset zatwierdzenie W zależności od podanych mu opcji modyfikuje także indeks i katalog roboczy. Możliwe opcje: git reset --soft zatwierdzenie
git reset --mixed zatwierdzenie
git reset --hard zatwierdzenie
Opcja --soft zmienia HEAD tak, by wskazywało na zatwierdzenie, indeks i katalog roboczy pozostają bez zmian.
Opcja --mixed (domyślna) zmienia HEAD tak, by wskazywało na zatwierdzenie, zmienia indeks tak żeby odzwiercidlał stan w podanym zatwierdzeniu natomiast katalog roboczy pozostawia bez zmian.
Opcja --hard zmienia HEAD tak, by wskazywało na zatwierdzenie, zmienia indeks tak żeby odzwiercidlał stan w podanym zatwierdzeniu oraz zmienia katalog roboczy tak żeby odzwierciedlał stan w podanym zatwierdzeniu.
Polecenie "git reset" przechowuje także oryginalną wartość HEAD w ORIG_HEAD.

Wyświetla historię zmian refów w repozytorium: git reflog

Przenosi zmiany wprowadzone w podanym zatwierdzeniu do bieżącego odgałęzienia: git cherry-pick zatwierdzenie

Anulowanie zmian wprowadzonych w podanym zatwierdzeniu: git revert zatwierdzenie

Wprowadza zmiany w najnowszym zatwierdzeniu aktualnej gałęzi: git commit --amend

Zmiana bazy podanego odgalezienia na ostatnie zatwierdzenie odgałęzienia master: git rebase master odgalezienie Polecenie to może powodować wystąpienie konfliktów, które należy rozwiązać. Po rozwiązaniu konfliktów należy wykonać: git rebase --continue Można w tym miejscu także wykonać: git rebase --abort aby zaniechać zmiany bazy i przywrócić stan repozytorium do stanu sprzed wykonania polecenia "git rebase".

Zapisanie stanu katalogu roboczego i indeksu do skrytki stash wraz z krótkim komunikatem: git stash save "Komunikat"

Przywrócenie ze skrytki stash poprzedniego stanu katalogu roboczego i indeksu: git stash pop

Usuwa zapamiętany stan ze stosu skrytki: git stash drop

Odtwarza zapamiętany w skrytce kontekst bez usuwania go ze stosu: git stash apply

Wyświetlenie stosu przechowywanych w skrytce kontekstów poczynając od najnowszego: git stash list

Wyświetlenie zmian w indeksie i w plikach w najnowszym wpisie w skrytce: git stash show

Wyświetlenie zmian w indeksie i w plikach (wraz z diffami tych plików) w najnowszym wpisie w skrytce: git stash show -p

Wyświetlenie zmian w indeksie i w plikach (wraz z diffami tych plików) w podanym wpisie w skrytce (np. stash@{1}): git stash show -p numer_pozycji

Wyświetlenie rejestru odniesień dla refu HEAD (domyślnego): git reflog show

Wyświetlenie rejestru odniesień dla podanego odgałęzienia: git reflog branch_name

Wyczyszczenie całego reflogu: git reflog expire --expire=now --all
git gc

Wygenerowanie n plików zawierających łaty w postaci wiadomości email dla n ostatnich zatwierdzeń: git format-patch -n

Wyrysowanie tekstowego drzewa zatwierdzeń: git log --graph --pretty=oneline --abbrev-commit --all

Wysłanie łaty na podany adres email: git send-email -to developers@domena.pl 0001-A.patch

Ustawienie w konfiguracji portu smtp: git config --global sendemail.smtpserverport 465

Zastosowanie do bieżącego repozytorium podanej łaty: git am /tmp/git/patches/0002-B.patch

Zastosowanie do bieżącego repozytorium wszystkich łat z katalogu /tmp/git/patches git am /tmp/git/patches/*

Zastosowanie do bieżącego repozytorium wszystkich łat z katalogu /tmp/git/patches stosując łączenie trzytorowe. Przydatne kiedy łaty wprowadzają zmiany z kilku gałęzi repozytorium bazowego: git am -3 /tmp/git/patches/*

Kontunuacja stosowania łat po pomyślnym rozwiązaniu konfliktów: git am -3 --resolved

Na czas stosowania łat git tworzy podkatalog .git/rebase-apply/patch, w którym można znaleźć przyczynę błędu aplikowania łaty.

Przeskoczenie zastosowania łaty (po wystąpieniu problemu z jej aplikowaniem): git am --skip

Wyczyszczenie nieudanego "git am" i powrót do stanu pierwotnego: git am --abort

Usunięcie pliku fname z całej historii repozytorium gita: git filter-branch --tree-filter 'rm -f fname' master lub git filter-branch --index-filter 'git rm --cached --ignore-umatch fname' master

Usunięcie z treści komunikatów linijki zawierającej tekst "to_remove" oraz zamienienie wszystkich tekstów 'rename_me_from' na 'rename_me_to': git filter-branch --msg-filter 'sed -e "/to_remove/d" -e "s/rename_me_from/rename_me_to/" master

Wyświetlenie identyfikatorów SHA1 wszystkich commitów, które modyfikowały plik fname.c: git rev-list master -- fname.c

Przywrócenie pliku fname.c z wcześniejszego miejsca w bieżącej gałęzi: git checkout HEAD~2:fname.c

Aby utworzyć nową komendę gita, tworzymy gdzieś na ścieżce (np. w /usr/local/bin) skrypt shellowy i nadajemy mu nazwę git-nazwa_polecenia (np. git-moje-polecenie) oraz dajemy mu uprawnienia do wykonania (np. 755). Od tej chwili polecenie będzie dostępne po wywołaniu: git nazwa_polecenia (np. git moje-polecenie)

Wyświetlenie zmian z ostatnich trzech dni: git whatchanged --since='three days ago' --oneline

Wyczyszczenie plików nie podlegających kontroli wersji w katalogu bieżącym i wszystkich jego podkatalogach: git clean

Wyszukanie w repozytorium gita wszystkich commitów zawierających w komunikacie podany wzorzec: git grep -i wzorzec

Wyszukanie w archiwum gita wszystkich plików w podanym katalogu zawierających podany wzorzec: git grep -l wzorzec -- katalog