I used SourceTree on Windows 10 to commit and push two files and another commit + push after that. Now I noticed, there is sensible information in a comment in one of the files of the first push. I tried to delete that push completly, so it would not be stored in bitbucked anymore.
Here is what I did so far in the git bash console:
//Reset my local head: both achieved the same
git reset --hard MyLastGoodCommitHash
git reset --hard HEAD~2
//Now overwrite the original server content
git push -force
git gc
Now if I look up the commits in BitBucket, the last good commit is on head and in SourceTree origin/develop and develop are on the same good commit. Also "git status" is all clean and positive. But in SourceTree I still see the other two commits I did after that and I can check them out. Also in Bitbucked, if I use the search with the commit hash of the unwanted commits, I can still find them. So they are not actually deleted.
Two questions:
When you did the reset --hard
you orphaned the undesirable commits, meaning that no branch name points to them. (I am assuming here that no tag name points to them either; if it does, you need to delete that tag separately.)
Then when you pushed with force, you mirrored that state of affairs up to BitBucket.
So far, so good. But orphan commits are not immediately destroyed. If you want that, you need to say
git gc --prune=now --aggressive
That should remove the commits from the purview of your local Git (including Sourcetree). But it does not force BitBucket's Git to perform the same operation. If that's a serious concern, you'd probably need to open a ticket with the BitBucket people in order to ask them to do that for you.