GIT

System kontroli wersji:

▪ Oparty o zmiany
▪ Mocne skupienie na możliwości tworzenia podwersji (branchy)
▪ Niezależny, zdecentralizowany

Repozytorium:

Główny folder w którym trzymamy pliki związane z projektem oraz zmianami gita.
▪ Wszystkie informacje związane z gitem są w ukrytym folderze .git
▪ Repozytorium może być lokalne (na Twoim komputerze) lub zdalne
(na Github, Gitlab, Bitbucket).
TWORZENIE REPOZYTORIUM

W folderze z plikami:
git init - stwórz repozytorium
git status - sprawdź obecny stan repozytorium

Zmiany robocze (working directory)

Zmiany do zatwierdzenia (Staging Area)
Zmiany zatwierdzone/utrwalone git directory (repozytorium)

git add * (lub ścieżka) - dodanie zmian w plikach do stagingu

git commit -m “<TYTUŁ COMMITA>”
git diff - do jakich zmian doszło. Bardzo potężne narzędzie, możemy sprawdzać czym się
różnią poszczególne wersje!
REVERT - wycofanie’ commit’a poprzez stworzenie nowego
▪ nowy commit usuwa zmiany

▪ bezpieczne rozwiązanie (nie zepsujemy historii)

Git revert <hash commita> - cofanie commita
REPOZYTORIUM ZDALNE:
▪ zewnętrzne repozytorium, z którym chcemy
synchronizować/wymieniać się z naszym lokalnym repozytorium

▪ umieszczone na zewnętrznym serwerze

▪ lokalne repozytorium musi znać adres zdalnego (origin)
Stwórz repozytorium na githubie. Po stworzeniu nowego repozytorium zastosuj się do
instrukcji:
git remote add origin <adres-repozytorium>
git branch -M main

git push -u origin main

Praca na zdalnym repo:
git fetch – ściągnięcie informacji o stanie zdalnego repozytorium
git pull – j.w. + merge wybranego brancha zdalnego do lokalnego
git push – wypchnięcie obecnego brancha do ustawionego jako upstream

Commity określają kolejne utrwalone zmiany w repozytorium.

Commit składa się z
▪ hasha - checksum + timestamp
▪ autora - kto dokonał zmian
▪ daty
▪ tytułu
▪ zmian
DOBRY COMMIT:
jeden commit powinien odpowiadać jednej zmianie
▪ treść wiadomości powinna informować jakie zmiany commit zawiera
▪ wiadomość powinna być jednoznaczna
▪ .. ale jednocześnie nie za długa

git log - pokazuje jakie były wcześniejsze commity

git diff - pokazuje obecne, niezakomitowane zmiany
git diff <hash commita> - pokazuje jakie zmiany zaszły od commita
git checkout <hash commita> - zerkamy jak wyglądało repozytorium gdy
wszedł dany commit!

HEAD – wskaźnik
W ramach repozytorium możemy wrócić do dowolnego momentu w
czasie (do każdego commita)
▪ Wskazywać możemy też na różne odgałęzienia (branche)

Przekieruj wskaźnik na wcześniejszego commita

▪ Git log - historia commitów (wychodzi się przyciskając “q”)
▪ Git checkout <hash commita>
▪ Git status
Wróć do najnowszego commita:
▪ Git checkout master

BRANCH
wskaźnik na commit (!)
▪ pozwala na rozgałęzienie projektu
▪ można go zawsze dodać/usunąć/zmienić
▪ master - pierwszy i domyślny branch

master - wersja produkcyjna dla klientów

develop - wersja, gdzie pracują developerzy i testują testerzy
feature-branch-1

git branch <nazwa-brancha> - tworzenie brancha

git branch - listowanie branchy
git checkout <nazwa-brancha> - przechodzenie na branch
git checkout -b <nazwa-brancha> - stworzenie i przejście na branch

MERGE – łączenie zmian

Aby połączyć zmiany musimy przejść na branch, do którego będziemy je łączyć!

Git checkout <branch>
Git merge <branch>

KONFLIKTY
• Merdżuj często - małe zmiany
▪ Przed merdżowaniem zmerdżuj zmiany do swojego roboczego
brancha
▪ branch-roboczy merge master
▪ Master merge branch-roboczy

FORK - Skopiowanie czyjegoś repozytorium do swojego konta

KLONOWANIE - Ściągnięcie dostępnego repozytorium i ustawienie zdalnego origin

git clone <url>

AMEND - ‘nadpisanie’ ostatniego commit’a

▪ zmienia historię
▪ Stosuj tylko względem niewysłanych commitów
▪ Typowy use case - niedodanie pliku do commita, niepoprawna nazwa
commita
Git commit –amend

RESET - wycofanie lokalnych zmian z poczekalni

▪ soft - nie zmienia ‘working directory’ ani poczekalni
▪ mixed - domyślna opcja, usuwa zmiany z poczekalni
▪ hard - usuwa zmiany z ‘working directory’ oraz poczekalni
▪ ‘usuwanie’ commit’ów z historii danej gałęzi
▪ zmiana historii commit’ów i próba wrzucenia zmian do zewnętrznego
repozytorium zakończy się błędem
Przydatne gdy macie lokalnie, zacomitowane zmiany, ale nie chcecie ich
wypchnąć do repozytorium zdalnego.

Czym jest github?

-Systemem kontroli wersji
-Miejscem współdzielenia kodu
-Systemem śledzenia zmian w kodzie
-Systemem służącym łączeniu zmian dokonanych na wielu plikach p_ze różne osoby

Komenda: git init my-app:

A utworzy katalog ./my-app/.git
B inicjalizuje lokalne repozytorium Gita w katalogu ./my-app
C jest niepoprawna, bo git init może być tylko i wyłącznie wywołane w pustym katalogu i to
właśnie w nim tworzy repozytorium
D łączy lokalny katalog ze zdalnym repozytorium na GitHubie, nazwanym my-app

Do synchronizacji zmian pomiędzy repozytorium lokalnym a zdalnym służą komendy:

A git pull
B git push
C git origin
D git fetch
Pull request to:
A Włączenie zmian do głównego brancha
B Konflikt wynikający z edycji tej samej części kodu p zez wiele osób
C Poinformowaniem innych członków zespołu o zamianach ze włączenia zmian do
określonego
brancha. Daje nam przestrzeń na przejrzenie zmian i dyskusję nad kodem
D Komenda do synchronizacji zmian z repozytorium zdalnym