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. Lekcje 11 i 12 pokazują Gita w Visual Studio Code i na egzaminie INF.04.

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

Lekcja 11

Git i GitHub w VS Code

Visual Studio Code ma wbudowany panel Gita. Pod spodem działa ten sam Git co w terminalu, więc oba sposoby możesz mieszać: commit zrobiony w panelu od razu widać w git log, a polecenie wpisane w terminalu od razu zmienia panel.

VS Code nie instaluje Gita. Jeśli w terminalu nie działa git --version, wróć do lekcji 1. Nazwy przycisków w tej lekcji pochodzą z angielskiej wersji VS Code. W polskiej wersji przyciski są w tych samych miejscach, tylko z przetłumaczonymi podpisami.

Panel Source Control

Otwórz folder projektu (File → Open Folder). Panel Gita otwiera ikona rozgałęzienia na pasku po lewej albo skrót z tabeli.

Co	Windows	macOS
Panel Source Control	`Ctrl+Shift+G`	`⌃⇧G`
Commit z pola opisu	`Ctrl+Enter`	`⌘Enter`
Terminal w VS Code	Ctrl+`	⌃`
Paleta poleceń	`Ctrl+Shift+P`	`⌘⇧P`

Jeśli folder nie jest jeszcze repozytorium, panel pokazuje przycisk Initialize Repository. Działa jak git init.

Commit bez terminala

Changeszmienione pliki

plus przy pliku
→

Staged Changespoczekalnia

Commit
→

Historiazapisany commit

Na liście Changes są zmienione pliki. Litera obok nazwy mówi, co się stało: M plik zmieniony, U nowy i jeszcze nieśledzony, D usunięty.
Kliknięcie pliku otwiera porównanie: po lewej wersja z ostatniego commita, po prawej obecna. To ten sam wynik co git diff.
Plus przy pliku przenosi go do Staged Changes, czyli do poczekalni, jak git add. Minus wyjmuje go z powrotem.
Wpisz opis w polu nad listą i kliknij Commit albo naciśnij Ctrl+Enter⌘Enter.

Gdy poczekalnia jest pusta, VS Code zapyta, czy zapisać od razu wszystkie zmiany. To wygodne, ale do commita trafiają wtedy także pliki, których nie oglądałeś.

W edytorze, obok numerów wierszy, widać kolorowe paski: zielony to nowe wiersze, niebieski zmienione, a czerwony trójkąt miejsce, z którego wiersze usunięto. Kliknięcie paska pokazuje, co było wcześniej.

Ostrożnie z zakręconą strzałką przy pliku (Discard Changes). Wyrzuca niezapisane zmiany w pliku, tak jak git restore. VS Code pyta o potwierdzenie, ale po zgodzie zmian już nie odzyskasz.

Pliku, którego Git ma nie śledzić, nie musisz wpisywać ręcznie: kliknij go prawym przyciskiem na liście Changes i wybierz Add to .gitignore.

Historia i gałęzie

Na dole panelu Source Control jest wykres historii (Source Control Graph, w nowszych wersjach po prostu Graph). Pokazuje commity i gałęzie jak git log --oneline --graph. Historię jednego pliku pokazuje sekcja Timeline na dole panelu Explorer.

Nazwa bieżącej gałęzi jest w lewym dolnym rogu okna, na pasku stanu. Kliknięcie otwiera listę: wybierz gałąź, żeby się na nią przełączyć (git switch), albo Create new branch…, żeby utworzyć nową (git switch -c). Do scalenia otwórz paletę poleceń, wpisz „merge” i wybierz polecenie Gita do scalania gałęzi.

GitHub

Repozytorium bez zdalnej kopii ma w panelu przycisk Publish Branch. Folder, który nie jest jeszcze repozytorium, ma przycisk Publish to GitHub. VS Code zapyta o nazwę i o to, czy repozytorium ma być prywatne (private), czy publiczne (public). Potem utworzy je na GitHubie i wyśle gałąź, czyli zrobi za Ciebie git remote add origin i git push -u origin main.

Przy pierwszym połączeniu z GitHubem VS Code poprosi o zgodę na zalogowanie. Kliknij Allow, a przeglądarka otworzy stronę GitHuba z prośbą o potwierdzenie. Później VS Code wysyła i pobiera bez pytania, a konto widać pod ikoną konta w lewym dolnym rogu.

Pobranie repozytorium z GitHuba: paleta poleceń → Git: Clone → Clone from GitHub, potem wybierz repozytorium i folder. Na koniec VS Code zaproponuje otwarcie pobranego projektu.

Obok nazwy gałęzi na pasku stanu jest przycisk synchronizacji z liczbami, np. 1↓ 2↑: jeden commit do pobrania i dwa do wysłania. Kliknięcie robi git pull, a potem git push. Pojedyncze polecenia (Pull, Push, Fetch) są w menu … u góry panelu Source Control.

Konflikty

Pliki z konfliktem trafiają do osobnej grupy Merge Changes. Nad każdym miejscem konfliktu VS Code wyświetla odnośniki: Accept Current Change zostawia Twoją wersję, Accept Incoming Change wersję z drugiej gałęzi, a Accept Both Changes obie, jedna pod drugą. Przycisk Resolve in Merge Editor otwiera widok z obiema wersjami u góry i wynikiem na dole.

Po rozwiązaniu dodaj plik plusem do poczekalni i zrób commit. To te same kroki co git add i git commit z lekcji 7.

Któremu poleceniu odpowiada plus przy pliku w panelu Source Control?

git commit
git add
git push

Na pasku stanu przy gałęzi widać 1↓ 2↑. Co zrobi kliknięcie?

Pobierze jeden commit z GitHuba i wyśle dwa swoje
Cofnie jeden commit i doda dwa nowe
Przełączy na drugą gałąź

Zrobiłeś commit w panelu VS Code. Co pokaże git log w terminalu?

Nic, VS Code prowadzi osobną historię
Ten commit, ale dopiero po git push
Ten commit od razu, bo to ten sam Git

Lekcja 12

Git na egzaminie INF.04

W arkuszu INF.04 ze stycznia 2026 (zadanie 02) Git jest częścią zadania: kod aplikacji mobilnej trzeba zapisywać w repozytorium, a historię pokazać na zrzutach ekranu. Wśród 21 arkuszy INF.04 z lat 2021–2026 dostępnych w serwisie zawodowe.edu.pl to jedyny taki arkusz, ale wymaganie może wrócić.

Co każe arkusz

Po przygotowaniu projektu aplikacji założyć w nim lokalne repozytorium Git.
Skonfigurować repozytorium: nazwą użytkownika ma być numer zdającego, a e-mailem egzamin@poczta.pl.
Zapisać co najmniej dwie wersje: po zbudowaniu widoku aplikacji i po zaprogramowaniu jej działania. Opisy commitów mają być znaczące.
W dokumentacji pokazać wszystkie zapisane wersje z opisami oraz konfigurację użytkownika (nazwę i e-mail). Można użyć poleceń Gita albo narzędzi środowiska programistycznego. Zrzuty ekranu nazywasz git1.png, git2.png itd. i zapisujesz w folderze dokumentacja.

Klucz oceniania ma za Gita dwa osobne kryteria: repozytorium skonfigurowane z nazwą i e-mailem oraz co najmniej dwa zapisy wersji. Każde z nich musi być udokumentowane zrzutem ekranu. Do arkusza był dołączony wyciąg z dokumentacji Gita z poleceniami config, help, init, add, status, diff, commit i log, więc na egzaminie możesz je podejrzeć.

Krok po kroku

Najpewniej zrobisz to w terminalu, w folderze projektu. W Android Studio terminal otwiera zakładka Terminal na dole okna (Alt+F12), w VS Code skrót Ctrl+`. Oba terminale startują w folderze otwartego projektu.

git init                                     # 1. repozytorium po utworzeniu projektu
git config user.name "01234567890"           # 2. numer zdającego
git config user.email "egzamin@poczta.pl"
git status                                   # co wejdzie do repozytorium

git add .                                    # 3. po zbudowaniu widoku
git commit -m "Widok quizu: obraz, pytanie, odpowiedzi i przycisk"

git add .                                    # 4. po zaprogramowaniu działania
git commit -m "Działanie quizu: sprawdzanie odpowiedzi i kolejne pytania"

Bez --global. Arkusz każe skonfigurować repozytorium, więc nazwę i e-mail ustawiasz tylko w nim. Trafiają do pliku .git/config projektu i nie zmieniają ustawień całego stanowiska egzaminacyjnego.

Najpierw konfiguracja, potem commit. Bez niej Git odmówi zapisu z komunikatem „Author identity unknown” albo, co gorsze, podpisze commit danymi, które ktoś zostawił w ustawieniach komputera.

Właściwy folder. git init wpisujesz w głównym folderze projektu, tym z plikiem settings.gradle albo settings.gradle.kts. Nowy projekt w Android Studio ma już pliki .gitignore, więc foldery build i ustawienia środowiska nie trafią do repozytorium. Przed pierwszym commitem sprawdź to w git status.

Znaczący opis mówi, co zrobiono na danym etapie. „Widok quizu: obraz, pytanie, odpowiedzi i przycisk” spełnia wymaganie. Opisy w rodzaju „zmiany”, „commit 1” albo „aaa” go nie spełniają.

Zapisuj na bieżąco. Arkusz przypomina o zapisie dopiskami „UWAGA” po opisie widoku i po opisie działania aplikacji. Commit zrób od razu po skończeniu etapu, nie na koniec egzaminu: git log pokazuje godzinę każdego zapisu.

Zrzut ekranu do dokumentacji

git log
git config user.name
git config user.email

git log wypisuje każdy commit z opisem, autorem (nazwą i e-mailem) i datą, a dwa kolejne polecenia pokazują konfigurację repozytorium. git log --oneline tu nie wystarczy, bo pomija autora. Gdy historia nie mieści się w oknie, git log pokazuje ją stronami; wyjdziesz klawiszem q.

Zrób zrzut całego ekranu z terminalem i wynikami. Na Windowsie Win+PrtSc zapisuje go w folderze Obrazy\Zrzuty ekranu. Skopiuj plik do folderu dokumentacja jako git1.png. Jeśli wszystko nie mieści się na jednym zrzucie, zrób kolejne: git2.png, git3.png.

Bez terminala: Git w Android Studio

Arkusz dopuszcza też narzędzia wbudowane w środowisko. W Android Studio:

Repozytorium: menu VCS → Create Git Repository… (w starszych wersjach VCS → Enable Version Control Integration… i wybór Git).
Commit: Git → Commit… (Ctrl+K). Zaznacz pliki, także te z grupy Unversioned Files, wpisz opis i kliknij Commit.
Gdy nazwa i e-mail nie są ustawione, Android Studio zapyta o nie przy pierwszym commicie. Odznacz wtedy Set properties globally, żeby ustawić je tylko w tym repozytorium.
Historia: okno Git (Alt+9), zakładka Log, z opisem, autorem i datą każdego commita.

Nazwy menu różnią się trochę między wersjami Android Studio, a terminal działa zawsze tak samo. Dlatego konfigurację do zrzutu najprościej i tak wypisać w terminalu. W VS Code te same kroki zrobisz panelem z lekcji 11.

Nie usuwaj folderu .git. Repozytorium to ukryty folder .git w projekcie. Zostaw go w projekcie, który pakujesz do archiwum na płytę: to w nim jest historia. W Eksploratorze Windows ukryte foldery pokazuje Widok → Pokaż → Ukryte elementy.

Jesteś w folderze projektu. Ustaw tylko w tym repozytorium nazwę użytkownika równą numerowi zdającego 01234567890.

Ustaw w tym repozytorium e-mail z arkusza: egzamin@poczta.pl.

Wypisz wszystkie zapisane wersje z opisami, autorem i datą, żeby zrobić zrzut git1.png.

Dlaczego na egzaminie lepiej ustawić nazwę i e-mail bez --global?

Bez --global commit jest szybszy
Arkusz każe skonfigurować repozytorium, a --global zmienia ustawienia całego stanowiska
--global nie działa w terminalu Android Studio

Który opis drugiego commita spełnia wymaganie z arkusza?

poprawki
commit 2
Działanie quizu: sprawdzanie odpowiedzi i kolejne pytania

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

Egzamin INF.04

`git config user.name "numer"`	nazwa tylko w tym repozytorium: numer zdającego
`git config user.email "egzamin@poczta.pl"`	e-mail z arkusza
`git add .`, potem `git commit -m "Opis etapu"`	zapis po widoku i po działaniu aplikacji
`git log`	historia z autorem i datą do zrzutu `git1.png`

VS Code

plus przy pliku, potem Commit	`git add`, potem `git commit`
przycisk synchronizacji przy gałęzi	`git pull`, potem `git push`
Publish Branch	nowe repozytorium na GitHubie i pierwszy `push`
Git: Clone → Clone from GitHub	`git clone`

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

Git i GitHub w VS Code

Panel Source Control

Commit bez terminala

Historia i gałęzie

GitHub

Konflikty

Git na egzaminie INF.04

Co każe arkusz

Krok po kroku

Zrzut ekranu do dokumentacji

Bez terminala: Git w Android Studio

Projekt końcowy

Ściąga

Codziennie

Gałęzie

Cofanie

Egzamin INF.04

VS Code

Różnice między systemami