GIT to system kontroli wersji. Pozwala na łatwą współpracę z innymi nad kodem, śledzenie wersji i cofanie zmian.
W GIT mamy trzy warstwy na jakich pracujemy:
- working directory – jest to fizyczne miejsce na dysku na którym dokonujemy operacji – zmian w plikach, tworzenia nowych i usuwania
- staging area – po dokonaniu zmian w plikach, dodajemy je do staging area. Jest to pośrednia warstwa między dokonaniem zmian w plikach, a ich zatwierdzeniem. Możemy w niej przechowywać wiele zmian, zanim zatwierdzimy je i wyślemy do repezytorium
- local repository – jest to właściwe repezytorium przechowywane na komputerze. Po komendzie commit, zmiany przechowywane w staging area są fizycznie widoczne w repezytorium – pliki zostają zmienione.
Mamy jeszcze dodatkową warstwę jaką jest lokalne repezytorium czyli np. GitHub czyli miejsce na serwerze. Dodajemy zmiany do lokalnego repezytorium poleceniem push.
Konfiguracja użytkownika Git:
Po instalacji Git lub na nowym środowisku należy ustawić użytkownika, który wykonuje operacje. Bez tego nie będzie można robić commitów. Jeśli na jednym komputerze pracuje jeden użytkownik można ustawić globalnie:
git config --global user.name "Dawid Brejecki"
git config --global user.email "dawidbre@gmail.com"
Aby sprawdzić ustawienia:
git config --global --list
Natomiast jeżeli używamy różnych użytkowników, musimy najpierw przejść do ścieżki repezytorium nad jakim będziemy pracować i dopiero ustawić użytkownika
cd /sciezkarepozytorium
git config --local user.name "Dawid Brejecki"
git config --local user.email "dawidbre@gmail.com"
Klonowanie repezytorium z GitHub
Aby pobrać repezytorium z lokalizacji sieciowej Github na lokalny komputer należy użyć polecenia clone:
Praca z repezytorium
Załóżmy że zmodyfkowaliśmy plik PCA.py z naszego repezytorium. Aby sprawdzić status wszystkich plików z repozytorium (jakie pliki wysłaliśmy na stage a dla jakich zmian daliśmy commit używamy polecenia git status:
Widzimy że zmiany nie zostały nawet wysłane na stage. W tym celu używamy polecenia git add
Jak widać mamy zmiany dla których możemy dać commit:
Załóżmy że przez większość część czasu nie używaliśmy gita. W tym czasie git oczywiście śledził nasze lokalne repezytorium. Aby wszystkie zmiany od razu dodać do stage i dać commit używamy polecenia git add .
Aby przenieść nasze zmiany na zdalne repezytorium GitHub używamy komendy git push origin main. Main oznacza naszą gałąź. Zmiany zostaną zapisane w tym zdalnym repezytorium, które było przez nas sklonowane wcześniej.
Jak widać zmiany zostały zachowane:
Jak chcemy wypchnąć zmiany do innego istniejącego zdalnego repo:
Historia wersji
Aby zobaczyć historię commitów wpisujemy komendę git log:
Sprawdzanie konkretnego pliku:
Szczegółowe informacje wraz z informacjami o zmienionych wierszach kodu uzuskujemy z komendą git log –p
Sprawdzanie kto i kiedy edytował każdą linijkę w pliku – git blame nazwa_pliku
Cofanie się do poprzednich wersji
Generalnie służy do tego polecenie git reset. Liczba przy parametrze HEAD wskazuje o ile commitów chcemy się cofnąć.
Opcja –soft cofa zmiany do danego commita, ale nie usuwa zmian ze stage i fizycznych plików:
opcja — mixed usuwa także zmiany ze stage, a opcja –hard dodatkowo przywraca pliki do stanu z danego commita
Jak widzimy, opcja hard przywróciła stan plików z poprzednich commitów i nie jest widoczna już historia następnych commitów
Aby cofnąć się do wersji konkretnego pliku, używamy polecenia git checkout ze wskazaniem hasha commita do którego chcemy się cofnąć. Nasze cofnięcie dotyczy także fizycznej postaci pliku na dysku. Nie jest widoczne w historii.
Załóżmy że to co zrobiliśmy na lokalnym repo jest zupełnie bez sensu i chcemy twardo cofnąć się do zmian ze zdalnego repo. Do tego musimy pobrać zmiany komendą git fetch origin, przełączyć się na odpowiednią gałąź np. main (jeśli jesteśmy nieprzełączeni) poleceniem git checkout main i zastosować zmiany poleceniem git reset –hard origin/main
Używany przez nas git reset usuwa historię commitów. Polecenie gir revert jej nie usuwa tylko dodaje kolejny commit z cofnięciem zmian