According to https://docs.pact.io/getting_started/versioning_in_the_pact_broker the commit SHA should be used as version. I understand the reasoning behind that, but what I don't understand how this plays together later with can-i-deploy. When deploying, I do not use a commit SHA, but a real version (e.g. 1.1.10). I would need to know the commit SHA when doing the can-i-deploy. I guess I could look it up from Git, but then need Git access at that moment (which I currently don't have).

you can use your semantic versions and your commit sha. you require the commit sha in order to effectively checkout the provider code for deployed/released versions when new contracts requiring verification are published. if you are using BDCT, you will just have a provider contract in each environment which means you technically don’t need to replay the consumer interactions against the deployed/released provider versions. PactFlow would perform a cross compat check of the consumer contracts vs the deployed/released provider contracts have you setup webhooks or looked at them?

how should I use both? Yes, we have webhooks configured for verification and there we just do it with a Git tag. No need for the SHA. BDCT?

git tags might work, you get a payload in the webhook with the provider version, in your case it would be a tag you would checkout. BDCT is bi-directional contract testing, a pactflow only feature whereby the comparison is done by comparing consumer pact files against a provider description, such as an OpenAPI Document, rather than using the Pact framework to replay the interactions against a locally running provider. I mentioned this as you asked about it in PactFlow channel

to pick this up one last time: you suggest to use a version in the form 1.2.13-<sha>? This could actually work across all use cases.

correct, that follows our best practise guidelines as well, https://docs.pact.io/getting_started/versioning_in_the_pact_broker#guidelines