A dev of mine once committed the env file.

I had to alter the fabric of time, space, and commit history.

No gitignore?

merging code via PR should be followed everywhere, as there is an option to revert the merge easily.

@ElectroArchiver gitignore ignores only .env.local by default and not .env, i also fucked up a few times forgetting to include .env in gitignore

I think this is because .env is supposed to be used for dev information such as route names, key names, parameter names, constants etc. So other devs can pull and use it and see those variables all grouped in .env

On the other hand .env.local is supposed to be used for super secret sensitive information such as access to api keys, github client id etc which only gets stored locally on the machine (hence the name). This is why gitignore has ignored this file by default and not .env

That is why @gagan-suie your friend should use .env.local for sensitive information and .env for dev naming stuff

@b2plane You fuck up enough number of times, you will automatically learn to run git status before you do anything.

Spending 2 seconds to double check what you're about to push will save you hours of debugging in future.

Sorry I forgot to mention that cloudflare workers changed it to

.dev.vars instead of .env

So this was not captured by the git ignore file.

Also, all env vars are handled in github actions or cloudflare workers dashboard. So this was just for the dev environment.

And the repo was private.

But still, bad practice.

@Sid2006 yeh he merged the code to his own branch and created a PR. And was trying to push the PR to dev branch.

That's where I caught it.

I could have had him redo his changes but it was a lot of commits. 😂

https://rtyley.github.io/bfg-repo-c...

Very usefull in these cases.

@b2plane

It's actually the reverse. .env is for secrets passed as environment variables. .env.local is a template for the .env with sensible defaults for a localhost. (Or if, say, providing a docker file).

Also, there is no such thing as gitignore "defaults". And most decent templates I've seen *do* ignore .env.

@Sid2006

No matter if you revert the merge, it's already in the history forever until you do a filter-branch or a force push.

@Sid2006 GitHub Desktop heh

Forgot to add. Checking in .env.local is not safe either, but it's less unsafe than checking in .env, since it usually only contains values that don't work outside of localhost.

@Sid2006 the env commit is still visible after a revert

I only had to do this once in the past - I shudder thinking about all the git stuff I had to do to make sure it was hidden

Really easy with https://rtyley.github.io/bfg-repo-c...

How many hours did it take to alter the fabric of spacetime?

Were it worth the trouble?

@ElectroArchiver

You want us to actually plan which files we need to ignore?

Let me get out my crystal ball.

@Grumpycat

All you have to do is fucking check your stage area before pushing.

Doesn't take a crystal ball nor prodigious clairvoyance.

@Grumpycat Ignoring any `.env` file is one of the

most common things, basically any project that uses an access token likely has it

Since we are talking about this topic,

Recently awesome me pushed my openapi key to a repo. I instantly got a mail regarding this and removed the key from repo and deleted it from open api dashboard .

It is all good. Right?

@sandeepbalan ur good since you deleted it from the openai dashboard.

@CoreFusionX

Yes every time. Don’t forget now.

Every time.

Your making my point for me.

Thank you.

@ElectroArchiver

Then why doesn’t git pre-populate the .gitignore on a new project with sensible defaults. The answer is because there are no sensible defaults. It always depends.

@Grumpycat

Everything depends, not an argument.

The GitHub repository creation wizard for example shows you common ignore files

Of course there are sensible defaults for the majority of all projects, that's why some IDEs have default for .gitignore files