You're not wrong there at all. That is a very reasonable assumption and I think the default behaviour with most early CD pipelines. Every commit leads to a deploy event.
However, this can be changed, so that not all commits/pushes are treated equally during CD. Either by using rules to ignore changes to certain sub-directories / files or through having reproducible builds and skipping the process restarting parts when the resulting artefacts between two commits haven't changed (e.g. the digest of a docker image not changing from one commit to the next).
This is often an optimisation though, and takes time/effort to put in place.
However, this can be changed, so that not all commits/pushes are treated equally during CD. Either by using rules to ignore changes to certain sub-directories / files or through having reproducible builds and skipping the process restarting parts when the resulting artefacts between two commits haven't changed (e.g. the digest of a docker image not changing from one commit to the next).
This is often an optimisation though, and takes time/effort to put in place.