- #122
- #121
- #120
- #119
- #118
- #117
- #116
- #115
- #114
- #113
- #112
- #111
- #110
- #109
- #108
- #107
- #106
- #105
- #104
- #103
- #102
- #101
- #100
- #99
- #98
- #97
- #96
- #95
- #94
- #93
- #92
- #91
- #90
- #89
- #88
- #87
- #86
- #85
- #84
- #83
- #82
- #81
- #80
- #79
- #78
- #77
- #76
- #75
- #74
- #73
- #72
- #71
- #70
- #69
- #68
- #67
- #66
- #65
- #64
- #63
- #62
- #61
- #60
- #59
- #58
- #57
- #56
- #55
- #54
- #53
- #52
- #51
- #50
- #49
- #48
- #47
- #46
- #45
- #44
- #43
- #42
- #41
- #40
- #39
- #38
- #37
- #36
- #35
- #34
- #33
- #32
- #31
- #30
- #29
- #28
- #27
- #26
How to Completely Remove Sensitive Files from Git History?
Sometimes, sensitive files that shouldn’t have been pushed are accidentally pushed to Git, and how to completely remove them from the records is a problem. The following explains how to fix this using the environment variable
.envas example.🐑 Step 1: Avoid mistake again
First, add the file to
.gitignoreto avoid making the same mistake in the future.🌿 Step 2: Surface Cleaning
Run
git rm -r --cached .envto remove.envfrom Git, but this only removes it from the staging area and does not remove it from the history.rRecursively delete files in the target folder--cachedOnly remove from the staging area, will not delete the actual file.envis the name of the file or folder to be deleted
🧽 Step 3: Deep Cleaning
Run
git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch .env" HEADto modify the history.rRecursively delete files in the target folderfForce delete the file without confirmation--cachedOnly remove from the staging area, will not delete the actual fileignore-unmatchIgnore errors if the file does not exist. This option ensures that the command will execute successfully even if the.envfile does not exist in some commits- HEAD indicates that the filtering operation should be performed on the current latest commit and its ancestors
✨ Step 4: Push Changes
Use
git push --forceto forcefully overwrite the modified results to the remote.⚠ Note: Any sensitive information that has been made public should be considered leaked and should be replaced immediately. Therefore, directly replacing all sensitive information rather than modifying the records is the safest approach. Recently, there have been issues with accidentally pushing sensitive information to private repositories, making this method quite suitable for removal.
- #25
- #24
- #23
- #22
- #21
- #20
- #19
- #18
- #17
- #16
- #15
- #14
- #13
- #12
- #11
- #10
- #9
- #8
- #7
- #6
- #5
- #4
- #3
- #2
- #1