Generator .gitignore

Wybierz wszystkie technologie używane w tym repozytorium.

Reguły dotyczące systemu i edytora zwykle należą do globalnego pliku wykluczeń Git.

Dalej: sprawdź reguły

Wybierz technologie używane w repozytorium, aby utworzyć projektowy plik .gitignore dla plików generowanych, zależności i lokalnych plików środowiska. Możesz wybrać kilka technologii. Reguły systemu operacyjnego i edytora pojawią się osobno, dzięki czemu osobiste preferencje możesz umieścić w globalnym pliku wykluczeń Git.

Jak utworzyć i zastosować reguły wykluczania

  1. 1

    Wybierz technologie projektu

    Zaznacz wszystkie technologie używane w repozytorium, na przykład Laravel i Node.js w aplikacji PHP z budowanym interfejsem.

  2. 2

    W razie potrzeby dodaj reguły osobiste

    Wybierz system lub edytor, aby zobaczyć osobny zestaw wykluczeń globalnych. Pomiń ten krok, jeśli masz już te reguły w swoim pliku globalnym.

  3. 3

    Sprawdź, skopiuj lub pobierz

    Przejrzyj reguły projektu. Skopiuj je do pliku `.gitignore` w katalogu głównym repozytorium albo pobierz ZIP i wypakuj znajdujący się w nim `.gitignore` do tego katalogu. Opcjonalne reguły osobiste umieść w globalnym pliku wykluczeń Git.

  4. 4

    Sprawdź przed zatwierdzeniem

    Zatwierdź projektowy `.gitignore`, aby udostępnić reguły współpracownikom. Upewnij się, że potrzebne pliki, zwłaszcza przykładowe konfiguracje i pliki blokady zależności, nadal są widoczne dla Git.

Które reguły należą do którego pliku?

Rodzaj reguły Gdzie ją umieścić Przykład
Pliki wynikowe projektu i zainstalowane zależności Zatwierdzany w repozytorium plik .gitignore node_modules/, vendor/, __pycache__/
Lokalne wartości środowiska Projektowy .gitignore .env i lokalne warianty .env.*
Pliki tworzone przez własny system i edytor Globalny plik wykluczeń Git albo .git/info/exclude dla jednego repozytorium Metadane Findera lub kopie zapasowe edytora
Pliki potrzebne współpracownikom Pozostaw pod kontrolą wersji, gdy są potrzebne .env.example, package-lock.json, composer.lock, Gemfile.lock

Git odczytuje projektowe pliki .gitignore, lokalny dla repozytorium .git/info/exclude oraz osobisty core.excludesFile. Po zatwierdzeniu .gitignore reguły projektu są udostępniane wraz z repozytorium. Reguły osobiste zwykle działają tylko na Twoim komputerze. Więcej informacji znajdziesz w dokumentacji Git dotyczącej gitignore i poradniku GitHub o ignorowaniu plików.

Przykład: usługa Node.js ze skryptami Python

Wybierz Node.js i Python. Plik projektu połączy reguły dla zainstalowanych pakietów, takich jak node_modules/, wyników kompilacji Node, takich jak dist/, oraz plików generowanych przez Python, takich jak __pycache__/ i .venv/. Wykluczy też lokalne wartości .env, pozostawiając możliwość śledzenia .env.example. Jeśli używasz Maca i Visual Studio Code, wybierz te opcje osobiste, aby osobno przejrzeć ich reguły. Przed zapisaniem porównaj oba wyniki z rzeczywistą zawartością repozytorium.

Generator korzysta z wybranych szablonów. Nie może sprawdzić Twoich plików ani ustalić, czy katalog dist/ zawiera wygenerowane dane czy kod źródłowy, który chcesz zatwierdzić. Zawęź lub usuń regułę, która nie pasuje do projektu. Polecenie git check-ignore -v path/to/file pokazuje, która reguła dotyczy pliku jeszcze nieśledzonego przez Git. Zbiór szablonów GitHub pomaga sprawdzić konwencje dla technologii i edytorów, ale nie zastępuje przeglądu własnego repozytorium.

Pliki środowiska i pliki blokady

Wykluczenie .env pomaga zapobiec dodaniu lokalnych danych uwierzytelniających w nowych zatwierdzeniach, ale nie usuwa sekretu już zapisanego w Git. Jeśli trafił do historii, przestań śledzić plik, sprawdź, dokąd skopiowano dane, i zmień dane uwierzytelniające. Śledź oczyszczony .env.example tylko wtedy, gdy zawiera przykładowe wartości zamiast prawdziwych sekretów. Wygenerowany plik już zawiera wyjątek !.env.example, dzięki któremu ogólna reguła .env.* nie ukrywa przykładu. Zachowaj ten wyjątek podczas edycji reguł.

W aplikacjach zachowuj pliki blokady zależności, aby kolejne instalacje używały wybranych wersji. npm zaleca zatwierdzanie package-lock.json, a Composer zaleca zatwierdzanie composer.lock. Biblioteki mogą stosować inne zasady, więc kieruj się ich polityką budowania i wydawania.

Najczęściej zadawane pytania

Reguły wykluczania dotyczą plików, których Git jeszcze nie śledzi. Aby przestać śledzić plik bez usuwania lokalnej kopii, uruchom git rm --cached path/to/file, a następnie zatwierdź usunięcie. Jeśli plik zawierał dane uwierzytelniające, zmień je i sprawdź historię repozytorium oraz kopie.

Zwykle warto śledzić oczyszczony .env.example i pliki blokady aplikacji. Plik przykładowy dokumentuje wymagane zmienne środowiska, a plik blokady ustala wersje zależności dla zespołu i wdrożeń. Sprawdź, czy przykład nie zawiera prawdziwych sekretów.

Tak. Wybierz wszystkie technologie używane w tym samym repozytorium. Generator połączy wybrane reguły projektu w jednym pliku .gitignore. Sprawdź, czy Twoje repozytorium nie używa któregoś z wykluczonych katalogów do innych celów.

Reguły osobiste używane w wielu repozytoriach umieść w globalnym pliku wykluczeń Git. Gdy XDG_CONFIG_HOME nie jest ustawione, Git domyślnie korzysta z ~/.config/git/ignore. Inną ścieżkę można wskazać przez core.excludesFile. Dla prywatnej reguły tylko w tym repozytorium użyj .git/info/exclude. Nie dodawaj osobno wygenerowanych reguł osobistych do wspólnego pliku projektu, chyba że chce tego zespół.

Wybrane technologie oraz opcjonalnie system lub edytor trafiają na serwer, aby utworzyć reguły. W procesie wieloetapowym te wybory pojawiają się też w adresie URL strony. Nie umieszczaj sekretów w adresie URL. Narzędzie tworzy reguły na podstawie wyborów; nie odczytuje repozytorium ani nie przesyła jego plików.

Powiązane narzędzia

Narzędzie jest dostępne w innych językach