You are right. Everyone else in this situation is wrong.

It sounds like you need to continue being "that guy" that annoys everyone by insisting on the process. Your boss isn't taking leadership on this, so you must do this instead. Pushing directly to master means that it is only a matter of time before your product will have a quality escape that impacts your customers and impacts your team.

You want to be the person that says "I told you so" in this case and has the communication (emails, etc.) to back this up. This should put you in a better position--you may even end up with your boss's job.

Another thing to consider is asking for better tools that make it easier for people to follow the process and harder to force push to master. GitHub and GitLab have a protected branch feature that only allows project owners to push to master. You can even lock down your repository so that merge requests must be approved by another developer and a QA person before they get merged. You can also get a build server that runs unit tests automatically on a merge/pull request. It sounds like your boss is on-board with this even though, so it shouldn't be too hard to convince him to start using for better tools.

Do not just wait for things to change after somebody notices a big screw up. You don't have control over what happens if management notices the developer team is making big mistakes. Call out the problems early and often for your own sake as much as the rest of the team's.

Of course, if you're tired of fighting, you always have the option to leave, but this could be a career-advancing opportunity for you if you choose to stay.

You are right. Everyone else in this situation is wrong.

It sounds like you need to continue being "that guy" that annoys everyone by insisting on the process. Your boss isn't taking leadership on this, so you must do this instead. Pushing directly to master means that it is only a matter of time before your product will have a quality escape that impacts your customers and impacts your team.

You want to be the person that says "I told you so" in this case and has the communication (emails, etc.) to back this up. This should put you in a better position--you may even end up with your boss's job.

Another thing to consider is asking for better tools that make it easier for people to follow the process and harder to force push to master. GitHub and GitLab have a protected branch feature that only allows project owners to push to master. You can even lock down your repository so that merge requests must be approved by another developer and a QA person before they get merged. You can also get a build server that runs unit tests automatically on a merge/pull request. It sounds like your boss is on-board with this even though, so it shouldn't be too hard to convince him to start using for better tools.

Do not just wait for things to change after somebody notices a big screw up. You don't have control over what happens if management notices the development team is making big mistakes. Call out the problems early and often for your own sake as much as the rest of the team's.

Of course, if you're tired of fighting, you always have the option to leave, but this could be a career-advancing opportunity for you if you choose to stay.

You are right. Everyone else in this situation is wrong.

It sounds like you need to continue being "that guy" that annoys everyone by insisting on the process. Your boss isn't taking leadership on this, so you must do this instead. Pushing directly to master means that it is only a matter of time before your product will have a quality escape that impacts your customers and impacts your team.

You want to be the person that says "I told you so" in this case and has the communication (emails, etc) to back this up. This should put you in a better position--you may even end up with your boss's job.

Another thing to consider is asking for better tools that make it easier for people to follow the process and harder to force push to master. Github and Gitlab have a protected branch feature that only allows project owners to push to master. You can even lock down your repository so that merge requests MUST be approved by another dev and a QA person before they get merged. You can also get a build server that runs unit tests automatically on a merge/pull request. It sounds like your boss is on-board with this even though, so it shouldn't be too hard to convince him to start using for better tools.

Do not just wait for things to change after somebody notices a big screw up. You don't have control over what happens if management notices the dev team is making big mistakes. Call out the problems early and often for your own sake as much as the rest of the team's.

Of course, if you're tired of fighting, you always have the option to leave, but this could be a career-advancing opportunity for you if you choose to stay.

You are right. Everyone else in this situation is wrong.

It sounds like you need to continue being "that guy" that annoys everyone by insisting on the process. Your boss isn't taking leadership on this, so you must do this instead. Pushing directly to master means that it is only a matter of time before your product will have a quality escape that impacts your customers and impacts your team.

You want to be the person that says "I told you so" in this case and has the communication (emails, etc.) to back this up. This should put you in a better position--you may even end up with your boss's job.

Another thing to consider is asking for better tools that make it easier for people to follow the process and harder to force push to master. GitHub and GitLab have a protected branch feature that only allows project owners to push to master. You can even lock down your repository so that merge requests must be approved by another developer and a QA person before they get merged. You can also get a build server that runs unit tests automatically on a merge/pull request. It sounds like your boss is on-board with this even though, so it shouldn't be too hard to convince him to start using for better tools.

Do not just wait for things to change after somebody notices a big screw up. You don't have control over what happens if management notices the developer team is making big mistakes. Call out the problems early and often for your own sake as much as the rest of the team's.

Of course, if you're tired of fighting, you always have the option to leave, but this could be a career-advancing opportunity for you if you choose to stay.