Как вести версионирование semver в git?
=========================================

 Здравствуйте,  

хочу понять как рациональнее всего вести версионирование приложения, используя Git и Semver  
  

Мы работаем по принципу gitflow - есть ветка dev, в которую мерджатся коммиты,  

есть ветки, скопированные от dev, в которых ведётся разработка,  

и есть ветка master, в которую периодически мерджится ветка dev  
  

В файлах приложения есть несколько мест с указанием версии приложения (для простоты предположим, что такое место одно, но оно есть)  
  

Допустим, есть файл index.php в ветке dev внутри которого есть строка Version 1.0.0  

Далее разработчики приступают к созданию новой версии 1.1.0, они копируют ветку dev каждый в свою новую ветку, например, это будут ветки feat1 и feat2.  

Должны ли они при старте менять версию в файле index.php? Или это должен сделать один из разработчиков, например, в ветке feat1, или вначале мы должны изменить версию в ветке dev и создать новый коммит (в изменениях которого будет всего 1 файл index.php с изменённой версией, что не очень удобно).  

Или вообще разработчики не должны менять версию и на протяжении всей разработки версия в index.php будет оставаться 1.0.0, и в конце будет создан коммит в ветке dev, меняющий версию.  

Или в ветке dev вообще версия не должна меняться и такие изменения должны быть в ветке мастер? Получается, что dev мержится в мастер со старой версией и потом создаётся новый отдельный коммит в мастере после мерджа dev для того, чтобы поправить значение версии в index.php? Или, возможно, есть какой-то автоматический способ, который будет сам менять версию внутри файла index.php при мержде веток в dev или в мастер? А ещё в гите есть релизы/теги, как использовать этот функционал вместе с внесением изменений в index.php?  
  

В общем у меня большой пробел в области понимания как вести версионирование с помощью git, буду благодарен любой помощи или статьям на эту тему. 

 На сколько помню, gitflow предполагает бранч от дева перед релизом, в которую можно закоммитить в том числе изменение версии. 

> Допустим, есть файл index.php в ветке dev внутри которого есть строка Version 1.0.0 

  
  

По оригинальной задумке, версия указывается tag'ом в release ветке, а не в коде. Tag есть свойство commit'а, так что тот, у кого доступ к release есть, может отметить версию в коде единолично. При релизе, коммиты из ветки release попадают не только в master, но и в develop.  
  

 И у всех все хорошо.  
  

[https://danielkummer.github.io/git-flow-cheatsheet...](https://danielkummer.github.io/git-flow-cheatsheet/index.ru_RU.html)  
  

Про автоматические способы версиоирования - г таком не слышал, но возможно организовать автоматизированное версионирование только если придерживаться строгой конвенции по комментированию коммитов, если расширить своими тегами: <https://habr.com/ru/company/yandex/blog/431432/>