Czym jest Git?

Co to jest Git?

Git to rozproszony system kontroli wersji, który pozwala śledzić zmiany w plikach projektu, porównywać kolejne wersje kodu i bezpiecznie wracać do wcześniejszego stanu pracy. Najczęściej używają go programiści, ale Git przydaje się także administratorom, testerom, twórcom stron oraz zespołom pracującym nad dokumentacją techniczną. Zamiast tworzyć kopie plików typu strona_finalna_v2_poprawiona.html, zapisujesz zmiany w repozytorium i opisujesz je krótkim komunikatem.

Git jest systemem rozproszonym. Każda osoba, która sklonuje projekt, ma u siebie lokalną kopię repozytorium wraz z historią zmian. To ważne, ponieważ możesz pracować offline, tworzyć własne gałęzie rozwoju i dopiero później zsynchronizować zmiany z resztą zespołu.

W praktyce Git odpowiada na bardzo proste pytania: kto zmienił dany plik, kiedy to zrobił, co dokładnie zostało zmienione i jak przywrócić poprzednią wersję, jeśli coś poszło nie tak. Dzięki temu łatwiej rozwijać stronę, aplikację lub sklep internetowy bez chaosu w plikach.

Jak działa Git?

Git zapisuje projekt jako serię punktów kontrolnych. Taki punkt kontrolny to commit. Każdy commit zawiera informację o zmianach, autorze, dacie oraz odniesieniu do wcześniejszego commita. Dzięki temu Git potrafi odtworzyć historię projektu krok po kroku.

Repozytorium

Repozytorium to miejsce, w którym Git przechowuje pliki projektu i historię ich zmian. Może być lokalne, czyli zapisane na Twoim komputerze, albo zdalne, np. na platformie takiej jak GitHub, GitLab lub Bitbucket.

Commit

Commit to zapisany stan zmian. Dobry commit powinien być logiczny i opisany tak, aby inna osoba mogła szybko zrozumieć, co zostało zrobione. Przykład: Poprawiono walidację formularza kontaktowego mówi więcej niż zmiany.

Branch, czyli gałąź

Branch to osobna linia pracy nad projektem. Dzięki gałęziom możesz rozwijać nową funkcję, poprawiać błąd albo testować zmianę bez naruszania głównej wersji kodu. W wielu zespołach główna gałąź nazywa się main, ale w starszych projektach nadal spotkasz nazwę master.

Warto wiedzieć: Git nie przechowuje zmian wyłącznie jako listy różnic między plikami. W uproszczeniu zapisuje kolejne migawki projektu i łączy je w historię. To właśnie dlatego tak dobrze radzi sobie z gałęziami, scalaniem oraz porównywaniem wersji. Więcej technicznego kontekstu znajdziesz w oficjalnym rozdziale dokumentacji Git o gałęziach.

Czym różni się Git od GitHuba?

Git to system kontroli wersji instalowany lokalnie lub używany na serwerze. GitHub to platforma online, która pozwala przechowywać repozytoria Git w chmurze, współpracować z zespołem, tworzyć pull requesty, przeglądać kod i uruchamiać automatyzacje.

W codziennej pracy wygląda to tak: zmieniasz pliki lokalnie, zapisujesz zmiany jako commit, a potem wysyłasz je do zdalnego repozytorium. Zespół może je pobrać, sprawdzić, omówić i połączyć z główną wersją projektu.

Najważniejsze komendy Git

Git ma wiele komend, ale na start wystarczy znać kilka podstawowych. To one pozwalają utworzyć repozytorium, zapisać zmiany i zsynchronizować projekt z zespołem.

• git init – tworzy nowe repozytorium Git w bieżącym katalogu.
• git clone – kopiuje istniejące repozytorium, najczęściej z platformy zdalnej.
• git status – pokazuje, które pliki zostały zmienione, dodane lub usunięte.
• git add – dodaje wybrane zmiany do obszaru przygotowania, czyli staging area.
• git commit – zapisuje przygotowane zmiany w historii projektu.
• git branch – pokazuje lub tworzy gałęzie.
• git checkout albo git switch – przełącza między gałęziami.
• git pull – pobiera zmiany ze zdalnego repozytorium i łączy je lokalnie.
• git push – wysyła lokalne commity do zdalnego repozytorium.
• git merge – scala zmiany z jednej gałęzi do drugiej.

Dobre praktyki pracy z Git

Git daje dużą swobodę, ale bez prostych zasad w repozytorium szybko pojawia się bałagan. Warto ustalić z zespołem, jak nazywać gałęzie, jak opisywać commity i kiedy scalać zmiany z główną gałęzią projektu.

• Twórz krótkie i konkretne commity, które opisują jedną logiczną zmianę.
• Nie zapisuj haseł, kluczy API ani danych dostępowych w repozytorium.
• Używaj pliku .gitignore, aby pominąć pliki tymczasowe, cache, zależności i lokalne konfiguracje.
• Pracuj na osobnych gałęziach, gdy rozwijasz funkcję lub poprawiasz błąd.
• Pobieraj zmiany przed rozpoczęciem pracy, aby ograniczyć ryzyko konfliktów.
• Opisuj pull requesty, jeśli projekt korzysta z platformy do przeglądu kodu.

Korzyści z używania Git

• Praca offline: Dzięki lokalnym repozytoriom, programiści mogą pracować nad kodem bez konieczności stałego połączenia z internetem.​
• Łatwe przywracanie wersji: Możliwość powrotu do wcześniejszych wersji kodu ułatwia debugowanie i analizę zmian.​
• Współpraca: Git umożliwia wielu programistom równoczesną pracę nad tym samym projektem, minimalizując ryzyko konfliktów i ułatwiając integrację zmian.
• Historia i kontrola – każdy commit jest zapamiętywany i opisany, co pozwala analizować rozwój kodu.