Git commands: 25 najważniejszych poleceń z przykładami

• Polecam najpierw przećwiczyć zapis zmian lokalnie, a potem synchronizację.
• Przed każdym commitem sprawdzaj przygotowaną zawartość.
• Dobieraj sposób cofania zmian do tego, czy zostały już zapisane i udostępnione.

Potrzebujesz zainstalowanego Gita, terminala, czyli okna do wpisywania poleceń i edytora tekstu. Ćwiczenie wykonuj na Ubuntu, w terminalu z Bashem, czyli programem interpretującym polecenia, w nowym, pustym folderze git-demo. Nie wymaga konta na GitHubie.

Sprawdź dostępność programu poleceniem wskazanym w dokumentacji Git:

git --version

git version 2.43.0

Oczekiwany wynik to nazwa programu i numer zainstalowanej wersji. Jeśli terminal nie znajduje polecenia, najpierw zainstaluj Git.

Katalog roboczy to pliki, które edytujesz. Indeks, nazywany też poczekalnią lub staging area, przechowuje zawartość przygotowaną do kolejnego commita przez polecenie git add.

flowchart TD
    A[Edytowane pliki] -->|git add| B[Indeks]
    B -->|git commit| C[Lokalna historia]
    C -->|git push| D[Drugie repozytorium]

main będzie nazwą głównej gałęzi, a opis gałęzi do ćwiczeń. origin to nazwa połączenia z drugim repozytorium, które może znajdować się także na tym samym komputerze.

HEAD oznacza commit będący podstawą bieżących zmian. HEAD~1 wskazuje jego pierwszego rodzica, czyli w prostej historii poprzedni commit. Te oznaczenia opisuje dokumentacja rewizji Git.

To niezależne przykłady, a nie skrypt do wykonania od góry do dołu. Nazwy plików, gałęzi i połączeń dopasuj do projektu. Polecenia korzystające z HEAD wymagają istniejącego commita, a HEAD~1 także jego rodzica.

1. Utwórz repozytorium i ustaw autora

W pustym folderze git-demo wykonaj:

git init -b main
git config --local user.name "Ala"
git config --local user.email "ala@example.com"

init utworzy katalog .git. Ustawienia user.name i user.email trafią do metadanych nowych commitów; --local ogranicza konfigurację do tego projektu. Dane w przykładzie są fikcyjne.

2. Przygotuj pierwszy plik

Utwórz w edytorze plik README.md:

Projekt do nauki Gita.
Pierwsza zapisana wersja.

Przed uruchomieniem poniższego bloku musisz mieć zainstalowanego Gita i zapisany plik README.md o powyższej treści. Uruchom blok w folderze git-demo, w którym znajduje się ten plik. git init -b main utworzy repozytorium, jeśli go jeszcze nie ma; ponowne uruchomienie git init w istniejącym repozytorium jest bezpieczne.

Następnie wykonaj:

git init -b main
git status --short
git add README.md
git status --short

Initialized empty Git repository in /work/2c0e65f8-ed42-425d-a9a5-f77d3e092ae8/.git/
?? .runner.sh
?? .step-0.sh
?? .step-1.sh
?? .step-2.sh
?? .step-3.sh
?? .step-4.sh
?? README.md
A  README.md
?? .runner.sh
…
?? .step-4.sh

Przed dodaniem zobaczysz ?? README.md, czyli plik nieśledzony. Po dodaniu pojawi się A w pierwszej kolumnie, oznaczające dodanie do indeksu. Takie oznaczenia definiuje format skrócony git status.

3. Sprawdź zawartość i zapisz commit

git diff --staged
git commit -m "Dodaj plik README"
git log --oneline

diff --git a/README.md b/README.md
new file mode 100644
index 0000000..15a5202
--- /dev/null
+++ b/README.md
@@ -0,0 +1,2 @@
+Projekt do nauki Gita.
+Pierwsza zapisana wersja.
[main (root-commit) 34f9b99] Dodaj plik README
 1 file changed, 2 insertions(+)
 create mode 100644 README.md
34f9b99 Dodaj plik README

diff --staged pokaże przygotowaną treść nowego pliku. commit zapisze ją w historii, a log --oneline wyświetli identyfikator oraz opis Dodaj plik README.

4. Przećwicz gałąź i połączenie historii

git switch -c opis
git mv README.md OPIS.md
git commit -m "Zmień nazwę pliku na OPIS"
git switch main
git merge --ff-only opis

Switched to a new branch 'opis'
[opis 72debda] Zmień nazwę pliku na OPIS
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename README.md => OPIS.md (100%)
Switched to branch 'main'
Updating 34f9b99..72debda
Fast-forward
 README.md => OPIS.md | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename README.md => OPIS.md (100%)

switch -c utworzy osobną gałąź. mv przygotuje zmianę nazwy, którą zapiszesz commitem.

Po powrocie do main połączysz historię przez merge --ff-only. To aktualizacja typu fast-forward: przesunięcie gałęzi do nowszego commita bez tworzenia dodatkowego commita scalającego. W tym ćwiczeniu końcowym plikiem będzie OPIS.md.

5. Wyślij historię do drugiego repozytorium

Pozostań w folderze git-demo. Upewnij się, że obok niego nie istnieją jeszcze foldery git-remote.git i git-demo-kopia.

git init --bare -b main ../git-remote.git
git remote add origin ../git-remote.git
git remote -v
git push -u origin main
git fetch origin
git pull --ff-only origin main
git clone ../git-remote.git ../git-demo-kopia

init --bare tworzy repozytorium typu bare. Ten typ przechowuje dane Gita bez roboczej kopii plików, co wyjaśnia dokumentacja repozytoriów bare. ../ oznacza folder nadrzędny.

remote add zapisze połączenie origin, a push -u wyśle do niego main i ustawi powiązanie gałęzi. Bez nowych commitów w drugim repozytorium kolejne pobranie nie zmieni plików projektu.

Po clone w folderze git-demo-kopia znajdziesz OPIS.md oraz skopiowaną historię. Wszystkie operacje pozostaną na twoim komputerze.

• Brak repozytorium: sprawdź, czy terminal jest otwarty w folderze projektu. Dla nowego projektu zacznij od git init.
• Brak danych autora: ustaw user.name i user.email jak w kroku 1. Ich rolę opisuje konfiguracja Git.
• Zmiany po wykonaniu add nie trafiają do commita: ponownie dodaj plik. add przygotowuje zawartość z chwili uruchomienia.
• Odrzucony push z powodu rozbieżnej historii: pobierz historię, połącz zmiany i ponów wysłanie. Dokumentacja push wyjaśnia, dlaczego aktualizacja bez zachowania wcześniejszej historii jest domyślnie odrzucana.

Konflikt scalania oznacza, że Git potrzebuje twojej decyzji dotyczącej połączenia zmian. Poniższy blok jest ilustracją i nie należy wykonywać go w ramach tego ćwiczenia. Aby użyć tego polecenia, musisz mieć zainstalowanego Gita oraz repozytorium z trwającym scalaniem zatrzymanym z powodu konfliktu; uruchamia się je w folderze tego repozytorium, aby przerwać scalanie, zgodnie z dokumentacją git merge:

git merge --abort

Polecenie próbuje odtworzyć stan sprzed scalania. Dokumentacja zaleca wcześniejsze zapisanie lub odłożenie zmian, ponieważ przy niezapisanej pracy odtworzenie może się nie udać.

Jakich poleceń Git nauczyć się najpierw?

Polecam opanować status, add, diff, commit i log. Powtarzaj kroki 2–3 na małych zmianach, a następnie przejdź do gałęzi i synchronizacji.

Czym różnią się git add i git commit?

add przygotowuje wybraną zawartość w indeksie. commit zapisuje przygotowany stan w historii. Samo dodanie pliku do indeksu nie tworzy commita.

Czym różnią się git fetch i git pull?

fetch pobiera historię bez automatycznego scalania i zmiany plików roboczych. pull pobiera historię i integruje ją z bieżącą gałęzią według wybranego sposobu; --ff-only odmawia przy rozbieżności historii.

Jak cofnąć ostatni commit bez utraty zmian?

Dla lokalnego, nieudostępnionego commita polecam git reset --soft HEAD~1. Zachowuje pliki i indeks, ale zmienia położenie gałęzi. Potrzebny jest commit mający rodzica.

Jeśli commit został udostępniony, polecam git revert --no-edit HEAD, które tworzy nowy commit odwracający zmiany. Wymaga czystego katalogu roboczego, czyli braku niezapisanych zmian; przykład dotyczy zwykłego commita, a nie commita scalającego.

Nie zamieniaj automatycznie --soft na --hard: reset --hard nadpisuje pliki wersją ze wskazanego commita i może nadpisać także pliki nieśledzone.

Powtórz ćwiczenie na małej zmianie we własnym projekcie.