Eu acho que há situações em que ignorar o .gitignore é muito útil. Por exemplo, quando você tem várias equipes ou uma equipe grande trabalhando na mesma base de código. Nesse caso, você precisa ter certas convenções, uma delas é sobre o que é ignorado no repositório git. Geralmente, trata-se de ignorar arquivos e diretórios criados pelo IDE ou OS, alguns logs gerados etc.
No entanto, existe uma força que tende a introduzir alterações não convencionais no .gitignore
arquivo. o.gitignore
arquivo pode ser alterado ainda mais por pessoa irresponsável, por engano, por uma ferramenta usada ou em outro caso.
Para ter uma força contrária a isso, podemos fazer o seguinte:
- O .gitignore inicial deve refletir a convenção nas equipes,
- Depois de pressionado, o .gitignore deve ser protegido adicionando a entrada .gitignore e pressionando essa alteração novamente.O
.gitignore
arquivo é " lacrado " dessa maneira.
O arquivo " selado " .gitignore
pode ser alterado, apenas localmente, sem propagar esses trocadores para outros membros da (s) equipe (s). No entanto, se uma mudança for amplamente aceita em toda a equipe, é possível "destravá-la", altere-a e "selar" novamente. Isso não pode ser feito por engano, apenas intencionalmente.
Infelizmente, você não pode estar 100% protegido da estupidez, mas dessa maneira fez tudo o que pôde para impedir que coisas estúpidas acontecessem.
Se você tem uma equipe relativamente pequena com profissionais muito bons, isso não seria importante, mas mesmo esses caras gostariam de ter uma coisa a menos para se preocupar.
O uso .git/info/exclude
é legal quando você não pode fazer nada sobre as configurações de infraestrutura, apenas cobrindo seu próprio ** para não cometer um erro.
Do ponto de vista do que é certo e do errado, estou votando por ter a entrada .gitignore dentro do .gitignore
arquivo, dando a todos a liberdade de fazer localmente o que quiserem, mas não invadindo os outros.
git add self && git commit -m "-1 for reverting existential depression" && git remote rm HEAD