Quando eu postei o tutorial completo sobre Docker, muitos anos atrás, algumas pessoas comentaram pedindo mais detalhes a respeito desse trecho aqui que comentei no post:
Bom, depois de.. *check notes*, mais de OITO anos, chegou a hora de eu detalhar como funciona isso, afinal, antes tarde do que mais tarde, certo? Então vamos lá.
Uma tarefa comum quando você está desenvolvendo um projeto é rodar um linter. Linters são ferramentas que analisam o código fonte do seu projeto e buscam detectar diferentes problemas no código, incluindo possíveis falhas na lógica e também questões relacionadas ao estilo do código. Porém, se tem uma coisa que incomoda MUITO é quando você está desenvolvendo, QUASE finalizando o software, e precisa ESPERAR para que ferramentas de verificação assim (que incluem tanto linters quanto testes, que são importantes para qualquer projeto) assim rodem.
Como usuário da excelente distribuição Arch Linux (BTW, I use Arch), eu só gostaria de fazer aqui um breve lembrete para todos vocês: Antes de você gastar bastante tempo compilando um pacote gigante do AUR (ou Arch User Repository), como por exemplo o qt5-webkit, vale checar se você realmente PRECISA desse pacote OU se ele é dependência para algum outro pacote instalado na sua máquina.
Como programador, uma coisa que eu aprecio demais na nossa profissão é a possibilidade de criar side projects. Claro, relaxar é super importante, eu não nego, ainda mais para nós que trabalhamos basicamente pensando muito o dia inteiro.
Mas poder criar projetos que resolvem AQUELE problema ou necessidade chato que você tem - e ainda de quebra poder ajudar outras pessoas (ou até faturar algum $$$ extra, em alguns casos) - também é algo muito bem vindo.
O problema, como sempre, é que isso é basicamente...trabalho, e por mais interessante que seja poder customizar cada parte do seu próprio projeto, o fato é que quanto mais você demora para lançá-lo - por qualquer motivo que seja - maiores são as chances de você acabar desistindo e/ou partindo para outro projeto.
E é nesse ponto que entra o Dokku: um projeto que, após ser instalado em um servidor (VPS ou dedicado, conforme o seu bolso deixar), lhe permite facilmente criar novas aplicações e fazer deploy delas, usando um workflow muito parecido com o do Heroku, mas sem os custos extras (além do custo do servidor e do seu tempo, é claro).
Uma coisa que todo iniciante de Git costuma fazer é comittar tudo o que há no projeto no repositório. Isso inclui dependências, arquivos compilados, arquivos temporários, e assim vai. Entretanto, com o tempo, esse tipo de arquivos tendem a ser modificados, e tendem a bagunçar muito mais do que deveriam o repositório. Como se isso não fosse o suficiente, à cada clone feito, é necessário lidar com uma quantidade muito maior de dados, pois não há como clonar um repositório no git sem clonar todos os arquivos (você pode até customizar o que vai ser baixado ou não, mas, dada uma branch, você precisa baixar todos os arquivos da branch para conseguir usá-la), o que tende a causar problemas ainda mais significativos ao decorrer do tempo. Por causa disso, hoje vou falar um pouco sobre o .gitignore e como criá-lo, um arquivo simples que lista o que o Git deve ignorar quando você estiver trabalhado no repositório, de forma que seja possível evitar a adição de arquivos indesejados no repositório sem dificuldades, tornando os arquivos indesejados totalmente invisíveis ao Git.