Czy wielu `.gitignore`s jest marszczonych?

O ile repo nie składało się z kilku niezależnych projektów, wydaje się, że najprościej byłoby mieć tylko jeden .gitignoreplik w katalogu głównym repo niż różne. Czy istnieje standardowa najlepsza praktyka w zakresie tej lub analizy online, gdy jedno podejście jest lepsze od drugiego?

Mogę wymyślić co najmniej dwie sytuacje, w których chciałbyś mieć wiele .gitignoreplików w różnych (pod) katalogach.

• Różne katalogi mają różne typy plików do zignorowania. Na przykład .gitignoregórny katalog projektu ignoruje wygenerowane programy, a Documentation/.gitignoreignoruje wygenerowaną dokumentację.

• Zignorować podane pliki tylko w danym (pod) katalogu (można użyć /sub/foow .gitignore, choć).

Pamiętaj, że wzorce w .gitignorepliku odnoszą się rekurencyjnie do katalogu (pod), w którym znajduje się plik i wszystkich jego podkatalogów, chyba że wzorzec zawiera „/” (więc np. Wzorzec namestosuje się do każdego pliku wymienionego namew danym katalogu i wszystkich jego podkatalogach, podczas gdy /namedo pliku o tej nazwie tylko w podanym katalogu).

Tytułem uwagi, jednym z przypadków, w których możliwość posiadania wielu .gitignoreplików jest bardzo przydatna, jest to, że potrzebujesz dodatkowego katalogu w kopii roboczej, którego nigdy nie zamierzasz zatwierdzać. Wystarczy umieścić 1 bajt .gitignore(zawierający tylko jedną gwiazdkę) w tym katalogu i nigdy się nie pojawi w git statusitd.

Możesz mieć wiele .gitignore, każdy oczywiście w swoim własnym katalogu.
Aby sprawdzić, które gitignore zasada jest odpowiedzialny za ignorowanie plików, należy użyć git check-ignore: git check-ignore -v -- afile.

I możesz mieć inną wersję .gitignore pliku dla każdej gałęzi: widziałem już taką konfigurację, która zapewnia, że ​​jedna gałąź ignoruje plik, podczas gdy druga gałąź nie: patrz na przykład to pytanie .

Jeśli twoje repozytorium obejmuje kilka niezależnych projektów, najlepiej byłoby je odnieść do podmodułów .
To byłyby najlepsze praktyki, pozwalające na klonowanie każdego z tych projektów niezależnie (wraz z ich odpowiednimi .gitignoreplikami), przy jednoczesnym powołaniu się na konkretną wersję globalnego projektu nadrzędnego.
Zobacz prawdziwą naturę submodułów, aby uzyskać więcej.

Zauważ, że od gita 1.8.2 (marzec 2013) możesz zrobić git check-ignore -v -- yourfile, aby zobaczyć, który program gitignore (z którego .gitignorepliku) jest stosowany do ' yourfile', i lepiej zrozumieć, dlaczego wspomniany plik jest ignorowany.
Zobacz „ Która gitignorereguła ignoruje mój plik? ”

Pro singiel

• Łatwe do znalezienia.

• Wyszukanie zasad wykluczenia może być dość trudne, jeśli mam wiele gitignore, na kilku poziomach w repozytorium.

• W przypadku wielu plików zazwyczaj kończy się to dość powieleniem.

Pro wiele

• Zakres wiedzy obejmuje część drzewa plików, w której jest potrzebna.

• Ponieważ Git śledzi tylko pliki, pusty plik .gitignore jest jedynym sposobem na zatwierdzenie „pustego” katalogu.

  (A przed Git 1.8 jedynym sposobem na wykluczenie takiego wzorca my/**.examplebyło utworzenie go my/.gitignorez tym wzorcem **.foo. Ten powód nie ma teraz zastosowania, jak możesz /my/**/*.example.)

Wolę pojedynczy plik, w którym mogę znaleźć wszystkie wyjątki. Nigdy nie brakowało mi pliku .svn dla katalogu i nie będę również tęsknił za katalogiem .gitignore.

To powiedziawszy, wiele gitignorów jest dość powszechnych. Jeśli ich użyjesz, przynajmniej bądź konsekwentny w ich użyciu, aby uzasadnić ich pracę. Na przykład możesz umieścić je w katalogach tylko jeden poziom od katalogu głównego.

Istnieje wiele sytuacji, w których chcesz popełnić katalog do repo Git ale bez plików w tym, na przykład logs, cache, uploadskatalogi itp

Dlatego zawsze robię, aby dodać .gitignoreplik do tych katalogów o następującej treści:

*
!.gitignore

Dzięki temu .gitignoreplikowi Git nie będzie śledził żadnych plików w tych katalogach, ale nadal pozwoli mi dodać .gitignoreplik, a zatem sam katalog do repozytorium.