How to version semver in git?

Question

git

Hello,
I want to understand how it is most rational to version an application using Git and Semver.
We work according to the gitflow principle - there is a dev branch into which commits are merged,
there are branches copied from dev in which development is underway,
and there is a master branch, into which periodically the dev branch is merged
There are several places in the application files indicating the version of the application (for simplicity, we assume that there is only one such place, but it exists)
Let's say there is an index.php file in the dev branch that contains the line Version 1.0.0
Next, the developers start creating new version 1.1.0, they copy the dev branch each to their own new branch, for example, these will be the feat1 and feat2 branches.
Should they change the version in the index.php file at startup? Either one of the developers should do this, for example, in the feat1 branch, or first we should change the version in the dev branch and create a new commit (which will only have 1 index.php file with the changed version, which is not very convenient).
Or in general, developers should not change the version and throughout the development the version in index.php will remain 1.0.0, and at the end a commit will be created in the dev branch that changes the version.
Or in the dev branch, in general, the version should not change and such changes should be in the master branch? It turns out that dev is merged into the master with the old version and then a new separate commit is created in the master after the dev merge in order to correct the version value in index.php? Or perhaps there is some automatic way that will automatically change the version inside the index.php file when merge branches in dev or master? And there are also releases/tags in the git, how to use this functionality along with making changes to index.php?
In general, I have a big gap in understanding how to version with git, I will be grateful for any help or articles on this topic.

Answer 1

As far as I remember, gitflow assumes a branch from the dev before the release, into which you can commit, including changing the version.

Answer 2

Let's say there is an index.php file in the dev branch which contains the line Version 1.0.0

According to the original idea, the version is indicated by a tag in the release branch, and not in the code. Tag is a property of the commit, so whoever has access to release can mark the version in the code alone. When releasing, commits from the release branch get not only to master, but also to develop.
And everyone is doing well.
https://danielkummer.github.io/git-flow-cheatsheet...
About automatic versioning methods - I haven’t heard of this, but it’s possible to organize automated versioning only if you follow the strict convention for commenting on commits, if you expand it with your own tags: https:/ /habr.com/ru/company/yandex/blog/431432/