Env File Accidentally Committed to Git: How to Fix It

An env file leak happens when a .env file gets pushed to a remote repository by mistake. As a result, the API keys and database passwords inside it stay in the project's history. In this guide we walk through the exact order of steps to take. We cover how to clean past commits, and what to change so the mistake does not happen again. Talha Aslan and our team cover this topic often while setting up project environments for clients, so here is the plain version.

What Should You Do First When an Env File Leak Happens?

When an env file leak happens, you do not start by cleaning the repository. You start by revoking and rotating every key and password inside the file. Once a file reaches a remote server, someone may have already seen it. Therefore, deleting it from history later does not undo that. Rotation always comes first, history cleanup comes second.

The order matters. First, rotate every affected key or password. Then, check whether the repository is public or private. After that, clean the historical commits, and finally have the team update their local clones. Skipping this order means you risk treating an un-rotated key as safe.

Why Should You Never Commit a .env File to Git?

A .env file usually stores database passwords, email server credentials, payment provider keys, and third-party API tokens as plain text. Once this file lands in a repository, anyone who can see that repository sees those values too. However, even a private repo carries risk from team changes, former employees, or a mismanaged invite link.

Our guide to contributing to open source on GitHub covers repository visibility in more detail. A plain text file does not behave like an encrypted value, either. So, anyone who opens it reads the content directly. This applies to small side projects too, not just large companies, for instance. A key reused across environments turns a small leak into a bigger one. A solo developer testing an idea on a weekend faces the same exposure as a funded startup, because the key itself does not know the size of the project behind it.

What Should You Do in the First 10 Minutes After an Env File Leak?

Acting in order during the first 10 minutes limits the damage. The goal here is to stop the risk, not to finish a full history cleanup right away. In practice, that means a short, focused checklist. The numbered list below covers that first response.

1. Write down every key, password, and token in the file, and note which service each one belongs to.
2. Rotate or revoke each one from its own service dashboard: payment provider, email, database, and so on.
3. Check whether the repository is public or private and who currently has access.
4. Tell your project lead or team what happened instead of quietly fixing it alone.
5. Plan the history cleanup step, which the next section covers.

Which Values Inside a .env File Carry the Most Risk?

Not every line in a .env file carries the same risk. A database password or a payment provider secret key ranks highest, because it grants direct access to data or to money movement. An email sending key or a third-party API token sits in the middle instead, since misuse there damages your sending reputation.

General application settings, like an environment name or a time zone, carry lower risk. Still, they deserve protection, because they help an attacker map your system. Treat the whole file as sensitive once a leak happens, rather than judging each line on its own. This matters because attackers often combine a low-value setting with a higher-value key to map out an entire system faster. For example, a test environment key can sometimes reach production data too.

Why Should You Rotate Keys and Passwords Immediately?

Rotating a key immediately matters more than removing the file from history. However, history cleanup takes real time, and the old key still works during that window. The moment you rotate, any leaked copy stops being useful to whoever has it.

So, the correct order is rotate first, clean second. Some teams skip history cleanup entirely and only rotate. That said, this is acceptable when the repository is private and the risk looks limited. In larger teams, though, it is worth confirming with whoever manages access that the repository truly stays private over time. Rotation itself usually finishes within minutes from the relevant service dashboard. Also, remember to update the application with the new value right after, or the service stops working.

Does It Matter Whether the Repository Is Public or Private?

A public repository turns a leak into an immediate risk. In fact, automated scanning bots can find exposed keys within minutes. If your public repo has a leaked .env file, rotate the keys before anything else. Instead, do not wait for the history cleanup step.

A private repository carries lower but non-zero risk. Former team members, a mismanaged invite link, or a compromised account can still expose the same data. In other words, "private means safe" is a false assumption. The table below compares both scenarios. Use it as a quick reference the next time you are unsure how urgently to react.

How Does a .gitignore File Prevent a .env Leak?

A .gitignore file is a rule list. It tells Git which files to leave untracked. Add .env and .env.* lines at the root of your repository. As a result, Git stops tracking those files; git status no longer lists them and git add . no longer stages them.

The official Git documentation explains that .gitignore works together with rules in parent directories too. You can confirm whether a path is really ignored with git check-ignore -v .env, which shows the matching rule. However, this rule only applies to files Git does not already track. A file already committed once needs a different fix, covered next.

Is .gitignore Enough If the File Was Already Committed?

No, it is not enough. Once a file has been committed and pushed, that content stays in history. Instead, adding it to .gitignore only stops future changes from being tracked. The historical version stays reachable whenever someone clones the repository or browses its history.

Two separate actions follow from here: untracking the file going forward, and cleaning the historical copies. The next two sections cover each one.

How Do You Untrack a File with git rm --cached?

Keep the file on disk and remove it from Git's tracking with git rm --cached .env. Commit that change right after. This step does not delete the file from your computer. Instead, it only records that Git no longer tracks it.

Add the .env line to .gitignore right after this step. Otherwise, the file can land on the stage again on the next change. Together these two steps stop future accidental additions. Still, the old version in history is there.

How Do You Fully Remove a .env File from Past Commits?

Removing a file from past commits means rewriting repository history. Consequently, that changes every commit's hash. The official GitHub documentation recommends git filter-repo for this job. The tool can strip a given file path from every reference, or replace specific text strings across the whole history.

Back up the repository fully before this step. A simple copy in a separate folder is usually enough, and it gives you a safety net if a command does not behave as expected. Also, close or merge any open pull requests, since a rewritten history can break comments and comparisons on them. At a conceptual level the process has three parts: remove the file from all history, verify the local repository, then force-push to the remote.

Conceptually, How Does git filter-repo Clean Up History?

git filter-repo scans the entire repository history. It rebuilds that history with the file path or text pattern you specify stripped out of every commit. The official GitHub guide notes that you should run the tool against any earlier file locations too, if the file moved around during the project's life.

As a result, every commit gets a new hash. The before and after states become two genuinely different histories. Moreover, signed commit signatures get lost in the process, a side effect the official documentation states explicitly.

What Changes After You Force-Push?

Once history is rewritten, you need a force-push to send it to the remote. Because a normal push does not accept a history that changed underneath it. After this step, every commit hash on the remote matches your local copy.

Some references, especially ones tied to pull requests, can be read-only on the server side. Consequently, they resist a force-push in that case. Close or merge open pull requests first, then temporarily disable branch protection if needed. Double-check which branch and which remote you are targeting before running this command. A quick git remote -v check only takes a few seconds and can save a lot of cleanup later. Otherwise, running it against the wrong branch creates a different problem entirely.

What Happens to Teammates' Existing Clones?

Teammates' existing local clones do not know history was rewritten. So, a plain git pull can bring the old, leaked commits right back. The safest path after cleanup is to have everyone re-clone the repository.

If re-cloning is not possible, team members should rebase their branches onto the new history instead of merging them. Because a merge can reintroduce the old history by accident. Send the team a short heads-up about the exact date and which branches are affected. A message the day before gives everyone time to finish pending work and avoid losing it. This way, everyone switches cleanly. If a rebase produces conflicts, our guide to resolving Git merge conflicts applies the same logic to those cases.

When Should You Contact GitHub or GitLab Support About a Leak?

Even after you clean history and force-push, old commits can stay briefly reachable. Specifically, a platform's cached views or certain pull request references can still hold them. The official GitHub documentation suggests contacting support in this case to clear caches and remove affected references.

Share the repository name, the number of affected pull requests, and the first changed commit your cleanup tool reported. Support teams generally ask whether the exposed credentials were already rotated, since that changes how urgent the request is on their side. This way, you speed up the process. This request does not replace key rotation or history cleanup. Instead, it only clears platform-side leftovers after you have already done both.

What If Someone Has Forked Your Repository?

If your repository has been forked, each fork holds its own independent copy. However, your history cleanup does not automatically reach those forks. The official documentation recommends contacting fork owners directly and asking them to remove the file or delete the fork.

On a popular public repository with many forks, this process can take time. Therefore, key rotation should never be skipped in that situation. You simply cannot control every fork out there.

What Are Common Scenarios Behind a .env File Leak?

A .env file leak happens in a few recognizable ways. Still, each one has a slightly different priority action. The list below summarizes the most common cases and where to look first.

1. A new project skips setting up .gitignore, so the file enters the repository with the very first commit.
2. Someone pushes an urgent fix and runs git add . without noticing that it stages the file too.
3. A new contributor copies the real .env file instead of the .env.example template into the repository.
4. A CI/CD script writes a file containing real keys back into the repository during a test run.

Every scenario shares the same lesson. Once a file reaches a remote server, reverting the step that sent it there does not guarantee nobody saw it. In short, whatever the scenario, the first action is always key rotation.

Which Logs Should You Check After a .env File Leak?

Before rotating keys, check recent access logs for that key where available, on a database, payment provider, or email tool. This way, you spot whether misuse already happened. Access from an unexpected location or time can point to someone using the key.

Also note the gap between when the file was pushed and when you noticed it. Specifically, that window helps you judge how wide the risk is. A short window does not mean low risk, it only affects the odds. Still, checking logs never replaces rotation. Rotate the key regardless of what the logs show.

What Do Pre-Commit Hooks Do to Prevent This?

A pre-commit hook is a check script that runs automatically before a commit completes. As a result, it blocks the commit if it detects a file matching a secret pattern. This way, the hook catches a .env file at commit time, even if someone stages it by accident.

Open source tools like git-secrets and gitleaks set up this kind of hook. Likewise, both scan for known key formats. Some platforms now offer similar protection at push time too, a feature usually called push protection. Add the hook to your project's setup script so the whole team uses it, not just one developer's machine. A hook that only one person installed protects that one person's commits, not the project as a whole.

Why Is the .env.example Approach Recommended?

A .env.example file lists only the variable names, without real values. It can safely live in the repository. In practice, a new contributor copies this template and fills in their own local values. As a result, a real .env file never has to enter the repository at all.

This approach also documents which environment variables the project needs. A new developer figures out what to configure by reading .env.example. In other words, that file becomes part of the setup guide on its own. Keep it updated too. When a new variable gets added to the project, add its name to the template. Otherwise, new contributors are left guessing why the app fails to start.

What Alternatives Exist Beyond a Local .env File?

For small and mid-sized projects, a local .env file protected by .gitignore is usually enough. For larger teams or production environments, a dedicated secrets manager separates keys from the code repository entirely. Moreover, it also lets you control access centrally.

Your hosting provider's or cloud platform's environment variable panel is another option. As a result, values entered there never touch the repository. Whichever method you pick, the underlying rule stays the same. Keep secret values separate from code and from the repository, and limit who can access each one.

How Do You Prevent a .env Leak from the Start of a New Project?

Set up a .gitignore file with a .env line before your first commit. This way, that removes the risk from day one. If you want a refresher on core Git and GitHub commands, our Git and GitHub guide covers the basics.

If you are also deciding on package management, our article on what pnpm is and how it differs from npm and yarn touches on project setup steps too, where the .env file also needs correct configuration. For database decisions, our piece on when to use SQLite versus PostgreSQL and MySQL briefly covers where to store a connection string, another secret value.

Why Does a Post-Incident Review Matter for the Team?

A short review after the leak is fixed reduces the chance of the same mistake happening again. Note how the mistake happened, how long it took to notice, and what actions the team took.

This record is not about blame. Instead, it is about spotting a gap in the process. If a pre-commit hook was never set up, this incident is the right moment to add one. Keep the review short. Still, a lengthy meeting is not the point here. A quick note is often the simplest tool against the same mistake a year later.

Do Enterprise Projects Need Extra Security Layers?

A team working at enterprise scale should treat a .env file leak as both a code-level and an infrastructure-level risk. Our broader piece on website data security and encryption is worth a look here.

If you are building a custom software project and want environment variable management set up correctly from the start, our custom software development service folds this process into the delivery itself. Secrets management is only one part of web security overall. Our OWASP Top 10 web security vulnerabilities article covers related topics like misconfiguration and sensitive data exposure too.

A Lasting Checklist for Preventing a .env File Leak

The list below summarizes lasting safeguards worth checking regularly on both new and existing projects.

• Add .env and .env.* to .gitignore before the first commit, not after.
• Commit a .env.example template instead of real values.
• Set up a pre-commit hook such as git-secrets or gitleaks.
• Review staged files with git diff --cached before every commit.
• Keep production keys in a secrets manager, not in a file.

Review this checklist again whenever the project grows or the team changes. After all, it is not a one-time task, and a project that looked small a year ago may now hold far more sensitive data than it did at the start. When a new team member joins, walk through it together. This way, it speeds up onboarding and builds a shared habit over time. Handled calmly and in the right order, a .env file leak is a manageable incident. The one thing you should never delay is rotating the keys.