Git od podstaw dla administratora: commity, gałęzie i bezpieczny push

Kiedy Git pomaga, a czego nie zastępuje?

Git zapisuje historię śledzonych plików. Administrator zyskuje odpowiedź na pytania: co zmieniło się w konfiguracji, kto to zapisał, jaki był poprzedni stan i które wersje można porównać. To szczególnie przydatne dla playbooków Ansible, plików Nginx, manifestów Kubernetes i kodu aplikacji.

Git nie uruchamia wdrożenia, nie sprawdza poprawności konfiguracji i nie zastępuje kopii zapasowej hosta ani danych aplikacji. Commit jest punktem historii plików, a nie dowodem, że zmiana zadziała na serwerze. Przed wdrożeniem nadal wykonuj test właściwy dla usługi, na przykład nginx -t, ansible-playbook --check albo test aplikacji.

Git nie obejmuje też automatycznie każdego pliku z dysku. Nieśledzony plik, którego nie dodano przez git add, nie trafia do commita. Jeżeli jego jedyna kopia zniknie, Git nie będzie miał czego odzyskać. Z tego powodu pierwszym odruchem przed eksperymentem powinno być git status, a nie polecenie cofające.

Jakie pojęcia trzeba znać przed pierwszym poleceniem?

Repozytorium to katalog projektu wraz z ukrytym katalogiem .git. W .git Git przechowuje historię i dane potrzebne do odtworzenia śledzonych wersji. Zwykła kopia repozytorium może więc tworzyć commity i oglądać historię bez połączenia z siecią.

Katalog roboczy (working tree)

To pliki widoczne na dysku, które właśnie edytujesz. Zmiana w katalogu roboczym nie jest jeszcze częścią historii.

Poczekalnia (staging area, index)

To dokładnie wybrany zestaw zmian dla następnego commita. Polecenie git add dodaje do niej wskazane pliki; nie wysyła niczego na serwer.

Commit

To lokalnie zapisany punkt historii: zawartość wybranych plików, opis, autor, czas i odniesienie do poprzedniego stanu. Commit ma identyfikator, zwykle skracany do kilku znaków hasha.

Gałąź (branch)

To nazwa wskazująca bieżący commit danej linii pracy. Nowa gałąź nie kopiuje całego katalogu; pozwala bezpiecznie oddzielić zmianę od stabilnej gałęzi main.

Zdalne repozytorium (remote)

To nazwany adres innego repozytorium, na przykład origin. Służy do wymiany commitów między komputerami albo osobami.

Fast-forward

To scalenie, w którym gałąź docelowa nie ma własnych nowych commitów. Git przesuwa wtedy tylko jej wskaźnik do przodu; nie tworzy dodatkowego commita scalającego.

Nazwy GitHub i GitLab nie oznaczają innego rodzaju Gita. Są usługami, które hostują zdalne repozytoria oraz dodają uprawnienia, przeglądy zmian, zgłoszenia i automatyzację. Poniższe commity działają lokalnie, nawet jeżeli nie masz konta w żadnej z tych usług.

Jak założyć i zapisać pierwsze lokalne repozytorium?

Poniższy przykład uruchamiasz na swojej stacji administracyjnej jako zwykły użytkownik, w nowym katalogu laboratoryjnym. Nie dotyka on hosta 192.0.2.20; ten adres należy do puli dokumentacyjnej. Zastąp ścieżkę, nazwę i adres e-mail własnymi wartościami, ale nie wklejaj tu haseł, tokenów ani kluczy prywatnych.

# Na stacji administratora, poza katalogiem produkcyjnej konfiguracji:
git --version
mkdir -p "$HOME/git-lab/monitoring-inventory"
cd "$HOME/git-lab/monitoring-inventory"

# Załóż lokalne repozytorium i nazwij główną gałąź main.
git init
git branch -M main

# Ustaw autora tylko dla TEGO repozytorium.
git config --local user.name "Administrator przykładowy"
git config --local user.email "admin@example.test"

# Sprawdź efekt. Te polecenia niczego nie wysyłają.
git branch --show-current
git config --local --list

Oczekujesz komunikatu o utworzeniu pustego repozytorium, nazwy main oraz dwóch wpisów user.name i user.email. Opcja --local zapisuje dane w tym repozytorium. Gdy świadomie chcesz ustawić dane dla wszystkich repozytoriów bieżącego użytkownika, użyj osobno git config --global.

Teraz tworzymy wyłącznie przykładowy inventory. Plik .gitignore mówi Gitowi, aby nie proponował nowych plików pasujących do podanych wzorców. Nie usuwa pliku, który był już śledzony wcześniej.

mkdir -p inventory

cat > inventory/lab.ini <<'EOF'
[backup]
backup-lab-01 ansible_host=192.0.2.20
EOF

cat > .gitignore <<'EOF'
.env
*.pem
*.key
EOF

# Obejrzyj pliki, zanim cokolwiek trafi do historii.
git status --short
git diff -- inventory/lab.ini .gitignore

git status --short powinien pokazać dwa nieśledzone pliki jako ??. Zwykłe git diff może jeszcze nic nie wypisać, ponieważ pliki są nowe i nie zostały dodane do poczekalni. To normalne.

# Dodaj wyłącznie pliki, które mają należeć do pierwszego commita.
git add inventory/lab.ini .gitignore

# Sprawdź dokładną zawartość PRZED zapisem.
git diff --staged

# Zapisz lokalny punkt historii.
git commit -m "Dodaj inventory hosta backupowego w laboratorium"

# Potwierdź czysty katalog roboczy i obejrzyj historię.
git status
git log --oneline --decorate -3

Sukces oznacza komunikat o utworzeniu commita, czysty katalog roboczy oraz jeden wpis w git log. Commit istnieje tylko lokalnie. Nie zobaczą go jeszcze GitHub, GitLab ani inny administrator.

Jak pracować na gałęzi i bezpiecznie ją scalić?

Dla niezależnej zmiany twórz gałąź przed edycją. W tym przykładzie dopisujemy drugi host laboratorium. Jeżeli masz już niezapisane zmiany na main, git switch -c również utworzy gałąź i zachowa je w katalogu roboczym; przed przełączeniem sprawdź jednak wynik przez git status.

# Nadal w ~/git-lab/monitoring-inventory, na stacji administratora:
git switch -c feature/drugi-host-backup

printf '%s\n' 'backup-lab-02 ansible_host=192.0.2.21' >> inventory/lab.ini
git diff
git add inventory/lab.ini
git diff --staged
git commit -m "Dodaj drugi host backupowy do laboratorium"

# -sb pokazuje gałąź i zwięzły stan katalogu.
git status -sb

Po commicie git status -sb powinien wskazywać feature/drugi-host-backup i brak zmian w katalogu. Sprawdź merytorycznie plik oraz wykonaj test właściwy dla jego rodzaju przed scaleniem. Git potwierdza historię plików, nie poprawność inventory ani dostęp SSH do hostów.

# Wybierz GAŁĄŹ DOCELOWĄ, a potem dodaj do niej zmianę.
git switch main
git merge --ff-only feature/drugi-host-backup

# Obejrzyj wszystkie nazwy gałęzi i ich commity.
git log --oneline --graph --decorate --all

# Usuń lokalną gałąź roboczą dopiero po udanym scaleniu.
git branch -d feature/drugi-host-backup

W tym przypadku git merge --ff-only powinno wypisać Fast-forward. Oznacza to, że main nie miała własnych nowych commitów, więc Git tylko przesunął jej wskaźnik do commita z gałęzi roboczej. Opcja --ff-only jest celowa: gdy historia się rozeszła, operacja zatrzyma się bez tworzenia niespodziewanego merge commita. Wtedy obejrzyj różnicę przez git log --oneline --left-right main...feature/drugi-host-backup i zdecyduj razem z zespołem, czy potrzebny jest merge, rebase czy inny sposób integracji.

Czym różni się lokalny Git od GitHub i GitLab?

Lokalny Git jest programem i bazą historii w katalogu .git na Twojej stacji. Działa offline: status, diff, add, commit, gałęzie i log nie wymagają konta ani połączenia z serwerem.

GitHub, GitLab albo własny serwer Git przechowują dodatkową kopię repozytorium pod adresem sieciowym. To właśnie tam zwykle zarządza się uprawnieniami, pull requestami lub merge requestami, ochroną gałęzi i CI. Uwierzytelnianie SSH albo HTTPS rozwiązuje dostęp do tego serwera; nie jest częścią mechanizmu commita.

Dla istniejącego projektu zwykle zaczynasz od git clone. Polecenie tworzy nowy katalog, pobiera historię i ustawia nazwę origin dla adresu źródłowego. Uruchom je na stacji administratora, w katalogu nadrzędnym, nie wewnątrz innego repozytorium.

cd "$HOME/git-lab"
git clone git@git.example.test:infra/monitoring-inventory.git monitoring-inventory
cd monitoring-inventory

# Potwierdź adres oraz stan po pobraniu.
git remote -v
git status -sb

Zastąp git.example.test:infra/monitoring-inventory.git adresem z własnego GitLaba, GitHuba lub serwera firmowego. Najpierw upewnij się, że adres jest właściwy i że masz prawo czytać dane repozytorium. Klonowanie nie daje prawa do push; to zależy od uprawnień po stronie serwera.

Jak użyć clone, fetch, pull i push bez nadpisywania pracy?

Jeżeli chcesz opublikować lokalne laboratorium z poprzedniego przykładu, najpierw utwórz na serwerze puste repozytorium bez automatycznego pliku README i bez commita inicjalnego. Wtedy historia lokalna może zostać wysłana bez łączenia dwóch niezależnych początków.

# W lokalnym repozytorium ~/git-lab/monitoring-inventory:
git remote add origin git@git.example.test:infra/monitoring-inventory.git
git remote -v

# Puste repozytorium nie wypisze gałęzi, ale polecenie powinno zakończyć się powodzeniem.
git ls-remote --heads origin

# -u zapisuje powiązanie lokalnej main z origin/main.
git push -u origin main
git status -sb

Po pierwszym push oczekujesz informacji o utworzeniu main na origin, a git status -sb powinien pokazać śledzenie origin/main. Jeśli serwer odrzuci push, ponieważ zdalne main ma własne commity, zatrzymaj się. Pobierz historię i obejrzyj ją; nie naprawiaj sytuacji poleceniem git push --force.

# Pobierz stan serwera, ale jeszcze nie zmieniaj plików ani bieżącej gałęzi.
git fetch --prune origin

# < oznacza commity tylko lokalne, a > commity tylko na origin/main.
git log --oneline --left-right main...origin/main

# Dołącz zdalne zmiany wyłącznie, gdy możliwy jest fast-forward.
git pull --ff-only

# Wyślij własne commity dopiero po sprawdzeniu wyniku.
git push

git fetch aktualizuje lokalny obraz serwera, na przykład origin/main, ale nie modyfikuje plików. git pull --ff-only najpierw pobiera dane, a potem aktualizuje gałąź tylko wtedy, gdy nie musi wybierać sposobu łączenia historii. Jeżeli zatrzyma się z informacją o rozbieżności, przeczytaj git log --left-right, sprawdź zasady projektu i ustal z zespołem dalszy krok.

Jak cofać zmiany bez niepotrzebnej utraty danych?

Najpierw ustal, gdzie znajduje się zmiana: w katalogu roboczym, w poczekalni czy w commicie. Zacznij od git status, git diff i git diff --staged. Nie używaj git reset --hard jako pierwszej reakcji; może trwale usunąć pracę, która nigdy nie trafiła do commita.

Jak wycofać plik z poczekalni, ale zachować jego treść?

# Zmienia tylko staging area; plik na dysku zostaje bez zmian.
git restore --staged inventory/lab.ini

To właściwy krok, gdy przez pomyłkę użyto git add. Potwierdź rezultat przez git status: plik powinien pojawić się jako zmieniony, ale nieprzygotowany do commita.

Jak odłożyć pracę, gdy trzeba pilnie zmienić gałąź?

git stash push -u -m "WIP: inventory backup"
git stash list
git switch main

# Po powrocie na gałąź roboczą:
git stash apply

git stash push -u zapisuje tymczasowo również nieśledzone pliki. Używaj apply, gdy chcesz najpierw sprawdzić wynik i zachować wpis w schowku; pop usuwa go po udanym zastosowaniu. Najbezpieczniejszym trwałym ratunkiem nadal pozostaje mały commit na osobnej gałęzi.

Jak uratować commit utworzony lokalnie na złej gałęzi?

Gdy ostatni commit powstał tylko lokalnie na main i nie został wysłany, najpierw nadaj mu drugą nazwę. Dopiero potem cofnij main. Ten wariant nie dotyczy commita, który inni mogli już pobrać.

# Punkt wyjścia: jesteś na main, a pomyłkowy commit jest ostatni i niewysłany.
git status
git log --oneline -3

# Gałąź zabezpiecza commit przed przesunięciem main.
git branch feature/pomylona-zmiana
git reset --keep HEAD~1
git switch feature/pomylona-zmiana
git log --oneline --graph --decorate --all

--keep zatrzyma reset zamiast nadpisać kolidujące zmiany w katalogu roboczym. Jeśli commit został już opublikowany na współdzielonej gałęzi, nie przepisuj historii. Wykonaj git revert <hash-commita>, przetestuj nowy commit odwracający i wyślij go zwykłym git push.

Jak odzyskać commit po pomyłce?

git reflog
git switch -c rescue/odzyskaj <hash-z-reflog>
git log --oneline --decorate -3

Reflog jest lokalną historią ruchów wskaźnika HEAD. Po znalezieniu właściwego hasha nowa gałąź zabezpiecza commit przed dalszymi operacjami. Reflog nie zastępuje kopii zapasowej: stare wpisy i nieosiągalne obiekty mogą z czasem zostać usunięte.

Co zrobić, gdy sekret trafi do repozytorium?

Nie zapisuj w Git haseł, tokenów API, prywatnych kluczy, plików .env ani rzeczywistych danych klientów. Używaj zmiennych środowiskowych, systemu zarządzania sekretami albo mechanizmu szyfrowania przyjętego w zespole. Do repozytorium może trafić szablon, na przykład .env.example, ale bez rzeczywistych wartości.

Jeżeli plik został dodany do poczekalni, ale nie powstał jeszcze commit, wyjmij go ze staging area i dopisz wzorzec do .gitignore:

git restore --staged .env
printf '%s\n' '.env' >> .gitignore
git status

Jeżeli plik był już śledzony, samo dopisanie go do .gitignore nie wystarczy. Polecenie git rm --cached .env przestaje śledzić go od następnego commita, lecz zostawia plik na dysku. Nie usuwa jednak jego dawnych zawartości z istniejącej historii.

# Zatrzymaj śledzenie pliku, ale zachowaj jego lokalną kopię.
git rm --cached .env
printf '%s\n' '.env' >> .gitignore
git add .gitignore
git commit -m "Przestań śledzić lokalny plik .env"

Kiedy diagnozować lub konserwować repozytorium?

W codziennej pracy Git sam wykonuje większość lekkich prac porządkowych. Ręczna konserwacja ma sens po dużym imporcie, po naprawie historii albo gdy repozytorium wyraźnie zwalnia. Najpierw diagnozuj, a nie uruchamiaj agresywne czyszczenie.

# Te polecenia czytają stan; nie modyfikują plików projektu.
git count-objects -vH
git fsck --full

# Uruchom standardowe, planowe porządkowanie tylko wtedy, gdy jest potrzebne.
git maintenance run

git count-objects -vH pokazuje rozmiar i liczbę obiektów. git fsck --full sprawdza spójność obiektów, ale nie naprawia brakujących danych. Jeżeli zgłasza uszkodzenie, zatrzymaj się i odzyskaj repozytorium z poprawnego klona albo kopii zapasowej. git maintenance run wykonuje standardowy zestaw prac porządkowych. Nie zaczynaj od git gc --aggressive ani git gc --prune=now, ponieważ mogą długo działać i skrócić czas odzyskania niedawno osieroconych commitów.

Jak rozwiązać częste sytuacje bez zgadywania?

Jak sprawdzić, co dokładnie zmienię?

git status -sb
git diff
git diff --staged
git log --oneline --graph --decorate -10

Pierwsze dwa polecenia pokazują bieżący katalog i różnice, a git diff --staged jest podglądem następnego commita. Ostatnie polecenie pokazuje krótką historię z nazwami gałęzi.

Jak pobrać jeden commit z innej gałęzi?

git switch moja-galaz
git cherry-pick <hash-commita>
git status
git log --oneline -3

git cherry-pick odtwarza zmianę wskazanego commita na bieżącej gałęzi i tworzy nowy commit. Przed użyciem sprawdź treść przez git show <hash-commita>. Jeżeli wystąpi konflikt, rozwiąż go, dodaj poprawione pliki przez git add i użyj git cherry-pick --continue; aby całkowicie zrezygnować, użyj git cherry-pick --abort.

Jak znaleźć zmianę w pliku bez szukania winnego?

git log -p -- sciezka/do/pliku.conf
git blame sciezka/do/pliku.conf
git show <hash>:sciezka/do/pliku.conf

git log -p pokazuje kolejne zmiany pliku, git blame wskazuje commit ostatnio zmieniający każdą linię, a git show wyświetla dawną wersję bez modyfikowania katalogu roboczego.

Jaka jest bezpieczna kolejność codziennej pracy?

1. Na początku sprawdź git status i różnice.
2. Utwórz gałąź dla niezależnej zmiany, zanim ją zapiszesz.
3. Dodaj świadomie wybrane pliki przez git add, a potem sprawdź git diff --staged.
4. Utwórz mały, zrozumiały commit i przetestuj jego rzeczywisty efekt.
5. Przed pull lub push pobierz stan serwera przez git fetch i obejrzyj rozbieżności.
6. Na gałęziach współdzielonych odwracaj błędy przez git revert; nie wymuszaj wysłania historii bez uzgodnienia.

Taka kolejność rozdziela lokalną pracę od publikacji, daje czytelny punkt powrotu i ogranicza sytuacje, w których Git trzeba „naprawiać” pod presją. Dopiero po opanowaniu tej pętli warto sięgać po bardziej zaawansowane operacje, takie jak rebase czy przepisanie historii.

Część naszego kodu jest publiczna w repozytorium sysgroup/linuxlab na GitHubie. To przykład zdalnego repozytorium; codzienna praca z jego historią nadal zaczyna się od lokalnego klona i tych samych poleceń Git.