Zanim zaczniesz

Git od zera, na Windowsie i na Macu

Git zapamiętuje kolejne wersje Twoich plików. Możesz wrócić do dowolnej z nich, pracować nad kilkoma pomysłami naraz i mieć ten sam projekt na kilku komputerach.

Kurs prowadzi od instalacji do swobodnej pracy z GitHubem na dwóch maszynach. Polecenia Gita są takie same w obu systemach. Różni się instalacja, logowanie do GitHuba, schowek i kilka ustawień. W tych miejscach kurs pokazuje wersję dla systemu wybranego w górnym pasku.

Jak korzystać

Wybierz system u góry. Wybór możesz zmienić w każdej chwili, np. gdy przesiadasz się na drugi komputer.
Wpisuj polecenia u siebie w terminalu równolegle z czytaniem. Bez tego niewiele zostaje w głowie.
Każda lekcja kończy się zadaniami. W zadaniu „Wpisz polecenie” piszesz komendę tak, jak w terminalu. Kurs ją sprawdza, ale niczego nie uruchamia.
Postęp zapisuje się tylko w tej przeglądarce.

Którego terminala używać

Na Windowsie instalator Gita dodaje program Git Bash. Używaj go w tym kursie: działają w nim te same polecenia co na Macu (ls, cat, touch, ścieżki z /). Git działa też w PowerShellu i w terminalu VS Code. Tam, gdzie PowerShell wymaga innej składni, jest to zaznaczone.

Na Macu otwórz program Terminal (Spotlight: ⌘ Spacja, wpisz „Terminal”). Domyślną powłoką jest zsh i wszystkie polecenia z kursu działają w niej bez zmian.

Co	Windows (Git Bash)	macOS (Terminal)
Folder domowy	`/c/Users/imie`	`/Users/imie`
Wklej do terminala	`Shift+Insert`	`⌘V`
Przerwij polecenie	`Ctrl+C`	`Ctrl+C`
Wyjdź z przeglądania logu	`q`	`q`

Lekcja 1

Instalacja

Najpierw sprawdź, czy Git już jest. Jeśli nie, instalacja zajmuje kilka minut.

git --version

Jeśli widzisz coś w rodzaju git version 2.4x.x, przejdź do następnej lekcji.

Windows

Najprościej przez winget, w PowerShellu lub Terminalu Windows:

winget install --id Git.Git -e --source winget

Druga droga to instalator ze strony git-scm.com. Zadaje dużo pytań. Wartości domyślne są dobre, zwróć uwagę tylko na trzy:

Default editor: wybierz edytor, który znasz, np. Visual Studio Code. Domyślny Vim bywa pułapką.
Initial branch name: zaznacz „Override” i wpisz main.
Credential helper: zostaw Git Credential Manager. Dzięki niemu logowanie do GitHuba odbywa się w oknie przeglądarki.

Po instalacji zamknij i otwórz terminal na nowo, inaczej polecenie git nie będzie widoczne.

macOS

Apple dostarcza Gita w pakiecie narzędzi programisty. To polecenie otwiera okno instalacji:

xcode-select --install

Jeśli używasz Homebrew, możesz zainstalować nowszą wersję i od razu narzędzie gh, które przyda się przy logowaniu do GitHuba:

brew install git gh

Po instalacji przez Homebrew otwórz nowe okno Terminala i sprawdź which git. Ścieżka /opt/homebrew/bin/git (lub /usr/local/bin/git na Macach z Intelem) oznacza wersję z Homebrew, /usr/bin/git wersję Apple. Obie nadają się do kursu.

Sprawdź, jaka wersja Gita jest zainstalowana.

Po instalacji terminal odpowiada, że nie zna polecenia git. Co zrobić najpierw?

Zainstalować Gita jeszcze raz
Zamknąć terminal i otworzyć go ponownie
Założyć konto na GitHubie

Lekcja 2

Konfiguracja

Git podpisuje każdy zapis Twoim imieniem i adresem e-mail. Ustawiasz to raz na każdym komputerze.

git config --global user.name "Jan Kowalski"
git config --global user.email "jan@example.com"
git config --global init.defaultBranch main

Podaj ten sam e-mail co na GitHubie, wtedy commity z obu komputerów będą przypisane do Twojego konta. Opcja --global zapisuje ustawienie dla wszystkich repozytoriów na tym komputerze, w pliku ~/.gitconfig.

Końce linii

Windows kończy wiersz znakami CRLF, Mac i Linux samym LF. Bez ustawienia Git potrafi pokazać cały plik jako zmieniony, choć nikt nie ruszył ani litery. Na każdym systemie ustaw inną wartość:

Windows

git config --global core.autocrlf true

macOS

git config --global core.autocrlf input

true: w repozytorium trafia LF, a w Twoim folderze pliki mają CRLF.

input: pliki zostają z LF, a przypadkowe CRLF Git zamieni przy zapisie do repozytorium.

W lekcji o dwóch komputerach dodasz jeszcze plik .gitattributes, który ustala to samo wewnątrz repozytorium, niezależnie od ustawień komputera.

Edytor

Git czasem otwiera edytor, np. gdy pominiesz opis commita. Najpierw sprawdź, którego użyje teraz:

git var GIT_EDITOR

To polecenie pokazuje edytor, który Git faktycznie uruchomi. Samo ustawienie z konfiguracji zobaczysz tak:

git config --get core.editor

Puste wyjście oznacza, że edytor nie jest ustawiony w konfiguracji. Git bierze go wtedy kolejno ze zmiennych środowiskowych GIT_EDITOR, VISUAL, EDITOR, a na końcu używa vi. Ustaw taki, z którego umiesz wyjść, np. Visual Studio Code:

git config --global core.editor "code --wait"

Opcja --wait jest konieczna: Git czeka dzięki niej, aż zamkniesz kartę z plikiem w VS Code, i dopiero wtedy kończy np. commit.

Polecenie code musi być dostępne w terminalu. Sprawdzisz to poleceniem code --version.

Jeśli terminal nie zna polecenia code, uruchom ponownie instalator VS Code, zaznacz „Dodaj do PATH” i otwórz terminal od nowa.

Jeśli terminal nie zna polecenia code, w VS Code otwórz paletę (⌘⇧P) i wybierz „Shell Command: Install 'code' command in PATH”.

Sprawdzenie

git config --global --list

Ustaw swoje imię i nazwisko dla wszystkich repozytoriów na tym komputerze.

Jaką wartość core.autocrlf ustawiasz na Windowsie, a jaką na Macu?

Windows: true, Mac: input
Windows: input, Mac: true
Na obu false

Lekcja 3

Pierwsze repozytorium

Repozytorium to zwykły folder, w którym Git prowadzi historię. Cała historia leży w ukrytym podfolderze .git.

mkdir strona
cd strona
git init

Trzy miejsca

Zmiana przechodzi przez trzy miejsca, zanim trafi do historii. Większość nieporozumień z Gitem bierze się z pomylenia dwóch pierwszych.

Folder roboczypliki, które edytujesz

git add
→

Poczekalniato, co wejdzie do najbliższego commita

git commit
→

Historiazapisane commity

Poczekalnia (ang. staging area) pozwala zapisać tylko część zmian. Poprawiłeś literówkę i jednocześnie zacząłeś nowy formularz? Dodajesz do poczekalni samą literówkę i zapisujesz ją osobno.

Pierwszy commit

echo "<h1>Witaj</h1>" > index.html
git status                  # index.html jest „untracked”
git add index.html          # do poczekalni
git status                  # „Changes to be committed”
git commit -m "Dodaj stronę główną"

git status jest bezpieczne i nic nie zmienia. Wpisuj je za każdym razem, gdy nie masz pewności, co się dzieje. Podpowiada też kolejne polecenia.

Dobry opis commita

Mówi, co commit robi: „Dodaj walidację formularza”, nie „zmiany” ani „poprawki 2”.
Jeden commit to jedna myśl. Lepiej trzy małe niż jeden na koniec dnia.
git add . dodaje wszystko z bieżącego folderu. Wygodne, ale przed commitem spójrz w git status, czy nie wpadło coś zbędnego.

Jesteś w nowym folderze projektu. Zrób z niego repozytorium.

Dodaj do poczekalni wszystkie zmienione i nowe pliki.

Zapisz zawartość poczekalni w historii, z opisem podanym od razu w poleceniu.

Robisz git add index.html, potem dopisujesz w pliku jeszcze jeden wiersz i robisz git commit. Co trafi do commita?

Plik z nowym wierszem
Nic, Git zgłosi błąd
Plik w wersji z chwili git add, bez nowego wiersza

Lekcja 4

Historia i różnice

Dwa pytania, które zadajesz Gitowi najczęściej: co już zapisałem i co zmieniłem od tamtej pory.

Historia

git log                         # pełne wpisy, wyjście klawiszem q
git log --oneline               # jeden wiersz na commit
git log --oneline --graph --all # z rysunkiem gałęzi
git show a1b2c3d                # co dokładnie zmienił ten commit

Każdy commit ma identyfikator, np. a1b2c3d. To początek długiego skrótu SHA. W poleceniach wystarcza pierwszych 7 znaków.

Różnice

Polecenie	Co porównuje
`git diff`	folder roboczy z poczekalnią: zmiany jeszcze niedodane
`git diff --staged`	poczekalnię z ostatnim commitem: to, co zaraz zapiszesz
`git diff main stopka`	dwie gałęzie

W wyniku wiersze z - zostały usunięte, a wiersze z + dodane. Zmieniony wiersz pojawia się jako para: stary z minusem, nowy z plusem.

Pusty wynik git diff po git add jest poprawny. Zmiany są już w poczekalni, więc pokaże je git diff --staged.

Pokaż historię w zwartej postaci, po jednym wierszu na commit.

Zrobiłeś git add. Sprawdź przed commitem, co dokładnie jest w poczekalni.

Lekcja 5

Plik .gitignore

Nie wszystko powinno trafić do repozytorium. Śmieci systemowe, hasła i pobrane biblioteki zostają poza nim.

Utwórz w głównym folderze repozytorium plik .gitignore. Każdy wiersz to wzorzec nazw, które Git ma pomijać:

.gitignore

# systemowe: wpisz oba, nawet jeśli dziś pracujesz na jednym systemie
.DS_Store
Thumbs.db
desktop.ini

# edytory
.vscode/
.idea/

# zależności i wyniki budowania
node_modules/
dist/

# dane prywatne
.env
*.log

Na Macu Finder tworzy plik .DS_Store w każdym otwartym folderze. Bez wpisu w .gitignore trafi do repozytorium przy pierwszym git add ..

Na Windowsie analogiczne są Thumbs.db i desktop.ini. Wpis .DS_Store też zostaw: przyda się, gdy otworzysz projekt na Macu.

Globalna lista dla całego komputera

Pliki systemowe możesz wykluczyć raz, dla wszystkich repozytoriów:

Windows (Git Bash)

printf "Thumbs.db\ndesktop.ini\n" >> ~/.gitignore_global
git config --global core.excludesFile ~/.gitignore_global

macOS

echo ".DS_Store" >> ~/.gitignore_global
git config --global core.excludesFile ~/.gitignore_global

Plik już jest w repozytorium

.gitignore działa tylko na pliki, których Git jeszcze nie śledzi. Jeśli plik został wcześniej zapisany w commicie, trzeba go wyjąć ze śledzenia. Na dysku zostaje:

git rm --cached .env
git commit -m "Przestań śledzić .env"

Hasło w historii zostaje w historii. git rm --cached usuwa plik z kolejnych commitów, ale stare nadal go zawierają. Hasło lub klucz, który trafił na GitHuba, trzeba zmienić.

Plik config.local.php trafił kiedyś do repozytorium. Dopisałeś go do .gitignore, ale Git dalej pokazuje jego zmiany. Wyjmij go ze śledzenia, nie kasując z dysku.

Co pomija wiersz node_modules/?

Tylko plik o nazwie node_modules
Każdy folder node_modules wraz z zawartością
Wszystkie pliki z rozszerzeniem .modules

Lekcja 6

Gałęzie

Gałąź to osobna linia pracy. Zaczynasz na niej coś nowego, a main przez ten czas zostaje w działającym stanie.

Praca na gałęzi

git switch -c stopka        # utwórz gałąź i przejdź na nią
# ...edytujesz, git add, git commit, ile razy trzeba...
git switch main             # wróć na main
git merge stopka            # dołącz zmiany ze stopki
git branch -d stopka        # gałąź zrobiła swoje

Polecenie	Działanie
`git branch`	lista gałęzi, bieżąca ma gwiazdkę
`git switch nazwa`	przejście na istniejącą gałąź
`git switch -c nazwa`	nowa gałąź i przejście na nią
`git switch -`	powrót na poprzednią gałąź
`git branch -d nazwa`	usunięcie scalonej gałęzi

W starszych poradnikach zobaczysz git checkout nazwa i git checkout -b nazwa. Robią to samo. switch jest nowszy i służy tylko do gałęzi, więc trudniej nim coś zepsuć.

Dwa rodzaje scalenia

Fast-forward: na main nic się nie zmieniło od odejścia gałęzi. Git przesuwa main do przodu i nie tworzy dodatkowego commita.
Commit scalający: obie gałęzie mają nowe commity. Git łączy je i zapisuje commit z dwoma rodzicami, jak na rysunku.

Przed zmianą gałęzi zrób commit albo odłóż zmiany poleceniem git stash (lekcja 9). Niezapisane zmiany przechodzą na drugą gałąź razem z Tobą albo blokują przejście.

Utwórz gałąź stopka i od razu na nią przejdź.

Stoisz na main. Dołącz do niej pracę z gałęzi stopka.

Chcesz, żeby zmiany ze stopka znalazły się na main. Na której gałęzi musisz stać, wpisując git merge?

Na main
Na stopka
Nie ma znaczenia

Lekcja 7

Konflikty

Konflikt powstaje, gdy dwie gałęzie zmieniły ten sam fragment tego samego pliku. Git nie zgaduje, która wersja jest właściwa, tylko pyta Ciebie.

Po nieudanym git merge (albo git pull) plik wygląda tak:

index.html

<<<<<<< HEAD
<h1>Sklep rowerowy</h1>
=======
<h1>Serwis i sklep rowerowy</h1>
>>>>>>> stopka

Od <<<<<<< HEAD do =======: wersja z gałęzi, na której stoisz.
Od ======= do >>>>>>>: wersja z gałęzi, którą dołączasz.

Rozwiązanie krok po kroku

git status pokaże pliki oznaczone „both modified”.
Otwórz każdy z nich. Zostaw to, co ma być w pliku: jedną wersję, drugą albo połączenie obu. Usuń trzy wiersze ze znacznikami.
git add index.html oznacza konflikt jako rozwiązany.
git commit kończy scalenie. Git sam proponuje opis.

VS Code pokazuje nad konfliktem przyciski „Accept Current Change”, „Accept Incoming Change” i „Accept Both Changes”. Robią dokładnie to, co ręczna edycja.

git merge --abort           # wycofaj się, stan jak przed scaleniem

Jak mieć mniej konfliktów: pobieraj zmiany przed rozpoczęciem pracy, rób małe commity i nie trzymaj gałęzi tygodniami bez scalania.

Scalenie skończyło się konfliktami w pięciu plikach, a Ty nie masz teraz na to czasu. Wróć do stanu sprzed scalenia.

Poprawiłeś plik i usunąłeś znaczniki konfliktu. Co teraz?

Od razu git commit
Jeszcze raz git merge stopka
git add tego pliku, potem git commit

Lekcja 8

GitHub i zdalne repozytoria

Do tej pory wszystko działo się na Twoim dysku. Zdalne repozytorium to kopia na serwerze: zapas na wypadek awarii i miejsce, przez które wymieniasz się zmianami z drugim komputerem.

Twój komputerfolder roboczy i lokalna historia

git push →
← git pull

GitHub (origin)zdalna kopia historii

Logowanie

GitHub nie przyjmuje hasła do konta w terminalu. Są dwie drogi: HTTPS z logowaniem przez przeglądarkę albo klucz SSH. Na początek wygodniejszy jest HTTPS.

Windows, HTTPS: nic nie konfigurujesz. Przy pierwszym git push lub git clone prywatnego repozytorium Git Credential Manager otworzy okno logowania do GitHuba i zapamięta dostęp w Menedżerze poświadczeń Windows.

macOS, HTTPS: najprościej przez narzędzie gh. Wybierz kolejno GitHub.com, HTTPS i logowanie przez przeglądarkę:

brew install gh
gh auth login

Dostęp trafia do Pęku kluczy i Git korzysta z niego sam.

Klucz SSH (druga droga)

Klucz generujesz osobno na każdym komputerze. Każdy komputer ma własny, a na GitHubie dodajesz oba.

ssh-keygen -t ed25519 -C "jan@example.com"

Zatwierdź domyślną lokalizację Enterem. Potem skopiuj publiczną część klucza (plik z końcówką .pub):

Windows (Git Bash)

clip < ~/.ssh/id_ed25519.pub

W PowerShellu: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub | Set-Clipboard

macOS

pbcopy < ~/.ssh/id_ed25519.pub
ssh-add --apple-use-keychain ~/.ssh/id_ed25519   # hasło klucza do Pęku kluczy

Na GitHubie wejdź w Settings → SSH and GPG keys → New SSH key, wklej klucz i nazwij go od komputera, np. „Laptop Windows”. Sprawdzenie:

ssh -T git@github.com       # „Hi login! You've successfully authenticated”

Pliku bez .pub nikomu nie pokazuj. To klucz prywatny. Na GitHuba trafia wyłącznie zawartość pliku id_ed25519.pub.

Wysłanie istniejącego repozytorium

Na GitHubie utwórz puste repozytorium (bez README i bez .gitignore). Potem w swoim folderze:

git remote add origin https://github.com/login/strona.git
git push -u origin main

origin to umowna nazwa zdalnego repozytorium. -u łączy lokalną gałąź main ze zdalną, więc następnym razem wystarczy samo git push i git pull. Przy SSH adres ma postać git@github.com:login/strona.git.

Pobranie repozytorium na drugi komputer

git clone https://github.com/login/strona.git
cd strona

clone tworzy folder, pobiera całą historię i sam ustawia origin.

Codzienna wymiana

Polecenie	Działanie
`git push`	wysyła Twoje nowe commity na serwer
`git fetch`	pobiera nowości z serwera, ale nie zmienia Twoich plików
`git pull`	`fetch` i od razu scalenie z Twoją gałęzią
`git remote -v`	pokazuje adresy zdalnych repozytoriów

Dodałeś origin. Wyślij gałąź main pierwszy raz tak, żeby później wystarczało samo git push.

Pobierz na ten komputer repozytorium strona użytkownika jan z GitHuba.

Czym różni się git fetch od git pull?

Niczym, to dwie nazwy tego samego
fetch tylko pobiera, pull pobiera i scala z Twoją gałęzią
fetch wysyła zmiany, pull je pobiera

Lekcja 9

Jedno repozytorium, Windows i Mac

Praca na dwóch systemach wymaga jednego nawyku i trzech ustawień. Nawyk jest ważniejszy.

Rytm pracy

Siadasz do komputera: git pull.
Pracujesz i robisz commity.
Wstajesz od komputera: git push.

Jeśli zapomnisz o push na jednym komputerze i zrobisz commity na drugim, historie się rozejdą. Nic nie ginie, a git pull je scali, czasem z konfliktem. Czystszą historię daje:

git pull --rebase           # Twoje lokalne commity lądują po tych z serwera

Niedokończona praca: stash

git pull odmówi, gdy masz niezapisane zmiany w plikach, które przyszły z serwera. Odłóż je na bok, pobierz nowości i przywróć:

git stash                   # schowaj niezapisane zmiany
git pull
git stash pop               # przywróć je

Stash zostaje na tym jednym komputerze. Żeby przenieść niedokończoną pracę na drugi, zrób commit na osobnej gałęzi i wypchnij ją.

Ustawienie 1: końce linii w repozytorium

Dodaj do głównego folderu plik .gitattributes. Działa na każdym komputerze, także tam, gdzie ktoś pominął core.autocrlf:

.gitattributes

* text=auto eol=lf
*.png binary
*.jpg binary
*.pdf binary
*.bat text eol=crlf
*.ps1 text eol=crlf

Pierwszy wiersz każe trzymać pliki tekstowe z LF, w repozytorium i na dysku. Współczesne edytory na Windowsie radzą sobie z tym bez problemu. Skrypty .bat i .ps1 zostają przy CRLF. Jeśli dodajesz ten plik do istniejącego projektu, wyrównaj stare pliki jednym commitem:

git add --renormalize .
git commit -m "Ujednolić końce linii"

Ustawienie 2: wielkość liter w nazwach

Dyski Windowsa i Maca domyślnie nie rozróżniają Logo.png od logo.png. Serwer z Linuksem rozróżnia, więc strona działająca u Ciebie może po wgraniu zgubić obrazek. Zmiana samej wielkości liter w Eksploratorze lub Finderze bywa dla Gita niewidoczna. Rób ją przez Gita:

git mv Logo.png logo.png

Najprostsza zasada: nazwy plików małymi literami, bez spacji i polskich znaków.

Ustawienie 3: pliki wykonywalne

Mac zapisuje, czy plik wolno uruchomić. Windows nie ma takiej informacji. Jeśli w repozytorium jest skrypt powłoki, ustaw to przez Gita. Działa na obu systemach:

git update-index --chmod=+x buduj.sh

Jeśli git status na Macu pokazuje pliki jako zmienione, a git diff wypisuje tylko „old mode / new mode”, to właśnie ta różnica.

Git na Windowsie pomija te uprawnienia (core.fileMode false), więc u Ciebie problem się nie pojawi. Zobaczysz go dopiero na Macu.

Objaw	Przyczyna	Rozwiązanie
Cały plik oznaczony jako zmieniony	końce linii	`.gitattributes` i `--renormalize`
W repozytorium jest `.DS_Store`	Finder	`.gitignore`, potem `git rm --cached`
Obrazek działa lokalnie, na serwerze nie	wielkość liter	`git mv`
`push` odrzucony („rejected”)	na serwerze są nowsze commity	`git pull --rebase`, potem `git push`

Masz niedokończone zmiany, a musisz zrobić git pull. Odłóż zmiany na bok.

git push został odrzucony, bo drugi komputer wysłał wcześniej swoje commity. Pobierz je tak, żeby Twoje commity znalazły się po nich, bez commita scalającego.

Dlaczego .gitattributes jest pewniejszy niż samo core.autocrlf?

Bo działa szybciej
Bo zmienia końce linii także w plikach binarnych
Bo podróżuje razem z repozytorium i nie zależy od ustawień komputera

Lekcja 10

Cofanie zmian

Właściwe polecenie zależy od tego, dokąd zmiana już dotarła: do pliku, do poczekalni, do commita czy na serwer.

Sytuacja	Polecenie
Zepsułem plik, chcę wersję z ostatniego commita	`git restore index.html`
Dodałem plik do poczekalni przez pomyłkę	`git restore --staged index.html`
Literówka w opisie ostatniego commita	`git commit --amend -m "Nowy opis"`
Zapomniałem pliku w ostatnim commicie	`git add plik`, potem `git commit --amend --no-edit`
Ostatni commit był przedwczesny, zmiany chcę zachować	`git reset --soft HEAD~1`
Commit jest już na serwerze i trzeba go odwrócić	`git revert a1b2c3d`

revert czy reset

git revert dodaje nowy commit, który odwraca zmiany wskazanego. Historia zostaje nietknięta, więc jest bezpieczny dla commitów już wypchniętych.
git reset przesuwa gałąź wstecz, czyli usuwa commity z historii. Używaj tylko dla commitów, których jeszcze nie wysłałeś.

Dwa polecenia kasują pracę bez pytania: git restore plik nadpisuje niezapisane zmiany w pliku, a git reset --hard kasuje wszystkie niezapisane zmiany w repozytorium. Zmian, których nie było w żadnym commicie, Git nie odzyska.

Koło ratunkowe: reflog

Git przez kilka tygodni pamięta każde położenie, w którym była Twoja gałąź, także po reset. Commit, który „zniknął”, zwykle da się odnaleźć:

git reflog                  # lista ostatnich położeń z identyfikatorami
git switch -c ratunek a1b2c3d   # nowa gałąź w odnalezionym miejscu

Reflog jest lokalny. Na drugim komputerze go nie ma.

Plik index.html trafił do poczekalni za wcześnie. Wyjmij go stamtąd, zostawiając zmiany w pliku.

Commit a1b2c3d jest na GitHubie i psuje stronę. Odwróć jego zmiany bezpiecznie.

Kiedy git commit --amend jest złym pomysłem?

Gdy commit został już wypchnięty na serwer
Gdy commit ma mniej niż godzinę
Gdy zmieniasz tylko opis

Pod ręką

Ściąga

Wszystkie polecenia z kursu w jednym miejscu.

Codziennie

`git status`	co się zmieniło i co jest w poczekalni
`git add plik` / `git add .`	do poczekalni
`git commit -m "Opis"`	zapis do historii
`git pull`	pobierz i scal zmiany z serwera
`git push`	wyślij commity na serwer
`git log --oneline --graph --all`	historia z gałęziami
`git diff` / `git diff --staged`	zmiany niedodane / dodane

Gałęzie

`git switch -c nazwa`	nowa gałąź
`git switch nazwa`	przejście na gałąź
`git merge nazwa`	dołącz gałąź do bieżącej
`git merge --abort`	przerwij scalanie z konfliktem
`git branch -d nazwa`	usuń scaloną gałąź
`git push -u origin nazwa`	wyślij gałąź na serwer pierwszy raz

Cofanie

`git restore plik`	odrzuć niezapisane zmiany w pliku
`git restore --staged plik`	wyjmij z poczekalni
`git commit --amend`	popraw ostatni, niewysłany commit
`git revert id`	odwróć commit nowym commitem
`git reset --soft HEAD~1`	cofnij ostatni commit, zachowaj zmiany
`git stash` / `git stash pop`	odłóż zmiany / przywróć
`git reflog`	historia położeń gałęzi

Różnice między systemami

Co	Windows	macOS
Instalacja	`winget install --id Git.Git -e`	`xcode-select --install`
Terminal	Git Bash	Terminal (zsh)
`core.autocrlf`	`true`	`input`
Logowanie HTTPS	Git Credential Manager	`gh auth login`
Klucz do schowka	`clip < ~/.ssh/id_ed25519.pub`	`pbcopy < ~/.ssh/id_ed25519.pub`
Pliki do ignorowania	`Thumbs.db`, `desktop.ini`	`.DS_Store`
Plik ustawień	`C:\Users\imie\.gitconfig`	`/Users/imie/.gitconfig`

Git od zera, na Windowsie i na Macu

Jak korzystać

Którego terminala używać

Instalacja

Windows

macOS

Konfiguracja

Końce linii

Edytor

Sprawdzenie

Pierwsze repozytorium

Trzy miejsca

Pierwszy commit

Dobry opis commita

Historia i różnice

Historia

Różnice

Plik .gitignore

Globalna lista dla całego komputera

Plik już jest w repozytorium

Gałęzie

Praca na gałęzi

Dwa rodzaje scalenia

Konflikty

Rozwiązanie krok po kroku

GitHub i zdalne repozytoria

Logowanie

Klucz SSH (druga droga)

Wysłanie istniejącego repozytorium

Pobranie repozytorium na drugi komputer

Codzienna wymiana

Jedno repozytorium, Windows i Mac

Rytm pracy

Niedokończona praca: stash

Ustawienie 1: końce linii w repozytorium

Ustawienie 2: wielkość liter w nazwach

Ustawienie 3: pliki wykonywalne

Cofanie zmian

revert czy reset

Koło ratunkowe: reflog

Projekt końcowy

Ściąga

Codziennie

Gałęzie

Cofanie

Różnice między systemami