Em ambientes UNIX, o arquivo pode ser criado executando simplesmente > .env, que é até mais rápido que a versão com touch, uma vez que essa última precisa criar um processo, esperar esse processo ser escalonado, rodar, e então voltar ao process do shell, enquanto com > quem cria o arquivo é o próprio shell. Na prática, essa diferença não é tão perceptível, mas pode fazer diferença em shellscripts.
De fato é importante não versionar o .env, colocando-o no .gitignore, por exemplo. Porém se ele já foi commitado, não adianta colocar no .gitignore que só funciona para novos arquivos, então é necessário fazer um commit removendo esse arquivo, e só então ele não será mais versionado. Isso pode pareceber bobo, mas é o motivo da ideia que alguns tem de fazer uma versão iniciar do arquivo sem os dados sensíveis, commitar, e depois alterá-lo tentando colocar no .gitignore não funcionar tão bem, embora a ideia possa ser interessante, um git add . ou git commit -a commitaria o .env sem o desenvolvedor perceber, além de dificultar qualquer alteração como adicionar um novo parâmetro de configuração.
Aproveitando o assunto, eu gosto da discução sobre configuração apresentada pelo 12 factor app.
eu gosto de versionar o .env.example com os indicativos de configurações que devem ser seguidos, me ajuda muito na hora de subir um ambiente novo seja em produção, homologação ou em outra máquina dev ...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Em ambientes UNIX, o arquivo pode ser criado executando simplesmente
> .env, que é até mais rápido que a versão comtouch, uma vez que essa última precisa criar um processo, esperar esse processo ser escalonado, rodar, e então voltar ao process do shell, enquanto com>quem cria o arquivo é o próprio shell. Na prática, essa diferença não é tão perceptível, mas pode fazer diferença em shellscripts.De fato é importante não versionar o
.env, colocando-o no.gitignore, por exemplo. Porém se ele já foi commitado, não adianta colocar no.gitignoreque só funciona para novos arquivos, então é necessário fazer um commit removendo esse arquivo, e só então ele não será mais versionado. Isso pode pareceber bobo, mas é o motivo da ideia que alguns tem de fazer uma versão iniciar do arquivo sem os dados sensíveis, commitar, e depois alterá-lo tentando colocar no.gitignorenão funcionar tão bem, embora a ideia possa ser interessante, umgit add .ougit commit -acommitaria o.envsem o desenvolvedor perceber, além de dificultar qualquer alteração como adicionar um novo parâmetro de configuração.Aproveitando o assunto, eu gosto da discução sobre configuração apresentada pelo 12 factor app.
Obrigado por acrescentar ao artigo! Ainda não conhecia essa abordagem do 12 Factor App, achei muito interessante!
eu gosto de versionar o .env.example com os indicativos de configurações que devem ser seguidos, me ajuda muito na hora de subir um ambiente novo seja em produção, homologação ou em outra máquina dev ...