gitignore wszystkie pliki rozszerzenia w katalogu


Odpowiedzi:


123

Nigdy nie próbowałem, ale git help ignoresugeruje, że jeśli szuka .gitignoresię *.jsw /public/static, będzie to robić co chcesz.

Uwaga: koniecznie sprawdź również odpowiedź Joeysa poniżej: jeśli chcesz zignorować pliki w określonym podkatalogu, właściwym rozwiązaniem jest lokalny plik .gitignore (lokalizacja jest dobra). Jeśli jednak potrzebujesz tego samego wzoru, aby zastosować się do całego repo, to ** rozwiązanie jest lepsze.


19
To nie jest konieczne najlepsze rozwiązanie. Potencjalnie ludzie będą musieli przeglądać różne pliki .gitignore, aby dowiedzieć się, dlaczego ich plik jest ignorowany. Niektórzy wolą mieć wszystkie te informacje w jednym pliku .gitignore przechowywanym w katalogu głównym repo.
haren

1
@haren to nie jedyne rozwiązanie - odpowiedź Joeya jest również z pewnością ważna. Wybierz to, co najbardziej Ci odpowiada. Twierdziłbym, że zasady ignorowania lokalnego dla katalogu powinny znajdować się w tym katalogu, a reguły globalne powinny być globalne. (Również ta odpowiedź jest starożytna i nie sądzę, aby ** była wtedy obsługiwana).
ptyx

211

Wygląda na to, że **składnia jest obsługiwana gitod wersji 1.8.2.1zgodnie z dokumentacją .

Dwie kolejne gwiazdki („ **”) we wzorach dopasowanych do pełnej nazwy ścieżki mogą mieć specjalne znaczenie:

  • Początkowe „ **”, a następnie ukośnik oznacza dopasowanie we wszystkich katalogach. Na przykład „ **/foo” pasuje do pliku lub katalogu „ foo” w dowolnym miejscu, tak samo jak wzorzec „ foo”. „ **/foo/bar” pasuje do pliku lub katalogu „ bar” w dowolnym miejscu bezpośrednio w katalogu „ foo”.

  • Końcowy „ /**” pasuje do wszystkiego w środku. Na przykład „ abc/**” dopasowuje wszystkie pliki w katalogu „ abc” względem położenia .gitignorepliku z nieskończoną głębią.

  • Ukośnik, po którym następują dwie kolejne gwiazdki, następnie ukośnik odpowiada zero lub większej liczbie katalogów. Na przykład „ a/**/b” pasuje ” a/b,„ a/x/b”,„ a/x/y/b”i tak dalej.

  • Inne kolejne gwiazdki są uważane za nieprawidłowe.


1
Jaka jest różnica między xxx/**i xxx/?
thuzhf

9
xxx/**celuje we wszystkie pliki i katalogi wewnątrz, xxxnatomiast bezpośrednio xxx/na xxxkatalog. To naprawdę ma znaczenie tylko przy negowaniu wzorców !jako „Nie można ponownie dołączyć pliku, jeśli katalog nadrzędny tego pliku jest wykluczony.”, Więc używając xxx/*lubxxx/** byłoby konieczne w takim przypadku.
joeyhoer

4
Wszystkie pliki z końcówką .meta powinny być ignorowane przez git. Jak to działa? **.js?
Czarny

„Inne kolejne gwiazdki są uważane za nieprawidłowe”. podsumowuje wszystko
imrok

68

AKTUALIZACJA: Spójrz na odpowiedź @ Joeya : Git obsługuje teraz **składnię we wzorach. Oba podejścia powinny działać dobrze.


Strona podręcznika gitignore (5) stwierdza:

Wzorce odczytywane z pliku .gitignore w tym samym katalogu co ścieżka lub w dowolnym katalogu nadrzędnym, przy czym wzorce w plikach wyższego poziomu (do najwyższego poziomu drzewa roboczego) są zastępowane przez wzorce w plikach niższego poziomu do katalogu zawierający plik.

Oznacza to, że wzorce w .gitignorepliku w dowolnym katalogu repozytorium wpłyną na ten katalog i wszystkie podkatalogi .

Podany wzór

/public/static/**/*.js

nie jest całkiem poprawne, po pierwsze dlatego, że (jak słusznie zauważyłeś) **Git nie używa składni. Ponadto wiodące /kotwice wzorujące się na początku nazwy ścieżki. (Więc /public/static/*.jsbędzie pasować, /public/static/foo.jsale nie /public/static/foo/bar.js .) Usunięcie wiodącego też /nie zadziała, dopasowanie ścieżek takich jak public/static/foo.jsi foo/public/static/bar.js. EDYCJA: Samo usunięcie wiodącego ukośnika też nie zadziała - ponieważ wzorzec nadal zawiera ukośnik, Git traktuje go jako zwykły, nierekurencyjny glob powłoki (dzięki @Joey Hoer za wskazanie tego).

Jak sugerował @ptyx, musisz utworzyć plik <repo>/public/static/.gitignorei dołączyć tylko ten wzorzec:

*.js

Nie ma żadnych wiodących elementów /, więc będzie pasować do dowolnej części ścieżki, a ten wzorzec zostanie zastosowany tylko do plików w /public/statickatalogu i jego podkatalogach.


2
Nie jest to do końca prawdą - konkretnie część „Usuwanie wiodącej /nie będzie działać, dopasowując ścieżki jak public/static/foo.jsi foo/public/static/bar.js”. to fałsz. Cytując dokumentację: „Jeśli wzorzec nie zawiera ukośnika /, Git traktuje go jako wzorzec glob powłoki i sprawdza zgodność z nazwą ścieżki względem położenia pliku .gitignore (względem najwyższego poziomu drzewa roboczego, jeśli nie z pliku .gitignore). ” foo/public/static/bar.jsnie byłoby dopasowane, ponieważ wzorzec zawiera /.
joeyhoer

@JoeyHoer dzięki wskazówce, odpowiednio zaktualizowałem swoją odpowiedź.
Adam Sharp

9

Aby zignorować nieśledzone pliki, przejdź do .git / info / exclude. Wyklucz to plik z listą ignorowanych rozszerzeń lub plików.


2
Nie byłoby to przeniesione na inne klony repozytorium, takie jak .gitignore (oczywiście po popełnieniu).
jpmc26,

3

Uważam, że najprostszym rozwiązaniem byłoby użycie find. Nie lubię, gdy wielu .gitignorekręci się w podkatalogach i wolę zarządzać unikalnym, najwyższym poziomem .gitignore. Aby to zrobić, możesz po prostu dołączyć znalezione pliki do swojego .gitignore. Załóżmy, że /public/static/to jest twój projekt / git home, użyłbym czegoś takiego:

find . -type f -name *.js | cut -c 3- >> .gitignore

Odkryłem, że wycięcie ./na początku jest często konieczne, aby git zrozumiał, których plików należy unikać. Dlatego też cut -c 3-.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.