Git Flashcards
Co to jest Git?
Git to najpopularniejszy system kontroli wersji znacznie usprawnia, a jednocześnie zabezpiecza codzienną pracę przy kodzie.
git clean -idf
usuwa nieśledzone pliki z katalogu roboczego (working directory)
działania polecenia git clean nie da się odwrócić
Flaga -idf pozwala na uruchomienie polecenia git clean w trybie interaktywnym, gdzie git pyta nas, które pliki chcielibyśmy usunąć
git reset
Przenosi pliki z przechowalni (index, stage) do katalogu roboczego (working directory).
Pełni odwrotną rolę niż git add.
Zmienia status plików że ‘śledzone’ z powrotem na ‘zmodyfikowane’
git rm
cofa pliki z repozytorium i dodają je z powrotem na stage (do przechowalni)
po wykonaniu git rm musimy zrobić commit opisujący tę czynność
Stage
Kolejka oczekiwania (git add dodaje tam pliki)
clear
Polecenia terminala, które usuwa wcześniej wpisane komendy
git add .
. dodaje wszystkie pliki do przechowalni (indexu, stage)
zmienia status plików ze ‘zmodyfikowane’ na ‘śledzone’
git status
Pozwala sprawdzić jaki status mają pliki w naszym projekcie
1. zmodyfikowany (modified)
2. śledzony (staged)
3. zatwierdzony (commited)
albo też mówi o tym na jakim jesteśmy branchu
git checkout – index.html
Cofa wszystkie zmiany w pliku ‘index.html’
git checkout
Pozwala się przełączać pomiędzy różnymi encjami:
- plikami
- commitami
- branchami
git log –oneline
Pozwala podejrzeć historię w przydatnym dla oka formacie
Przywracanie zmian za pomocą git checkout
podejrzenie historii:
$ git log –oneline
kopiujemy kod (hash np. 654321e) commita, do którego chcemy wrócić
$ git checkout 654321e
w tym momencie znajdujemy się w trybie odłączonej głowy ‘detached head’ gdzie możemy dowolnie przeglądać projekt i wprowadzać eksperymentalne zmiany, które nie zostaną zapisane.
Jeśli chcemy je zachować to wpisujemy:
$ git checkout -b <new-branch-name></new-branch-name>
tryb odłączonej głowy
Po wpisaniu git checkout <hash>
znajdziemy się w trybie odłączonej głowy 'detached head' gdzie możemy dowolnie przeglądać projekt i wprowadzać eksperymentalne zmiany, które nie zostaną zapisane. Jeśli chcemy je zachować to wpisujemy:
git checkout -b <new-branch-name></new-branch-name></hash>
jak odwrócić zmiany z wybranego commitu i zapisać je jako nowy commit (bez modyfikacji historii)
wchodzę na git log –oneline
kopiuje hash commitu (np. 654321e) do którego chcę cofnąć, a następnie wklejam go do polecanie git revert:
$ git revert 654321e
Historia commitów w żaden sposób nie zostaje zmodyfikowana ani usunięta
jak przywrócić zmiany w repozytorium do wskazanego punktu z historii zmian (z modyfikacją historii)
możemy użyć git reset
należy jednak pamiętać, że polecenie git reset stosujemy na commitach, na których nie zrobiono jeszcze git push
wchodzę na git log –oneline
kopiuje hash commitu (np. 654321e) do którego chcę cofnąć. Teraz mamy 3 opcje do wyboru:
git reset –mixed (domyślny)
wszystkie nowsze commity będą usunięte z historii gita i znajdą się w katalogu roboczym
git reset –soft
nowsze commity trafią na stage i będziemy je mogli dodać do następnego commitu
git reset –hard
nowsze commity zostaną całkowicie utracone
Wybieram:
$ git reset –hard 654321e
working directory
katalog roboczy
lokalny folder, w którym pracujemy nad danym projektom i tworzymy swoje pliki projektu
stage (index)
przechowalnia
miejsce, do którego dodajemy zmiany w plikach za pomocą polecenia
$ git add
history
historia (często repozytorium zdalne)
miejsce, do którego trafiają pliki za pomocą polecenia
$ git commit
(każdą zmianę zatwierdzamy w historii)
git add
zmiany zostają wysłane z working dirtectory (katalog roboczy) do stage (index, przechowalnia)
zmiany te/pliki zmieniają wtedy status ze
zmodyfikowanego (modified) na śledzony (staged)
git commit
wysyła zmiany ze stage (index, przechowalnia) do historii repozytorium zdalnego
zmiany te/pliki zmieniaja wtedy status ze staged (śledzony, w przechowywalni) na zatwierdzony (commited)
git reset – files
modyfikuje historię repozytorium zdalnego
zmiany są usuwane z historii i wracajądo przechowalni (index, stage) - możemy je wysłać z następnym commitem
pliki zmieniają status z zatwierdzony na śledzony
git checkout –file
zmiany w danym pliku są cofane z przechowalni (stage, index) z powrotem do katalogu roboczego, w którym pracujemy (working directory)
pliki zmieniają status ze śledzony na zmodyfikowany
git init
inicjuje powstanie nowego repozytorium (powstaje plik .git)
git commit
dodaje zmiany/pliki do repozytorium (historii)
zmieniają one wtedy status ze śledzone (w przechowalni) na zatwierdzone (commited)
git commit -m “pozwala dodać kometarz/opis wysyłanego commita”
git log –author=”Jagoda”
lub
git log –oneline –author=”Jagoda”
wyszukuje w historii commity wysłane przez Jagodę
git log –grep=”view”
przeszukiwanie commitów po frazie
git log –oneline -3
określamy ile commitów z historii chcemy zobaczyć w formie skondensowanej
git log –oneline – index.html
wyszukiwanie commitów dot. konkretnych plików (ścieżek)
gdy znajdziemy w historii jakiś commit, który nas interesuje możemy w niego wejść wpisując
$ git checkout 654321e
ale można użyć też flagi patch
$ git log –oneline –patch – index.html
a jeszcze ciekawiej:
$ git log –oneline –summary – index.html
gdzie wyświetlona jest skrócona informacja o tym, co zostało zrobione z danym plikiem
lub
$ git log –oneline –stat – index.html
która wyświetla statystyki zmian konkretnych plików
git log –format =”%h %an %s (%cr)”
flaga format komendy git log pozwala na użycie dostępnych opcji formatowania opisanych w dokumentacji.
Np. tutaj chcemy otrzymać %h - skrócone hashe commitów
%an - imię autora
%s - komentarze
%cr - informację o tym kiedy commit został dodany w nawiasie
git shortlog
pokazuje historię zmian z podziałem na użytkowników
Jak powinien wyglądać elegancki opis commita?
Powinien mieć tytuł z dużej litery, bez kropki, w trybie rozkazującym. Potem
niezbyt długi opis (max 73 znaki, gdyż git nie łamie linii. Tytuł i opis powinny być oddzielone od siebie 1 pustym wierszem.
po wpisaniu :
$ git commit
bez flag, powinien nam się otworzyć domyślny edytor tekstu np. vi lub sublime text
