Napisał Pan kod, ale obawia się Pan zepsuć działającą wersję. Albo pracuje Pan w zespole i gubi się, kto i kiedy wprowadził zmiany. A może po prostu chce Pan „wycofać" nieudany eksperyment jedną komendą.

Wszystko to zapewnia Git, system kontroli wersji, bez którego nie obywa się żaden nowoczesny projekt. Jednak próg wejścia wielu odstrasza: terminal, klucze SSH, gałęzie, pull requesty.

W rzeczywistości podstawowy cykl pracy można opanować w godzinę. Ta instrukcja jest właśnie o nim: od instalacji do pierwszego pusha, bez lania wody i zbędnej teorii.

💡 Szybki przegląd:

• Zainstaluje Pan Git pod swój system operacyjny i ustawi nazwę użytkownika jedną komendą
• Wygeneruje Pan klucz SSH Ed25519 i powiąże go z kontem na GitHubie
• Utworzy Pan repozytorium, połączy je z lokalnym folderem i wykona pierwszy push
• Sklonuje Pan istniejące repozytorium przez HTTPS lub SSH do pracy lokalnej
• Opanuje Pan nowoczesne komendy git switch i git restore zamiast git checkout

1. Instalacja Gita

Git działa na Windows, macOS i Linux. Najpewniejszy sposób to pobrać instalator z oficjalnej strony git-scm.com.

Dla Windows proszę pobierać wersję 64-bitową. Podczas instalacji kreator zaproponuje wybór domyślnego edytora, strategię obsługi zakończeń linii i terminal; dla początkującego odpowiednie są wartości domyślne, z wyjątkiem edytora: zamiast Vima wygodniej jest wybrać Nano lub VS Code.

Szczegółowa instrukcja instalacji Gita na Windows (ze zrzutami ekranu każdego kroku kreatora) jest już na naszym blogu: jak zainstalować Git na Windows.

Proszę sprawdzić, czy Git działa poprawnie:

1
git --version

Jeśli terminal pokazał wersję (na przykład git version 2.48.0), instalacja przebiegła pomyślnie.

2. Wstępna konfiguracja Gita

Przed pierwszym commitem Git musi wiedzieć, kim Pan jest. Imię i email trafią do historii każdej zmiany; na ich podstawie współpracownicy zrozumieją, kto jest autorem poprawki.

1
git config --global user.name "Ваше Имя"
2
git config --global user.email "[email protected]"

Flaga --global zapisuje ustawienia globalnie, będą one obowiązywać dla wszystkich repozytoriów na tym komputerze. Jeśli dla konkretnego projektu potrzebne są inne dane, proszę powtórzyć komendę bez --global, będąc w folderze projektu.

Jeszcze dwie przydatne flagi:

1
git config --global core.editor "code --wait"   # редактор для сообщений коммитов
2
git config --global init.defaultBranch main     # ветка по умолчанию — main, не master

Od 2020 roku GitHub tworzy repozytoria z gałęzią main zamiast master. Wiersz init.defaultBranch main synchronizuje Pana lokalną instalację z tym standardem i pozwoli uniknąć zamieszania w przyszłości.

Proszę sprawdzić wszystko razem:

1
git config --list

3. Klucz SSH i powiązanie z GitHubem

GitHub wyłączył obsługę haseł dla operacji Git w 2021 roku. Dziś standardem są klucze SSH, a algorytmem, Ed25519 (bardziej kompaktowy i bezpieczniejszy niż przestarzały RSA).

Proszę wygenerować klucz:

1
ssh-keygen -t ed25519 -C "[email protected]"

Proszę nacisnąć Enter trzy razy: pusta fraza hasłowa jest całkowicie akceptowalna dla pracy lokalnej. Terminal pokaże odcisk palca i ścieżkę do klucza:

Teraz proszę skopiować klucz publiczny do schowka. Polecenie zależy od systemu operacyjnego:

macOS:

1
pbcopy < ~/.ssh/id_ed25519.pub

Linux (Ubuntu):

1
cat ~/.ssh/id_ed25519.pub

Windows (Git Bash):

1
clip < ~/.ssh/id_ed25519.pub

Pozostaje dodać klucz na GitHubie. Proszę zalogować się na konto, kliknąć awatar w prawym górnym rogu i wybrać Settings:

W bocznym menu proszę przejść do zakładki SSH and GPG keys:

Proszę nacisnąć zielony przycisk New SSH Key. W polu Title proszę nadać kluczowi sensowną nazwę (na przykład „Laptop Asus"), w polu Key wkleić zawartość schowka i nacisnąć Add SSH Key.

Proszę sprawdzić połączenie:

1
ssh -T [email protected]

Odpowiedź Hi username! You've successfully authenticated... oznacza, że wszystko jest skonfigurowane.

4. Tworzenie repozytorium i pierwsza synchronizacja

Na stronie github.com/new proszę utworzyć nowe repozytorium: nadać nazwę, pozostawić Public lub wybrać Private, NIE zaznaczać opcji „Add a README file" (w przeciwnym razie wystąpi konflikt przy pierwszym pushu).

Teraz w terminalu proszę przejść do folderu projektu i wykonać sekwencję:

1
git init                          # инициализация Git в папке
2
git add .                         # индексация всех файлов
3
git commit -m "Первый коммит"     # фиксация состояния

Proszę powiązać lokalny folder ze zdalnym repozytorium i wysłać zmiany:

1
git remote add origin [email protected]:yourname/yourproject.git
2
git push -u origin main

Flaga -u zapamiętuje powiązanie „lokalna gałąź → zdalna". Następnym razem wystarczy zwykłe git push.

Proszę nie zapomnieć o .gitignore, umieszcza się w nim pliki, które nie powinny trafić do repozytorium (logi, pliki tymczasowe IDE, foldery zależności takie jak node_modules/). Gotowe szablony dla dowolnego stosu technologicznego można pobrać z gitignore.io.

5. Klonowanie repozytorium

Klonowanie to pobranie cudzego (lub własnego, ale z GitHuba) repozytorium na lokalną maszynę wraz z pełną historią zmian.

Na stronie repozytorium proszę kliknąć zielony przycisk Code:

Otworzy się okno z trzema opcjami. Proszę wybrać SSH (jeśli skonfigurowali Państwo klucz zgodnie z krokiem 3) lub HTTPS:

Proszę skopiować URL i wykonać w terminalu:

1
git clone [email protected]:username/repository.git

Git utworzy folder o nazwie repozytorium i pobierze do niego wszystkie pliki oraz historię. Po sklonowaniu można od razu rozpocząć pracę.

Do codziennej nawigacji po gałęziach proszę używać nowoczesnych poleceń:

1
git switch feature-branch    # переключиться на существующую ветку
2
git switch -c new-feature    # создать новую ветку и переключиться
3
git restore file.txt          # откатить изменения в файле

Zastąpiły one przeciążone git checkout w Git 2.23 i od tego czasu stały się standardem. git checkout nigdzie nie zniknął, ale switch i restore są bezpieczniejsze i bardziej intuicyjne.

Jeśli wolą Państwo interfejs graficzny, GitHub Desktop zapewnia wizualne zarządzanie klonowaniem, commitami i gałęziami bez terminala.

Wideo: pełny kurs Git i GitHub w 2 godziny

Aby utrwalić materiał, proszę obejrzeć wyczerpujący samouczek wideo w języku angielskim, od instalacji po zaawansowane scenariusze pracy zespołowej:

⁉️🤔 Często zadawane pytania

Czym Git różni się od GitHuba?

Git to program do kontroli wersji, który działa na Pana/Pani komputerze. GitHub to serwis internetowy, który przechowuje repozytoria Gita w chmurze i dodaje narzędzia do pracy zespołowej: pull requesty, code review, issues. Odpowiednikami są GitLab i Bitbucket. Git może działać całkowicie bez GitHuba, ale GitHub bez Gita nie istnieje.

Czy trzeba uczyć się wiersza poleceń, skoro jest GitHub Desktop?

GitHub Desktop pokrywa większość codziennych zadań, ale terminal daje pełną kontrolę. Polecenia takie jak git rebase, git stash i git cherry-pick nie zawsze są oczywiste w GUI. CI/CD, serwery i scenariusze DevOps działają wyłącznie przez CLI. Nasza rada: proszę zacząć od Desktopa, a wiersz poleceń opanowywać równolegle, po 2-3 polecenia naraz.

Czy można zmienić nazwę gałęzi master na main w istniejącym projekcie?

Tak i jest to standardowa praktyka. Proszę wykonać: git branch -m master main, następnie git push -u origin main i git push origin --delete master. Potem w ustawieniach repozytorium na GitHubie proszę zmienić gałąź domyślną na main.

Co zrobić, jeśli Git odrzuca push z błędem „failed to push some refs"?

Prawie zawsze przyczyną jest to, że w zdalnym repozytorium są commity, których nie ma Pan/Pani lokalnie. Najpierw proszę zrobić git pull --rebase origin main, rozwiązać ewentualne konflikty, a potem powtórzyć git push. Flaga --rebase umieszcza Pana/Pani commity na wierzchu zdalnych, historia pozostaje liniowa.

Jak cofnąć ostatni commit, który jeszcze nie trafił na GitHuba?

git reset --soft HEAD~1, commit zniknie, ale zmiany pozostaną w indeksie (staged). Można je poprawić i zakomitować ponownie. Jeśli zmiany w ogóle nie są potrzebne, proszę użyć git reset --hard HEAD~1, ale należy być ostrożnym: twardy reset bezpowrotnie usuwa pliki.

Co dalej: Pana/Pani pierwszy cykl pracy

Podsumowujący obraz po tej instrukcji: Git jest zainstalowany, klucz SSH podpięty, repozytorium utworzone i zsynchronizowane. Przeszedł Pan/Pani drogę od zera do środowiska gotowego do pracy.

Dalej, praktyka. Proszę zacząć od małych rzeczy: zrobić trzy sensowne commity w projekcie testowym, otworzyć gałąź przez git switch -c, dodać plik i wysłać pull request do scalenia z mainem. To właśnie ten cykl (commit → branch → PR → merge) powtarza się codziennie w każdym zespole.

A kiedy już się Pan/Pani wdroży, proszę wrócić do nas po zaawansowane tematy: git rebase, interaktywny stash, rozwiązywanie konfliktów scalania i konfigurację CI/CD w GitHub Actions.