Pytanie o to, jak korzystać z gita w projekcie, wraca za każdym razem, gdy do repozytorium dołącza nowa osoba albo gdy zespół przekracza próg pięciu programistów. Git sam w sobie jest tylko narzędziem — rozproszonym systemem kontroli wersji, który zapisuje migawki katalogu roboczego — ale sposób, w jaki go używasz, decyduje o tym, czy wdrożenie na produkcję zajmie cztery minuty, czy cztery godziny. W praktyce chodzi o trzy rzeczy: przewidywalny model gałęzi, czytelną historię commitów i automatyzację, która sama pilnuje jakości. Ten przewodnik pokazuje konkretne komendy, konfiguracje i liczby: ile kosztuje prywatne repozytorium, jak długo trwa klonowanie projektu o wadze 2 GB i dlaczego pliki .env nigdy nie powinny trafić do indeksu. Pokażę też fragmenty ustawień, które w małych zespołach eliminują większość konfliktów scalania, zanim ktokolwiek otworzy pull request.
Jak korzystać z gita w projekcie: konfiguracja startowa
Zanim powstanie pierwszy commit, ustaw tożsamość autora i sposób obsługi końców linii. Polecenia git config –global user.name oraz user.email zapisują dane w każdym commicie i nie da się ich później podmienić bez przepisywania historii. Na Windowsie dodaj core.autocrlf=true, na Linuksie i macOS wartość input — to jedna komenda, która kasuje setki fałszywych zmian w diffach.
Drugi krok to plik .gitignore, przygotowany zanim ktokolwiek uruchomi npm install czy composer install. Katalogi node_modules, vendor, build oraz pliki .env, .idea i .DS_Store nie mają czego szukać w repozytorium. Dobrze skonstruowany .gitignore potrafi zmniejszyć rozmiar projektu z 800 MB do 12 MB i skrócić czas klonowania o kilkadziesiąt sekund.
Trzecia decyzja dotyczy miejsca przechowywania repozytorium. GitHub Team, GitLab Premium i Bitbucket Standard mieszczą się w widełkach mniej więcej 15–80 zł miesięcznie za użytkownika, a własny Gitea albo Forgejo na małym serwerze kosztuje kilkanaście złotych miesięcznie za całą instancję. Wybór zależy od tego, czy potrzebujesz gotowego CI, czy tylko zdalnego magazynu kodu.
- git init — inicjalizacja repozytorium w istniejącym katalogu projektu
- git remote add origin — podpięcie zdalnego serwera do lokalnej kopii
- git status –short — szybki podgląd zmian bez ściany tekstu
- git log –oneline –graph –all — wizualizacja gałęzi w terminalu
- git config –global pull.rebase true — brak śmieciowych commitów typu Merge branch main
Klonowanie dużego repozytorium
Projekt z dziesięcioletnią historią i binariami potrafi ważyć 2–4 GB, a pełne git clone na łączu 50 Mb/s zajmie kilkanaście minut. Jeśli transfer trwa dłużej, sprawdź, jak sprawdzić prędkość internetu rzetelnie: pomiar w kablu, o różnych porach dnia, na serwerze w tym samym kraju. Warto też wiedzieć, jak wzmocnić sygnał WiFi w domu, bo słaby link psuje każdy push.
Model gałęzi: trunk based development kontra git flow
Git flow ze stałymi gałęziami develop, release i hotfix sprawdza się przy oprogramowaniu wydawanym w wersjach — desktopowych aplikacjach, urządzeniach, systemach z długim cyklem QA. Cena jest jednak wysoka: kod czeka na scalenie tygodniami, a konflikty rosną wykładniczo wraz z liczbą równoległych gałęzi funkcjonalnych utrzymywanych przez zespół.
Trunk based development odwraca logikę. Każdy pracuje na krótkiej gałęzi żyjącej maksymalnie dwa dni, scala do main za pomocą pull requesta i chowa niedokończone funkcje za flagami. Zespoły stosujące ten model wdrażają nawet kilkanaście razy dziennie, bo różnica między gałęzią a produkcją nigdy nie przekracza kilkuset linii kodu.
Trzecia opcja to model uproszczony: main jako produkcja i gałęzie feature/nazwa-zadania z numerem zgłoszenia z systemu ticketów. Dla dwu- lub trzyosobowego zespołu prowadzącego serwis firmowy albo sklep to zwykle najrozsądniejszy kompromis między porządkiem a narzutem administracyjnym, którego nikt nie chce obsługiwać.
| Model | Żywotność gałęzi | Częstotliwość wdrożeń | Dla kogo |
|---|---|---|---|
| Trunk based | do 2 dni | kilka razy dziennie | SaaS, aplikacje webowe |
| Git flow | 2–6 tygodni | raz na sprint | oprogramowanie wersjonowane |
| GitHub flow | 2–5 dni | kilka razy w tygodniu | małe zespoły produktowe |
| Model uproszczony | 1–7 dni | na żądanie klienta | agencje, serwisy firmowe |
Commity, pull requesty i czytelna historia
Commit powinien opisywać jedną zmianę i dać się cofnąć bez efektów ubocznych. Wiadomość „poprawki” po pół roku nie znaczy nic, natomiast „fix: pusty koszyk po wygaśnięciu sesji, zamyka #412″ prowadzi wprost do kontekstu. Zasada praktyczna: jeśli w opisie pojawia się spójnik „oraz”, masz do czynienia z dwoma commitami.
Pull request to miejsce, gdzie dzieje się realna kontrola jakości. Zmiana obejmująca do 400 linii jest recenzowana rzetelnie, powyżej tysiąca — recenzent klika akceptuj i idzie dalej. Ustaw wymóg jednej zatwierdzającej opinii, blokadę scalania przy czerwonym pipeline i automatyczne usuwanie gałęzi po scaleniu.
Historię warto porządkować przed scaleniem, nie po. Interaktywny rebase pozwala połączyć piętnaście commitów typu „wip” w trzy sensowne jednostki, a squash merge zostawia w main jeden wpis na zadanie. Nigdy nie przepisuj natomiast commitów, które zostały już wypchnięte na wspólną gałąź używaną przez innych.
Konwencja nazw i automatyczne wersjonowanie
Conventional Commits, czyli prefiksy feat, fix, docs, chore i refactor, wygląda na formalność, dopóki nie podepniesz generatora changelogu. Wtedy narzędzie samo podnosi wersję z 2.4.1 na 2.5.0 przy nowej funkcji i buduje listę zmian dla klienta. Koszt wdrożenia to jeden plik konfiguracyjny i piętnaście minut rozmowy z zespołem.
Od repozytorium do serwera: CI/CD i wdrożenia
Pipeline uruchamiany przy każdym pushu to minimum: instalacja zależności, testy jednostkowe, lint i build. Darmowe limity to zwykle około 2000 minut miesięcznie, a pakiety płatne startują od kilkunastu złotych. Testy trwające ponad dziesięć minut ludzie zaczynają omijać, więc pilnuj czasu wykonania równie mocno jak pokrycia kodu.
Docelowe środowisko determinuje kształt wdrożenia. Osoby zastanawiające się, jak wybrać hosting pod WordPress z repozytorium gita, powinny sprawdzić dostęp do SSH, obecność Composera i możliwość uruchomienia webhooka. Czym różni się VPS od hostingu współdzielonego, widać właśnie tutaj: na współdzielonym zwykle zostaje wgranie plików przez FTP, na VPS działa pełen git pull.
Kontrola wersji upraszcza też migracje. Gdy klient pyta, jak przenieść stronę na inny hosting, repozytorium daje odtwarzalny stan kodu, a osobno przenosisz bazę i pliki użytkowników. Po zmianie adresów przydaje się wiedza, jak ustawić przekierowanie 301 w .htaccess, żeby stare adresy nie generowały błędów 404 w wynikach wyszukiwania.
Ostatni etap to szyfrowanie. Instrukcja, jak zainstalować certyfikat SSL na serwerze, sprowadza się dziś do jednego polecenia klienta ACME, a darmowy certyfikat SSL Let’s Encrypt odnawia się automatycznie co 90 dni. Skrypt odnawiania trzymaj w repozytorium razem z konfiguracją serwera WWW — wtedy odtworzenie maszyny zajmuje minuty, nie dni.
Bezpieczeństwo, sekrety i infrastruktura w repozytorium
Klucz API w historii commitów jest jawny na zawsze, nawet po usunięciu pliku kolejnym commitem. Sekrety trzymaj w zmiennych środowiskowych albo menedżerze typu Vault, a do repozytorium wrzucaj wyłącznie plik .env.example. Skaner sekretów w pipeline kosztuje kilka sekund na build i wyłapuje pomyłki, zanim staną się incydentem.
Konfiguracja infrastruktury zasługuje na wersjonowanie tak samo jak kod aplikacji. Pliki strefy trzymane w repozytorium odpowiadają na pytanie, jak skonfigurować rekordy DNS domeny w sposób powtarzalny i możliwy do zrecenzowania. Przy okazji rozstrzyga się, co to jest rekord CNAME — alias wskazujący jedną nazwę na drugą, typowy przy podpinaniu CDN lub środowiska testowego.
Do repozytorium warto dopisać krótką dokumentację operacyjną: gdzie kupiona jest domena, kto ją odnawia i jak sprawdzić kto jest właścicielem domeny przy pomocy zapytania whois. Znajdzie się tam też procedura opisująca, jak przedłużyć domenę po wygaśnięciu w okresie karencji, która zwykle trwa około 30 dni, zanim nazwa trafi na aukcję.
Na koniec plan awaryjny. Jeśli rozumiesz, jak korzystać z gita w projekcie, cofnięcie złego wdrożenia to git revert i ponowne uruchomienie pipeline’u — zwykle poniżej pięciu minut. Repozytorium lustrzane u drugiego dostawcy oraz nocny zrzut bazy dopełniają całości i chronią przed awarią jednego konta.
Jak zacząć używać gita w istniejącym projekcie bez kontroli wersji?
Zacznij od kopii zapasowej całego katalogu i bazy danych, bo pierwsze porządki zawsze coś usuwają. Następnie utwórz .gitignore, wykonaj git init i pierwszy commit obejmujący wyłącznie kod źródłowy — bez zależności, cache’u i plików wgranych przez użytkowników. Wypchnij repozytorium na zdalny serwer i dopiero wtedy zacznij pracować na gałęziach. Kolejnym krokiem jest opisanie w pliku README sposobu uruchomienia projektu lokalnie: wymaganej wersji PHP lub Node, komend instalacyjnych i listy zmiennych środowiskowych. Taka migracja zajmuje zwykle jeden dzień roboczy, a zwraca się przy pierwszej awarii, gdy zamiast szukać kopii pliku z datą w nazwie, po prostu porównujesz dwa commity.
Czy git nadaje się do wersjonowania grafik i plików wideo?
Domyślnie nie, ponieważ git zapisuje każdą wersję pliku binarnego w całości, a nie jako różnicę. Dziesięć poprawek pliku PSD o wadze 200 MB rozdmuchuje repozytorium do 2 GB i spowalnia każdą operację, łącznie z przełączaniem gałęzi. Rozwiązaniem jest Git LFS, który trzyma w repozytorium wskaźniki, a same pliki na osobnym serwerze — limity darmowe to zwykle 1 GB przestrzeni, a dodatkowe pakiety kosztują kilkanaście złotych miesięcznie. Alternatywnie grafiki źródłowe trzymaj w chmurze plikowej, a w repozytorium umieszczaj wyłącznie wyeksportowane, zoptymalizowane zasoby produkcyjne w formatach WebP lub AVIF.
Co zrobić, gdy pojawi się konflikt scalania?
Konflikt to informacja, że dwie osoby zmieniły ten sam fragment pliku, a nie awaria. Uruchom git status, żeby zobaczyć listę plików w stanie both modified, otwórz je i usuń znaczniki konfliktu, zostawiając docelową treść. Po sprawdzeniu, że aplikacja się uruchamia i testy przechodzą, wykonaj git add oraz git commit. Przy skomplikowanych przypadkach pomaga git mergetool albo widok trójstronny w edytorze, pokazujący wersję bazową obok obu zmian. Najlepszą profilaktyką jest częste pobieranie zmian z main i utrzymywanie krótkich gałęzi — konflikt po dwóch dniach ma kilka linii, konflikt po miesiącu potrafi zająć całe popołudnie.
