The accepted answer suggests that only the repo maintainer should increment the version number. This is the usually how things work in projects with a single maintainer, or in larger projects where there might be a number of maintainers but a single designated release manager.
As a counterpoint though, it's not uncommon that versioned internal libraries might not have a single owner or maintainer. Often in a case like this multiple parties could be bumping the version with only loose coordination. This situation isn't bad, assuming all contributors understand the release process and are trusted to execute it. In this situation, it's the responsibility of the party that merges second to correct the version number. So in the example, if Bob merges first then Carol is responsible for updating her request to bump the version to 0.1.2, and vice versa if Carol merges first Bob will produce 0.1.2.
An approach like this won't scale indefinitely, but there's nothing inherent in git or typical versioning strategies that requires there be a single party that is solely responsible for producing new versions of a software package.
In particular git itself is a distributed VCS, and if a version number is stored in a tracked file then that file is managed the same way as any other file. Concurrent edits to the version file can produce conflicts and will have to be resolved by human intervention, the same way as any other tracked file. The only additional consideration is that version changes typically come along with a publishing process and re-publishing the same version is either a bad idea or not permitted depending on the ecosystem, so some additional care has to be taken in the publishing process, but ultimately there is a correct answer to "what is the correct value for the version file?" that depends on the history of the project, when that history changes (e.g. a merge or rebase occurs) that answer may change but there doesn't need to be a single arbiter of releases to produce a correct answer.