[Dúvida] E se ...

Você vai aprender ao longo do tempo que existem alguns arquivos gerados automaticamente por programas de desenvolvimento, arquivos com dados sensíveis como senhas e/ou chaves de acesso, e por fim arquivos de teste que até você mesmo pode criar ao longo do desenvolvimento de uma aplicação. Esses e diversos outros arquivos não são necessários ao compartilhar seu código em um repositório git, seria até perigoso compartilhar suas credenciais abertamente em sites como o GitHub por exemplo! Nesse caso o gitignore é essencial pra que você defina exatamente o que não deve ser compartilhado ao adicionar arquivos em um repositório.

É comum que programadores realizem commits de código que não funciona por questão de organização, falta de tempo ou por não ter os conhecimentos necessários para trabalhar em algum ponto específico da aplicação em determinado momento. O que vai dizer se realizar commits "incompletos" é algo ideal ou não são os paradigmas de desenvolvimento do projeto em questão, algumas metodologias de desenvolvimento de software definem que é aceitável realizar commits de código que não funciona, já outras metodologias podem não aceitar isso tão bem. Nesses casos, como você mesmo mencionou, outros desenvolvedores podem continuar trabalhando no que não funciona e podem até mesmo adicionar melhorias ao que já funciona.

Ok, entendi. Mas se for arquivos em que poderia ser perigoso compartilhar as credencias abertamente em sites como o GitHub, não vejo a necessidade de colocá-los em repositórios, não é mesmo. Por exemplo, estou desenvolvendo um site altamente elaborado, guardado a "sete chaves" e que seria um erro se caísse na concorrência ou em empresas que desenvolvem programas semelhantes e que possam "clonar" meu trabalho. Eu jamais colocaria em um repositório GitHub, concorda? Não sei se a minha opinião (idéia) foi bem explanada.

Desculpa se não fui muito claro, você acabou misturando um pouco alguns conceitos nesse exemplo, primeiro a gente precisa entender a diferença entre código proprietário e código aberto.

Em casos que você não quer que empresas adversárias tenham acesso ao seu código você pode aderir a uma filosofia de desenvolvimento baseada em código proprietário ao mesmo tempo que usa uma ferramenta de desenvolvimento como o GitHub, não há problema algum nisso. O que você poderia fazer é determinar nas configurações do repositório que apenas pessoas previamente definidas por você podem visualizar esse código, geralmente uma equipe seleta de desenvolvedores que fazem parte da empresa é definida como pessoas com acesso permitido. Deu para entender que nada disso é papel do gitignore?

Pra que a gente usa o gitignore então? Dando um exemplo bem prático, um editor de texto bastante popular no Linux é o Vim. Por padrão o Vim salva cópias ocultas dos arquivos que você está editando para que você possa desfazer alterações ou recuperar dados em caso de qualquer problema, geralmente arquivos terminando em .swp que você não consegue enxergar mas o git consegue. Isso é um problema, imagina se você está trabalhando em 10 arquivos de texto diferentes e cada um tem seu .swp, você pode acabar enviando 20 arquivos de texto para um repositório e metade desses arquivos são utilizados exclusivamente pelo seu editor de texto atual, completamente inúteis para qualquer outro propósito. A boa notícia? Dá pra falar para o git simplesmente ignorar esses arquivos utilizando o gitignore!

Fala, Jefferson, belezinha?

Eu também ficava pensando nisso: qual o motivo de ter uma ferramenta que, além de compartilhar as versões dos projetos, também funciona como um tipo de backup em nuvem?

Excelente esclarecimento, Rodrigo, entendi perfeitamente.

E eu até ainda agora achava que este recurso "ignore" era uma ação que só poderia ser feita pelo GitHub ou sites específicos para isso. Mas que nada, é só criar um arquivo texto, nomear corretamente e inserir no arquivo os nomes de pastas e arquivos que deseja retirar dos commits, seja lá pelo motivo que for.

Muito bom!!!

Abs e bons estudos pra vocês!