I'm not saying this for the good of your team, even though it will be good for your team. I'm telling you this for your own sake: don't martyr yourself for your software development opinions!

Software engineering attracts a certain type of mind. Our thinking is necessarily precise -- the computer does exactly what we tell it to do, and if we tell it to do something incorrectly, that's on us. In general, this leads to strong views on how development should be done. Every programmer I've met that has two or more years of development experience has already developed strong beliefs about sustainable, maintainable development conventions, and does not hesitate to inform you about them.

This is fine in isolation -- you have your principles, you stick to them, and your code is cleaner and more maintainable as a result. You always use spaces, you use the gitflow workflow when branching in source control, you always promote through dev/stg/prd environments, you use the pytest framework for unit tests, etc etc. You are a paragon of forward-thinking development discipline.

Problems arise, though, when you must work on a project with an engineer who doesn't share your ideology. Yes, I use that word on purpose: "best practices" are ideology, not universal laws. Good software can be written in myriad ways, and so two skilled engineers can have equally valid, yet diametrically opposed, opinions about development practices.

And so we come to the hard truth of my rant: it is better to conform to the development practices accepted by the majority of your team than to try and force them to accept your convictions. Nothing tanks productivity on a team faster than arguing about development practices and tooling. It might be hard for you to accept, but your pet convention is not so superior that it is worth wasting engineer-weeks (or even engineer-days!) arguing about.

If you just can't accept the idiotic processes your team has in place, and you feel so strongly about your development conventions that you find yourself trying to convince your coworkers again and again to change their ways, it's probably best for everyone if you try and find a role on a new team that shares your convictions. You will be happier, your former team will be happier, your new team will welcome you with open arms, you will crush all your performance reviews, and society will be improved by all the code you will be shipping.