Git delete file from specific commit

Question

I have to delete a file from previous commmit, I have delete that file from last commit and master branch but that file still showing from different commit

 https://github.com/username/repo/blob/ccf60c8e811d911565e5f88e454dd85e45d89d1e/.env

but i have deleted .env file from master branch.

i have tried below command in local -

git filter-branch --index-filter 'git rm --cached --ignore-unmatch .env' -- --all

output was below listed -

 Rewrite 83586a63ecb950c5262c851dbbfd521ef5ec8a65 (95/97) (4 seconds passed, remaining 0 predicted)    
 WARNING: Ref 'refs/heads/feature/dependencies' is unchanged
 WARNING: Ref 'refs/heads/master' is unchanged
 WARNING: Ref 'refs/heads/mff1' is unchanged
 WARNING: Ref 'refs/remotes/origin/master' is unchanged
 WARNING: Ref 'refs/remotes/origin/mff1' is unchanged
 WARNING: Ref 'refs/stash' is unchanged 

after that .env file still showing on that link -

 https://github.com/username/repo/blob/ccf60c8e811d911565e5f88e454dd85e45d89d1e/.env

2nd try-

than i used

 git obliterate .env

its rewrite all commit but still could not delete .env file from repo.

Please guide me how to delete that file?

thanks...

Answer 1

By default, git will not delete unreferenced blobs straight away; you need to trigger a garbage collection ( git gc ) on the target copy of the repo.

(I'm searching the github docs to see how you can trigger this on a repo, it would be an action available to a repo's administrator; other servers (like gitlab) call it "housekeeping"

[edit] couldn't find it at a quick glance, contact github's tech support

a question you can ask is: "can you please run a git gc on my repo?" )

---

Regardless of the above:
if any secrets have been pushed to that repo, these secrets have been published .

You should revoke those secrets and create new ones (eg: change passwords, generate new keys, etc...).

Answer 2

You literally cannot remove commits. You can only add commits.

Suppose that you have an existing Git repository that has 10 commits in it (each of the ten commits has a big ugly hash ID). The last five of the ten commits have a file named bad in them. To simplify talking about the repository, let's suppose that these ten commits are found by a single main branch (named master or main or whatever), with no other branch names.

If you use git filter-branch to "remove" the bad file named bad , what you get is a repository with fifteen commits. Ten of the fifteen commits lack the file named bad , and five of the fifteen commits have the filed named bad in them. These are the same five commits from before; All we did was add five new-and-improved commits. the bad commits remain.

The commits that you will find by starting from the last commit in the main branch (whatever it is named) and working backwards will be the ten good commits. The five bad commits will be hard to find: the only way to find them will be by using the raw hash IDs of any of these five bad commits, eg, by having saved the hash IDs earlier. Using a GitHub URL that has the raw hash ID in it counts as using the hash ID: you will find the commit this way.

You can now push the updated commits (with --force ) to GitHub, but this will merely add the five good commits to the repository over on GitHub. That repository will now have all fifteen commits.

This is what you are doing right now. "Deleting" the bad commits doesn't actually delete anything. Eventually, those commits, if un-find-able, will drop away; or, you can have GitHub support remove them sooner. But anyone who saved the raw hash ID will be able to get the file back until GitHub eventually removes the commits, if they ever do.