Odpowiedzi:
Zaletą .gitignorejest to, że w przeciwieństwie do plików można go sprawdzić w samym repozytorium .git/info/exclude. Inną zaletą jest to, że możesz mieć wiele .gitignoreplików, po jednym w każdym katalogu / podkatalogu dla specyficznych dla katalogu reguł ignorowania, w przeciwieństwie do .git/info/exclude.
Tak więc .gitignorejest dostępny we wszystkich klonach repozytorium. Dlatego w dużych zespołach wszyscy ludzie ignorują ten sam rodzaj plików przykładu *.db, *.log. Możesz mieć bardziej szczegółowe reguły ignorowania z powodu wielu .gitignore.
.git/info/excludejest dostępny tylko dla pojedynczych klonów, dlatego to, co jedna osoba ignoruje w swoim klonie, nie jest dostępne w klonie innej osoby. Na przykład, jeśli ktoś używa Eclipsedo programowania, może mieć sens, aby ten programista dodał .buildfolder do.git/info/exclude ponieważ inni deweloperzy mogą nie używać Eclipse.
Ogólnie rzecz biorąc, reguły files / ignore, które muszą być uniwersalnie ignorowane, powinny wejść .gitignore, a w przeciwnym razie pliki, które chcesz zignorować tylko w swoim lokalnym klonie, powinny wejść do.git/info/exclude
~/.gitignorew Twoim komentarzu powyżej. Rozumiem, że reguły ignorowania mogą być na 3 poziomach - $PROJECT/.git/info/excludedla (projektu, użytkownika) specyficznych reguł ignorowania, $PROJECT/<any number of directories>/.gitignoreczyli dla specyficznych dla projektu reguł ignorowania dla dowolnego użytkownika w dowolnym miejscu (po wpisaniu), ~/.gitignore dla specyficznych dla użytkownika reguł ignorowania dla dowolnego projektu dla tego użytkownika na tej maszynie. Na podstawie celu wybierasz miejsce, w którym chcesz umieścić wpis.
git rm --cached <path-name>usunie ją z repozytorium, ale zachowa lokalnie. git update-index --skip-worktree <path-name>zignoruje zmiany w pliku, ale zachowa go w repozytorium. Z ciekawości: dlaczego chcesz wykluczyć plik sln? To ważna część rozwiązania .Net, prawda?
Googled: 3 sposoby wykluczania plików
.gitignore dotyczy każdego klonu tego repozytorium (wersjonowane, każdy będzie miał),.git/info/exclude dotyczy tylko Twojej lokalnej kopii tego repozytorium (lokalnej, nie udostępnianej innym),~/.gitignore dotyczy wszystkich repozytoriów na Twoim komputerze (lokalnych, nie udostępnianych innym).3. w rzeczywistości wymaga ustawienia konfiguracji na komputerze:
git config --global core.excludesfile '~/.gitignore'
.git/info/excludes, kiedy powinien .git/info/exclude, co potwierdza dokumentacja, do której prowadzi.
Aby zaoferować nasze (rzeczywiste) doświadczenie: zaczęliśmy używać .git / info / exclude, kiedy musieliśmy dostosować niektóre pliki konfiguracyjne w każdym środowisku programistycznym, ale nadal chcieliśmy, aby źródło było utrzymywane w repozytorium i dostępne dla innych programistów.
W ten sposób pliki lokalne, po sklonowaniu i zmodyfikowaniu, można wykluczyć z zatwierdzeń bez wpływu na oryginalne pliki w repozytorium, ale niekoniecznie są również ignorowane w repozytorium.
Służy .gitignoredo ignorowania reguł specyficznych dla projektu . Użyj excludelub globalnego pliku ignorowania, aby ignorować reguły specyficzne dla twojego środowiska .
Na przykład moje globalne pliki ignorowania ignorują pliki tymczasowe generowane przez dowolny edytor, którego używam - ta reguła jest specyficzna dla mojego środowiska i może być inna dla innego programisty w tym samym projekcie (być może używają oni innego edytora). OTOH, moje .gitignorepliki projektu ignorują takie rzeczy, jak klucze API i artefakty kompilacji - te są przeznaczone dla projektu i powinny być takie same dla wszystkich w projekcie.
To pomaga?