Wiedza · 5 min czytania

GitHub co to jest: sejf na projekt zbudowany z AI

GitHub co to jest w praktyce: kopia zapasowa projektu, historia zmian i cofanie po nieudanym promptcie. Trzy komendy, darmowy plan, realne pułapki.

Adrian Serafin

GitHub to miejsce w chmurze, w którym trzymasz kopię swojego projektu razem z całą historią zmian. Nie jest to edytor kodu ani hosting strony. To magazyn wersji: każda zapisana zmiana zostaje na zawsze i w każdej chwili możesz do niej wrócić. Jeśli budujesz coś z pomocą AI i boisz się, że jeden nieudany prompt rozwali działającą aplikację, właśnie po to jest GitHub.

Poradniki, na które najczęściej trafisz, tłumaczą GitHuba przyszłym programistom: portfolio dla rekrutera, praca zespołowa, gałęzie, scalanie. To wszystko prawda i to wszystko jest Ci na starcie niepotrzebne. Ten tekst jest o czymś innym: o tym, co GitHub daje osobie, która nie pisze kodu ręcznie, tylko rozmawia z modelem i chce mieć pewność, że nie straci wieczoru pracy.

Git to mechanizm, GitHub to miejsce

Te dwie nazwy myli się nagminnie, więc rozdzielmy je raz. Git to program, który działa na Twoim komputerze i pilnuje historii plików w folderze z projektem. GitHub to serwis, na który tę historię wysyłasz, żeby istniała też poza Twoim laptopem.

Praktyczna różnica jest taka: Git chroni Cię przed złą zmianą, GitHub chroni Cię przed utratą komputera. Jedno bez drugiego jest połową zabezpieczenia.

Repozytorium (skrót: repo) to po prostu jeden projekt na GitHubie: folder z plikami plus wszystkie jego wcześniejsze stany. Jedna aplikacja, jedna strona, jeden pomysł, jedno repo.

Git odpowiada na pytanie „jak to wyglądało wczoraj”, GitHub na pytanie „gdzie to jest, gdy laptop przestaje się włączać”.

Do czego służy GitHub, gdy kod pisze za Ciebie AI

Pytanie „do czego służy GitHub” ma dla Ciebie inną odpowiedź niż dla studenta informatyki. Kiedy pracujesz z asystentem w stylu Claude Code, przez godzinę potrafisz wygenerować kilkanaście zmian w kilkunastu plikach. Nie masz pojęcia, która z nich zepsuła logowanie.

GitHub rozwiązuje dokładnie ten problem, dając Ci cztery rzeczy:

  • Punkt cofnięcia. Zapisujesz stan, w którym wszystko działa. Po nieudanej serii promptów wracasz do niego jedną komendą, którą AI napisze za Ciebie.
  • Kopię poza komputerem. Kradzież laptopa, awaria dysku, przypadkowe skasowanie folderu przestają być katastrofą.
  • Historię „co się zmieniło”. Widzisz, które linijki doszły, a które zniknęły, plik po pliku. Ta funkcja nazywa się diff, czyli porównanie wersji, i pod tym słowem znajdziesz ją w interfejsie.
  • Adres, który podajesz innym narzędziom. Większość usług do publikacji strony pyta o repozytorium na GitHubie i po podłączeniu wypuszcza nową wersję po każdej Twojej zmianie.

Ten ostatni punkt jest niedoceniany. Dla wielu osób GitHub to nie jest wybór, tylko warunek wstępny: bez repozytorium po prostu nie da się wygodnie opublikować projektu w sieci.

Trzy komendy, które wystarczą na pierwsze pół roku

GitHub dla początkujących wygląda groźnie, bo dokumentacja opisuje kilkadziesiąt operacji. Pracując sam nad jednym projektem, używasz trzech. Poniżej po ludzku, co robią.

KomendaCo realnie robiKiedy jej używasz
commitZapisuje stan projektu w historii, z krótkim opisemZawsze, gdy coś zaczęło działać
pushWysyła zapisane stany z komputera na GitHubaNa koniec sesji pracy albo po ważnej zmianie
pullŚciąga najnowszą wersję z GitHuba na komputerGdy siadasz do projektu na drugim urządzeniu

Analogia z grą jest tu uczciwa: commit to zapis stanu gry, push to przeniesienie zapisu do chmury, pull to wczytanie go na innym sprzęcie. Gałęzie i propozycje zmian, podpisane na ekranie jako branch i pull request, przydają się dopiero wtedy, gdy nad jednym projektem pracują dwie osoby albo gdy testujesz ryzykowny pomysł obok wersji produkcyjnej.

Nie musisz uczyć się ich składni na pamięć. Prosisz asystenta: „zapisz obecny stan z opisem: działający formularz kontaktowy i wyślij na GitHuba”. On wykonuje komendy, Ty rozumiesz, co się właśnie stało. Ta różnica, rozumieć bez zapamiętywania, jest sednem podejścia opisanego w tekście o vibe codingu.

Ile to kosztuje i skąd bierze się mit o płatnych repozytoriach

Dla Twojego zastosowania GitHub jest darmowy i to nie jest wersja okrojona do trzech projektów. Plan Free dla konta osobistego obejmuje nieograniczoną liczbę repozytoriów publicznych i prywatnych oraz nieograniczoną liczbę współpracowników, co GitHub opisuje w dokumentacji swoich planów.

Mit „prywatne repozytoria są płatne” pochodzi z czasów sprzed zmiany, w której podstawowe funkcje serwisu udostępniono wszystkim za darmo, co opisuje oficjalne FAQ o zmianach w planach. Starsze polskie poradniki wciąż powielają starą wersję.

Automatyzacje na standardowych maszynach są darmowe, bez limitu minut, dla repozytoriów publicznych, a limity i dopłaty dotyczą prywatnych, co GitHub tłumaczy w opisie rozliczeń GitHub Actions.

Realnie: budując stronę firmową albo prosty produkt w pojedynkę, nie zobaczysz żadnego rachunku. Rachunek pojawia się dopiero przy intensywnych automatyzacjach w prywatnych repozytoriach.

Copilot to osobny produkt i osobny rachunek

Na GitHubie znajdziesz też Copilota, czyli asystenta AI. To nie jest część planu Free w pełnym zakresie i ma własny cennik, niezależny od tego, że repozytoria masz za darmo.

Świadomie nie podaję tu kwot ani szczegółów rozliczeń. Warunki bywają zmieniane, a informacja o cenie jest tym rodzajem twierdzenia, które starzeje się najszybciej i najbardziej boli, gdy jest nieaktualne. Przed zakupem sprawdź aktualny stan na stronie planów Copilota. Jest tam też wymieniony darmowy wariant, więc możesz zobaczyć, jak narzędzie działa, przed jakąkolwiek decyzją o płaceniu.

Jedno przy okazji: samo zdanie „Copilot kosztuje tyle a tyle miesięcznie” bywa mylące bez dopowiedzenia, jaki zakres korzystania mieści się w abonamencie i co się dzieje, gdy go przekroczysz. To pytanie warto zadać przed kliknięciem zakupu, niezależnie od tego, jaka liczba widnieje na stronie w dniu, w którym ją czytasz.

Co w GitHubie irytuje i dla kogo to nie ma sensu

Byłoby nieuczciwe napisać, że wchodzi się w to gładko. Interfejs jest zaprojektowany dla ludzi, którzy znają żargon, więc pierwsze tygodnie to zgadywanie, co znaczy połowa przycisków. Komunikaty o błędach potrafią zajmować dwadzieścia linijek i nie mówić wprost, co zrobić.

Najdroższa pomyłka początkującego nie ma jednak nic wspólnego z żargonem: to wysłanie na GitHuba plików z kluczami API albo hasłami do bazy. W repozytorium publicznym takie dane widzi każdy i bywają znajdowane bardzo szybko, a za cudze zużycie Twojego klucza rachunek dostajesz Ty. Dlatego przed pierwszym push sprawdź, czy w projekcie nie ma pliku z hasłami, i wyklucz go z wysyłki. Późniejsze usunięcie pliku nie wystarcza, bo w historii zmian zostaje jego stara wersja: klucz trzeba unieważnić i wygenerować nowy.

Zdarzy Ci się też zablokować na konflikcie, czyli sytuacji, gdy dwie wersje pliku nie dają się połączyć automatycznie. Pracując sam, trafisz na to rzadko, ale gdy trafisz, stracisz na tym pół godziny i sporo nerwów.

GitHub nie ma sensu, jeśli Twój projekt to jedna strona zrobiona w gotowym kreatorze, który sam trzyma wersje. Wtedy dokładasz sobie warstwę bez zysku.

Skala serwisu i jedno zastrzeżenie o mnie

Warto znać kontekst: GitHub przekroczył 180 milionów deweloperów, przybyło ponad 36 milionów kont w ciągu roku, a TypeScript wyprzedził Pythona i JavaScript jako najczęściej używany język, co pokazuje raport Octoverse 2025. Ten sam raport wiąże skok rejestracji z udostępnieniem darmowego Copilota, więc znaczna część nowych kont to nie nowi programiści, tylko ludzie tacy jak Ty.

Serwis należy do Microsoftu, który ogłosił przejęcie 4 czerwca 2018 roku za 7,5 miliarda dolarów w akcjach, według komunikatu Microsoftu. Zastrzeżenie: prowadzę kurs o pracy z Claude Code, więc mam interes w tym, żebyś wszedł w to podejście. Dlatego staram się pisać też o rzeczach, które w nim uwierają, i uczciwie powiedzieć, że jeśli Twój projekt to jedna prosta strona, spokojnie możesz się bez tego obejść.

Konkretny następny krok: załóż darmowe konto, wrzuć do niego projekt, który już masz na dysku, i zapisz jego stan zanim wpiszesz kolejny prompt. Pierwszy raz, gdy jedną komendą wrócisz do wersji sprzed nieudanej zmiany, przestaniesz traktować GitHuba jak narzędzie programistów, a zacznie być po prostu Twoim przyciskiem cofania. Jeśli dopiero zaczynasz, zacznij od pierwszej działającej wersji aplikacji i podłącz repozytorium od razu, a nie po tygodniu.