Co to jest GitHub?

Autor: Opublikowano

W skrócie: GitHub to platforma internetowa do przechowywania projektów, śledzenia zmian i współpracy nad kodem oraz dokumentacją. Korzysta z Gita — systemu, który zapisuje historię zmian w plikach. Możesz używać GitHuba do własnych projektów, pracy zespołowej albo zgłaszania błędów w cudzych programach; nie musisz od razu znać poleceń terminala.

GitHub a Git — czym się różnią?

Git to system kontroli wersji, czyli narzędzie pozwalające zapisywać kolejne stany projektu, porównywać zmiany i wracać do wcześniejszych wersji. Działa lokalnie na komputerze i nie wymaga konta w żadnej usłudze internetowej. Zamiast tworzyć foldery „projekt-finalny” i „projekt-finalny-poprawiony”, zapisujesz zmiany wraz z opisem.

GitHub to usługa wykorzystująca Gita, która dodaje wspólne miejsce na projekt, przeglądanie kodu, dyskusje i zarządzanie dostępem. GitHub i Git nie są więc dwiema nazwami tego samego narzędzia. Z Gita można korzystać bez GitHuba, również z innymi platformami, takimi jak GitLab czy Bitbucket.

Podstawowym miejscem pracy jest repozytorium: zbiór plików projektu wraz z historią zmian. Repozytorium na GitHubie może być publiczne, czyli widoczne dla wszystkich, albo prywatne, dostępne tylko dla uprawnionych osób. Prywatność nie zastępuje jednak zasad bezpiecznego przechowywania danych.

Do czego służy GitHub w praktyce?

Najczęściej GitHub służy do pracy nad oprogramowaniem, ale można w nim przechowywać również dokumentację, materiały szkoleniowe czy pliki tekstowe strony internetowej. Szczególnie dobrze sprawdza się przy treściach, w których przydatne jest porównywanie zmian linia po linii. Jest mniej wygodny jako zwykły magazyn dużych filmów, zdjęć lub dokumentów wymagających edycji w pakiecie biurowym.

Platforma pomaga wykonywać kilka powiązanych zadań:

GitHub Pages nie jest uniwersalnym hostingiem aplikacji z bazą danych i kodem wykonywanym po stronie serwera. Samo umieszczenie projektu w repozytorium również nie oznacza, że aplikacja zacznie działać pod publicznym adresem — do tego potrzebne jest jej uruchomienie w odpowiednim środowisku.

Jak wygląda współpraca nad zmianami?

Wyobraź sobie zespół prowadzący stronę firmową. Jedna osoba poprawia formularz kontaktowy, a druga zmienia cennik. Obie mogą pracować na osobnych gałęziach (branches), czyli równoległych liniach rozwoju projektu, bez natychmiastowego zmieniania jego głównej wersji.

Zmiany zapisuje się w commitach. Commit to zapis stanu projektu z informacją o autorze i opisem, na przykład „Popraw walidację adresu e-mail”. Dobrze opisane, niewielkie commity ułatwiają później zrozumienie, skąd wzięła się konkretna poprawka.

Gdy formularz jest gotowy, autor otwiera pull request, czyli propozycję połączenia zmian z wybraną gałęzią, zwykle główną. Pozostali widzą różnice, mogą dodać komentarze i sprawdzić wyniki testów. Po przeglądzie zmiany można połączyć — to operacja nazywana merge.

Jeżeli dwie osoby zmienią ten sam fragment w różny sposób, może powstać konflikt. Git nie zawsze potrafi rozstrzygnąć go automatycznie: człowiek musi zdecydować, która wersja lub jakie połączenie wersji jest poprawne. Platforma wspiera współpracę, ale nie zastępuje oceny jakości kodu.

Jak zacząć bez znajomości terminala?

Do przeglądania publicznych repozytoriów zazwyczaj nie potrzebujesz konta. Konto przydaje się, gdy chcesz tworzyć własne projekty, komentować lub zgłaszać problemy. Pierwsze repozytorium możesz przygotować w przeglądarce:

  1. Utwórz konto i włącz uwierzytelnianie dwuskładnikowe, czyli dodatkowe potwierdzenie logowania.
  2. Wybierz utworzenie repozytorium, nadaj mu nazwę i świadomie ustaw widoczność.
  3. Dodaj plik README.md — opis projektu, widoczny na głównej stronie repozytorium. Rozszerzenie .md oznacza Markdown, prosty sposób formatowania tekstu.
  4. Zapisz krótką informację o celu projektu i zatwierdź ją jako commit.
  5. Utwórz gałąź, popraw opis i otwórz pull request, aby przećwiczyć przeglądanie różnic.

Do wygodniejszej pracy z plikami na komputerze możesz później wykorzystać GitHub Desktop, graficzną aplikację obsługującą typowe operacje Gita. Klonowanie repozytorium tworzy lokalną kopię wraz z historią; pobranie archiwum ZIP daje pliki, ale nie przygotowuje kopii do pracy z historią Gita.

Na co uważać przed publikacją projektu?

Nie zapisuj w repozytorium haseł, kluczy API ani danych klientów. Usunięcie sekretu z aktualnego pliku nie usuwa go automatycznie z wcześniejszych commitów. Jeśli klucz został ujawniony, trzeba go przede wszystkim unieważnić lub wymienić, a następnie uporządkować historię i sprawdzić skutki wycieku.

Publiczny kod nie oznacza automatycznie zgody na dowolne wykorzystanie. Sprawdź plik licencji, często nazwany LICENSE, oraz warunki używanych zależności. To ogólna wskazówka, nie indywidualna porada prawna; brak licencji nie jest równoznaczny z brakiem praw autorskich.

GitHub oferuje funkcje bezpłatne i płatne. Przed wdrożeniem zespołowym sprawdź w oficjalnym cenniku oraz dokumentacji aktualne limity automatyzacji, przestrzeni i funkcji danego planu.

Na początek załóż prywatne repozytorium z przykładowym README i przeprowadź jedną zmianę przez gałąź oraz pull request. Poznasz podstawowy sposób pracy bez publikowania rzeczywistego kodu lub danych.

Zobacz też: Co to jest 2FA?

Przeczytaj także

Co to jest PHP-FPM?
Dowiedz się, jak PHP-FPM obsługuje żądania PHP, czym różni się od serwera WWW i jak dobrać ustawienia procesów do ruchu oraz zasobów hostingu.
Co to jest BIND?
Poznaj BIND, otwarte oprogramowanie serwera DNS: sprawdź, jak obsługuje domeny, czym różnią się jego role i kiedy warto samodzielnie go wdrożyć.
Co to są Security Headers?
Poznaj najważniejsze Security Headers, ich rolę w ochronie strony oraz sposób sprawdzania i wdrażania nagłówków bez blokowania potrzebnych funkcji.