Czym jest Git i jak się go używa?

Zarządzanie kodem to podstawa pracy każdego developera. Jeśli słyszałeś o Git, ale nadal nie do końca wiesz, czym jest i jak go używać, to poczytaj dalej. Zobaczysz jak działa Git, czym różni się od GitHuba, jak zacząć z nim pracę i co zrobić, gdy coś pójdzie nie tak. Nawet jeśli dopiero zaczynasz, po lekturze będziesz wiedział, jak świadomie korzystać z tego narzędzia.

Czym jest Git?

Pracowałeś kiedyś z kodem i na pewno trafiłeś na moment, w której chciałeś cofnąć się do starszej wersji projektu. Albo porównać zmiany między różnymi etapami pracy. Otóż właśnie to git rozwiązuje te problemy. To taki system kontroli wersji, który śledzi wszystkie zmiany w kodzie, niezależnie od tego, ile osób nad nim pracuje. Zamiast przeszukiwać foldery z kopią zapasową, masz pełną historię projektu w jednym miejscu. Przejrzystą i gotową do cofnięcia lub porównania w każdej chwili.

Ale po kolei. Sam Git działa lokalnie. Oznacza to, że cała historia repozytorium znajduje się na Twoim komputerze. Nie musisz mieć dostępu do internetu, żeby śledzić zmiany, tworzyć nowe wersje czy przeskakiwać między nimi. To duża przewaga nad starszymi narzędziami, które często wymagały połączenia z centralnym serwerem. Oczywiście swego czasu istniały inne systemy kontroli wersji chociażby CVS (Concurrent Versions System) czy Subversion (SVN) ale to właśnie dzięki GitHub to gitzyskał swoją popularność, zmienił logikę całkowicie logikę pracy.

Dzięki Gitowi możesz łatwo pracować z innymi. Tworzysz tzw. gałęzie (branch), czyli osobne linie rozwoju. Na przykład: jeden programista dodaje nową funkcję, drugi poprawia błędy, a trzeci optymalizuje wydajność. Wszystko dzieje się równolegle, bez przeszkadzania sobie nawzajem. Potem te zmiany można połączyć, analizując każdą linię kodu.

Zauważ, że Git to nie tylko narzędzie do cofania zmian. To centrum zarządzania całym cyklem życia aplikacji. Od pierwszego commita (zatwierdzenie zmian) aż po wdrożenie produkcyjne. Pozwala porządkować pracę, ułatwia komunikację w zespole i zapewnia bezpieczeństwo kodu. Nawet jeśli coś pójdzie nie tak, możesz szybko wrócić do stabilnej wersji.

W świecie koderów na pytanie git co to, musisz znać odpowiedź. Git to nieodzowny element pracy każdego programisty, niezależnie od technologii, w której pracuje. Generalnie zrozumienie Gita to pierwszy krok do profesjonalnego podejścia do tworzenia oprogramowania.

Jakie są różnice między Git a GitHub?

Wielu początkujących programistów myli Git z GitHub. Sam też na samym początku nie wiedziałem, co jest co. To zrozumiałe, bo oba narzędzia często występują razem, a ich nazwy brzmią git-podobnie. Ale pełnią zupełnie inne role. Zanim zaczniesz ich używać, warto abyś to wiedział.

Git to narzędzie. Działa na Twoim komputerze. Przechowuje historię zmian, pozwala cofać się do wcześniejszych commitów, tworzyć gałęzie, rozwiązywać konflikty. Mówiąc wprost – to silnik, który obsługuje Twoje repozytorium kodu.

GitHub z kolei, to usługa w chmurze. Jeśli zastanawiasz się, github co to, wyobraź sobie coś w rodzaju Dropboxa, ale stworzonego specjalnie dla kodu. To miejsce, gdzie możesz przechowywać repozytoria Git online. Ale to dopiero początek. GitHub to także platforma społecznościowa dla programistów. Można tam zgłaszać błędy, omawiać zmiany, wysyłać pull requesty i prowadzić całe projekty open source.

No to GitHub do czego służy? No właśnie do współpracy. Ułatwia zespołom dzielenie się kodem, kontrolowanie dostępu i przeglądanie historii zmian. Daje też dostęp do funkcji takich jak CI/CD, integracje z zewnętrznymi narzędziami czy automatyczne testowanie. Możesz też za pomocą GitHuba śledzić projekty innych programistów, forknąć repozytorium (sklonować repozytorium – fork, z zamiarem własnej modyfikacji), pracować nad własną wersją i później zaproponować zmiany oryginalnym autorom.

W praktyce GitHub i Git działają razem. Piszesz kod lokalnie, commitujesz zmiany za pomocą Gita, a następnie wysyłasz je do zdalnego repozytorium na GitHubie. Dzięki temu masz kopię zapasową w chmurze i możesz dzielić się kodem z innymi. Ale co najlepsze, nie musisz używać akurat GitHuba, żeby korzystać w pełni z Gita. Istnieją alternatywy – GitLab, Bitbucket czy nawet rozwiązania self-hosted, takie jak Gitea, które możesz zainstalować na własnym serwerze. Są szczególnie popularne, jeśli obawiasz się wycieku kodu z powodu np. błędnej konfiguracji.

Rozumienie tej różnicy ma znaczenie. Pozwala lepiej planować pracę, korzystać z właściwych narzędzi i nie dać się zaskoczyć, gdy coś nie działa tak, jak powinno. Git to narzędzie programisty. GitHub to miejsce, gdzie ten kod żyje i rozwija się razem z innymi.

Jak korzystać z systemu Git?

Dopiero wchodzisz w Gita i masz pustkę w terminalu? Spokojnie, każdy tak zaczynał. Zaraz ogarniemy, jak to wszystko działa – na przykładach, bo tak najlepiej.

git konfiguracja

Zanim jednak ruszysz dalej, warto wykonać podstawową git konfiguracja. Dzięki temu Git będzie wiedział, kto robi zmiany. Wpisz dwa polecenia:

git config --global user.name "Twoje Imię"
git config --global user.email "twoj@email.com"

To wystarczy, by wszystkie commity miały podpis. Możesz też skonfigurować edytor, kolory lub aliasy – ale na początek to nie jest konieczne.

Pierwszy krok to utworzenie repozytorium Git. Wchodzisz do folderu z projektem i wpisujesz git init. Właśnie w tym momencie Git zaczyna śledzić zmiany. Nie musisz tworzyć niczego więcej. Repozytorium zostaje założone lokalnie i od tej pory wszystko, co robisz, trafia do historii.

git config --global init.defaultBranch main

Zmieniamy sobie nazwę głównej gałęzi jako main zamiast master. (master jako nazwa stało się niemodne, choć dalej wspierane, po prostu main to już nowy standard)

mkdir moj-projekt
cd moj-projekt
git init

Dodawanie plików do repozytorium

Po zmianie plików musisz powiedzieć Gitowi, co ma zapamiętać. Wpisujesz git add ., żeby dodać wszystkie zmodyfikowane pliki. Możesz też wskazać pojedynczy plik, jeśli chcesz kontrolować, co dokładnie trafia do historii.

git add .

## albo

git add README.md

Tworzenie commitów

Kiedy pliki są już dodane, tworzysz commit. To nic innego jak migawka kodu. Wpisujesz git commit -m "Opis zmian". Staraj się pisać jasno, co zrobiłeś – to bardzo pomaga, gdy później szukasz konkretnego etapu pracy.

git commit -m "Pierwszy commit: dodano README"

Tworzenie i łączenie branchy

Pracując nad nową funkcją, warto utworzyć oddzielną gałąź. Dzięki temu nie mieszasz zmian z głównym kodem. Wpisz git checkout -b nazwa-brancha, a potem normalnie dodajesz i commitujesz zmiany. Gdy skończysz, możesz połączyć gałąź z główną za pomocą git merge. To standard w pracy zespołowej.

repozytorium github – czyli jak pracować zdalnie

Masz już wszystko lokalnie. Ale czas przesłać projekt do internetu. Zakładasz repozytorium github, kopiujesz jego adres i dodajesz je jako zdalne:

git remote add origin https://github.com/twoj-uzytkownik/twoj-projekt.git

Potem tylko git push -u origin main, by wysłać wszystkie zmiany. Od teraz możesz pracować lokalnie, a potem wypychać kod na GitHuba, gdzie inni go zobaczą, skomentują lub zrecenzują.

Ale po kolei. Najpierw utworzym to nasze repozytorium. Nazwa repo nie musi być taka sama jak naszego folderu na dysku (ta może być dowolna).

Dla testów Widoczność repozytorium ustawiłem na Public, i bez automatycznego dodania readme.md bo sami dodamy ten plik w przykładzie.

Uwierzytelnianie hasłem do GitHuba, nie jest już obsługiwane od 2021 roku. GitHub wymaga teraz tokenu (PAT) albo klucza SSH. Teraz utworzymy sobie taki Token dostępowy.

Wejdź tutaj: https://github.com/settings/tokens

1. Kliknij „Generate new token (classic)”
2. Wybierz zakres uprawnień:
   ✅ Zaznacz repo
   (możesz też dodać workflow, write:packages, jeśli potrzebujesz)
3. Skopiuj token – zapisz go, bo drugi raz już go nie zobaczysz
4. Teraz, gdy Git poprosi o login i hasło:
   • Login: Twoja nazwa użytkownika GitHub
   • Hasło: Wklej ten token zamiast zwykłego hasła

Teraz wpisujemy

git remote add origin https://github.com/adam-hitme/projekt-testowy.git

Dodajesz tym zdalne repozytorium o nazwie origin, czyli Twój projekt na GitHubie.

Wysyłasz swoją lokalną gałąź main do zdalnego repozytorium na GitHubie. -u ustawia ją jako domyślną gałąź do kolejnych push/pull.

git push -u origin main

Tworzymy i dodajemy kolejne pliki w lokalnym repozytorium git i robimy kolejny commit.

touch engine.php
touch index.php
touch style.css
git add .
git commit -m "Dodano pliki silnika i frontu"

Jeśli zastanawiasz się, git jak używać w codziennej praktyce – to właśnie tak. Git daje Ci kontrolę nad kodem. A jeśli nauczysz się go świadomie używać, staje się Twoim największym sojusznikiem w każdej fazie projektu.

Jakie są podstawowe pojęcia w Git?

Jeśli dopiero zaczynasz przygodę z kontrolą wersji, Git na pewno wydaje Ci się skomplikowany. Ale kiedy poznasz podstawowe pojęcia, wszystko zacznie układać się w logiczną całość. Ten fragment to spis pojęć git dla początkujących, które musisz znać.

• Commit – to zapis zmian w kodzie. Traktuj to jak zapisanie stanu gry. Zmieniasz coś w plikach, dodajesz do stagingu (git add), a potem robisz commit (git commit). Każdy commit ma swój unikalny identyfikator i opis – najlepiej konkretny, np. „Dodano walidację formularza”.
• Branch – inaczej gałąź. Pozwala pracować nad różnymi wersjami kodu równolegle. Główna gałąź to najczęściej main lub master. Tworzysz nową gałąź, np. feature/login, i tam robisz zmiany, nie ruszając głównej linii kodu. Kiedy skończysz, możesz połączyć zmiany z main.
• Merge – czyli scalanie. Jeśli skończyłeś pracę na branchu i chcesz, żeby zmiany trafiły do głównego kodu, robisz merge. Git porównuje zmiany i automatycznie scala je, jeśli nie ma konfliktów. A jeśli są – pozwala rozwiązać je ręcznie, dając pełną kontrolę.
• Pull request – używany głównie na platformach takich jak GitHub. To prośba o ocenę i ewentualne połączenie zmian z główną gałęzią. W zespole to codzienność. Dzięki temu każdy commit może być zrecenzowany, zanim trafi do produkcji.
• Repository (repozytorium) – to cały projekt zarządzany przez Git. Zawiera historię zmian, wszystkie branche, commit’y i konfigurację. Możesz mieć je lokalnie, na swoim komputerze, albo zdalnie – np. na GitHubie.
• Clone – to skopiowanie całego repozytorium z innego źródła, np. z GitHuba. Wpisując git clone, pobierasz projekt i możesz od razu na nim pracować, mając pełną historię zmian.

Wszystkie te pojęcia tworzą spójny system. Na początku mogą brzmieć obco, ale szybko staną się naturalne. Zwłaszcza jeśli zaczniesz regularnie pracować z Gitem. Zrozumienie ich to nie teoria – to praktyczne narzędzie, które ratuje Cię przed chaosem w projekcie.

Nie musisz znać całej dokumentacji na pamięć. Ale jeśli ogarniesz te podstawy, dalsza praca pójdzie znacznie szybciej. I z większym spokojem.

Jakie są najczęstsze błędy w Git i jak je rozwiązać?

Każdy, kto pracuje z Gitem dłużej niż parę dni, zaliczył wpadkę. I dobrze – to najlepsza lekcja. Ale warto wiedzieć, jak z tych błędów wyjść. Dlatego przygotowałem ten mini git poradnik, który ułatwi Ci życie, gdy coś pójdzie nie tak.

Najczęstszy klasyk? Commit do złej gałęzi. Pracujesz nad nową funkcją, ale zapomniałeś przełączyć się z main na feature/nazwa. Nie panikuj. Wystarczy stworzyć nową gałąź git branch nowa-nazwa, potem cofnąć ostatni commit z main (git reset HEAD~1) i przenieść się na właściwy branch. Bez kasowania kodu, bez strat.

Inny popularny problem to nadpisanie zmian przez git pull. Pracowałeś lokalnie, ktoś wypchnął zmiany do GitHuba, a Ty ściągasz je, nie robiąc najpierw commita lokalnie. Efekt? Konflikty albo utracone zmiany. Rozwiązanie: najpierw commituj wszystko, potem robisz git pull --rebase, żeby uniknąć niepotrzebnych merge’y i konfliktów.

Zdarza się też, że dodajesz do commita pliki, których nie chciałeś – np. plik .env z hasłami. Szybka reakcja: git reset HEAD plik.env, potem git restore plik.env. Jeśli commit już trafił na GitHuba, sprawa się komplikuje, ale i to da się odratować przez git rebase lub filter-branch.

A co z konfliktem podczas merge? Git jasno pokazuje, które fragmenty kodu wymagają decyzji. W plikach pojawia się podział <<<<<<<, =======, >>>>>>>. Twoje zadanie to ręczne wybranie, które fragmenty zostają. Potem git add, git commit i gotowe.

Na koniec klasyk: paniczne użycie git push --force. To potężne narzędzie, ale bardzo ryzykowne. Używaj tylko wtedy, gdy wiesz, co robisz. W przeciwnym razie możesz nadpisać zmiany kolegi z zespołu i wywołać niezłą burzę. Jeśli już musisz, zawsze komunikuj to wcześniej.

Ten git poradnik nie rozwiąże wszystkich problemów, ale nauczy Cię jednego: Git to narzędzie, które daje drugą szansę. Nawet jeśli coś pójdzie nie tak, masz sposoby, by to naprawić. Zamiast się bać, lepiej poznać, jak działa pod maską – wtedy każdy błąd to po prostu kolejny krok w nauce.