GIT – Podstawy
Opis
Git to VCS (version control system). Jest on rozproszony systemem wersjonowania kodu. Czyli mamy zapisane wszystkie wcześniejsze wersje kodu. Możemy w łatwy sposób do nich wrócić aby porównać działanie obecnego kodu z wcześniejszym.
Inne systemy kontroli wersji
Git to nie jedyny VCS. Jest ich bardzo dużo i działają one na różne sposoby.
VCS można podzielić 3 rodzaje działania
- Lokalny system kontroli wersji
- Scentralizowany system kontroli wersji
- Rozproszony system kontroli wersji
Lokalny system kontroli wersji
Jest to najprostszy system który zapisuje zmiany danego pliku na naszym komputerze. Najbardziej popularny to RCS.
Scentralizowany system kontroli wersji
Czyli w skrócie mówiąc każdy commit trafia do centralnego serwera gdzie jest przechowywana historia zmian.
Zalety:
- Łatwiejsza kontrola nad projektem
- Każdy wie co kto robi
Wady:
- Gdy serwer centralny uszkodzi się wszystkie dane zostają utracone
- Gdy programista nie ma Internetu nic nie skomituje
- Brak możliwości zapisu testowego kodu na boku
Najczęściej używane programy: SVN (Subversion), Perforce
W katalogu .git
- Hooks – Znajdują się tam skrypty które są uruchamiane w różnych komendach. Jest tam np.: skrypt który się uruchamia przed komendą push który sprawdza czy jest ustawiony odpowiedni adres URL aby można było wysłać zmiany.
- Info – W tym folderze znajduje się plik exclude który działa na takiej samej postacie jak .gitignore.
- Logs – W tym folderze się informację o wszystkich comitach oraz oraz o tagach.
- Objects – Tutaj jest serce GIT-a. Znajdziemy tutaj wszystkie obiekty jakie są przechowywane przez Gita.
- Refs – Znajdują się tutaj wskaźniki do tagów i branchów.
- COMMIT_EDITMSG – Jest to plik tymczasowy gdzie znajduje się ostatnia nazwa commitu.
- Config – Zawiera on ustawienia dla danego repozytorium. Są tam takie dane jak adres URL do zdalnego repozytorium, nazwa użytkownika gita i jeszcze inne ustawienia.
- Description – Opis danego repozytorium
- FETCH-HEAD – Jest to plik tymczasowy który jest tworzony podczas polecenia git fetch. Znajduje się tam informacje o ostatnich comitach. I przez to GIT może sprawdzić czy są jakieś zmiany.
- HEAD – Opisuje na jakim branch-u jesteśmy lub na jakim commicie.
- Index – Znajdują się tutaj informację o tym jakie rzeczy przechowuje index(stan pomiędzy workspace a comitem. Jest to stan gdy damy git add {nazwa pliku}
Gitignore
Plik .gitignore – plik w którym wykluczamy pliki
Branch
Są to osobne klon projektu które pomagają nam w tworzeniu kodu. Najlepiej do każdej zmiany tworzyć osobny branch. Kiedy skończymy zmiany dopiero wtedy je z marge do głównego branchu.
Marge
Jest to łączenie połączenie zawartości 2 branchów w jeden. Występują dwa sposoby margu:
- Fast-Forward – Działa tak samo jak commit. Jest po prostu zapisywany dalsza historia komitów. Występuje on wtedy gdy pomiędzy utworzeniem 2 branchu a margem nie było żadnych innych komitów. Nie trzeba tworzyć nowego komita. Jest przenoszony tylko na wskaźnik ostatni komit brancha którego margujemy.
- 3-way-merge – jest tworzony nowy commit podczas merge. Występuje on wtedy gdy pomiędzy utworzeniem 2 branchu a margem jest jakiś inny komitów.
Stash
Mniej więcej to schowek w którym możemy tymczasowo przetrzymywać zmienione pliki i potem je przywrócić. Jest on tylko w wersji lokalnej. On bazuje na wewnętrznych komitach
Detached HEAD
Jest to tak naprawdę stan kiedy przeniesiemy się w historii komitów i coś tam zrobimy. Jest to tak naprawdę branch bez nazwy. Aby zapisać zmiany gdy mamy detached HEAD najlepiej zrobić wtedy nowy branch gdzie damy te zmiany.
Revert
Przywracanie zmian dla danego komita. Tworzy się dodatkowy komit który pokazuje że wracamy do danego komitu.
Reset/Delete
Za pomocą tego polecenia możemy wrócić kod do danego komitu ale usuwamy wcześniejsze komity.
Mamy 3 rodzeje resetu:
- Domyślny -mixed – zostaną usunięte z gita ale trafią do wersji roboczej do IDE
- —soft – od razu pliki trafiają do staged
- —hard – pliki/zmiany są usuwane
Zmiana nazwy commitu
Zmiana nazwy komitu powinna być tylko wtedy gdy mamy zmiany lokalnie lub kiedy wiemy ze nikt nie używa naszych zmian na zewnętrznym repozytorium. Do zmiany komita możemy użyć dwóch polecań:
- git commit —amend -m “nazwa komitu” – Zmienia nam nazwę ostatnich komiut i możemy również zmienić jego zawartość np. dodaj jakiś plik
- git rebase -i HEAD~{ilość komitów wstecz które chcemy zmodyfikować} – Możemy zmodyfikować kilka ostatnich komitów. Po tym poleceniu odpala nam się edytor i wybieramy które komity chcemy zmodyfikować przez podmianę przed nimi z pick na reword lub skróceniu “r”
GitHub Fork i Pull Request
Wykorzystywań gównie w open source aby naprawić jakie issue. Pobieramy przez forka na własne repozytorium kopie repozytorium
Dobre nazywanie commit
Chodzi głównie o to aby wiedzieć co było robione w kodzie. Dobre praktyki:
- Podzielenie commitu na tytuł i opis. Tytuł krótki a w opisie dodać więcej szczegółów. Możemy użyć komendy git commit -m”{subject}” -m”{description}”
- Max ilość tytułu do 72 znaków
- Pisanie w trybie rozkazującym
Git Log
Za pomocą tego polecenia mamy cała historię comitów.
Git Rebase
Działa podobnie jak marge tylko tutaj zamiast łączyć dwie gałęzie przepisuje je do gałęzi której łączymy. Nie powinno się je robić na komitach które są już są na remote gdyż rebase modyfikuje istniejące komity.
Powinno się go robić tak że do własnego brancha lokalnego robimy rebase gałęzi głównej aby wyrówna komity i potem jak wszystko mamy to wtedy robimy marge do gałęzi głównej. Wtedy nasze komity są przepisywane a komity z brancha są dociągane.
Dzięki temu mamy liniowość komitów.
Gdy mamy konflikt rozwiązujemy po każdym komit.
Git Squash
Łączenie komitów w jeden za pomocą rebase -i {ilość komitów wstecz}/{do id komitu wstecz}. Wtedy pojawia nam się notatnik w którym zanazczamy które komity chcemy złączyć. Do tego celu zmieniamy “pick” na “s” i zamykamy notatnik. Wtedy pojawi się ponownie notatnik gdzie podajemy nazwę komitu.
Możemy tez użyć squasha podczas merge ale wtedy nie modyfikujemy komitów na branchu tylko jakby je kopiujemy do docelowego brancha. Gdy wykonamy takie polecenie nie mamy od razu komita tylko zmiany trafiają do stage index. Przez co możemy je jeszcze zmodyfikować i dopiero wtedy zkomitować. Wada tego rozwiązania jest to że w drzewku gita nie mamy żadnej informacji że ten komit jest z danej gałęzi.
Git Cherry-pick
Przenoszenie konkretnych komitów z innego brancha. Za pomocą polecenia git cherry-pick {id komitu}. Lub kiedy nie chcemy automatycznie komita dajemy git cherry-pick -n {id komitu}
Git reflog
Za poleceniem git reflog widzimy wszystkie logi/zmiany w naszym repozytorium. Dzięki czemu widzimy tam tazie zeczy jak usunięte komity, zmienione nazwy komitów itp. Te zmienny widzimy tylko nasze lokalne, zmiany z remota (usunięte komity itp.) nie są widziane za pomocą tego polecenia.
Tagi w Git
Tagi w git są to dodatkowe informację do danego komita. Za pomocą tagów możemy oznaczyć że ten comitt dana wersja projektu lub jakaś kluczowa funkcjonalność. Aby się wyróżniła z reszty komitów.
