Tester Gitignore

„Dlaczego moja negacja .gitignore nie działa?” to jedno z najczęstszych pytań dotyczących Gita, a szczera odpowiedź jest prawie zawsze taka sama: „!wzorzec” próbujący ponownie dołączyć plik do katalogu, który wcześniej wykluczał już wcześniejsza reguła, nigdy nie może zadziałać, ponieważ git nie schodzi do ignorowanych katalogów, aby ponownie sprawdzić wszystko, co się w nich znajduje. To narzędzie ponownie implementuje algorytm dopasowywania .gitignore gita — a nie przybliżenie — specjalnie po to, aby móc wychwycić i wyjaśnić dokładnie tę sytuację, wraz z każdą inną regułą wzorca obsługiwaną przez git.

Wklej reguły .gitignore do jednego pola i listę ścieżek plików (po jednej w wierszu, np. `dist/index.js`, `node_modules/foo/bar.js` lub `.env`) do drugiego, a narzędzie oceni każdą ścieżkę dokładnie w taki sam sposób, w jaki zrobiłby to git: komentarze i puste linie są pomijane, końcowe spacje są usuwane, chyba że nastąpi ucieczka, początkowe „!” neguje regułę, początkowe `/` zakotwicza go w katalogu głównym zamiast pozwalać na dopasowanie na dowolnej głębokości, końcowy `/` ogranicza go do katalogów, a klasy znaków `*`, `?`, `[abc]` i `**` (dopasowujące się ponad granicami katalogów) działają zgodnie z udokumentowanymi regułami glob.

Co najważniejsze, ścieżki są sprawdzane katalog po katalogu, od katalogu głównego w dół, w ten sam sposób, w jaki działa własny silnik ignorowania gita — a nie poprzez testowanie pełnej ścieżki pod kątem każdej reguły z osobna. To właśnie umożliwia prawidłowe wykrycie przypadku martwej negacji: jeśli `dist/` zostanie zignorowane w linii 3, a później `!dist/keep.js` spróbuje uratować jeden z znajdujących się w nim plików, to narzędzie zgłosi, że `dist/keep.js` jest nadal ignorowane, podaje regułę linii 3 jako przyczynę i osobno flaguje negację jako przyćmioną, zamiast po cichu udawać, że zadziałało.

W tabeli wyników każdej testowanej ścieżce przydzielany jest własny wiersz z wyraźnym werdyktem „tak/nie” dotyczący zignorowania, dokładny tekst reguły i numer wiersza, który o tym zadecydował, a także – jeśli ma to zastosowanie – prostą notatką wyjaśniającą cieniowaną negację lub dziedziczoną regułę katalogu nadrzędnego. To jest szczegół, który zamienia zagmatwany plik .gitignore w taki, o którym możesz pomyśleć przed zatwierdzeniem.