Как вернуться на предыдущую версию ветки release?

Как вернуться на предыдущую версию ветки release?

Этот вопрос касается управления версиями и работы с Git. Есть несколько способов в зависимости от того, на каком этапе разработки вы находитесь и хотите ли вы полностью отменить изменения или просто откатиться назад.

Понимание ветки release

Release ветка — это ветка для выпуска новой версии приложения. Обычно она создаётся из develop и мёржится в main/master с тегом версии.

main        o---o---o---o (v1.0)
             \ /
release      o---o---o (hotfixes)
             / \
develop     o---o---o---o

Способ 1: Локальное откатывание (если ещё не закоммитили)

Отменить последний коммит

# Отменить последний коммит, сохраняя изменения
git reset --soft HEAD~1

# Отменить последний коммит и все изменения
git reset --hard HEAD~1

# Отменить последний коммит, оставляя файлы, но без индекса
git reset --mixed HEAD~1  # (по умолчанию)

Пример

# Текущая history ветки release
# abc123 - Неправильное изменение
# def456 - Прошлая версия (хорошая)

# Вернуться на прошлую версию
git reset --hard def456

# Или на один коммит назад
git reset --hard HEAD~1

Способ 2: Восстановление после коммита (не запушили)

Использование reflog

# Показать историю всех операций
git reflog

# Пример вывода:
# abc123 HEAD@{0}: commit: Bad change
# def456 HEAD@{1}: commit: Good version
# ghi789 HEAD@{2}: merge: Merge branch 'develop'

# Вернуться к предыдущему состоянию
git reset --hard HEAD@{1}

Способ 3: Откатывание после push (уже в удалённом репозитории)

Создание нового коммита, отменяющего изменения

# Показать коммиты ветки
git log --oneline release

# Пример:
# abc123 - Bad change
# def456 - Good version
# ghi789 - Previous

# Создать новый коммит, отменяющий изменения (SAFEST)
git revert abc123

# Теперь история выглядит так:
# 123xyz - Revert "Bad change"  <- Новый коммит
# abc123 - Bad change
# def456 - Good version
# ghi789 - Previous

Способ 4: Силовой reset (если никто не зависит от ветки)

# ❌ ОПАСНО! Переписывает историю
# Используй только если уверен, что никто не работает на этой ветке

# Вернуться на коммит локально
git reset --hard def456

# Переписать историю на удалённом хранилище
git push origin release --force

# Или безопаснее
git push origin release --force-with-lease

Способ 5: Создание новой версии (рекомендуется для release)

# Когда нужна новая стабильная версия

# 1. Создать новую ветку от стабильного коммита
git checkout -b release/v1.0.1 def456

# 2. Добавить исправления если нужны
# ... делаем изменения ...

# 3. Закоммитить
git commit -m "v1.0.1 release"

# 4. Создать тег версии
git tag -a v1.0.1 -m "Version 1.0.1"

# 5. Запушить
git push origin release/v1.0.1
git push origin v1.0.1

Практический пример: Workflow с release

# Ситуация: release была обновлена плохим коммитом
# Текущая версия в release: v1.0.0 + bad commit
# Нужна версия: v1.0.0 (стабильная)

# 1. Посмотреть историю release ветки
git log --oneline release -10
# abc123 - Fix: Update CI config (BAD)
# def456 - v1.0.0 release
# ghi789 - Merge from develop

# 2. Вариант A: Отменить через revert (БЕЗОПАСНО)
git revert abc123
git push origin release

# 2. Вариант B: Откатиться к стабильной версии (ТОЛЬКО если ещё не использовалась)
git reset --hard def456
git push origin release --force-with-lease

# 3. Вариант C: Создать новую ветку от стабильной версии
git checkout -b release/hotfix def456
git cherry-pick <нужные коммиты>
git push origin release/hotfix

Откатывание в production (очень важно!)

# Если release уже установлена в production

# 1. Создать hotfix ветку
git checkout -b hotfix/rollback main

# 2. Откатиться к предыдущей версии (через новый коммит)
git revert <плохого коммита>

# или

git reset --hard <хорошей версии>
git commit --allow-empty -m "Rollback to stable version"

# 3. Мёрж в main
git checkout main
git merge --no-ff hotfix/rollback -m "Hotfix: Rollback to stable"

# 4. Тег новой версии
git tag -a v1.0.1-hotfix -m "Rollback from bad release"

# 5. Деплой
git push origin main
git push origin v1.0.1-hotfix

Шпаргалка: Что выбрать?

┌─ Локально (не запушили)?
│  └─> git reset --hard HEAD~1
│
├─ Уже запушили, но другие не работают на ветке?
│  └─> git reset --hard <commit>
│      git push --force-with-lease
│
├─ Другие уже работают на ветке?
│  └─> git revert <commit>
│      git push
│
└─ Production? Срочный rollback?
   └─> git revert (создать новый коммит)
       или
       создать hotfix ветку
       Никогда --force!

Команды в контексте release

# Посмотреть теги (версии)
git tag -l

# Посмотреть аннотированный тег
git show v1.0.0

# Откатить release ветку на тег
git checkout release
git reset --hard v1.0.0

# Или через checkout
git checkout v1.0.0
git checkout -b release-hotfix

Git Flow подход (популярный стандарт)

# Release ветка создаётся из develop
git checkout -b release/v1.0.0 develop

# Исправления только в release (если нужны)
git commit -m "Version bump"

# Мёрж в main с тегом
git checkout main
git merge --no-ff release/v1.0.0
git tag -a v1.0.0 -m "Release v1.0.0"

# Обратный мёрж в develop
git checkout develop
git merge --no-ff release/v1.0.0

# Удалить release ветку
git branch -d release/v1.0.0

# Если нужна новая версия
git checkout -b release/v1.0.1 main^  # Откатиться на коммит перед v1.0.0

Важные правила

1. Не используй --force на shared ветках — используй --force-with-lease
2. Используй revert для shared веток — создаёт новый коммит вместо переписания
3. Всегда проверяй что откатываешь — git diff перед reset
4. Делай бэкап — создай копию ветки перед опасными операциями
5. Документируй rollback — создай issue или коммент в CI/CD

# Бэкап перед опасной операцией
git branch backup-release release

# Теперь можно:
git reset --hard <commit>

# Если пошло не так
git reset --hard backup-release

Резюме

• git reset: для локальных изменений (до push)
• git revert: для публичных веток (уже запушено)
• git checkout + tag: для возврата на конкретную версию
• hotfix ветка: для срочных исправлений в production

Главное: После push на shared ветку используй revert, не reset!