How to Remove an Accidental .env Commit from Git History Using Git Bash on Windows

Accidentally committing a .env file to a Git repository is a common mistake, but it should be treated seriously because environment files often contain sensitive information such as API keys, database credentials, access tokens, and application secrets.

If you already pushed the repository to a remote platform such as GitHub, GitLab, or Bitbucket, simply deleting the file in a new commit is not enough. The file may still exist in the repository history and could still be recovered. To properly fix the problem, you need to remove the file from the entire Git history and then rotate any secrets that were exposed.

Important Warning Before You Begin

Rewriting Git history changes commit hashes. If other people are working on the same repository, they will need to re-sync their local copies after the history rewrite. Before making any changes, it is a good idea to create a backup of the repository.

git clone --mirror your-repo-url backup-repo.git

This creates a full mirror backup that you can restore if needed.

Step 1: Open Git Bash and Navigate to Your Repository

Launch Git Bash on your Windows machine and move into the root folder of your repository.

cd /c/path/to/your/repo

Make sure you are inside the correct repository before running any history-rewrite commands.

Step 2: Suppress the Filter-Branch Warning

Git displays a warning when using git filter-branch because it is an older tool. Since you already decided to use it, you can suppress the warning in Git Bash with the following command:

export FILTER_BRANCH_SQUELCH_WARNING=1

Step 3: Remove the .env File from All Commits

Run the following command exactly as shown:

git filter-branch --force --index-filter \
"git rm --cached --ignore-unmatch .env" \
--prune-empty --tag-name-filter cat -- --all

This command scans the entire repository history and removes the .env file from every commit where it exists. The --prune-empty option removes commits that become empty after the file is deleted, and the command applies to all branches and tags.

Step 4: Delete Backup References Created by Filter-Branch

After the rewrite, Git keeps references to the old history. These must be removed so the sensitive file is not still recoverable locally.

rm -rf .git/refs/original/

Step 5: Expire the Reflog

Next, clear the reflog so Git stops tracking the previous commit history.

git reflog expire --expire=now --all

Step 6: Run Garbage Collection

Now permanently clean up the orphaned objects from the repository.

git gc --prune=now --aggressive

This step is important because it helps remove the old objects containing the deleted .env file.

Step 7: Force Push the Cleaned History

If the repository was already pushed to a remote, you must force push the rewritten history.

git push origin --force --all
git push origin --force --tags

Be careful with this step. Force pushing rewrites the remote history, so other developers on the project must be informed.

Step 8: Prevent the File from Being Committed Again

Add the .env file to your .gitignore file so Git ignores it in the future.

echo .env >> .gitignore
git add .gitignore
git commit -m "Ignore .env file"

If the file is still being tracked in your current working tree, remove it from Git tracking without deleting your local copy:

git rm --cached .env
git commit -m "Remove .env from tracking"

Step 9: Verify the File Is Gone

To confirm that the file no longer exists in Git history, run:

git log --all -- .env

If the cleanup worked, this command should return no results.

Critical Final Step: Rotate All Secrets

Even after removing the file from Git history, you must assume that the contents of the .env file were exposed. If the repository was ever pushed to a shared remote, the secrets may already have been copied or scanned.

You should immediately rotate or replace any sensitive values that were stored in the file, including:

• API keys
• Database usernames and passwords
• Access tokens
• JWT or application secrets
• Third-party service credentials

What Team Members Should Do After the Rewrite

If other people are using the repository, ask them not to continue committing on the old history. They should re-clone the repository or reset their local branch to match the new remote history.

git fetch origin
git reset --hard origin/main

Replace main with the correct branch name if your repository uses a different default branch.

Conclusion

Accidentally committing a .env file is fixable, but the proper solution involves more than just deleting the file. Using Git Bash on Windows, you can remove the file from the entire repository history with git filter-branch, clean up the old references, force push the rewritten history, and then protect the repository by updating .gitignore. Most importantly, always rotate any exposed secrets after the cleanup is complete.