Strictly speaking, one can never be 100% sure that a commit doesn't break a program.
Even with all sorts of testing possible (unit testing, integration, component, system, manual, UI, fuzz, security, penetration .. you name it). This is due to a Halting problem. A relevant extract from the Wikipedia follows below:
In computability theory, the halting problem can be stated as follows: "Given a description of an arbitrary computer program, decide whether the program finishes running or continues to run forever". This is equivalent to the problem of deciding, given a program and an input, whether the program will eventually halt when run with that input, or will run forever.
Alan Turing proved in 1936 that a general algorithm to solve the halting problem for all possible program-input pairs cannot exist. A key part of the proof was a mathematical definition of a computer and program, which became known as a Turing machine; the halting problem is undecidable over Turing machines.
If your PM cares about value and stable predictable delivery, you can perhaps convince him to have a look at SCRUM framework.
Others have given many interesting advices on how to interact with your PM. Personally, I would advise to set up a meeting with your PM and the team where you can discuss your processes. I am in strong favour of SCRUM, so this would be largely related to the SCRUM.
I would try explaining, that a goal of 100% is elusive. It cannot be reached. Never. In the whole universe. History has seen many such examples, demo of the release of Windows 95 for instance. So an outcome of this - software will fail.
Second, I would advice to adopt a practice, where you can deliver value, instead of the confidence of a commit. Something, that customers care about. Iteratively, repeatedly and reliably. Now, you can shift your PM's perspective from the 100%-assurance, to something that actually matters. That is: software is in use, your product is improving and the team delivering value to the customer.
Third, the should be a definition of done. Something, that a development team comes up with. This may include: documentation, implementation, testing, quality gates etc. This is very important, as you can now shift the subjectivity (that is "are you 100% sure?") to objectivity (that is all bullet points of the definition of done are completed).
There are other very important steps that SCRUM promotes. But all of them would allow developers to mitigate such frustration, and allow them to deliver objectively quantifiable result, compared to subjective assurance.