Сначала немного теории, чтобы обосновать практические рекомендации. Надеюсь, заскучать не успеете.
Что вообще происходит и откуда взялись ветки develop и release
Указанная вами статья – про модель рабочего процесса под названием git flow. Это в целом хорошая модель. Она была придумана, чтобы упорядочить бардак и анархию при совместной работе над кодом в больших проектах, и именно в них она эффективна. Если у вас сто человек работает над одним приложением, если вы вынуждены поддерживать старые версии (исправлять баги и критические уязвимости), если в день делаются сотни коммитов — берите, не пожалеете.
А для команд, которые
- немногочисленны, примерно до 10 человек;
- работают по agile и дробят задачи настолько, чтобы они делались за день-два;
- используют в основном самую последнюю версию продукта и не должны тащить старые версии;
... git flow попросту не нужен. Он создаёт больше проблем, чем решает.
Как сделать проще
Но зачем мне создавать ветку релиза если у меня в ветке девелоп уже все готово
Правильно! Вам и девелоп-то не нужен.
Для небольших команд и соло-разработки больше подходят «легковесные» модели организации рабочего процесса. Самая популярная называется GitHub Flow, от неё отличаются некоторыми деталями и бóльшей глубиной проработки GitLab Flow и Simple Git workflow (Atlassian).
Суть всех простых моделей рабочего процесса
- Есть единственная стабильная (постоянная, долгоживущая) ветка
master.
- Любая фича или исправление бага делается в отдельной ветке, которая ветвится от
master.
- Как только фича или багфикс готов, прошёл ревью и тестирование, соответствующая ветка мержится в
master. Потом ветка обязательно удаляется, чтобы не копить хлам.
Кроме очевидной простоты преимущество в том, что код не пишется «в стол» и не залёживается в релизных ветках, а выпускается как можно быстрее. Чем короче путь от идеи до продакшена — тем лучше для дела. Клиенты (пользователи) быстрее получают новые фичи, а вы быстрее получаете обратную связь от клиентов и деньги за эти фичи.
Как создавать и называть ветки
Принято начинать название feature-ветки с номера задачи в трекере задач.
git checkout master
git checkout -b 123-featurebranch
Вы же где-то ведёте список задач? Начните, если нет, и вот почему:
- Чтобы не держать их в голове, т.к. это ненадёжно и съедает ресурсы мозга
- Чтобы вы могли их оценивать, планировать, выбирать приоритеты
- Чтобы хранить информацию о багах и способах их воспроизвести.
- Тренировка для командной работы; вы наверняка не будете всю жизнь работать соло.
- Если проект в опенсорсе, то кто-нибудь придёт и заведёт вам задачу-пожелание или задачу-багрепорт. Или возьмёт вашу задачу и сделает, просто так, даром. Нельзя сделать задачу, которая не описана, верно?
Формулируйте маленькие, атомарные задачи, чтобы работа в ветке шла 1-3 дня, не больше. Это важно для работы соло и критически важно для командной работы.
Локальные ветки желательно тоже пушить на удалённый сервер, это хороший способ не потерять код, когда пролил чай в ноутбук, rm -rf /, пожар, кража, метеорит...
git push -u origin 123-featurebranch:
Как мержить ветки
Есть два основных способа:
Ветку можно замержить вручную, локально. В командной строке это так:
git checkout master
git merge --no-ff 123-featurebranch
git push
Если вы используете GitHub, GitLab, Bitbucket — можно открыть пулл/мерж-реквест и потом его замержить.
При этом фактически мержатся удалёные ветки, потом вам нужно будет подтянуть себе результат мержа (git pull).
Этот способ помогает проводить инспекцию кода в команде и разное автоматизированное тестирование, но если вы работаете один, мерж-реквесты почти не нужны.
Особенности:
- Мержить ветки нужно через
--no-ff, чтобы всегда создавался мерж-коммит. Он поможет вам просматривать историю, он помогает найти ветку, в которой был сделан коммит, и точно обозначает место, где эту ветку замержили, его можно отменить с помощью git revert. Любите мерж-коммиты, они вам пригодятся.
- Не нужно мержить в
master то, что не готово, не доделано и т.п. Ветка master священна, в ней всегда должен быть рабочий код.
- Никогда не нужно мержить ветку
master в ветку фичи. Исключения — подтягивание кода из мажорного релиза в долгоживущую ветку, разные ветки для разных тестовых окружений и прочие ситуации, которые почти не встречаются при соло-разработке небольшого проекта.
Релиз
Когда вы готовы сделать релиз, просто возьмите нужный мерж-коммит и повесьте на него тег. Используйте аннотированные (annotated) теги. В них сохраняется дата и автор, как в коммите. Таким образом сохранится информация о том, кто именно и когда принял решение о выпуске релиза.
git tag -a v1.0 -m "Version 1.0"
Чтобы запушить теги на удалённый сервер, делайте так:
git push --follow-tags
Параметр --follow-tags нужен для того, чтобы запушить только аннотированные теги и не пушить легковесные (lightweight), если они у вас вдруг есть.
Не отмечайте релизными тегами коммиты в feature-ветках. Замержили, протестировали результат, отметили тегом полученный мерж-коммит. Всё, что не в master, не может быть релизом.
Для создания номеров версий используйте семантическое версионирование.
Выпускайте релизы как можно чаще
Поскольку ветка master всегда обязана содержать работающий код и вы всегда мержите в неё только готовые фичи, каждый мерж — это фактически маленький релиз. При этом обязательно каждый раз пересобирайте приложение. Не факт, что его нужно сразу выпускать для всех пользователей — слишком частые обновления приложения могут их раздражать.
Но постарайтесь собрать группу бета-тестеров (начните с себя), для которых вы будете выпускать приложение после каждого мержа ветки в master. Таким образом вы ускорите получение обратной связи, а чем быстрее цикл ОС, тем быстрее развивается ваше приложение и ваши навыки. В этом суть Agile.
Практика
С учётом вышесказанного, предлагаю такой план действий.
- Замержить (слить) develop в master.
- Повесить на полученный мерж-коммит тег.
- Удалить ветку develop и не вспоминать о ней до поры.
