Здравствуйте,
хочу понять как рациональнее всего вести версионирование приложения, используя 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, буду благодарен любой помощи или статьям на эту тему.
По моему, это и есть ответ на мой вопрос. Мы этот шаг благополучно пропускали простым слиянием дева в мастер, следствием чего и возникла путаница с версионированием.
Допустим, есть файл index.php в ветке dev внутри которого есть строка Version 1.0.0
По оригинальной задумке, версия указывается tag'ом в release ветке, а не в коде. Tag есть свойство commit'а, так что тот, у кого доступ к release есть, может отметить версию в коде единолично. При релизе, коммиты из ветки release попадают не только в master, но и в develop.
Про автоматические способы версиоирования - г таком не слышал, но возможно организовать автоматизированное версионирование только если придерживаться строгой конвенции по комментированию коммитов, если расширить своими тегами: https://habr.com/ru/company/yandex/blog/431432/
Да, допустим версии для исходников хранить только в тегах, а при билде через gulp-replace подменять в нужных местах в файлах. Но как быть, например, с файлом changelog.md, если я хочу хранить его в репозитории - на каком этапе вносить изменения в данный файл?
Dubrovin, я изначально некорректно выразился, только в тегах хранить не нужно, если это не удобно, просто тэг первичный; подразумевается, что кто-то принял решение "вот с этого момента считать новой версией" и добавил тэг.
Если changelog в первый раз появляется в ветке develop, то изменять его лучше в той ветке. В случае хотфиксов в release ветке в крайнем случае можно сделать git rebase --onto develop release hotfix
