There's no way to remove them without modifying the history, so if anyone's pulled the changes, you may have to deal with that mess - see recovering from upstream rebase in man git-rebase
. This can be pretty bad, depending on your workflow - one way or another you'll probably have to make everyone aware that they need to switch to the "new" master branch, rebasing any work in progress on top of it.
If the commit were still on the tip, you could reset to the commit before it:
git reset --hard HEAD^
or amend it:
git rm test.wav
git commit --amend
But since it's no longer at the tip, your best bet is probably to probably do it with an interactive rebase:
git rebase -i <commit-before-mistake>
Change "pick" to "edit" on the commit you want to fix, then have at it! (or even remove the whole commit if that's okay)*
After you finish doing whichever of these you pick, you'll have to force the push, since it's no longer a fast-forward:
git push -f origin
* If you've subsequently committed modifications to these files, you'll get issues as you continue on in the rebase. They should be straightforward to deal with, since you just want the files gone. Of course, if there've been a hundred commits since then that'll all cause conflicts, you could have a look at git-filter-branch
. The relevant example from the man page is:
git filter-branch --index-filter ’git rm --cached --ignore-unmatch filename’ HEAD
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…