Czym jest plik .gitignore i jak się go używa?

Question

Accepted Answer

Plik **.gitignore** mówi Gitowi, które pliki i katalogi mają być **ignorowane** — nie śledzone w kontroli wersji. Służy do wykluczenia wygenerowanych plików, zależności, sekretów i plików specyficznych dla środowiska, które nie powinny być zatwierdzone.

## Co robi .gitignore

```text
# .gitignore — patterns of files Git should NOT track
node_modules/          # dependencies (reinstalled from package files, don't commit)
dist/                  # build output (generated, don't commit)
*.log                  # log files
.env                   # ⚠️ SECRETS / environment variables — NEVER commit!
.DS_Store              # OS-specific junk
.vscode/               # editor config (often personal)
build/
coverage/
*.tmp
```

Git ignoruje pliki pasujące do tych wzorów — nie pojawią się w `git status`, nie zostaną zinscenizowane i nie będą zatwierdzone.

## Składnia wzorów

```text
node_modules/    → ignore a directory (and everything in it)
*.log            → ignore all files with a .log extension
!important.log   → EXCEPTION: do NOT ignore this (negation)
/build           → ignore "build" only in the root (leading slash = root-relative)
doc/*.txt        → .txt files in doc/ but not subdirectories
**/temp          → "temp" anywhere in the tree
```

## Co ignorować (typowe kategorie)

```text
✓ DEPENDENCIES — node_modules/, vendor/ (reinstalled from manifests; huge, don't commit)
✓ BUILD OUTPUT — dist/, build/, *.o (generated from source)
✓ SECRETS — .env, credentials, keys (⚠️ NEVER commit secrets — a serious security issue)
✓ ENVIRONMENT/OS/EDITOR files — .DS_Store, .idea/, .vscode/ (personal/machine-specific)
✓ LOGS, caches, temp files
```

```text
⚠️ Already-tracked files aren't ignored by adding them later — untrack first:
   git rm --cached <file>   (then commit; .gitignore prevents re-adding)
```

## Dlaczego to ważne

Rozumienie `.gitignore` jest ważne dla **utrzymania repozytoriów czystych i bezpiecznych**, dlatego jest niezbędną praktyczną wiedzą z Gita.

Plik `.gitignore` wyklucza pliki, które **nie powinny być w kontroli wersji**, rozwiązując kilka rzeczywistych potrzeb.

Utrzymuje repozytoria czyste, wykluczając **pliki wygenerowane/pochodne** (wynik kompilacji, skompilowane artefakty) i **zależności** (`node_modules`, które są ogromne i przeinstalowywane z plików manifestu — ich zatwierdzanie powiększałoby repozytorium) — dzięki temu repozytorium zawiera tylko znaczący kod źródłowy.

Wyklucza **pliki specyficzne dla środowiska i osobiste** (śmieci systemu operacyjnego jak `.DS_Store`, konfiguracje edytorów), które zaśmieccałyby repozytorium i powodowały szum.

Najważniejsze jest to, że jest niezbędne dla **bezpieczeństwa**: wyklucznie **sekretów** (pliki `.env`, poświadczenia, klucze API) jest kluczowe, ponieważ **zatwierdzenie sekretów jest poważnym błędem bezpieczeństwa** — raz zatwierdzone, sekrety znajdują się w historii repozytorium (i potencjalnie przesłane do zdalnych/publicznych repozytoriów, gdzie mogą być wykorzystane), dlatego `.gitignore` jest kluczową obroną przed przypadkowym zatwierdzeniem poufnych danych.

Rozumienie **składni wzorów** (katalogi, symbole wieloznaczne, negacja, względna do katalogu głównego) pozwala na napisanie efektywnych reguł ignorowania, a wiedza o ważnym punkcie zapalnym, że **pliki już śledzone muszą być niebędące pod kontrolą** (`git rm --cached`) przed zastosowaniem `.gitignore`, zapobiega powszechnemu zamieszaniu.

Ponieważ czyste repozytoria (bez wygenerowanych plików, zależności czy bałaganu) i szczególnie **niezatwierddzanie sekretów** są ważne dla jakości i bezpieczeństwa repozytorium, a `.gitignore` jest standardowym mechanizmem wykluczania plików, które nie powinny być śledzone, zrozumienie `.gitignore` — co ignorować (zależności, wynik kompilacji i krytycznie sekrety), składnię wzorów i punkt zapalny dotyczący niebędących pod kontrolą plików — jest niezbędną, często stosowaną wiedzą z Gita do utrzymania czystych, bezpiecznych repozytoriów, przy czym aspekt bezpieczeństwa dotyczący ochrony sekretów przed kontrolą wersji jest szczególnie ważny.