Jak działa Git – podstawy dla początkujących

Wyobraź sobie, że piszesz ważną pracę dyplomową. Zapisujesz plik jako praca.docx. Po kilku poprawkach zmieniasz nazwę na praca_poprawiona.docx, potem praca_final.docx, a na końcu praca_final_ostateczna_v2.docx. Brzmi znajomo?

W świecie programowania takie podejście to przepis na katastrofę. Tutaj z pomocą przychodzi Git – narzędzie, które dla programistów jest tym, czym „Save Game” dla graczy lub wehikuł czasu dla bohaterów science-fiction.

W tym artykule wyjaśnimy, jak działa Git, czym różni się od GitHub i dlaczego musisz go znać, jeśli myślisz o karierze w IT.

Czym właściwie jest Git?

Git to rozproszony system kontroli wersji (Distributed Version Control System). Stworzył go Linus Torvalds (twórca Linuxa) w 2005 roku.

Mówiąc najprościej: Git śledzi każdą, nawet najmniejszą zmianę w plikach twojego projektu. Dzięki niemu możesz:

• Cofnąć się do dowolnego momentu w historii projektu.
• Eksperymentować bez ryzyka zepsucia głównego kodu.
• Pracować zespołowo nad tymi samymi plikami bez nadpisywania cudzej pracy.

Jak Git „widzi” twoje pliki? (Trzy stany)

To najważniejsza koncepcja, którą musisz zrozumieć. Git nie działa jak zwykłe „Zapisz” w edytorze tekstu. Proces zapisywania zmian w Gicie jest podzielony na trzy etapy (strefy):

1. Working Directory (Katalog roboczy): To miejsce, w którym aktualnie pracujesz. Tutaj edytujesz pliki, kasujesz je lub dodajesz nowe. Zmiany tutaj są „brudne” – Git o nich wie, ale jeszcze ich nie zapamiętał.
2. Staging Area (Poczekalnia / Index): To strefa buforowa. Tutaj wybierasz („dodajesz”) konkretne pliki, które chcesz zatwierdzić w najbliższym zapisie. Możesz edytować 10 plików, ale do poczekalni dodać tylko 2.
3. Repository (Repozytorium / .git): To serce Gita. Gdy wykonasz polecenie „commit” (zatwierdź), pliki z poczekalni trafiają tutaj na stałe jako „migawka” (snapshot) historii.

Kluczowe pojęcia, które musisz znać

Zanim wpiszesz pierwszą komendę, warto zrozumieć słownik Gita:

• Repository (Repo): Katalog twojego projektu śledzony przez Gita.
• Commit: Pojedynczy punkt w historii (zapis). Każdy commit ma swój unikalny identyfikator (hash) i komentarz opisujący, co zostało zrobione.
• Branch (Gałąź): Niezależna linia rozwoju projektu. Wyobraź sobie drzewo – pień to główna wersja programu (zazwyczaj nazywana main lub master). Gdy chcesz dodać nową funkcję, tworzysz nową gałąź, pracujesz na niej, a gdy skończysz – łączysz ją z pniem.
• Merge (Scalanie): Proces łączenia zmian z jednej gałęzi do drugiej (np. włączenie gotowej funkcji do głównego kodu).

Git a GitHub – to nie to samo!

To najczęstszy błąd początkujących.

GitHub dodaje do Gita warstwę społecznościową i narzędzia do zarządzania projektami, ale bez Gita sam GitHub byłby tylko zwykłym hostingiem plików.

Niezbędnik początkującego 6 komend na start

Oto lista komend, których będziesz używać przez 90% czasu:

1. git init – Tworzy nowe repozytorium w obecnym folderze (start projektu).
2. git clone [adres_url] – Pobiera istniejące repozytorium z internetu (np. z GitHuba) na twój dysk.
3. git status – Najlepszy przyjaciel. Mówi ci, w jakim stanie są twoje pliki (czy są w poczekalni, czy zostały zmienione).
4. git add [nazwa_pliku] – Przenosi plik z katalogu roboczego do Staging Area (przygotowuje do zapisu).
   • Tip: git add . dodaje wszystkie zmienione pliki naraz.
5. git commit -m "Twój opis zmian" – Tworzy trwały zapis zmian znajdujących się w Staging Area.
6. git push – Wysyła twoje lokalne commity na zdalny serwer (np. GitHub).

Dlaczego warto?

Nauka Gita na początku może wydawać się trudna – zwłaszcza obsługa terminala. Jednak korzyści są ogromne. Git daje ci pewność siebie. Możesz eksperymentować z kodem, wiedząc, że w każdej chwili możesz wpisać git checkout i wrócić do działającej wersji sprzed godziny.

To standard przemysłowy. Nieważne, czy będziesz pracować w Google, w małym startupie, czy tworzyć hobbystyczny projekt – Git będzie twoim codziennym narzędziem pracy.