System kontroli wersji to fundament nowoczesnego wytwarzania oprogramowania, bez którego trudno wyobrazić sobie pracę w większym zespole programistycznym. Git, stworzony przez Linusa Torvaldsa, zrewolucjonizował sposób, w jaki programiści współpracują nad kodem, wprowadzając model rozproszony, w którym każda kopia repozytorium jest pełnoprawnym archiwum całego projektu. Dzięki temu nawet całkowita awaria serwera centralnego nie powoduje utraty historii zmian. Platforma GitHub z kolei dodała do Gita warstwę społecznościową i narzędziową, umożliwiającą łatwe dzielenie się kodem i współpracę na niespotykaną dotąd skalę.

Podczas tego wykładu uczestnicy poznają nie tylko składnię komend Gita, lecz także filozofię stojącą za tym narzędziem, która opiera się na pojęciach takich jak nienaruszalność danych (ang. data integrity) i możliwość nielinearnego rozwoju projektu poprzez gałęzie. Zrozumienie tych koncepcji jest kluczowe, ponieważ pozwala programiście nie tylko używać Gita, ale też rozumieć, dlaczego działa on w określony sposób. Wiedza ta jest niezbędna już na pierwszym roku studiów informatycznych, ponieważ większość przedmiotów projektowych wymaga korzystania z systemu kontroli wersji.

Polecana literatura oraz zasoby Internetu

Ilustracja z folderem pełnym plików o nazwach typu projekt_final_v2_poprawiony_ostateczny.zip doskonale oddaje chaos, jaki panuje wśród osób niestosujących kontroli wersji. Taki ręczny system archiwizacji jest nie tylko podatny na błędy ludzkie, ale przede wszystkim całkowicie pozbawia programistę informacji kontekstowych. Po otwarciu takiego pliku po miesiącu nikt nie jest w stanie stwierdzić, co dokładnie zmieniono w danym wydaniu, dlaczego wprowadzono daną modyfikację i czy nie spowodowała ona regresji w innych częściach systemu.

Brak kontroli wersji prowadzi również do marnowania czasu na ręczne porównywanie plików oraz do sytuacji, w której ważna zmiana zostaje przypadkowo nadpisana. Programista musi polegać na własnej pamięci lub na komentarzach w kodzie, które często są nieaktualne lub wprowadzają w błąd. W środowisku akademickim problem ten jest szczególnie widoczny podczas realizacji większych projektów grupowych, gdzie bez kontroli wersji łatwo o utratę efektów pracy całego zespołu na kilka dni przed terminem oddania.

Praca zespołowa nad kodem bez systemu kontroli wersji to jedno z największych wyzwań w branży IT, potocznie określane mianem integracyjnego piekła. Każda próba ręcznego scalenia zmian wprowadzonych przez różne osoby kończy się zazwyczaj nadpisaniem czyjejś pracy lub powstaniem niespójności w kodzie, które są niezwykle trudne do wykrycia. Problemy te narastają wykładniczo wraz z liczbą osób pracujących nad tym samym projektem oraz z długością czasu, jaki upłynął od ostatniej synchronizacji.

Współczesne metodyki zwinne, takie jak Scrum czy Kanban, zakładają ciągłą integrację kodu (ang. Continuous Integration), która byłaby niemożliwa bez solidnego systemu kontroli wersji. Git radzi sobie z tym wyzwaniem, umożliwiając każdemu programiście pracę na własnej gałęzi (branch) i dostarczając mechanizmów do łączenia zmian, takich jak merge i rebase. Dzięki temu konflikty są wykrywane automatycznie na poziomie poszczególnych linii kodu, a nie całych plików, co znacznie ułatwia ich rozwiązywanie.

Systemy kontroli wersji (VCS) ewoluowały od prostych lokalnych rozwiązań, takich jak RCS (Revision Control System), przez scentralizowane systemy CVS i SVN (Subversion), aż po nowoczesne systemy rozproszone, jak Git i Mercurial. Każda z tych generacji wnosiła istotne usprawnienia, które odpowiadały na rosnące wymagania branży. Scentralizowane VCS rozwiązały problem współdzielenia kodu w zespole, ale wprowadziły pojedynczy punkt awarii oraz konieczność stałej łączności z serwerem.

Rozproszone systemy kontroli wersji, na czele z Gitem, całkowicie wyeliminowały te ograniczenia, ponieważ każda lokalna kopia repozytorium zawiera pełną historię projektu. Oznacza to, że programista może pracować w pełni offline, a jednocześnie ma dostęp do całej historii zmian, gałęzi i znaczników. Co więcej, Git stosuje kryptograficzne sumy kontrolne SHA-1 do identyfikacji każdego obiektu w repozytorium, co gwarantuje integralność danych i utrudnia nieautoryzowane modyfikacje historii.

Git został zaprojektowany przez Linusa Torvaldsa w 2005 roku z konkretnym celem: zastąpienie zastrzeżonego systemu BitKeeper, który był używany do zarządzania kodem źródłowym jądra Linux. Torvalds postawił przed sobą kilka kluczowych wymagań: szybkość operacji, wsparcie dla nieliniowego rozwoju (tysiące gałęzi), pełną dystrybucję oraz odporność na uszkodzenia danych. Już po kilku miesiącach pierwsza wersja Gita była gotowa i zaczęła być używana do zarządzania kodem jądra, co było najlepszym testem poprawności projektu.

Dziś Git jest standardem w branży IT, z którego według corocznych ankiet Stack Overflow korzysta ponad 90 procent profesjonalnych programistów. Jego popularność wynika nie tylko z funkcjonalności, ale również z ogromnego ekosystemu narzędzi i platform, które wokół niego powstały, w tym GitHub, GitLab, Bitbucket oraz niezliczonych integracji z systemami CI/CD, edytorami i środowiskami IDE. Umiejętność sprawnego posługiwania się Gitem jest obecnie jednym z podstawowych wymagań na większości stanowisk pracy w IT.

Rozproszony model kontroli wersji stosowany przez Gita radykalnie różni się od scentralizowanego modelu znanego z Subversion (SVN) czy CVS. W modelu scentralizowanym istniał jeden główny serwer przechowujący pełną historię, a programiści pobierali jedynie wybrane pliki. W przypadku awarii serwera historia projektu mogła zostać bezpowrotnie utracona, a praca zespołu zostawała zablokowana. Git odwraca tę logikę, czyniąc każdą lokalną kopię pełnoprawnym repozytorium.

Model rozproszony przynosi szereg praktycznych korzyści. Po pierwsze, każdy programista ma pełną kopię zapasową projektu, co zwiększa niezawodność całego systemu. Po drugie, większość operacji, takich jak przeglądanie historii, tworzenie gałęzi czy zatwierdzanie zmian, działa w pełni offline bez konieczności komunikacji z serwerem. Po trzecie, kopia zdalna (remote) pełni funkcję centralnego punktu wymiany, ale nie jest ani wymagana, ani jedynym autorytatywnym źródłem prawdy.

Proces instalacji Gita różni się w zależności od systemu operacyjnego, ale we wszystkich przypadkach jest prosty i dobrze udokumentowany. Na systemie Windows zaleca się pobranie oficjalnego instalatora z witryny git-scm.com, który oprócz samego Gita instaluje również emulator terminala Git Bash oraz graficzny interfejs Git GUI. Instalator pozwala na wybór różnych opcji konfiguracyjnych, takich jak domyślny edytor tekstu czy obsługa zakończeń linii (CRLF vs LF).

Na systemach Linux i macOS Git zazwyczaj jest dostępny w domyślnych repozytoriach pakietów. W przypadku Linuksa komenda sudo apt install git (dla dystrybucji bazujących na Debianie) lub sudo yum install git (dla Fedory i CentOS) załatwia sprawę w kilka sekund. Na komputerach Mac najwygodniejszym sposobem jest skorzystanie z menedżera pakietów Homebrew (brew install git). Po instalacji warto zawsze zweryfikować jej poprawność komendą git --version, która wyświetla numer zainstalowanej wersji.

Konfiguracja tożsamości w Gicie to jeden z najważniejszych kroków, który często jest pomijany przez początkujących. Bez ustawienia nazwy użytkownika i adresu e-mail Git nie pozwoli na utworzenie pierwszego zatwierdzenia, ponieważ każdy commit musi być jednoznacznie powiązany z konkretną osobą. Warto pamiętać, że flaga --global oznacza, iż konfiguracja zostanie zastosowana dla wszystkich repozytoriów na komputerze, ale zawsze można ją nadpisać dla konkretnego projektu, używając komendy bez tej flagi.

Oprócz tożsamości warto skonfigurować inne przydatne ustawienia, takie jak domyślny edytor (git config --global core.editor code --wait, aby używać Visual Studio Code) czy aliasy dla często używanych komend (git config --global alias.st status). Konfiguracja Gita jest przechowywana w pliku .gitconfig w katalogu domowym użytkownika i można ją w każdej chwili odczytać, modyfikować lub przenosić na inny komputer. W środowisku akademickim szczególnie ważne jest użycie prawdziwego imienia i nazwiska, aby prowadzący mógł jednoznacznie przypisać zmiany do konkretnego studenta.

Repozytorium Gita to w istocie zwykły folder na dysku, który zawiera dodatkowy podfolder o nazwie .git, przechowujący całą bazę danych obiektów Gita. Wewnątrz .git znajdują się między innymi katalogi objects (przechowujący wszystkie wersje plików i drzewa katalogów), refs (przechowujący wskaźniki do gałęzi i znaczników) oraz plik HEAD (wskazujący, na której gałęzi obecnie pracujemy). Cała ta struktura sprawia, że repozytorium Gita jest samodzielne i przenośne – wystarczy skopiować cały folder, aby otrzymać działające repozytorium.

Należy podkreślić, że folderu .git nie wolno modyfikować ręcznie ani usuwać, ponieważ zawiera on krytyczne dane o historii projektu. Standardowo folder ten jest ukryty w systemach Unix/Linux i Windows, co chroni go przed przypadkowym usunięciem przez użytkownika. Tworząc nowe repozytorium komendą git init, Git automatycznie tworzy strukturę katalogów i plików niezbędną do działania systemu, przygotowując folder na przyjęcie pierwszych plików projektu.

Komenda git init to jedna z najprostszych, a zarazem najważniejszych komend w Gicie. Po jej wykonaniu w bieżącym katalogu zostaje utworzona struktura .git, która inicjalizuje puste repozytorium gotowe do śledzenia zmian. Warto zwrócić uwagę, że git init można wywołać wielokrotnie w tym samym katalogu – jeśli repozytorium już istnieje, komenda po prostu zaktualizuje istniejące pliki bez niszczenia historii. Jest to przydatne na przykład po sklonowaniu repozytorium z pominięciem folderu .git.

Tworząc pierwsze repozytorium, warto od razu zadbać o odpowiednią organizację pracy. Przed wykonaniem git init należy utworzyć główny katalog projektu i zastanowić się nad strukturą plików. Dobrą praktyką jest również natychmiastowe utworzenie pliku README.md opisującego cel projektu oraz pliku .gitignore dostosowanego do używanego języka programowania. Dzięki temu pierwszy commit będzie zawierał kompletną i przemyślaną strukturę początkową.

Commit, nazywany po polsku zatwierdzeniem, jest podstawowym budulcem historii w Gicie. Każdy commit jest identyfikowany przez 40-znakowy skrót SHA-1, który jest kryptograficzną sumą kontrolną zawartości plików, metadanych (autor, data, opis) oraz identyfikatora rodzica, co tworzy łańcuch bloków. Dzięki tej konstrukcji modyfikacja dowolnego commita w przeszłości jest natychmiast wykrywalna, ponieważ zmieniłaby się suma kontrolna wszystkich następnych zatwierdzeń.

Tworzenie commitów wymaga przestrzegania pewnych dobrych praktyk, aby historia projektu była czytelna dla wszystkich członków zespołu. Przede wszystkim każdy commit powinien dotyczyć jednej logicznej zmiany i zawierać opis wyjaśniający, co zostało zrobione i dlaczego. W profesjonalnych projektach stosuje się różne konwencje nazewnictwa, takie jak Conventional Commits (np. feat: dodanie walidacji formularza, fix: naprawa błędu w logowaniu), które ułatwiają automatyczne generowanie dziennika zmian i określanie wersji semantycznej.

Staging area, nazywany również indeksem lub poczekalnią, to unikalna cecha Gita, która odróżnia go od większości innych systemów kontroli wersji. Obszar ten działa jak pośrednik między katalogiem roboczym (working directory) a repozytorium, umożliwiając programiście precyzyjne określenie, które zmiany mają zostać uwzględnione w następnym zatwierdzeniu. Dzięki temu można pracować nad kilkoma niezależnymi zadaniami jednocześnie, a następnie podzielić zmiany na osobne commity.

Mechanizm stagingu daje ogromną kontrolę nad procesem zatwierdzania. Programista może nie tylko wybrać, które pliki trafią do commita, ale również, które fragmenty wewnątrz pliku (git add -p, czyli patch mode). Jest to szczególnie przydatne, gdy w jednym pliku wprowadzono kilka niezależnych zmian, z których tylko część jest gotowa do zatwierdzenia. Umiejętne wykorzystanie staging area jest jedną z cech wyróżniających doświadczonych użytkowników Gita od początkujących.

Przykład pierwszego commita na slajdzie ilustruje klasyczny wzorzec pracy z Gitem, który będzie powtarzany wielokrotnie podczas każdej sesji programistycznej. Sekwencja git status - git add - git commit to podstawowy cykl, który powinien wejść w nawyk każdemu programiście. Warto zwrócić uwagę, że git status przed dodaniem pliku pokazuje go jako untracked, co oznacza, że Git widzi nowy plik, ale nie śledzi go jeszcze – konieczna jest jawna decyzja o rozpoczęciu śledzenia.

Po utworzeniu pierwszego commita warto sprawdzić, jak wygląda historia repozytorium za pomocą git log, która wyświetli pojedynczy wpis z identyfikatorem, autorem, datą i opisem. Dla początkującego studenta ważne jest zrozumienie, że każdy kolejny commit zostanie dodany do tej listy, tworząc liniową historię projektu. W razie pomyłki przy opisie commita można go poprawić komendą git commit --amend, ale należy pamiętać, że zmienia to identyfikator SHA-1 ostatniego zatwierdzenia.

Git status to komenda, której częstotliwość użycia w codziennej pracy programisty ustępuje prawdopodobnie tylko git add i git commit. Jej głównym zadaniem jest dostarczenie informacji o aktualnym stanie repozytorium, podzielonym na trzy kategorie: zmiany oczekujące na zatwierdzenie (staged), zmiany w katalogu roboczym nieprzygotowane do zatwierdzenia (unstaged) oraz pliki nieśledzone (untracked). Dzięki kolorowemu kodowaniu wyjścia (zielony dla staged, czerwony dla unstaged) stan repozytorium jest czytelny na pierwszy rzut oka.

Regularne sprawdzanie statusu repozytorium pomaga uniknąć wielu typowych błędów, takich jak przypadkowe zatwierdzenie niekompletnych zmian lub zapomnienie o dodaniu nowego pliku. W profesjonalnym środowisku programiści często używają aliasu git status -s (skrócona wersja) lub konfigurują wtyczki w edytorach, które pokazują status plików bezpośrednio w interfejsie IDE. Niezależnie od preferowanego narzędzia zrozumienie informacji zwracanych przez git status jest absolutną podstawą pracy z Gitem.

Komenda git add jest kluczowym narzędziem do zarządzania obszarem stagingu i wymaga zrozumienia różnych opcji, jakie oferuje. Najprostsza forma git add nazwa_pliku dodaje pojedynczy plik, podczas gdy git add . dodaje wszystkie zmiany z bieżącego katalogu i podkatalogów, ale nie obejmuje plików usuniętych. Z kolei git add -A (lub git add --all) dodaje wszystkie zmiany z całego repozytorium, w tym usunięcia i nowe pliki, niezależnie od bieżącej lokalizacji w terminalu.

Bardziej zaawansowani użytkownicy docenią opcję git add -p (interactive patch mode), która pozwala na przejrzenie każdej zmiany w pliku i podjęcie decyzji, czy ma ona trafić do stagingu. Jest to niezwykle przydatne, gdy w jednym pliku wprowadzono kilka niezależnych modyfikacji, z których tylko niektóre są gotowe do zatwierdzenia. W środowisku edukacyjnym warto uczyć studentów właśnie tej metody od początku, ponieważ kształtuje to dyscyplinę tworzenia czytelnej historii projektu.

Git commit to komenda finalizująca cykl pracy z Gitem, która przenosi zmiany z obszaru stagingu do repozytorium, tworząc nowy punkt w historii projektu. Podstawowa forma git commit -m opis wymaga podania krótkiego opisu, który powinien być sformułowany w trybie rozkazującym i odpowiadać na pytanie, co zmiana robi, a nie co zrobił programista. W przypadku większych zmian zaleca się pominięcie flagi -m, co spowoduje otwarcie domyślnego edytora i umożliwienie napisania dłuższego opisu z podziałem na tytuł i treść.

W ważnych projektach warto stosować konwencję Conventional Commits, która narzuca strukturę komunikatu: typ(scope): opis. Przykładowe typy to feat (nowa funkcjonalność), fix (naprawa błędu), docs (zmiana w dokumentacji) czy refactor (zmiana struktury kodu bez wpływu na działanie). Taka standaryzacja ułatwia automatyzację generowania dziennika zmian oraz automatyczne określanie numeru wersji projektu zgodnie z semantycznym versioningiem (SemVer).

Git log to niezwykle elastyczne narzędzie do przeglądania historii repozytorium, oferujące dziesiątki opcji formatowania i filtrowania. Domyślne wyjście pokazuje pełną listę commitów w kolejności odwrotnej chronologicznej, z identyfikatorem SHA-1, autorem, datą i opisem. Dla wygody warto zapamiętać git log --oneline, które wyświetla skróconą postać, oraz git log --graph, które dodaje graficzną reprezentację gałęzi i łączeń między commitami.

Git log oferuje również zaawansowane opcje filtrowania, takie jak git log --author=nazwa (commity danego autora), git log --since=2.weeks (commity z ostatnich dwóch tygodni) czy git log --grep=słowo (wyszukiwanie w opisach). Dla celów edukacyjnych warto zwrócić uwagę, że git log pokazuje historię bieżącej gałęzi, co oznacza, że po przejściu na inną gałąź zobaczymy inny zestaw commitów. Jest to kluczowe do zrozumienia przy pracy z gałęziami i łączeniem zmian.

Przedstawiony na slajdzie cykl pracy z Gitem to podstawowy workflow, który towarzyszy programiście podczas każdej sesji kodowania. Warto zwrócić uwagę, że cykl ten można rozszerzać o dodatkowe kroki w zależności od potrzeb, na przykład o przegląd zmian przed zatwierdzeniem (git diff) czy pobieranie aktualizacji ze zdalnego repozytorium (git pull). Zrozumienie tego podstawowego cyklu jest fundamentem, na którym buduje się bardziej zaawansowane techniki, takie jak rebasing, cherry-picking czy interactive staging.

W praktyce codzienna praca programisty rzadko ogranicza się do tych czterech kroków, ponieważ dochodzą elementy współpracy zespołowej: push, pull, rozwiązywanie konfliktów i code review. Niemniej jednak solidne opanowanie podstawowego cyklu edytuj-dodaj-zatwierdź jest warunkiem koniecznym przed przejściem do bardziej zaawansowanych zagadnień. W środowisku akademickim zaleca się wykonanie co najmniej kilkunastu powtórzeń tego cyklu na prostym projekcie, aby automatyzm stał się naturalny.

Praktyczny przykład z plikiem hello.py doskonale ilustruje ewolucję projektu w czasie i sposób, w jaki Git ją rejestruje. Pierwszy commit zawiera minimalną wersję programu z pojedynczym printem, co pokazuje, że zatwierdzenia nie muszą być duże ani skomplikowane. Drugi commit dodaje interakcję z użytkownikiem przez funkcję input, co jest naturalnym rozszerzeniem działania programu. Każdy z tych commitów jest samodzielny i można do niego wrócić w przyszłości.

Taki sposób pracy, w którym każdy commit reprezentuje krok w rozwoju aplikacji, jest kluczowy dla utrzymania czytelnej historii projektu. Gdyby obie zmiany zostały zatwierdzone w jednym commicie, trudniej byłoby zrozumieć, która konkretnie modyfikacja odpowiada za dodanie interaktywności. Co więcej, gdyby w drugiej zmianie pojawił się błąd, łatwiej byłoby go zlokalizować i wycofać, jeśli jest on w oddzielnym, małym commicie.

Git diff to narzędzie służące do szczegółowego porównywania różnych wersji plików w repozytorium, działające na zasadzie porównania linia po linii. Używana bez argumentów komenda git diff pokazuje różnice między katalogiem roboczym a obszarem stagingu, co pozwala sprawdzić, co zostało zmienione od ostatniego git add. Z kolei git diff --staged porównuje obszar stagingu z ostatnim zatwierdzeniem, co jest przydatne przed wykonaniem git commit do ostatecznej weryfikacji zbioru zmian.

Zrozumienie formatu wyjścia git diff jest ważne, ponieważ ten sam format jest używany w wielu innych kontekstach Gita, takich jak mergowanie czy code review na GitHubie. Linie poprzedzone znakiem minus (-) oznaczają usunięty tekst, a linie poprzedzone plusem (+) oznaczają dodany tekst. Nagłówki @@ wskazują, w których liniach pliku nastąpiła zmiana. Dla wygody warto również znać git diff --color-words, które pokazuje różnice na poziomie słów, a nie całych linii.

Plik .gitignore to jeden z pierwszych plików, które powinny trafić do nowego repozytorium, ponieważ chroni je przed zaśmieceniem plikami nieistotnymi z perspektywy projektu. Wzorce w .gitignore są wzorami dopasowującymi ścieżki, obsługującymi standardowe znaki specjalne, takie jak gwiazdka (*) oznaczająca dowolny ciąg znaków, znak zapytania (?) oznaczający pojedynczy znak oraz wykrzyknik (!) oznaczający wyjątek od reguły. Ignorowanie dotyczy zarówno plików już istniejących w katalogu roboczym, jak i tych, które pojawią się w przyszłości.

W przypadku różnych języków programowania i środowisk utrzymanie własnego .gitignore od zera może być uciążliwe, dlatego GitHub udostępnia gotowe szablony w repozytorium github/gitignore. Szablony te są dostosowane do konkretnych technologii i uwzględniają specyficzne dla nich wzorce, na przykład __pycache__/ dla Pythona, node_modules/ dla Node.js czy .idea/ dla IntelliJ IDEA. Dodatkowo podczas tworzenia nowego repozytorium GitHub oferuje wybór szablonu .gitignore, co znacząco ułatwia początkową konfigurację.

Git restore to nowoczesna komenda wprowadzona w Gicie 2.23, która zastępuje starsze i mniej intuicyjne komendy git checkout i git reset w kontekście cofania zmian w plikach. Należy wyraźnie rozróżniać dwie sytuacje: przywrócenie pliku w katalogu roboczym (git restore plik) powoduje bezpowrotne usunięcie lokalnych zmian, podczas gdy usunięcie pliku z obszaru stagingu (git restore --staged plik) zachowuje zmiany w katalogu roboczym, ale usuwa je z poczekalni. Różnica ta jest krytyczna dla bezpieczeństwa pracy.

Podczas korzystania z git restore należy zawsze upewnić się, jakie zmiany zostaną utracone. Warto przed wykonaniem tej komendy sprawdzić różnice poleceniem git diff, a w razie wątpliwości rozważyć wykonanie git stash, który tymczasowo odkłada zmiany na później, zamiast je usuwać. W kontekście edukacyjnym należy podkreślić, że usunięcie zmian w Gicie jest w większości przypadków operacją nieodwracalną, jeśli nie zostały one wcześniej zatwierdzone.

Częste i małe commity są jedną z najważniejszych dobrych praktyk w pracy z Gitem, ponieważ bezpośrednio wpływają na czytelność historii projektu i ułatwiają debugowanie. Gdy każde zatwierdzenie zawiera jedną konkretną zmianę, w przypadku wystąpienia błędu łatwo jest zidentyfikować commit, który go wprowadził, i w razie potrzeby go wycofać bez wpływu na inne funkcjonalności. Zasada ta jest szczególnie ważna w projektach zespołowych, gdzie każdy programista pracuje nad różnymi częściami systemu.

W praktyce oznacza to, że programista powinien zatwierdzać zmiany za każdym razem, gdy ukończy logicznie spójną jednostkę pracy, na przykład dodanie nowej funkcji, naprawienie błędu czy refaktoryzację metody. Nie ma sensu czekać z zatwierdzeniem do końca dnia czy tygodnia, ponieważ wtedy traci się możliwość precyzyjnego określenia, kiedy dana zmiana została wprowadzona. Częste commity to również naturalne punkty kontrolne, do których można wrócić w razie problemów.

Dobry opis zatwierdzenia to nie luksus, ale konieczność w profesjonalnym projekcie, która w długiej perspektywie oszczędza godziny pracy całego zespołu. Opis powinien odpowiadać na dwa podstawowe pytania: co zmieniono i dlaczego to zrobiono. Odpowiedzią na pierwsze pytanie jest krótki tytuł (do 50 znaków), który powinien być sformułowany w trybie rozkazującym, na przykład Popraw walidację adresu e-mail. Drugie pytanie wymaga dłuższego wyjaśnienia w głównej części opisu, oddzielonej pustą linią od tytułu.

Dla początkujących studentów przydatną wskazówką jest zasada, że opis commita powinien uzupełniać zdanie: Ten commit wprowadza... Przykładowo: Ten commit wprowadza walidację formatu e-mail w formularzu rejestracyjnym. Unikajmy natomiast niejasnych opisów, takich jak drobne poprawki czy update, które nie niosą żadnej informacji o charakterze zmiany. W profesjonalnych projektach często wymaga się, aby każdy commit był powiązany z konkretnym zgłoszeniem (issue) w systemie śledzenia błędów.

Slajd podsumowujący pierwszą część wykładu zbiera najważniejsze pojęcia związane z lokalną pracą w Gicie, które stanowią solidny fundament do dalszej nauki. Zrozumienie różnicy między katalogiem roboczym, obszarem stagingu a repozytorium jest kluczowe, ponieważ na tej różnicy opiera się cały model działania Gita. Wszystkie bardziej zaawansowane techniki, od gałęzi poprzez rebase aż po cherry-pick, bazują na tych samych mechanizmach wewnętrznych, które właśnie poznaliśmy.

Przed przejściem do części dotyczącej GitHuba warto upewnić się, że każdy student potrafi samodzielnie utworzyć repozytorium, dodać plik i zatwierdzić zmianę bez zaglądania do notatek. Te trzy czynności będą powtarzane dziesiątki razy podczas każdego projektu, dlatego muszą stać się nawykiem. W razie trudności zaleca się ćwiczenie na prostym projekcie osobistym, gdzie błędy nie będą miały poważnych konsekwencji.

GitHub to zdecydowanie więcej niż tylko hosting repozytoriów Git. Jest to platforma społecznościowa, która zrewolucjonizowała sposób, w jaki programiści współpracują i dzielą się kodem. Kluczowymi funkcjonalnościami są Pull Requesty do zgłaszania propozycji zmian, Issues do śledzenia błędów i zadań, GitHub Actions do automatyzacji procesów CI/CD, GitHub Pages do hostowania stron statycznych oraz Wiki do prowadzenia dokumentacji. Wszystkie te elementy tworzą ekosystem, który znacząco ułatwia zarządzanie cyklem życia oprogramowania.

Przejęcie GitHuba przez Microsoft w 2018 roku za 7,5 miliarda dolarów było szeroko komentowane w środowisku programistów, ale platforma zachowała swoją otwartość i neutralność wobec różnych technologii. Obecnie na GitHubie hostowane są setki milionów repozytoriów, w tym tak kluczowe projekty jak jądro Linuksa, TensorFlow, Kubernetes czy Visual Studio Code. Dla studentów kierunków IT GitHub jest nie tylko narzędziem pracy, ale także wizytówką zawodową i źródłem wiedzy o najlepszych praktykach programistycznych.

GitHub pełni kilka kluczowych funkcji w życiu programisty, z których najważniejszą jest rola cyfrowego portfolio. Rekruterzy i menedżerowie techniczni regularnie przeglądają profile kandydatów na GitHubie, szukając dowodów na praktyczne umiejętności programistyczne, styl kodowania oraz sposób współpracy z innymi. Aktywny profil z różnorodnymi projektami, regularnymi commitami i udziałem w projektach open source jest często cenniejszy niż formalne wykształcenie, szczególnie na początku kariery.

Z punktu widzenia inżynierii oprogramowania GitHub oferuje narzędzia, które są standardem w branży. Code review za pośrednictwem Pull Requestów, automatyczne testowanie z GitHub Actions, ochrona gałęzi (branch protection rules) oraz zarządzanie dostępem na poziomie zespołów to funkcje, które stosuje większość firm technologicznych. Dlatego znajomość GitHuba jest nie tyle opcjonalnym uzupełnieniem, ile wymogiem na większości stanowisk w IT.

Rejestracja na GitHubie jest bezpłatna i zajmuje zaledwie kilka minut, ale warto poświęcić chwilę na przemyślenie wyboru nazwy użytkownika, ponieważ będzie ona widoczna publicznie i stanie się częścią tożsamości zawodowej. Zaleca się użycie kombinacji imienia i nazwiska lub pseudonimu profesjonalnego, unikając niepoważnych czy kontrowersyjnych nazw. Darmowe konto oferuje nieograniczoną liczbę repozytoriów publicznych i prywatnych, co jest w pełni wystarczające do celów edukacyjnych i mniejszych projektów komercyjnych.

Po rejestracji warto od razu skonfigurować podstawowe elementy profilu: zdjęcie, krótki bio opisujący zainteresowania technologiczne, linki do stron prywatnych oraz ustawienia prywatności. Konto na GitHubie łączy się z możliwością korzystania z GitHub Pages do hostowania stron statycznych za darmo, co może być wykorzystane do publikacji portfolio, dokumentacji projektów czy nawet pełnowartościowych stron internetowych przy użyciu generatorów statycznych.

Wybór między repozytorium publicznym a prywatnym ma daleko idące konsekwencje prawne i organizacyjne, które wykraczają poza kwestię widoczności kodu. Repozytorium publiczne oznacza, że każdy może nie tylko przeglądać kod, ale również tworzyć jego kopie (forki) i zgłaszać propozycje zmian, co może być pożądane w projektach open source, ale nieakceptowalne w projektach komercyjnych zawierających poufne informacje biznesowe. Decyzja o ustawieniu repozytorium jako publicznego powinna być świadoma i poprzedzona wyborem odpowiedniej licencji.

Repozytoria prywatne na darmowym koncie umożliwiają zaproszenie wybranych współpracowników, co jest idealne do realizacji projektów grupowych w ramach zajęć akademickich. Warto wiedzieć, że zmiana widoczności repozytorium z prywatnego na publiczne (i odwrotnie) jest możliwa w ustawieniach projektu w każdej chwili. Należy jednak pamiętać, że zmiana z publicznego na prywatne nie usuwa forków, które zostały już utworzone przez innych użytkowników.

Proces tworzenia repozytorium na GitHubie jest intuicyjny, ale wymaga podjęcia kilku ważnych decyzji już na starcie. Po nadaniu nazwy, która powinna być krótka, opisowa i zgodna z konwencją kebab-case (małe litery, myślniki zamiast spacji), należy zdecydować o widoczności i ewentualnie skonfigurować opcje początkowe. Zaznaczenie opcji Initialize this repository with a README tworzy plik README.md, co jest wygodne, ale uniemożliwia późniejsze połączenie z istniejącym lokalnym repozytorium poprzez git push.

Po utworzeniu repozytorium GitHub wyświetla instrukcje konfiguracyjne, które są dostosowane do różnych scenariuszy: utworzenie nowego repozytorium lokalnego, połączenie z istniejącym projektem lokalnym lub import z innego systemu kontroli wersji. Dla studentów szczególnie ważny jest scenariusz drugi, ponieważ większość projektów akademickich zaczyna się od pracy lokalnej, a dopiero później wymagane jest wysłanie jej na GitHub w celu oceny.

Plik README.md jest najważniejszym plikiem w każdym repozytorium, ponieważ to właśnie jego zawartość wyświetla się na stronie głównej projektu na GitHubie jako wizytówka i pierwsze źródło informacji dla odwiedzających. Dobrze napisany README powinien odpowiadać na pytania: czym jest projekt, jak go zainstalować i skonfigurować, jak go używać oraz jak można wnieść własny wkład. Format Markdown, w którym tworzy się README, jest prosty do nauczenia, a jednocześnie wystarczająco elastyczny, aby tworzyć czytelne i estetyczne dokumenty.

Tworząc README, warto wzorować się na najlepszych projektach open source, które często zawierają sekcje z odznakami (badges) informującymi o statusie testów, licencji czy wersji projektu. GitHub natywnie renderuje również diagramy Mermaid, tabele, listy kontrolne (task lists) oraz emoji, co pozwala na tworzenie atrakcyjnych wizualnie dokumentacji. Dla projektów akademickich README powinien zawierać również informację o autorze, celu projektu oraz wymaganiach technicznych.

Git clone to komenda, która tworzy lokalną kopię zdalnego repozytorium wraz z pełną historią wszystkich gałęzi i znaczników. Pod maską git clone wykonuje kilka operacji: tworzy nowy katalog, inicjalizuje w nim repozytorium (git init), dodaje zdalne repozytorium jako origin (git remote add), pobiera wszystkie obiekty (git fetch) i na koniec przełącza się na domyślną gałąź (git checkout). Dzięki temu po zakończeniu klonowania użytkownik ma pełnoprawną kopię projektu gotową do pracy.

Wybór protokołu przy klonowaniu ma znaczenie praktyczne. URL HTTPS jest prostszy w konfiguracji, ale wymaga podania tokena przy każdej operacji push, chyba że skonfiguruje się menedżer poświadczeń. URL SSH jest bezpieczniejszy i wygodniejszy po wstępnej konfiguracji kluczy, ale wymaga wygenerowania pary kluczy i dodania klucza publicznego do konta GitHub. Na uczelniach, gdzie komputery są współdzielone, wygodniejszym rozwiązaniem jest zwykle HTTPS z tokenem dostępowym.

Pojęcie remote (zdalnego repozytorium) jest fundamentem współpracy zespołowej z Gitem, ponieważ to właśnie przez zdalne repozytoria programiści wymieniają się zmianami. Domyślna nazwa origin jest konwencją, ale możemy mieć wiele remotów o różnych nazwach, co jest przydatne na przykład w modelu fork-and-pull, gdzie origin to nasz fork na GitHubie, a upstream to oryginalne repozytorium projektu. Sprawdzenie konfiguracji remotów komendą git remote -v powinno być regularnie wykonywane, szczególnie po sklonowaniu repozytorium.

Operacje na remotach nie są ograniczone do push i pull. Git umożliwia również dodawanie nowych remotów (git remote add), usuwanie niepotrzebnych (git remote remove), zmianę adresu URL (git remote set-url) oraz pobieranie informacji o zdalnych gałęziach (git remote show). Zrozumienie zarządzania remotami jest szczególnie ważne w projektach open source, gdzie często współpracuje się z wieloma forkami tego samego repozytorium.

Git push to komenda, która wysyła lokalne zatwierdzenia do zdalnego repozytorium, ale jej działanie jest często źle rozumiane przez początkujących. Push nie wysyła plików ani katalogu roboczego, a jedynie obiekty Gita (commity, drzewa, bloby) oraz aktualizuje referencje w zdalnym repozytorium. Oznacza to, że jeśli mamy niezapisane zmiany w katalogu roboczym, push ich nie wyśle – trzeba najpierw zatwierdzić je lokalnie. Opcja -u (--set-upstream) ustawia powiązanie między lokalną a zdalną gałęzią, co upraszcza kolejne wywołania do zwykłego git push.

Przed wykonaniem pusha należy upewnić się, że nasze lokalne repozytorium jest aktualne względem zdalnego, ponieważ Git nie pozwoli na wysłanie zmian, jeśli zdalna gałąź zawiera zatwierdzenia, których nie mamy lokalnie. W takiej sytuacji konieczne jest najpierw pobranie i scalenie zmian (git pull), a dopiero potem wysłanie własnych. Jest to jeden z najczęstszych problemów napotykanych podczas pierwszych prób pracy zespołowej z Gitem.

Git pull to komenda, która łączy w sobie dwie operacje: git fetch (pobranie zmian ze zdalnego repozytorium) oraz git merge (scalenie ich z bieżącą gałęzią). Warto zrozumieć tę dwuetapowość, ponieważ w niektórych sytuacjach warto wykonać fetch ręcznie, aby zobaczyć, jakie zmiany są dostępne, zanim zdecydujemy się je scalić. Git pull jest najbezpieczniejszy, gdy pracujemy na gałęzi, nad którą nikt inny nie pracuje, lub gdy mamy pewność, że scalenie nie spowoduje konfliktów.

W niektórych środowiskach pracy zaleca się używanie git pull --rebase zamiast zwykłego git pull. Opcja ta zmienia sposób integracji zmian: zamiast tworzyć dodatkowy commit scalający (merge commit), przepisuje historię, umieszczając nasze lokalne zatwierdzenia na końcu pobranych zmian. Dzięki temu historia pozostaje liniowa i czytelniejsza, ale należy używać tej opcji ostrożnie, ponieważ zmienia ona identyfikatory SHA lokalnych commitów.

Przedstawiony na slajdzie workflow to podstawowy cykl pracy z Gitem i GitHubem, który stosuje się zarówno w jednoosobowych projektach, jak i w profesjonalnych zespołach. Kluczowym elementem jest sekwencja pull - add - commit - push, która zapewnia, że przed rozpoczęciem pracy mamy najnowszą wersję kodu, a po zakończeniu nasze zmiany są dostępne dla reszty zespołu. W projektach zespołowych często dodaje się jeszcze krok code review przez Pull Request, który odbywa się pomiędzy push a ostatecznym zatwierdzeniem do głównej gałęzi.

Warto zaznaczyć, że git pull na początku i git push na końcu to para, której nie wolno rozdzielać. Pominięcie pulla przed rozpoczęciem pracy zwiększa ryzyko konfliktów, szczególnie jeśli inni członkowie zespołu wprowadzili zmiany w tych samych plikach. Z kolei pominięcie pusha po zatwierdzeniu zmian oznacza, że nasza praca jest dostępna tylko lokalnie i nie jest chroniona przed utratą w przypadku awarii komputera.

Scenariusz dodania istniejącego lokalnego projektu do GitHuba jest bardzo częsty, zwłaszcza w środowisku akademickim, gdzie studenci często rozpoczynają pracę lokalnie, a dopiero później dowiadują się o konieczności umieszczenia projektu na platformie. Kluczową różnicą w stosunku do klonowania jest to, że nie możemy mieć konfliktu początkowych commitów, dlatego repozytorium na GitHubie musi być puste, bez pliku README, .gitignore czy licencji.

Sekwencja komend do dodania istniejącego projektu jest dobrze znana: najpierw łączymy lokalne repozytorium ze zdalnym (git remote add origin URL), następnie upewniamy się, że główna gałąź nazywa się main (git branch -M main), a na koniec wysyłamy historię (git push -u origin main). W przypadku, gdy zdalne repozytorium nie jest puste, konieczne będzie użycie git pull --rebase origin main przed pushem, aby zintegrować istniejące zmiany.

Personal Access Token (PAT) to obecnie rekomendowany sposób uwierzytelniania w GitHubie, który zastąpił tradycyjne hasła w dostępie przez HTTPS. Tokeny są bezpieczniejsze od haseł, ponieważ można im nadać precyzyjnie określone uprawnienia (scope) i w każdej chwili je unieważnić bez zmiany hasła głównego. Podczas generowania tokena w ustawieniach developera wybieramy odpowiednie zakresy: repo do pełnego dostępu do repozytoriów, read:packages do odczytu pakietów, a write:packages do publikacji pakietów.

Po wygenerowaniu tokena należy go natychmiast skopiować i przechować w bezpiecznym miejscu, ponieważ GitHub nie pokaże go ponownie. Token można przechowywać w menedżerze haseł systemu operacyjnego lub w pliku konfiguracyjnym Gita za pomocą git credential-store. W środowisku akademickim zaleca się utworzenie tokena z minimalnymi uprawnieniami i ustawienie daty ważności na okres trwania kursu, co zwiększa bezpieczeństwo w przypadku wycieku danych.