Utwórz .gitignore z 61 szablonów dla języków, frameworków, edytorów i systemów
Działa w przeglądarce. Wpisane dane nie są nigdzie wysyłane. Sprawdzono 16 października 2026.Plik .gitignore wymienia pliki, których git ma nie śledzić, po jednym wzorcu w wierszu. Szablony dla danego stosu, takie jak Node.js, macOS i VS Code, można wybrać spośród 61 oficjalnych szablonów github/gitignore; łączą się w jeden plik do skopiowania lub pobrania, a każdą ścieżkę można sprawdzić według reguł przed commitem.
Ta strona została przetłumaczona maszynowo z angielskiego oryginału. Tłumaczenie nie zostało jeszcze sprawdzone przez człowieka, dlatego wiążąca jest wersja angielska. Przeczytaj angielski oryginał
Dotknij szablonów dla projektu, takich jak Node.js, macOS i VS Code, albo wyszukaj szablon po nazwie.
Dodaj własne wiersze, takie jak *.pem lub scratch/, w polu Własne reguły.
Wpisz kilka ścieżek w polu Testuj ścieżki, aby zobaczyć, które git zignoruje i która reguła o tym decyduje.
Kliknij Kopiuj lub Pobierz i zapisz plik jako .gitignore w głównym folderze repozytorium.
Każde nowe repozytorium potrzebuje pliku .gitignore przed pierwszym commitem, w przeciwnym razie wyniki kompilacji, zależności i ustawienia edytora trafiają do historii. GitHub publikuje jeden szablon dla każdego języka, frameworka, edytora i systemu operacyjnego; ta strona zawiera 61 z nich, ze stałego commita, i łączy wybrane w jeden plik.
Łączenie bez niespodzianek. Szablony się pokrywają: Node.js, Next.js i NestJS ignorują logi. Powtórzony wiersz jest usuwany tylko wtedy, gdy między dwiema kopiami nie stoi żadna reguła !, więc połączony plik ignoruje dokładnie to, co ignorują szablony jeden po drugim. Strona podaje, ile wierszy usunięto.
Testowanie ścieżek. Ścieżki wpisuje się w polu Testuj ścieżki, po jednej w wierszu, z ukośnikiem na końcu folderu. Każda jest oznaczana jako ignorowana lub zachowana, z numerem wiersza i regułą, która o tym zdecydowała. Dopasowanie działa według reguł samego git:
| Wzorzec | Pasuje do | Nie pasuje do |
|---|---|---|
*.log |
debug.log, logs/app.log |
log.txt |
build/ |
folder build na dowolnej głębokości |
plik o nazwie build |
/dist |
dist tylko na najwyższym poziomie |
src/dist |
doc/*.txt |
doc/a.txt |
doc/sub/a.txt |
**/secrets/** |
api/secrets/key.pem |
sam secrets |
!keep.log |
przywraca keep.log |
plik w ignorowanym folderze |
Plik w ignorowanym folderze pozostaje ignorowany. Git nie zagląda do ignorowanego folderu, więc !secret/ok.txt po secret/ nie działa. Zamiast tego należy napisać secret/*, a wiersz ! zadziała.
Pliki już śledzone. Plik .gitignore dotyczy tylko nieśledzonych plików. Jeśli plik został wcześniej zatwierdzony, należy usunąć go z indeksu poleceniem git rm --cached i zrobić commit; plik pozostaje na dysku.
Tester ścieżek sprawdzono z git check-ignore na ponad 1000 ścieżkach, na ręcznie napisanych zestawach reguł i prawdziwych szablonach. Wszystko działa w przeglądarce; nic, co zostanie wpisane, nie jest nigdzie wysyłane.
Należy zapisać go jako .gitignore, z kropką na początku i bez rozszerzenia, w głównym folderze repozytorium, obok folderu .git. Wzorce z ukośnikiem na początku lub w środku są odczytywane względem tego folderu. Plik .gitignore w podfolderze też działa i obowiązuje tylko poniżej niego.
Plik .gitignore dotyczy tylko plików, których git jeszcze nie śledzi. Gdy plik zostanie zatwierdzony, git nadal go śledzi. Należy uruchomić git rm --cached ze ścieżką, zrobić commit i od tego momentu reguła obowiązuje. Plik pozostaje na dysku; znika tylko jego kopia w indeksie.
Należy ignorować zawartość folderu, a nie sam folder: napisać logs/*, a potem !logs/keep.txt. Po wpisaniu logs/ git pomija cały folder bez zaglądania do środka, więc wiersz ! nigdy nie przywróci pliku. Pole Testuj ścieżki pokazuje, który przypadek zachodzi.
Ukośnik na końcu ogranicza wzorzec do folderów, więc build/ ignoruje folder o nazwie build, ale nie plik. Ukośnik na początku lub w środku wiąże wzorzec z folderem pliku .gitignore, więc /dist ignoruje tylko dist na najwyższym poziomie. Bez ukośnika wzorzec pasuje na dowolnej głębokości.
Tak. Wszystkie 61 tekstów pochodzi bez zmian z repozytorium github/gitignore ze stałego commita, czyli z kolekcji, której GitHub używa przy tworzeniu repozytorium, opublikowanej na licencji CC0. Każdy blok w wyniku ma nagłówek z nazwą szablonu, więc widać, skąd pochodzi reguła.
Tak, tak jak git w systemie Linux i w większości systemów CI, więc Build/ nie pasuje do folderu o nazwie build. W systemach Windows i macOS git zwykle ustawia core.ignorecase na true i ignoruje wielkość liter, więc wzorzec może pasować lokalnie, ale nie na serwerze kompilacji. Wzorce należy pisać z dokładną wielkością liter plików.
Stawki i przepisy się zmieniają; przed oparciem się na danej liczbie należy sprawdzić źródło.
Nadal coś nie działa? Zapytaj o narzędzie Generator .gitignore a odpowiedzieć może każdy, kto zna odpowiedź. Konto nie jest potrzebne.