For the sake of accuracy, commit access is actually mostly a maintenance role…making sure the repository doesn’t get vandalized and that only commits that have wide support or are otherwise no-brainers get merged. As such, people with commit access are called maintainers.
If a maintainer were to start merging stuff irresponsibly, other developers would either insist on revoking their commit access or would fork the project to a separate repository and get other developers to join that one instead where commit access can be reassigned however they want.
Anyone can fork the codebase repository and make arbitrary changes to their own repository. They can build a client from their own repository and run that instead if they want. They can also make binary builds for other people to run.
If someone wants to merge a change they’ve made in their own repository into Bitcoin Core, they can submit a pull request. Once submitted, anyone can review the changes and comment on them regardless of whether or not they have commit access to Bitcoin Core itself. These discussions often go on for many days, with the original author taking suggestions from peers and making changes and corrections. Only once there are no more reasonable concerns will a maintainer merge the code.
Consensus changes go well beyond code changes. There are two basic kinds of consensus changes: hard forks and soft forks. Hard forks result in a chain split, where different nodes will end up on separate chains and will see a different ledger, unless all nodes on the network are updated. Soft forks do not result in a chain split as long as they are ultimately supported by sufficient hashpower since that will ensure all nodes ultimately converge on the chain with the most proof-of-work.
Despite one chain having more hashpower than the other at the time of a fork, it can still be overtaken in hashpower later on. Hard forks and soft forks can be further subdivided into different classes depending on their behavior in these situations.
In order to make a consensus change, it is not only necessary to merge the code into the repository — it is also necessary to get other people on the network to run that code. And Bitcoin Core has, as a project, generally been very conservative when it comes to these sorts of changes. These changes require a deep understanding of not only the protocol but of game theory and politics as well, particularly if a change is likely to cause different players to have divergent interests.
Consensus changes that are likely to cause divergent interests are almost always avoided. And ensuring that a consensus change will not cause divergent interests is in general an extremely difficult problem which even seasoned experts sometimes get wrong. Any introduction of an incompatibility is liable to create divergent interests on the network and is not to be taken lightly!
