Co to jest Git?
Autor: Redakcja Domeny.ForSale Opublikowano
W skrócie: Git to rozproszony system kontroli wersji, czyli narzędzie do zapisywania historii zmian w plikach. Pozwala porównywać kolejne wersje, przywracać wcześniejszą treść i łączyć pracę kilku osób. Działa lokalnie na komputerze; GitHub ani połączenie z internetem nie są potrzebne do podstawowej pracy.
Do czego służy Git?
Bez kontroli wersji łatwo skończyć z plikami nazwanymi projekt-final, projekt-final2 i projekt-poprawiony. Git zastępuje takie ręczne kopie uporządkowaną historią. Każdy świadomie zapisany etap można opisać, sprawdzić i porównać z innym.
Git jest szczególnie przydatny przy kodzie źródłowym, konfiguracji, dokumentacji i artykułach zapisanych jako zwykły tekst, na przykład w Markdown. Potrafi przechowywać również zdjęcia czy dokumenty biurowe, ale ich zmian zwykle nie pokaże równie czytelnie jak różnic między liniami tekstu. Duże, często zmieniane pliki binarne wymagają dodatkowego planowania sposobu przechowywania.
Przykład: zmieniasz formularz kontaktowy, a po poprawce przestają działać powiadomienia. Jeśli wcześniejsze etapy pracy były zapisane w Gicie, możesz sprawdzić, co dokładnie się zmieniło, i odwrócić wadliwą modyfikację. Nie musisz odtwarzać poprzedniej wersji z pamięci.
Repozytorium, commit i gałąź — podstawowe pojęcia
Repozytorium to baza historii projektu wraz z informacjami potrzebnymi Gitowi do zarządzania wersjami. W typowym projekcie lokalnym te dane znajdują się w ukrytym katalogu .git, obok plików roboczych, które edytujesz.
Commit to zapisany stan śledzonych plików, połączony z wcześniejszą historią. Ma identyfikator, informację o autorze i opis. Dobry opis, na przykład „Popraw walidację adresu e-mail”, wyjaśnia cel zmiany lepiej niż „Poprawki”. Git nie tworzy commitów automatycznie po każdym zapisaniu pliku w edytorze.
Obszar przygotowania, nazywany też indeksem lub staging area, pozwala wybrać zmiany do następnego commita. Dzięki temu możesz edytować kilka plików, ale zapisać osobno poprawkę błędu i aktualizację dokumentacji. To ułatwia późniejsze zrozumienie historii.
Gałąź, czyli branch, to osobna linia pracy w repozytorium. Możesz na niej rozwijać nową funkcję bez natychmiastowej zmiany głównej wersji projektu. Scalanie, czyli merge, łączy zmiany z różnych gałęzi.
Określenie rozproszony oznacza, że zwykłe klonowanie repozytorium daje lokalną kopię jego historii, a nie tylko dostęp do plików na serwerze. Istnieją też klony z ograniczoną historią. W standardowej pracy przeglądanie zapisanych zmian i tworzenie commitów nie wymaga kontaktu z centralnym serwerem.
Git a GitHub — czym się różnią?
Git jest narzędziem do kontroli wersji. GitHub jest usługą, która między innymi przechowuje repozytoria Git i udostępnia funkcje współpracy, takie jak przegląd zmian czy zgłaszanie błędów. Podobną rolę pełnią GitLab i Bitbucket; repozytorium można też utrzymywać na własnym serwerze.
Repozytorium zdalne to druga kopia repozytorium dostępna pod określonym adresem. Polecenie push wysyła do niego lokalne commity, a fetch pobiera informacje i historię ze zdalnej kopii bez integrowania ich z bieżącą gałęzią. Polecenie pull pobiera zmiany i następnie je integruje — sposób integracji zależy od ustawień oraz użytych opcji.
Samo wykonanie commita nie publikuje więc pracy w internecie. Z kolei wysłanie zmian do usługi hostingowej nie musi oznaczać ich publicznego udostępnienia: o widoczności decydują uprawnienia repozytorium.
Jak zacząć: pierwszy zapis zmian
Zainstaluj Git, korzystając z instrukcji dla swojego systemu w oficjalnej dokumentacji projektu. W terminalu sprawdzisz instalację poleceniem git --version. Możesz też korzystać z interfejsu graficznego lub obsługi Gita w edytorze, ale podstawowy proces pozostaje taki sam.
W nowym katalogu testowym wykonaj:
git init
git config user.name "Jan Kowalski"
git config user.email "jan (at) example.com"
Te ustawienia autora dotyczą bieżącego repozytorium i nie służą do logowania. Wybierz adres świadomie: dane autora są częścią commitów i mogą być widoczne dla innych po udostępnieniu historii.
Utwórz w edytorze plik README.md, wpisz krótki opis projektu i zapisz go. Następnie wykonaj:
git status
git add README.md
git diff --staged
git commit -m "Dodaj opis projektu"
git log --oneline
git status pokazuje stan plików. git add przygotowuje wskazaną treść do zapisu, a git diff --staged pozwala ją sprawdzić przed commitem. Ostatnie dwa polecenia zapisują etap pracy i wyświetlają skróconą historię.
Współpraca i ograniczenia Gita
Przy współpracy Git potrafi automatycznie połączyć wiele niezależnych zmian. Jeśli jednak dwie osoby zmienią ten sam fragment w niezgodny sposób, może wystąpić konflikt scalania. Trzeba wtedy ręcznie ustalić właściwą treść, oznaczyć rozwiązane pliki przez git add i dokończyć operację. Git nie ocenia, która wersja jest merytorycznie poprawna.
Do repozytorium nie należy dodawać haseł, kluczy dostępowych ani innych sekretów. Plik .gitignore określa, które nieśledzone pliki Git ma pomijać, ale nie usuwa danych już zapisanych w historii. Ujawniony klucz trzeba unieważnić lub wymienić; usunięcie go tylko z najnowszej wersji nie wystarcza.
Git nie zastępuje również pełnej kopii zapasowej: nie chroni automatycznie niezapisanych zmian ani plików poza repozytorium. Na początek przećwicz dwa commity w katalogu testowym i porównaj je poleceniem git diff HEAD~1 HEAD. Zobaczysz dokładnie, jak Git pokazuje różnice między zapisanymi etapami.
Zobacz też: Co to jest AGI?
Przeczytaj także
