Ответ
После успешного деплоя кода из релизной ветки в production, я завершаю цикл разработки, следуя принятому в команде Git workflow (чаще всего Git Flow или его упрощенной версии).
Типичная последовательность действий:
-
Мерж релизной ветки в main (master): Все финальные коммиты, включая возможные последние исправления версий (version bumps), уже находятся в релизной ветке. Ее нужно влить в основную ветку.
git checkout main git pull origin main git merge --no-ff release-1.5.0 # --no-ff создает merge commit для истории git push origin main -
Создание тега: Тег отмечает точную версию кода, которая находится в production. Это критически важно для возможности отката и четкой идентификации версий.
git tag -a v1.5.0 -m "Release version 1.5.0: Добавлена панель аналитики" git push origin v1.5.0 -
Удаление релизной ветки: После мержа и создания тега ветка больше не нужна.
# Удаление локальной ветки git branch -d release-1.5.0 # Удаление ветки на удаленном репозитории (GitHub/GitLab) git push origin --delete release-1.5.0 -
Обновление ветки разработки (develop): Если используется Git Flow, необходимо также влить изменения из main обратно в develop, чтобы она содержала все актуальные фиксы.
git checkout develop git pull origin develop git merge main git push origin develop
Важное замечание: В некоторых командах релизную ветку не удаляют сразу, а оставляют на случай срочных hotfix-ов для этой конкретной версии. После внесения всех hotfix-ов ветку все равно удаляют. Решение зависит от соглашений в команде.
Ответ 18+ 🔞
Да ты посмотри, какая красота! Код улетел в продакшен, всё работает, клиенты довольны. А теперь, ёпта, самое время не расслабиться, а довести дело до конца, чтобы в истории не осталось хвостов, как у мартышлюшки. Пора прибраться в гите по-взрослому.
Как обычно это делается, если не хочешь потом охуеть от бардака:
-
Запихиваем релизную ветку в main: Всё, что было в
release-1.5.0— святое, финальное. Теперь надо это аккуратно влить в главную ветку, чтобы весь мир знал, что это официальная версия.git checkout main git pull origin main git merge --no-ff release-1.5.0 # Флаг --no-ff — чтобы не потерять историю, а то потом будешь как слепой котёнок искать, где что слилось git push origin main -
Вешаем бирку, то есть тег: Это, блядь, самое важное! Без тега — всё, пизда рулю. Потом если что-то пойдёт не так, и нужно будет откатиться, ты будешь метаться как угорелый, не зная, на какую конкретно версию откатываться. А так — есть чёткая точка в истории.
git tag -a v1.5.0 -m "Релиз версии 1.5.0: Добавили эту вашу панель аналитики, на которую все орали" git push origin v1.5.0 -
Выносим релизную ветку на помойку: Всё, она своё отработала. Держать её — только мусорить в списке веток. Смело удаляем.
# Сносим локально git branch -d release-1.5.0 # И добиваем на удалёнке, чтобы другие тоже не путались git push origin --delete release-1.5.0 -
Приводим в порядок develop: Чтобы ветка разработки не отстала от жизни и знала всё, что уже в проде, нужно подтянуть в неё изменения из main. Иначе в следующий раз начнутся конфликты — овердохуища, волнение ебать.
git checkout develop git pull origin develop git merge main git push origin develop
Но есть нюанс, чувак: Иногда релизную ветку не убивают сразу, а оставляют как запасной парашют — вдруг вылезет срочный баг, и нужно будет делать хотфикс именно для этой версии. Но это уже как договоритесь в команде. В любом случае, рано или поздно, а манда с ушами должна быть убрана.
