I would clarify that as never rebase after you push to a remote shared with others. I push and rebase my feature branch all the time. It's especially helpful when reviewing pull requests.
A feature branch pushed up to a shared repository is available to others, so at this point, it becomes a matter of communication and etiquette. I wouldn't force push to a remote branch if someone else is actively committing or has an upstream based off of mine, but that situation is rare on the teams I work on.
If we end up with a feature branch that other developers would work on (pretty rare), we would just treat it like we do for master. Create a new branch off it, rebase and merge. Same workflow.
While it may be rare, I prefer a workflow that doesn't have any gotchas. If we never rebase anything that has been pushed, our workflow never requires the developer to wonder if anyone else might be affected by a rebase. My devs have enough to think about. The more I can take off their plate, the better.
That's the nice thing about git. It supports different workflows. So whatever works best for your team is what you should do. There is no right or wrong way.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I would clarify that as never rebase after you push to a remote shared with others. I push and rebase my feature branch all the time. It's especially helpful when reviewing pull requests.
A feature branch pushed up to a shared repository is available to others, so at this point, it becomes a matter of communication and etiquette. I wouldn't force push to a remote branch if someone else is actively committing or has an upstream based off of mine, but that situation is rare on the teams I work on.
If we end up with a feature branch that other developers would work on (pretty rare), we would just treat it like we do for master. Create a new branch off it, rebase and merge. Same workflow.
While it may be rare, I prefer a workflow that doesn't have any gotchas. If we never rebase anything that has been pushed, our workflow never requires the developer to wonder if anyone else might be affected by a rebase. My devs have enough to think about. The more I can take off their plate, the better.
That's the nice thing about git. It supports different workflows. So whatever works best for your team is what you should do. There is no right or wrong way.