In particular, rebasing is very hazard-prone if someone else may have checked out your branch.
That's why you never rebase a published branch. This is easier to manage if your team uses a central repository as the 'official' repository and everybody pushes and pulls to that one. Then you know that your branches in your local repository are not public, not published, and safe for history-altering workflows like rebase. It's only the branches that you push that you're not allowed to rebase, at least not prior to the last push.
If your team doesn't use a central repository, and you're pushing and pulling between all of your local repositories, then I'd suggest using a naming convention for branches to distinguish public ones from private ones. Eg: start your private branch names with "DEV_". If someone else pulls a DEV_* branch, then they should expect that its history might change and they'll have to deal with that when it occurs.
My problem with that is my coworkers and I usually work on our own feature branch. Ideally I wouldn't push mine to the central repository until I'm done, so I can rebase on master without changing the public history, but at the end of the day I don't like to leave code only on my computer (what if my hard drive blows up??) so I push everything I don't want to lose.
Git is designed so that branching is cheap. Why not create your own development branch off of the feature branch? Then use the feature branch as an integration-only branch?
That's why you never rebase a published branch. This is easier to manage if your team uses a central repository as the 'official' repository and everybody pushes and pulls to that one. Then you know that your branches in your local repository are not public, not published, and safe for history-altering workflows like rebase. It's only the branches that you push that you're not allowed to rebase, at least not prior to the last push.
If your team doesn't use a central repository, and you're pushing and pulling between all of your local repositories, then I'd suggest using a naming convention for branches to distinguish public ones from private ones. Eg: start your private branch names with "DEV_". If someone else pulls a DEV_* branch, then they should expect that its history might change and they'll have to deal with that when it occurs.