процесс по git flow в репозитории, если над проектом может работать комманда разработчиков и его могут fork'ать и предлагать правки в коде другие люди
Я вижу процесс таким образом:
1) Вливаю v0.1.0 в main в удаленный репозиторий
2) Локально ответвляю от main - develop и делаю push -u develop в репозиторий
Получаются две одинаковые ветки локально и в репозитории: main и develop
3) От develop создаю локально feature_branch для разработки фичи, когда завершаю работу над фичей - делаю push -u feature_branch в репозиторий и делаю PR из feature_branch в develop
4) Локально перехожу у себя в develop и делаю pull
5) Создаю ветку release от develop
6) Тестирую код, меняю SemVer, ставлю тег и делаю push -u release в репозиторий
7) В репозитории делаю PR из release в main
Все ли верно я понимаю и как потом грамотно актуализировать ветки dev и main в репозитории и у себя локально ?
На мой взгляд как-то странно делать 2 merge коммита c PR из release - и в main, и в develop ?
сейчас модно trunk based
Да я понимаю, но я организацию грамотного work flow совсем недавно начал изучать, хочется изучить сначала на классике ) Если вас не затруднит - буду благодарен, если проясните несколько моментов, т.к. в литературе везде по разному пишут и упускают некоторые моменты
почитай как устроены open-source репозитории, там тот-же подход
Да там часто либо новые методологии с rebase итд, либо один main и каша ) Если бы найти какой-нибудь эталонный git flow репозиторий... К примеру не могу понять, tag с SemVer проставлять в release ветке или уже после PR в main ветке ? И еще есть несколько моментов, которые нигде не оговариваются в доках
Обсуждают сегодня