CODEWITHSUNDEEP
pythongitvirtualenv
Sridhar Murali
Sridhar Murali

Reputation: 358

Do I need to commit .env files into the repository?

I have just started learning backend dev using django. My question is do I just commit the project files in the server folder alone, or should I also commit the .env folder to the repository?

I have done the following:

  1. I have created virtual environment and I have also installed django in venv.
  2. I have setup a django server and super admin.
  3. I have setup the config.json to protect my API key.
  4. Included the same in .gitignore.

What happens if I do or do not commit .env?

Upvotes: 15

Views: 34074

Answers (5)

Energeneer
Energeneer

Reputation: 431

I agree with the other answers, however it may sometimes be useful to commit a sample .env or secrets file for other developers working on the same project.

If you wish to provide a sample .env file to keep in the repo but not track any further changes you can do so:

  1. Commit the sample file
  2. run the command git update-index --skip-worktree FILE_NAME
  3. Push everything

From now on, any changes to the files will only appear locally but not be committed to the online repo. Very useful when every dev needs to set up their own .env file.

Source

Upvotes: 3

Kirtan chhatrala
Kirtan chhatrala

Reputation: 56

No, it is not recommended to push the .env file to one's repository for security reasons.

The .env file contains sensitive information that should not be shared publicly. If committed, it becomes accessible to anyone who can access the repository, posing a significant security risk.

Instead, one should add the .env file to your .gitignore file and use the example.env file for sample .env. This ensures that it's not included in your commits, keeping the sensitive information private and local to your development environment.

Using an example.env file that contains only example environment keys without sensitive information can serve as a helpful template for developers to create their own local .env files.

Upvotes: 0

Vitaliy Markitanov
Vitaliy Markitanov

Reputation: 2448

Well, according to the documentation you should not commit '.env' file - see https://github.com/motdotla/dotenv#should-i-commit-my-env-file

But it will not hurt much (unless you leak secrets), as on a target environment you will most likely have pre-defined env vars, and values from '.env' will NOT be used for matching keys.

Sometimes you may even need to "share" env vars with your peers. Of course, you can use the approach defined in the documentation https://github.com/motdotla/dotenv#-deploying, but sometimes it is easier to commit .env file.

Just in case to avoid leaking secrets I usually have .env_sample file which has all the necessary keys with content like this:

key=<here is your secret>

and '.env' file with the same keys but real values and this file is excluded from source control (git or tfs or whatever you use). By this approach, you give an idea to your peers what your app needs and you don't leak secrets by accident.

Upvotes: 2

M.Jin
M.Jin

Reputation: 338

You shouldn't commit/include your .env file in your git repo because env stands for environment. You will different environment variables for your LOCAL, STAGING(development), PRODUCTION environments.

i.e. your LOCAL .env file might have something like

WEB_HOST=localhost
WEB_PORT=8000
ALLOWED_HOSTS=127.0.0.1, localhost

but your PRODUCTION .env will have something different like

WEB_HOST=www.mysite.com
WEB_PORT=8080
ALLOWED_HOSTS=www.mysite.com

Which is why you can't include your .env in your repo and should be created depending on the environment.

Upvotes: 12

damon
damon

Reputation: 15128

Assuming that your .env folder is your virtual environment, no you should not commit it.

The virtual environment should be rebuilt on the server using your requirements.txt file. The local environment you built on your development machine may have operating system specific binaries, and other compiled code that was generated for your local environment.

The server will have different compiled binaries, and therefore should rebuild the virtual environment using: pip install -r requirements.txt.

Upvotes: 11

Related Questions