Rebasing is for advanced git users who knows what he's doing. If one does not know how to use it or not feeling comfortable in general, he can happily take his own code and try to merge it into the latest version instead. No one is judging.
For the rest of the world where projects are open-source, more often than not, not those projects inside a corporation where only the team lead is making decisions, it's a powerful tool to settle down conflicts sort out history.
One does not need to change the history again, if he's not comfortable with it. Just use git as if it's centralised VCS like SVN. No big deal. In fact, in corporations you do. There only needs to be one person who manages the repository.
If you mean front end developers, then yes, that's me.
First, it's not front end's responsibility to sanitise the input before executing the query because it's not the front end code which operates on the database. What if we have ten front ends? Implement it ten times?
Second, it's the back end who's executing the query so they are doing it anyway. Doing it in the front end code is a waste of time and electricity.
It's not a war zone outpost. There is no such thing as multiple layers of security. It's absurd to think that a piece of malicious data "beat up" the security code at the first spot, just to be knocked out by the same security code further down the road. If a piece is code is effectively sanitising the input then the best place to put it is where it's closest to the database, and it only needs to happen once.