If I understand your problem correctly, you cannot push to the remote repository because your local history does not match to the remote history. This is what usually happens when you change hit commit locally with rebase or with filter branch.
If you push your local changes to the remote, you will rewrite some or all of the history of your projects. This means that every developer on your project will hit a bump when they try to git pull because now their local history is different from the remote's history. In a case like this, you usually want to message your co-developers about this happening because this can be pretty confusing as well as time consuming if they don't know what your filter-branch did.
Having said that, I believe you're looking for the --force option for git push. You want to run git push --force origin master. This will, as the name implies, overwrite whatever is in the remote with your local git history.
Please, read the docs before you do this and ask more questions if you have any as this is a potentially destructive thing to do.
Edit:
Your coworker has two option that I'm aware of. They can either go the fetch/reset route or the rebase route.
The fetch/reset route entails reseting your coworker's local repository to be exactly like the remote repository. This can be done with:
git fetch origin && git checkout master
git reset --hard origin/master
The rebase route entails applying your coworker's local commits on top of the newly cleaned master. In interactive mode, they'll have the chance to review every commit before including it. If the commit contains the file you wanted gone, they can simply omit it. This can be done with
git fetch
git rebase -i origin/master
The first option would be preferable if both of you agree that your repository should be the canonical one as it's faster. The second approach in turn gives you finer grained control.
You can check out this SO question that tackles the issue of pulling after force pushing more thoroughly: git pull after forced update
