Как вести OpenCart-проект в Git

OpenCart-проект без Git — это дополнительные риски. Непонятно, кто и когда изменил файл, нельзя быстро откатиться к рабочей версии, а перенос на новый сервер занимает больше времени. Git решает эти проблемы: каждое изменение фиксируется, можно вернуться к любой точке в истории, а деплой на сервер занимает одну команду. Но Git подходит не всем — об этом ниже в разделе «Кому Git действительно нужен».

Из практики: за 17 лет работы с OpenCart я видел десятки проектов, где доступы к базе данных или API маркетплейсов оказались в открытом репозитории. Однажды клиент привёл проект, где пароль от MySQL был захардкожен в пяти разных файлах — и три из них уже лежали на GitHub. Восстановление заняло двое суток, а репутационный ущерб — гораздо больше.

В этой статье — как правильно организовать Git-репозиторий для OpenCart, что хранить, что игнорировать, как защитить доступы и как настроить деплой. Особое внимание — безопасности: реальные примеры утечек и способы их предотвращения.

Что хранить в Git

Храните только то, что сделано вами или вашими разработчиками:

• Пользовательскую тему — все файлы вашей кастомной темы.
• Установленные модули — файлы модулей, которые вы устанавливали.
• OCMOD-модификации — XML-файлы модификаций.
• Доработки — изменённые файлы ядра OpenCart (если вы их правили).
• Документацию — README, инструкции по развёртыванию.
• Скрипты — деплой, миграции, бэкапы.

Не храните: ядро OpenCart (восстанавливается из дистрибутива), стандартные темы, кэш, логи, сессии, файлы с секретами.

Безопасность: самая важная часть

По практике, в 4 из 10 проектов, которые я забирал на поддержку, в Git-репозитории оказывались компрометированные данные. И это не только config.php — есть целый список файлов, где разработчики забывают про секреты.

Реальные кейсы утечек

Кейс 1: Парсер цен. Разработчик написал скрипт для парсинга цен конкурентов. Сохранил API-ключ маркетплейса прямо в файл скрипта — не в config.php, а прямо в теле PHP-кода. Забыл. Скрипт лежал в папке /scripts/. Выгрузил проект на GitHub. Через неделю аккаунт на маркетплейсе был взломан.

Кейс 2: Интеграция с CRM. При подключении amoCRM разработчик прописал токен авторизации в файле /catalog/controller/extension/crm/amo.php. Токен был в переменной $api_token = 'abc123...'. Файл попал в коммит. Кто-то нашёл токен через GitHub Dorking и начал слать спам клиентам магазина.

Кейс 3: Сторонний модуль. Купленный модуль для интеграции с доставкой содержал hardcoded пароль от API службы доставки. Модуль не использовал config.php — пароль был прямо в файле модуля. Разработчик не проверил и загрузил модуль в репозиторий.

Где искать захардкоженные секреты

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

# Ищем пароли, ключи, токены в PHP-файлах
grep -rn "password|api_key|secret|token" upload/ --include="*.php" | 
  grep -v "config.php" | grep -v ".gitignore"

grep -rn "mysqli_connect|new PDO|mysql_connect" upload/ --include="*.php"

grep -rn "Client-ID|Authorization-Token|Api-Key" upload/ --include="*.php"

# Проверяем, нет ли .env файла в коммитах
git log --all --full-history -- "*.env" ".env.*"

# Проверяем историю на наличие config.php
git log --all --full-history -- "config.php" "admin/config.php"

Если одна из этих команд что-то нашла — значит, секреты уже были в истории Git. Даже если вы удалите файл сейчас, он останётся в истории коммитов. Подробнее об этом — ниже.

Что делать, если секреты уже в истории Git

Шаг 1: Смените все скомпрометированные пароли и ключи немедленно. Не пытайтесь просто удалить файл из Git — пароль уже мог быть извлечён.

Шаг 2: Очистите историю Git (если репозиторий приватный):

# Установите git-filter-repo
pip install git-filter-repo

# Удалите config.php из всей истории
git filter-repo --path config.php --invert-paths
git filter-repo --path admin/config.php --invert-paths

# Удалите .env из всей истории
git filter-repo --path .env --invert-paths
git filter-repo --path ".env.*" --invert-paths

# Удалите скрипт с паролем
git filter-repo --path scripts/parser.php --invert-paths

# Форс-пуш (только для приватных репозиториев!)
git push origin --all --force

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

1. Смените все пароли и ключи (обязательно).
2. Удалите публичный репозиторий и создайте новый приватный.
3. Научитесь на этой ошибке — используйте .gitignore правильно.

Правильный .gitignore для OpenCart

Это не просто список файлов — это щит между вашим кодом и утечкой данных. Каждая строка имеет свою историю.

# ============================================
# OpenCart .gitignore — полная версия
# ============================================

# --- КОНФИГИ С ПАРОЛЯМИ (КРИТИЧНО!) ---
/config.php
/admin/config.php
/.env
/.env.*
*.env

# --- СЕРВЕРНЫЕ НАСТРОЙКИ ---
.htaccess
.htpasswd
robots.txt
sitemap.xml

# --- КЭШ И ВРЕМЕННЫЕ ФАЙЛЫ ---
/system/storage/cache/
/system/storage/logs/
/system/storage/session/
/system/storage/modification/
/image/cache/
/download/

# --- БАЗЫ ДАННЫХ И БЭКАПЫ ---
*.sql
*.sql.gz
*.tar.gz
*.zip
*.rar

# --- ЗАВИСИМОСТИ ---
/vendor/
/node_modules/
/bower_components/

# --- IDE И РЕДАКТОРЫ ---
/.idea/
/.vscode/
*.swp
*.swo
*~
.DS_Store
Thumbs.db

# --- СКРИПТЫ С СЕКРЕТАМИ (если есть) ---
# Раскомментируйте, если используете скрипты с API-ключами
# /scripts/parser.php
# /scripts/api-integration.php
# /scripts/cron/*.php

# --- СТОРОННИЕ МОДУЛИ С СЕКРЕТАМИ ---
# Некоторые модули хранят ключи прямо в файлах
# Проверяйте каждый модуль перед коммитом!
# /catalog/controller/extension/payment/some_gateway.php
# /catalog/model/extension/shipping/some_delivery.php

Почему config.php — это только начало

Стандартный config.php в OpenCart содержит пароль от базы данных. Но в реальных проектах секреты оказываются гораздо глубже:

Файл / Где искать	Что может быть	Риск
config.php	Пароль MySQL, ключ шифрования	Полный доступ к БД
admin/config.php	Пароль админки, API-ключи	Управление магазином
Скрипты в /scripts/	API-ключи маркетплейсов, CRM, доставки	Компрометация интеграций
Кастомные модули	Токены платёжных систем, API	Финансовые потери
Крон-задачи	Пароли от почтовых серверов, FTP	Спам, взлом
Логи с данными	Email-адреса клиентов, номера телефонов	Утечка персональных данных (152-ФЗ)

Практический пример: как найти секреты в проекте

Допустим, вы забрали проект на поддержку. Вот чек-лист проверки:

# 1. Проверяем Git-историю на наличие секретов
git log --all --full-history --diff-filter=A -- "*.php" | head -50

# 2. Ищем захардкоженные пароли (исключая config.php)
grep -rn "password.*=.*['"]" upload/ --include="*.php" | 
  grep -v config.php | grep -v "password_hash|password_verify"

# 3. Ищем API-ключи
grep -rn "api_key|api_secret|access_token|client_secret" 
  upload/ --include="*.php" | grep -v config.php

# 4. Ищем подключения к БД вне config.php
grep -rn "mysqli|PDO|mysql_" upload/ --include="*.php" | 
  grep -v config.php

# 5. Проверяем, есть ли .env в Git
git ls-files | grep -i ".env"

# 6. Ищем логи с персональными данными
find . -name "*.log" -exec grep -l "email|phone|телефон" {} ;

Если хотя бы одна команда что-то нашла — у вас проблема. Не паникуйте, но действуйте:

1. Смените все найденные пароли и ключи.
2. Добавьте найденные файлы в .gitignore.
3. Удалите файлы из Git: git rm --cached <файл>.
4. Очистите историю, если ключи были в коммитах.
5. Научите команду правилам.

Что игнорировать (.gitignore)

Полная версия .gitignore приведена выше. Здесь — пояснения по ключевым строкам:

# КОНФИГИ С ПАРОЛЯМИ — НЕ КОММИТИТЬ НИКОГДА
/config.php          # Пароль MySQL, ключ шифрования
/admin/config.php    # Пароль админки

# ПЕРЕМЕННЫЕ ОКРУЖЕНИЯ
/.env                # Секреты для Docker/Compose
/.env.local          # Локальные настройки
/.env.production     # Продакшен-настройки

# КЭШ — может содержать данные пользователей
/system/storage/cache/
/system/storage/session/

# ЛОГИ — могут содержать персональные данные
/system/storage/logs/

# ВРЕМЕННЫЕ ФАЙЛЫ МОДИФИКАЦИЙ
/system/storage/modification/

# ФАЙЛЫ, ГЕНЕРИРУЕМЫЕ АВТОМАТИЧЕСКИ
/image/cache/
/sitemap.xml
/cache/
/storage/

Скрипты с секретами: как поступать правильно

Если у вас есть скрипт, который подключается к API маркетплейса или CRM, никогда не храните ключ прямо в коде. Вот как нужно делать:

Плохо (хардкод):

<?php
// scripts/parser.php — ПЛОХО!
$api_key = "sk-abc123def456ghi789";  // ← УТЕЧКА!
$api_secret = "secret_xyz789";       // ← УТЕЧКА!

$data = file_get_contents(
    "https://api.marketplace.ru/v1/prices?key=" . $api_key
);

Правильно (через .env или config):

<?php
// scripts/parser.php — ПРАВИЛЬНО
require_once __DIR__ . '/../config.php';

// Используем константу из config.php
$api_key = MP_API_KEY;

// Или читаем из переменных окружения
$api_key = getenv('MP_API_KEY');
$api_secret = getenv('MP_API_SECRET');

if (!$api_key) {
    die("Ошибка: MP_API_KEY не задана. Проверьте config.php или .envn");
}

$data = file_get_contents(
    "https://api.marketplace.ru/v1/prices?key=" . $api_key
);

И добавьте этот скрипт в .gitignore, если он содержит уникальные настройки сервера:

# Скрипты с серверными настройками
/scripts/parser.php
/scripts/cron/
/scripts/integrations/

Структура репозитория

opencart-shop/
├── upload/                         # файлы сайта (только кастомные)
│   ├── catalog/view/theme/mytheme/ # ваша тема
│   ├── catalog/controller/         # ваши контроллеры
│   ├── catalog/model/              # ваши модели
│   ├── system/storage/modification/ # OCMOD-модификации
│   └── admin/language/             # языковые файлы
├── docs/                           # документация
│   ├── README.md
│   ├── CHANGELOG.md
│   └── deployment.md
├── scripts/                        # скрипты деплоя
│   ├── deploy.sh
│   └── backup.sh
├── .gitignore                      # игнорируемые файлы
├── .gitignore.example              # пример для других разработчиков
└── .env.example                    # пример переменных окружения

Файл .env.example

Вместо .env (который в .gitignore) создайте .env.example с шаблоном:

# .env.example — коммитится в Git
# Скопируйте в .env и заполните реальными значениями

# База данных
DB_HOST=localhost
DB_NAME=opencart
DB_USER=opencart_user
DB_PASSWORD=  # ← ЗАПОЛНИТЕ

# API маркетплейсов
MP_API_KEY=  # ← ЗАПОЛНИТЕ
MP_API_SECRET=  # ← ЗАПОЛНИТЕ

# CRM
AMO_API_KEY=  # ← ЗАПОЛНИТЕ

# Почтовый сервер
SMTP_HOST=smtp.example.com
SMTP_USER=  # ← ЗАПОЛНИТЕ
SMTP_PASSWORD=  # ← ЗАПОЛНИТЕ

Ветвление

Рекомендуемая схема ветвления для OpenCart-проекта:

Ветка	Назначение	Когда использовать
main	Продакшен-код	Только проверенный, рабочий код
develop	Разработка	Активная разработка, тестирование
feature/*	Новые функции	Каждая новая фича — отдельная ветка
hotfix/*	Срочные исправления	Баги в продакшене, требующие немедленного исправления

Деплой на продакшен

Вариант 1. Простой (для одного сервера)

# На сервере
cd /path/to/opencart
git pull origin main

# Обновление модификаций
cd admin
php cli_install.php install

Вариант 2. С деплой-скриптом

#!/bin/bash
# deploy.sh

set -e

echo "=== Деплой OpenCart ==="
echo "Пull latest changes..."
git pull origin main

echo "Installing dependencies..."
composer install --no-dev --optimize-autoloader

echo "Updating modifications..."
cd admin && php cli_install.php install && cd ..

echo "Clearing cache..."
rm -rf system/storage/cache/*
rm -rf system/storage/modification/*

echo "Setting permissions..."
chmod -R 755 upload/
chmod -R 644 upload/catalog/view/theme/
chmod 644 config.php
chmod 644 admin/config.php

echo "=== Деплой завершён! ==="

Вариант 3. С автоматизацией (CI/CD)

Для командных проектов — настройте автоматический деплой через GitHub Actions, GitLab CI или Jenkins:

1. Пуш в ветку main запускает пайплайн.
2. Пайплайн запускает тесты (если есть).
3. При успешных тестах — автоматический деплой на сервер.

Типичные ошибки и как их избежать

Ошибка	Последствия	Как делать правильно
Хранить config.php в Git	Полный доступ к БД для всех, кто видит репозиторий	.gitignore для config.php, переменные окружения
Захардкоженные API-ключи в скриптах	Компрометация интеграций, финансовые потери	Хранить ключи в config.php или .env
Не проверять модули перед установкой	Сторонний код с секретами в Git	Перед коммитом — grep по ключевым словам
Коммитить логи	Утечка персональных данных клиентов	.gitignore для storage/logs
Нет ветвления	Сломанный код в продакшене	Используйте develop → main
Нет деплой-скрипта	Ручной деплой, ошибки на сервере	Автоматизируйте деплой
Форс-пуш без обсуждения	Потеря истории, конфликты в команде	Форс-пуш — только в экстренных случаях

Чек-лист безопасности Git для OpenCart

Пройдитесь по этому списку перед тем, как первый раз запушить проект:

1. .gitignore создан и содержит config.php, .env, кэш, логи
2. Проведён поиск захардкоженных секретов (grep команды выше)
3. Нет .env файла в Git (проверьте: git ls-files | grep env)
4. Скрипты в /scripts/ не содержат API-ключей в открытом виде
5. Сторонние модули проверены на наличие секретов
6. Логи не коммитятся
7. Все разработчики знают правила коммита
8. Приватный репозиторий для коммерческих проектов
9. Деплой-скрипт создан и протестирован
10. Ветвление настроено (main/develop)

Рекомендации из практики

Как лучше: Ведите OpenCart в Git: весь проект, БД в дампе, модули как сабмодули. Это упрощает развёртывание и откат.

Как не делать: Не храните файлы OpenCart без Git — потеря данных при сбое гарантирована.

Кейс из практики: Магазин 2 года вёл проект без Git. При сбое хостинга потеряли 3 дня работы. Перевели в Git — откаты за 10 минут, развёртывание за 5 минут.

По практике, Git для OpenCart — не роскошь, а необходимость для серьёзного проекта. Закажите доработку OpenCart

Кому Git действительно нужен, а кому — нет

Git — не серебряная пуля. Вот честная оценка:

Ситуация	Git нужен?	Альтернатива
Команда из 3+ разработчиков	Да	—
Активная разработка, часто меняется код	Да	—
Много кастомных модулей и интеграций	Да	—
Один разработчик, стабильный магазин	Желательно	Регулярные бэкапы
Небольшой магазин, редкие правки	Не обязательно	Бэкап перед доработкой
Разработчики не знакомы с Git	С осторожностью	Бэкапы + регламент

Если вы выбираете бэкапы вместо Git — это нормально для простых проектов. Но соблюдайте правила:

1. Бэкап перед каждым изменением — не после, а именно перед.
2. Храните бэкапы не на том же сервере (облачное хранилище, другой сервер).
3. Проверяйте бэкапы — бесполезный бэкап, который не восстанавливается, хуже отсутствия бэкапа.
4. Фиксируйте, что менялось: простой текстовый файл «что сделал» с датой.

Частые вопросы

Нужен ли Git для личного проекта без команды?

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

Важный нюанс: если вы привлекаете разработчиков, плохо знакомых с Git, риск проблем кратно возрастает. Неправильный force push, случайное удаление ветки, конфликты при слиянии — всё это может привести к простоям магазина. В таком случае лучше обойтись бэкапами и чётким регламентом: «перед любым изменением — бэкап, после — проверка на тестовом стенде».

Как перенести существующий проект на Git?

1. Создайте репозиторий на GitHub/GitLab.
2. Добавьте .gitignore (сначала — потом первый коммит!).
3. Проверьте проект на секреты (grep команды выше).
4. Сделайте первый коммит с текущим состоянием проекта.
5. Настройте деплой на сервер.

Что делать, если забыл добавить файл в .gitignore и закоммитил?

# Удалите файл из Git, но оставьте на сервере
git rm --cached config.php

# Коммит
git commit -m "Remove config.php from tracking"

Но помните: файл всё ещё есть в истории Git. Если в нём были секреты — смените пароли.

Мой репозиторий публичный — что делать?

Для коммерческих проектов на OpenCart всегда используйте приватный репозиторий. Публичный репозиторий — это приглашение для конкурентов и злоумышленников. Если проект уже был публичным и содержит секреты:

1. Смените все пароли и ключи.
2. Удалите публичный репозиторий.
3. Создайте новый приватный.
4. Научитесь на этой ошибке.

Как защититься, если в команде есть junior-разработчики?

Настройте приватные правила репозитория (branch protection rules) — запретите пуш в main без ревью. Используйте pre-commit хуки для автоматической проверки секретов:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks

После установки gitleaks каждая попытка коммита с секретом будет автоматически заблокирована.

Связанные темы

• Как отлаживать OpenCart локально — настройка локальной среды разработки
• Как не сломать OpenCart при доработке модуля — безопасная доработка кода
• Как обновлять OpenCart-модули без поломки — безопасное обновление

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