Как правильно отправить релиз на git?

И вот готов у меня релиз первой версии, я следую совету этой статье на хабре и тут описано, что нужно создать ветку релиза и как она будет доведена до выпуска то слить ее в мастер и в девелоп, после чего удалить ее.

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

Но у меня локально есть только ветка девелоп и удалено есть девелоп и мастер.

Вопрос вот в чем, будет ли правильно сделать коммит на локальной ветке девелоп , поставить на нее таг, слить в удаленный девелоп и уже удаленный девелоп смержить с удаленным мастером.

Я просто не уверен, что эта концепция правильная и второе я не уверен, что можно делать мерж на удаленых ветках.

Посоветуйте как правильно сделать?

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

Что вообще происходит и откуда взялись ветки develop и release

Указанная вами статья – про модель рабочего процесса под названием git flow. Это в целом хорошая модель. Она была придумана, чтобы упорядочить бардак и анархию при совместной работе над кодом в больших проектах, и именно в них она эффективна. Если у вас сто человек работает над одним приложением, если вы вынуждены поддерживать старые версии (исправлять баги и критические уязвимости), если в день делаются сотни коммитов — берите, не пожалеете.

А для команд, которые

немногочисленны, примерно до 10 человек;
работают по agile и дробят задачи настолько, чтобы они делались за день-два;
используют в основном самую последнюю версию продукта и не должны тащить старые версии;

. git flow попросту не нужен. Он создаёт больше проблем, чем решает.

Как сделать проще

Но зачем мне создавать ветку релиза если у меня в ветке девелоп уже все готово

Правильно! Вам и девелоп-то не нужен.

Для небольших команд и соло-разработки больше подходят «легковесные» модели организации рабочего процесса. Самая популярная называется GitHub Flow, от неё отличаются некоторыми деталями и бóльшей глубиной проработки GitLab Flow и Simple Git workflow (Atlassian).

Суть всех простых моделей рабочего процесса

Есть единственная стабильная (постоянная, долгоживущая) ветка master .
Любая фича или исправление бага делается в отдельной ветке, которая ветвится от master .
Как только фича или багфикс готов, прошёл ревью и тестирование, соответствующая ветка мержится в master . Потом ветка обязательно удаляется, чтобы не копить хлам.

Кроме очевидной простоты преимущество в том, что код не пишется «в стол» и не залёживается в релизных ветках, а выпускается как можно быстрее. Чем короче путь от идеи до продакшена — тем лучше для дела. Клиенты (пользователи) быстрее получают новые фичи, а вы быстрее получаете обратную связь от клиентов и деньги за эти фичи.

Как создавать и называть ветки

Принято начинать название feature-ветки с номера задачи в трекере задач.

Вы же где-то ведёте список задач? Начните, если нет, и вот почему:

Чтобы не держать их в голове, т.к. это ненадёжно и съедает ресурсы мозга
Чтобы вы могли их оценивать, планировать, выбирать приоритеты
Чтобы хранить информацию о багах и способах их воспроизвести.
Тренировка для командной работы; вы наверняка не будете всю жизнь работать соло.
Если проект в опенсорсе, то кто-нибудь придёт и заведёт вам задачу-пожелание или задачу-багрепорт. Или возьмёт вашу задачу и сделает, просто так, даром. Нельзя сделать задачу, которая не описана, верно?

Формулируйте маленькие, атомарные задачи, чтобы работа в ветке шла 1-3 дня, не больше. Это важно для работы соло и критически важно для командной работы.

Локальные ветки желательно тоже пушить на удалённый сервер, это хороший способ не потерять код, когда пролил чай в ноутбук, rm -rf / , пожар, кража, метеорит.

Как мержить ветки

Есть два основных способа:

Ветку можно замержить вручную, локально. В командной строке это так:

Если вы используете GitHub, GitLab, Bitbucket — можно открыть пулл/мерж-реквест и потом его замержить. При этом фактически мержатся удалёные ветки, потом вам нужно будет подтянуть себе результат мержа ( git pull ). Этот способ помогает проводить инспекцию кода в команде и разное автоматизированное тестирование, но если вы работаете один, мерж-реквесты почти не нужны.

Особенности:

Мержить ветки нужно через --no-ff , чтобы всегда создавался мерж-коммит. Он поможет вам просматривать историю, он помогает найти ветку, в которой был сделан коммит, и точно обозначает место, где эту ветку замержили, его можно отменить с помощью git revert . Любите мерж-коммиты, они вам пригодятся.
Не нужно мержить в master то, что не готово, не доделано и т.п. Ветка master священна, в ней всегда должен быть рабочий код.
Никогда не нужно мержить ветку master в ветку фичи. Исключения — подтягивание кода из мажорного релиза в долгоживущую ветку, разные ветки для разных тестовых окружений и прочие ситуации, которые почти не встречаются при соло-разработке небольшого проекта.

Релиз

Когда вы готовы сделать релиз, просто возьмите нужный мерж-коммит и повесьте на него тег. Используйте аннотированные (annotated) теги. В них сохраняется дата и автор, как в коммите. Таким образом сохранится информация о том, кто именно и когда принял решение о выпуске релиза.

Чтобы запушить теги на удалённый сервер, делайте так:

Параметр --follow-tags нужен для того, чтобы запушить только аннотированные теги и не пушить легковесные (lightweight), если они у вас вдруг есть.

Не отмечайте релизными тегами коммиты в feature-ветках. Замержили, протестировали результат, отметили тегом полученный мерж-коммит. Всё, что не в master , не может быть релизом.

Для создания номеров версий используйте семантическое версионирование.

Выпускайте релизы как можно чаще

Поскольку ветка master всегда обязана содержать работающий код и вы всегда мержите в неё только готовые фичи, каждый мерж — это фактически маленький релиз. При этом обязательно каждый раз пересобирайте приложение. Не факт, что его нужно сразу выпускать для всех пользователей — слишком частые обновления приложения могут их раздражать.

Но постарайтесь собрать группу бета-тестеров (начните с себя), для которых вы будете выпускать приложение после каждого мержа ветки в master . Таким образом вы ускорите получение обратной связи, а чем быстрее цикл ОС, тем быстрее развивается ваше приложение и ваши навыки. В этом суть Agile.

Практика

С учётом вышесказанного, предлагаю такой план действий.

Замержить (слить) develop в master.
Повесить на полученный мерж-коммит тег.
Удалить ветку develop и не вспоминать о ней до поры.

будет ли правильно сделать коммит на локальной ветке девелоп, поставить на нее таг.

Я просто не уверен, что эта концепция правильная

Она одновременно может быть правильной, и не подходящей конкретно вашему проекту.

я не уверен, что можно делать мерж на удаленных ветках.

Нельзя. Вы синхронизируете локальные ветки с удаленными (fetch/pull), мержите, и синхронизируете удаленные с локальными (push). На самом деле даже ветка origin/master тоже является локальной.

Посоветуйте как правильно сделать?

IT - такая интересная область, в которой множество правильных ответов.

В частности, для проекта с одним разработчиком можно обойтись одной веткой master и помечать релизы тэгами.

git flow и прочие методики работают хорошо, только если вы понимаете какие именно проблемы они решают. Пока ваш проект таких проблем не содержит, методики сами лишь усложняют жизнь.

1 создать rc ветку 2 смержить с вашей dev 3 вылить rc ветку

Так делается для того, что в случае креша можно было спокойно переключиться на предыдущую стабильную ветку, пофиксить новую rc ветку и опять зарелизить. Удалять ветки крайне не рекомендую. На практике часто приходиться доставать изменения в других ветках. Но если у вас веток перевалило за N и вы в них уже путаетесь, тогда можно почистить и только локально (git branch -d <ветка>)

50 коммитов. А модуль2 в r2 тоже N коммитов. Смержили. Удалили r1 (полностью на сервере и локально git push origin :the_remote_branch). И вдруг ветка поломалась или модуль2 не нужен. Короче требуется восстановить только rc1. И начинается поиск коммита по хешу, а коммитов непонятно сколько. Но это не предел, представьте ситуацию когда вы помержились потом сделали доработку в rc1 потом в rc2 опять помержились. В этой ситуации ветку искать очень сложно.

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

Вся прелесть веток не только в том, что вы получаете свою копию проекта, но и в том, что ваши коммиты будут логически объединены:

Т.е. вы будете потом видеть, что эти 5 коммитов были сделаны в рамках реализации той фичи

Не слушайте никого, что т.к. вы девелопер одиночка, то вам можно не следовать всем этим правилам gitflow. Учитесь работать правильно изначально!

Используя модель git-flow и работая с чистым git , да, вы будете выполнять лишние команды, что будет замедлять вас. Но это не проблема этой модели, а ваша проблема, т.к. вы не используете нужные утилиты ;-) Например я использую gitflow-avh, отконфигурировал .gitconf

и добавил алиасы в .bashrc

И работаю в консоли со всеми этими "не нужными" ветками быстрее, чем используя всякие графические тулзы, и бонусом получаю красивую историю, т.к. следую git-flow . Плюс под рукой остаются вся мощность git (обычно графические утилиты реализуют далеко не все фичи, а в основном только базовые). Подробнее о том, как настроить окружение, можно посмотреть тут.

Не знаю как у вас, но в самом начале, когда я познакомился с git , у меня возникала путаница с пониманием того что есть ветки master , production , develop . Поэтому я для себя решил так. ИМХО:

Ветка, которую катим на боевые сервера - production
Ветка, в которой ведется разработка (то куда вы мержите ваши фичи) - develop

Да, и во многих статьях под веткой master подразумевают production

Но у меня локально есть только ветка девелоп и удалено есть девелоп и мастер.

Отвечая на ваш вопрос как делать правильно я обращу ваше внимание на то, что Ваша работа всегда происходит локально, а с удалённым репозиторием вы делаете только синхронизацию. Поэтому

Вы делаете мерж вашего локального девелоп в локальный мастер
Вы делаете push вашего локального мастера в удалённый

Ну а далее я поддержу вот этот развернутый ответ, за исключением никоторых моментов:

Есть единственная стабильная ветка master.

Её нельзя назвать стабильной, пока вы не проведёте тестирование. Во время тестирования вы можете обнаружить баг, для фикса которого вы сделаете дополнительный коммит в master . Соответственно на предыдушем коммите ваша ветка является не стабильной.

По этой причине придумали ветку release . В которой можно делать хоть сколько угодно итераций тестирования по завершению которых вы выпускаете свой релиз и делаете мерж ветки в master / production и develop .

Пусть что там не говорят, но в любом случаем вы должны иметь следующие ветки:

production ветка - это ветка в которой гарантированно любой коммит готов к деплою.
develop ветка - это ветка в которую вы сливаете ваши фичи
hotfix ветка - эта ветка (чтобы не делать cherry-pick из прод в дев) в которой вы делаете фиксы
release ветка - для спокойного создания релизов

Поэтому даже если вы программист одиночка я рекомендую вам следовать git-flow модели, чтобы уметь работать правильно

В том случае, что Вы описали Вы можете поступить 2 способами:

Пойти по пути git flow, создав release ветку и тут же её завершив.
Сделать слияние develop с master самостоятельно и [опционально] поставив tag на master.

Оба способа дадут одинаковый результат, но используя второй, нужно проделать меньше работы. Поэтому, на мой взгляд, стоит воспользоваться именно им.

Тогда вообще зачем нужны release ветки? Всё дело в том, что любая методология является набором некоторых принципов, которые были выработаны годами либо одним автором, либо группой авторов. git flow вырос из командной разработки, где, как правило, есть отдельные люди занимающиеся тестированием продукта, а могут ещё быть и те, кто продукт должен принять.

Вот здесь хорошо вписываются release ветки. К примеру, Ваша команда сделала определённые набор функционала, который требуется к выпуску, скажем, версии 1.0. Всё это находится в ветке develop и у Вас нет никакой уверенности, что код правильный(он не оттестирован как следует, и главный менеджер ещё тоже не изучал функционал). Вы могли бы выложить результат из develop, но что делать с простаивающими разработчиками, которые не могут вливать новый функционал в develop, т.к. есть чётко очерченный круг функционала выпуска?

Чтобы разработчики не простаивали — выпускаем release ветку, в которой уже нельзя добавлять никакого нового функционала, но должны быть исправлены любые найденные ошибки и неточности. Когда все найденные ошибки исправлены, и замечания учтены — release ветка закрывается, сливается с master и продукт выпускается.

Как Вы можете видеть, для Вас, как для одиночки, release ветка не нужна. Поэтому, просто обходите этот шаг стороной, если не хотите выполнять дополнительной работы и помните, что любая методология это набор общих принципов и правил, и почти всегда методологии нужно адаптировать к нуждам конкретного случая — если Вы не понимаете, как что-то использовать, то почти наверняка Вам это не нужно.

📎📎📎📎📎📎📎📎📎📎