Версионирование и откат обновлений сайта: настройка 2026

За 10+ лет веб-разработки я видел десятки ситуаций, когда обновление сайта превращалось в катастрофу — упавший интернет-магазин, сломанная интеграция с CRM, потерянные данные. Честно говоря, большинства этих проблем можно было избежать с помощью правильного версионирования и возможности быстрого отката.

Зачем нужен контроль версий для сайтов

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

Вот конкретный пример. У меня был клиент с интернет-магазином на WordPress — оборот около 2 млн в месяц. Решили обновить WooCommerce с версии 6.8 до 7.1. Казалось бы, стандартная процедура. Но обновление сломало кастомные хуки в payment gateway, и магазин перестал принимать платежи. А резервной копии свежей не было — только недельной давности.

Результат? Простой на 18 часов, потеря около 100 тысяч рублей выручки и недовольные клиенты. Если бы была настроена система версионирования с возможностью быстрого отката, весь инцидент занял бы максимум 15 минут.

Основные преимущества версионирования:

• Мгновенный откат при проблемах (5-10 секунд против часов восстановления из бэкапа)
• Возможность тестировать обновления на staging-окружении
• История всех изменений с возможностью посмотреть, что именно изменилось
• Безопасные эксперименты — всегда можно вернуть как было
• Командная работа без конфликтов

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

Git как основа версионирования сайтов

Git — мой основной инструмент для версионирования сайтов. Да, многие воспринимают Git только как инструмент для разработчиков, но на деле он отлично подходит и для production-сайтов.

Вот как я настраиваю Git-репозиторий для живого сайта на сервере:

# Создаём bare-репозиторий для деплоя
mkdir /var/git/mysite.git
cd /var/git/mysite.git
git init --bare

# Создаём post-receive хук для автоматического деплоя
cat > hooks/post-receive << 'EOF'
#!/bin/bash
cd /var/www/mysite
git --git-dir=/var/git/mysite.git --work-tree=/var/www/mysite checkout -f
# Устанавливаем права
chown -R www-data:www-data /var/www/mysite
# Очищаем кеш если нужно
php /var/www/mysite/artisan cache:clear 2>/dev/null || true
EOF

chmod +x hooks/post-receive

Теперь любой деплой — это простая команда git push production master. А откат на предыдущую версию:

# Смотрим историю коммитов
git log --oneline -10

# Откатываемся на нужный коммит
git reset --hard abc123f
git push production +master

У одного моего клиента с Laravel-проектом такая схема сработала идеально. Обновили зависимости Composer, что-то пошло не так с новой версией библиотеки для работы с PDF. Вместо того чтобы час разбираться в логах, я за 30 секунд откатил на предыдущий коммит. Сайт заработал, клиент доволен.

Но есть нюансы. Git хорошо работает с текстовыми файлами — PHP, CSS, JS, конфигами. А вот с медиафайлами и большими базами данных могут быть проблемы. Для этого я использую дополнительные инструменты.

Для WordPress я обычно создаю такой .gitignore:

wp-content/uploads/
wp-content/cache/
wp-content/backup-db/
wp-config.php
.htaccess
error_log
*.log

А для Битрикса:

/upload/
/bitrix/cache/
/bitrix/managed_cache/
/bitrix/stack_cache/
/bitrix/backup/
/bitrix/.settings.php
/bitrix/php_interface/dbconn.php

Настройка staging-окружения

Staging — это точная копия production-сайта, где можно безопасно тестировать обновления. Я всегда настраиваю staging для серьёзных проектов, и это экономит кучу времени и нервов.

Вот как я поднимаю staging на том же сервере, что и основной сайт:

# Создаём директорию для staging
mkdir /var/www/mysite-staging

# Клонируем основной сайт
cp -R /var/www/mysite/* /var/www/mysite-staging/

# Создаём отдельную базу данных
mysql -u root -p << EOF
CREATE DATABASE mysite_staging;
GRANT ALL PRIVILEGES ON mysite_staging.* TO 'mysite_user'@'localhost';
FLUSH PRIVILEGES;
EOF

# Копируем базу данных
mysqldump -u root -p mysite_production | mysql -u root -p mysite_staging

Для staging-окружения обязательно настраиваю отдельный поддомен или директорию. Обычно это staging.mysite.ru или mysite.ru/staging/. В nginx добавляю такой блок:

server {
    listen 80;
    server_name staging.mysite.ru;
    root /var/www/mysite-staging;
    
    # Закрываем от поисковиков
    location /robots.txt {
        return 200 "User-agent: *\nDisallow: /\n";
        add_header Content-Type text/plain;
    }
    
    # Базовая HTTP-авторизация
    auth_basic "Staging Environment";
    auth_basic_user_file /etc/nginx/.htpasswd;
    
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
    
    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}

Процесс тестирования обновлений на staging выглядит так:

1. Синхронизирую staging с production (код + база данных)
2. Применяю обновления на staging
3. Тестирую функционал, особенно критичные части
4. Если всё ОК — деплою на production
5. Если есть проблемы — разбираюсь на staging, не трогая основной сайт

У меня был случай с большим корпоративным сайтом на Битриксе. Нужно было обновить ядро с версии 20.0.400 до 22.0.100. На staging обновление прошло нормально, но при тестировании выяснилось, что сломалась кастомная интеграция с 1С. На production такая проблема стоила бы компании несколько часов простоя и потерянных заказов.

Инструменты для автоматического отката

Ручной откат — это хорошо, но автоматический — ещё лучше. Я настраиваю системы, которые сами откатывают изменения при обнаружении проблем.

Для мониторинга состояния сайта после деплоя использую простой скрипт:

#!/bin/bash
SITE_URL="https://mysite.ru"
HEALTH_CHECK_URL="$SITE_URL/health-check"
ROLLBACK_COMMIT=""

# Функция для отката
rollback() {
    echo "Обнаружена проблема, откатываемся..."
    cd /var/www/mysite
    git reset --hard $ROLLBACK_COMMIT
    systemctl reload nginx
    systemctl restart php8.2-fpm
    echo "Откат выполнен"
}

# Сохраняем текущий коммит для возможного отката
ROLLBACK_COMMIT=$(git rev-parse HEAD~1)

# Ждём несколько секунд после деплоя
sleep 10

# Проверяем доступность сайта
if ! curl -f -s "$SITE_URL" > /dev/null; then
    rollback
    exit 1
fi

# Проверяем health-check endpoint
if ! curl -f -s "$HEALTH_CHECK_URL" | grep -q "OK"; then
    rollback
    exit 1
fi

echo "Деплой успешен, сайт работает нормально"

Health-check endpoint — это специальная страница, которая проверяет критичный функционал. Для WordPress я создаю такой файл wp-content/health-check.php:

<?php
// Отключаем весь WordPress, нам нужны только базовые проверки
define('SHORTINIT', true);
require_once('wp-load.php');

$errors = [];

// Проверяем подключение к базе данных
try {
    $wpdb->get_var("SELECT 1");
} catch (Exception $e) {
    $errors[] = "Database connection failed";
}

// Проверяем запись в файлы
$test_file = ABSPATH . 'wp-content/uploads/health-test.txt';
if (!file_put_contents($test_file, time())) {
    $errors[] = "File write failed";
} else {
    unlink($test_file);
}

// Проверяем доступность внешних API (если используются)
$context = stream_context_create(['http' => ['timeout' => 5]]);
if (!@file_get_contents('https://api.example.com/ping', false, $context)) {
    $errors[] = "External API unavailable";
}

if (empty($errors)) {
    echo "OK";
    http_response_code(200);
} else {
    echo "ERRORS: " . implode(', ', $errors);
    http_response_code(500);
}
?>

Такая система автоматического отката спасла меня не раз. Особенно запомнился случай с Laravel-приложением — обновили зависимости, новая версия пакета для работы с Redis оказалась несовместимой. Сайт упал через 2 минуты после деплоя, но система автоматически откатила изменения ещё до того, как кто-то успел заметить проблему.

Для более продвинутого мониторинга использую связку Prometheus + Grafana. Настраиваю алерты на:

• Время ответа сайта больше 3 секунд
• Ошибки 5xx больше 1% от общего трафика
• Недоступность health-check endpoint
• Рост потребления памяти или CPU

Blue-Green деплоймент для критичных проектов

Для особо важных проектов — крупные интернет-магазины, банковские системы, высоконагруженные сервисы — я настраиваю Blue-Green деплоймент. Это когда у вас одновременно работают две идентичные среды, и переключение между ними происходит мгновенно.

Вот как это выглядит на практике. У меня есть два сервера или два набора контейнеров:

• Blue — текущая рабочая версия сайта
• Green — новая версия для тестирования

Процесс деплоя:

1. Деплою новую версию на Green-окружение
2. Тестирую на Green, пока Blue продолжает обслуживать пользователей
3. Если всё ОК — переключаю балансировщик с Blue на Green
4. Blue становится резервным окружением для отката

Настройка в nginx с upstream-блоками:

upstream backend_blue {
    server 127.0.0.1:8001;
}

upstream backend_green {
    server 127.0.0.1:8002;
}

# Активное окружение (переключаем тут)
upstream backend_active {
    server 127.0.0.1:8001;  # Blue активен
    # server 127.0.0.1:8002;  # Green активен
}

server {
    listen 80;
    server_name mysite.ru;
    
    location / {
        proxy_pass http://backend_active;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
    
    # Служебный endpoint для переключения
    location /switch-to-green {
        # Логика переключения или ручное изменение конфига
        return 200 "Switching to Green environment";
    }
}

У одного клиента с высоконагруженным интернет-магазином (около 10 тысяч заказов в день) такая схема работает безотказно уже 2 года. Обновления проходят без единой секунды простоя, а если что-то идёт не так — откат за 5 секунд.

Для автоматизации переключения написал простой скрипт:

#!/bin/bash
NGINX_CONFIG="/etc/nginx/sites-available/mysite"
CURRENT_ENV=$(grep -o "127.0.0.1:800[12]" $NGINX_CONFIG | head -1)

if [[ "$CURRENT_ENV" == "127.0.0.1:8001" ]]; then
    NEW_ENV="127.0.0.1:8002"
    echo "Switching from Blue to Green"
else
    NEW_ENV="127.0.0.1:8001"
    echo "Switching from Green to Blue"
fi

# Создаём бэкап конфига
cp $NGINX_CONFIG $NGINX_CONFIG.backup

# Переключаем
sed -i "s/server 127.0.0.1:800[12];/server $NEW_ENV;/" $NGINX_CONFIG

# Проверяем конфиг и перезагружаем
if nginx -t; then
    systemctl reload nginx
    echo "Successfully switched to $NEW_ENV"
else
    echo "Config error, rolling back"
    cp $NGINX_CONFIG.backup $NGINX_CONFIG
    exit 1
fi

Версионирование баз данных

Код откатить легко, а вот с базами данных всё сложнее. Нельзя просто взять и откатить базу на день назад — потеряются все новые заказы, регистрации, комментарии. Поэтому я использую миграции и умные схемы бэкапирования.

В Laravel миграции встроены, и это прекрасно:

<?php
// Migration: add_new_column_to_products
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;

class AddNewColumnToProducts extends Migration
{
    public function up()
    {
        Schema::table('products', function (Blueprint $table) {
            $table->decimal('discount_price', 10, 2)->nullable()->after('price');
            $table->index('discount_price');
        });
    }

    public function down()
    {
        Schema::table('products', function (Blueprint $table) {
            $table->dropIndex(['discount_price']);
            $table->dropColumn('discount_price');
        });
    }
}

Откат миграции — простая команда php artisan migrate:rollback. Но в WordPress и Битриксе таких возможностей нет из коробки, поэтому приходится делать самому.

Для WordPress создаю систему миграций:

<?php
// wp-content/migrations/001_add_custom_fields.php
class Migration_001_add_custom_fields {
    public function up() {
        global $wpdb;
        
        $sql = "ALTER TABLE {$wpdb->posts} 
                ADD COLUMN custom_field_1 VARCHAR(255) NULL AFTER post_content,
                ADD COLUMN custom_field_2 TEXT NULL AFTER custom_field_1";
        
        $wpdb->query($sql);
        
        // Обновляем версию схемы
        update_option('db_version_custom', '001');
    }
    
    public function down() {
        global $wpdb;
        
        $sql = "ALTER TABLE {$wpdb->posts} 
                DROP COLUMN custom_field_1,
                DROP COLUMN custom_field_2";
        
        $wpdb->query($sql);
        
        update_option('db_version_custom', '000');
    }
}

А вот скрипт для автоматических снапшотов базы перед каждым деплоем:

#!/bin/bash
DB_NAME="mysite_production"
DB_USER="root"
DB_PASS="password"
BACKUP_DIR="/var/backups/mysql"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
COMMIT_HASH=$(git rev-parse --short HEAD)

# Создаём снапшот с привязкой к коммиту
mysqldump -u$DB_USER -p$DB_PASS $DB_NAME > $BACKUP_DIR/${DB_NAME}_${TIMESTAMP}_${COMMIT_HASH}.sql

# Сжимаем для экономии места
gzip $BACKUP_DIR/${DB_NAME}_${TIMESTAMP}_${COMMIT_HASH}.sql

# Удаляем старые снапшоты (оставляем последние 50)
ls -t $BACKUP_DIR/${DB_NAME}_*.sql.gz | tail -n +51 | xargs rm -f

echo "Database snapshot created: ${DB_NAME}_${TIMESTAMP}_${COMMIT_HASH}.sql.gz"

Такой подход спас один проект на Битриксе. Обновили модуль интернет-магазина, а он внёс изменения в структуру таблиц заказов. Новая версия работала, но с багами в подсчёте скидок. Код откатил за секунды, а вот базу пришлось восстанавливать из снапшота. Благо, снапшот был сделан прямо перед обновлением.

Мониторинг и алертинг при обновлениях

Мониторинг — это глаза и уши системы версионирования. Без него можно часами не замечать, что после обновления что-то работает не так. Я настраиваю мониторинг на нескольких уровнях.

Первый уровень — простая проверка доступности. Использую службу мониторинга UptimeRobot или собственный скрипт:

#!/bin/bash
SITES=(
    "https://mysite.ru"
    "https://mysite.ru/catalog/"
    "https://mysite.ru/cart/"
    "https://mysite.ru/checkout/"
)

TELEGRAM_BOT_TOKEN="your_bot_token"
TELEGRAM_CHAT_ID="your_chat_id"

send_alert() {
    local message="$1"
    curl -s -X POST "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/sendMessage" \
         -d chat_id="$TELEGRAM_CHAT_ID" \
         -d text="🚨 Alert: $message"
}

for site in "${SITES[@]}"; do
    response_code=$(curl -s -o /dev/null -w "%{http_code}" "$site")
    response_time=$(curl -s -o /dev/null -w "%{time_total}" "$site")
    
    if [[ $response_code -ne 200 ]]; then
        send_alert "$site returned $response_code"
    elif (( $(echo "$response_time > 5.0" | bc -l) )); then
        send_alert "$site is slow: ${response_time}s"
    fi
done

Второй уровень — мониторинг ошибок в логах. Особенно важно после обновлений PHP или зависимостей:

#!/bin/bash
ERROR_LOG="/var/log/nginx/error.log"
PHP_ERROR_LOG="/var/log/php8.2-fpm.log"
LAST_CHECK_FILE="/tmp/last_error_check"

# Получаем время последней проверки
if [[ -f $LAST_CHECK_FILE ]]; then
    LAST_CHECK=$(cat $LAST_CHECK_FILE)
else
    LAST_CHECK=$(date -d "1 minute ago" +%s)
fi

# Ищем новые ошибки
NEW_ERRORS=$(find $ERROR_LOG $PHP_ERROR_LOG -newer $LAST_CHECK_FILE 2>/dev/null | xargs grep -i "fatal\|error\|warning" | wc -l)

if [[ $NEW_ERRORS -gt 0 ]]; then
    ERRORS_TEXT=$(find $ERROR_LOG $PHP_ERROR_LOG -newer $LAST_CHECK_FILE 2>/dev/null | xargs grep -i "fatal\|error" | tail -5)
    send_alert "Found $NEW_ERRORS new errors in logs:\n$ERRORS_TEXT"
fi

# Сохраняем время проверки
date +%s > $LAST_CHECK_FILE

Третий уровень — мониторинг бизнес-метрик. Для интернет-магазинов это количество заказов, конверсия, средний чек. У меня был случай, когда после обновления WooCommerce сайт работал нормально, но перестала работать интеграция с платёжной системой. Пользователи видели ошибку только на последнем шаге оформления заказа.

Обнаружили проблему только через 4 часа, когда заметили, что заказов стало в разы меньше обычного. С тех пор в критичных проектах всегда мониторю бизнес-показатели:

<?php
// Скрипт для мониторинга бизнес-метрик
$pdo = new PDO('mysql:host=localhost;dbname=mysite', $username, $password);

// Считаем заказы за последний час
$stmt = $pdo->prepare("
    SELECT COUNT(*) as orders_count, 
           AVG(total) as avg_order_value
    FROM orders 
    WHERE created_at >= DATE_SUB(NOW(), INTERVAL 1 HOUR)
");
$stmt->execute();
$current_stats = $stmt->fetch();

// Считаем средние показатели за аналогичное время вчера
$stmt = $pdo->prepare("
    SELECT COUNT(*) as orders_count,
           AVG(total) as avg_order_value  
    FROM orders 
    WHERE created_at >= DATE_SUB(NOW(), INTERVAL 25 HOUR)
      AND created_at <= DATE_SUB(NOW(), INTERVAL 24 HOUR)
");
$stmt->execute();
$yesterday_stats = $stmt->fetch();

// Проверяем отклонения
$orders_change = ($current_stats['orders_count'] / max($yesterday_stats['orders_count'], 1)) * 100;
$avg_change = ($current_stats['avg_order_value'] / max($yesterday_stats['avg_order_value'], 1)) * 100;

if ($orders_change < 50) { // Заказов меньше чем на 50%
    send_telegram_alert("⚠️ Orders drop: {$current_stats['orders_count']} vs {$yesterday_stats['orders_count']} yesterday");
}

if ($avg_change < 70 || $avg_change > 150) { // Средний чек изменился больше чем на 30%
    send_telegram_alert("💰 Average order value anomaly: " . round($current_stats['avg_order_value'], 2));
}
?>

Автоматизация всего процесса

Когда все компоненты настроены, можно автоматизировать весь процесс обновления и отката. Я создаю CI/CD пайплайны, которые берут на себя рутинные задачи.

Вот пример GitHub Actions для автоматического деплоя с возможностью отката:

name: Deploy with Rollback

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    
    steps:
    - uses: actions/checkout@v3
    
    - name: Setup PHP
      uses: shivammathur/setup-php@v2
      with:
        php-version: '8.2'
    
    - name: Install dependencies
      run: composer install --no-dev --optimize-autoloader
    
    - name: Run tests
      run: php artisan test
    
    - name: Create database snapshot
      run: |
        ssh ${{ secrets.SERVER_USER }}@${{ secrets.SERVER_HOST }} '
          mysqldump -u${{ secrets.DB_USER }} -p${{ secrets.DB_PASS }} ${{ secrets.DB_NAME }} > /var/backups/pre-deploy-$(date +%Y%m%d-%H%M%S).sql
        '
    
    - name: Deploy to server
      run: |
        rsync -avz --delete ./ ${{ secrets.SERVER_USER }}@${{ secrets.SERVER_HOST }}:/var/www/mysite/
    
    - name: Run migrations
      run: |
        ssh ${{ secrets.SERVER_USER }}@${{ secrets.SERVER_HOST }} '
          cd /var/www/mysite && php artisan migrate --force
        '
    
    - name: Health check
      id: health_check
      run: |
        sleep 30
        response=$(curl -s -o /dev/null -w "%{http_code}" ${{ secrets.SITE_URL }}/health-check)
        if [ $response -ne 200 ]; then
          echo "Health check failed"
          exit 1
        fi
    
    - name: Rollback on failure
      if: failure()
      run: |
        ssh ${{ secrets.SERVER_USER }}@${{ secrets.SERVER_HOST }} '
          cd /var/www/mysite
          git reset --hard HEAD~1
          php artisan migrate:rollback --force
        '

Такой пайплайн автоматически:

1. Прогоняет тесты
2. Создаёт снапшот базы данных
3. Деплоит новую версию
4. Применяет миграции
5. Проверяет работоспособность
6. Откатывается при любых проблемах

Но автоматизация — это не только CI/CD. Я создаю удобные команды для ручного управления:

#!/bin/bash
# deploy.sh - Главный скрипт управления деплоем

case "$1" in
    "staging")
        echo "Деплой на staging..."
        git push staging main
        ./health-check.sh staging.mysite.ru
        ;;
    "production")
        echo "Деплой на production..."
        ./backup-db.sh
        git push production main
        sleep 10
        if ! ./health-check.sh mysite.ru; then
            echo "Health check failed, rolling back..."
            ./rollback.sh
            exit 1
        fi
        echo "Деплой успешен!"
        ;;
    "rollback")
        echo "Откатываемся на предыдущую версию..."
        ./rollback.sh
        ;;
    "status")
        echo "Текущее состояние:"
        git log --oneline -5
        ./health-check.sh mysite.ru
        ;;
    *)
        echo "Использование: $0 {staging|production|rollback|status}"
        exit 1
        ;;
esac

У одного клиента с Laravel-приложением такая система работает уже полтора года. За это время было 47 деплоев, 3 автоматических отката и ни одной серьёзной проблемы. Разработчики деплоят новые фичи несколько раз в неделю, не боясь что-то сломать.

Особенно хорошо автоматизация работает в связке с правильно настроенным окружением разработчика. Когда у всех одинаковые версии PHP, MySQL, Redis — проблем с «у меня работает, а на проде не работает» практически не бывает.

Лучшие практики и частые ошибки

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

Частые ошибки:

1. Версионирование только кода без базы данных. Видел проекты, где код откатывается за секунды, а база остаётся в новом состоянии. Результат — сайт не работает. Всегда синхронизируйте откат кода и базы данных.

2. Отсутствие тестирования на staging. «Это мелкое изменение, можно сразу на прод» — такая логика рано или поздно приводит к проблемам. У меня был клиент, который «мелким изменением» в CSS сломал вёрстку корзины в Safari.

3. Игнорирование зависимостей. Обновили WordPress с 5.9 до 6.1, но забыли проверить совместимость плагинов. Один из плагинов перестал работать, а он отвечал за интеграцию с CRM.

4. Отсутствие мониторинга после деплоя. Деплой прошёл успешно, но никто не проверил, что сайт действительно работает. Через час начали поступать жалобы от пользователей.

5. Слишком большие изменения за раз. Пытаются обновить сразу PHP с 7.4 до 8.2, WordPress с 5.8 до 6.3 и ещё 10 плагинов. Если что-то ломается, сложно понять что именно.

Лучшие практики:

1. Атомарные изменения. Одно изменение — один коммит, один деплой. Обновили одну библиотеку — проверили, что всё работает, только потом обновляем следующую.

2. Описательные коммиты. Вместо «fix bug» пишите «Fix cart calculation error for products with discounts». Через полгода будете благодарить сами себя.

3. Тегирование релизов. Каждый деплой на production помечайте тегом: v1.2.3, v1.2.4 и так далее. Это упрощает откат на конкретную версию.

4. Документирование изменений. Ведите CHANGELOG.md с описанием того, что изменилось в каждой версии. Особенно важно для команды разработчиков.

5. Регулярные обновления. Лучше обновляться часто и малыми порциями, чем раз в год большой пачкой. Свежие обновления безопасности критически важны.

# Пример хорошего workflow обновлений
git checkout -b update-wordpress-6.3
# Обновляем только WordPress
wp core update
git add -A
git commit -m "Update WordPress from 6.2 to 6.3"
git push origin update-wordpress-6.3

# Тестируем на staging
git checkout staging
git merge update-wordpress-6.3
# Проверяем что всё работает

# Деплоим на production
git checkout main  
git merge update-wordpress-6.3
git tag v2.1.0
git push origin main --tags

6. Планирование окон обновлений. Для критичных проектов обновления лучше делать в нерабочее время или в периоды минимального трафика. У интернет-магазинов это обычно ночь с воскресенья на понедельник.

7. Команда на связи. При важных обновлениях должны быть на связи как минимум разработчик и системный администратор. Если что-то пойдёт не так, время реакции критично.

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

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