For those who missed the point: DEV BRANCH SHOULD BE A STABLE ONE.
No master/release branches are involved except for release/stabilization.

DEV branch must be kept STABLE at a daily basis. Said differently, feature branching gives you the freedom to work without be impacting by your teammates side effects. It is great but it comes with a price: you have in-turn the responsibility to push stable development into DEV branch.

Development activity is a two-sided coin namely work and delivery. Without a proper delivery your work – even the one you are pretty proud of - is worthless. By pushing your work without the proper level of quality you fail on the home stretch.

It is up to you to decide what you need to be confident before pushing (leveraging Resharper, Unit Test, teammate’s checks, application champion opinions, QA reviews, …).

Do not wait for a one-size-fits-all or ready-made solution. Be creative. Share your own method. Learn from others. Be constructive. Code reviewers should pay attention to details. Highlight potential shortcuts. Zoom out a bit. When creating a Pull Request your teammate ask not for an acquiescent feedback but for a watchdog. As teammate you know each other very well: you are aware of both skills and defects. It is there that experience is critical. See behind the broken Resharper rule. Does this code make sense with my own knowledge of the application? Help your teammate to see what he has missed. He will do the same for you the next time. Don’t be afraid to ask or point out. If you respect him it is your duty to do so. Whatever the outcome you will improve the overall team skill set.

We can fail but we have to rarely.
By failing, not only you break the continuous integration workflow but you damage the trust.
Trust inside and outside the team.
And trust is difficult to gain and very difficult to recover.

For those you already think about answering this. Take time. Take a deep breath. And remember you are first and foremost engineer. Engineers do not chat. They act.