Git-проверки перед публикацией сайта

Git хранит историю исходников отдельными зафиксированными версиями — коммитами. До коммита файл находится в рабочем каталоге, затем команда git add помещает выбранное изменение в индекс, то есть готовит его к фиксации. Проверка этих трёх состояний помогает точно определить, какие файлы попадут в следующую публикацию.

Как проверить состав будущей версии

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

Проверьте ветку и рабочее дерево

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

git status --short
git branch --show-current
git rev-parse --short HEAD

Короткий status различает изменённые, добавленные, удалённые и неотслеживаемые пути. Не продолжайте механически, если видите чужой или неизвестный файл. Сначала выясните его назначение.

Проверьте удалённый адрес без вывода учётных данных:

git remote -v
git status -sb

Remote URL не должен содержать токен. Если ветка отстала или разошлась с удалённой, не исправляйте это push --force. Получите изменения и разрешите конфликт в рабочей среде.

Прочитайте изменения рабочего каталога

git diff --stat
git diff
git diff --check

--stat показывает масштаб, полный diff — смысл, --check — некоторые проблемы пробелов. Большая механическая правка рядом с маленькой задачей заслуживает отдельного объяснения.

Для бинарных файлов Git покажет только факт изменения. Проверьте изображение визуально, формат, размеры и вес. Не доверяйте расширению: файл hero.webp должен действительно быть WebP.

Найдите новые файлы, которых ещё нет в Git

Новый неотслеживаемый файл не появляется в обычном git diff. Следующая команда перечисляет такие файлы полностью, включая содержимое новых каталогов:

git status --short --untracked-files=all

Особенно внимательно проверяйте:

• .env и варианты имени;
• *.key, *.pem, credentials и service accounts;
• дампы базы и backup-архивы;
• временные логи и скриншоты с персональными данными;
• собранный dist, если он не должен коммититься;
• ключи в документации и примерах команд.

Если секрет уже попал в commit, считайте его раскрытым и отзовите. Удаление последней строки не отменяет доступные клоны и историю.

Подготовьте к коммиту только выбранные файлы

Перечислите точные пути, которые относятся к текущей задаче. Команда добавит их в индекс, но ещё не создаст коммит и не отправит данные на сервер Git:

git add app/pages/pricing.html assets/pricing-chart.webp

Команда git add . допустима после полного просмотра состояния, но легко захватывает локальный мусор. После подготовки файлов снова проверьте содержимое индекса:

git diff --cached --stat
git diff --cached
git diff --cached --check

Это самый важный просмотр: именно содержимое индекса станет коммитом. Если лишний путь уже добавлен, уберите его из индекса командой git restore --staged ПУТЬ, не удаляя сам файл, и повторите проверку.

Запустите проверки до коммита

Для npm-проекта с такими сценариями в package.json выполните проверку и сборку в корне репозитория. Если проект использует другие имена, возьмите их из README:

npm run check
npm run build

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

Проверьте, не изменила ли команда файлы:

git status --short

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

Зафиксируйте одну законченную задачу

Сообщение должно описывать получившееся изменение. Следующий пример фиксирует уже подготовленные файлы и не добавляет ничего нового в индекс:

git commit -m "Validate pricing page before deploy"

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

git show --stat --oneline HEAD
git status --short

Рабочее дерево должно быть чистым, если deploy требует ровно зафиксированное состояние. Один тематический commit проще review и rollback, чем смесь контента, зависимостей и случайного форматирования.

Прочитайте итоговое изменение ещё раз

Даже при работе в одиночку сделайте паузу между написанием и публикацией. Прочитайте staged diff от начала до конца и ответьте:

• соответствует ли изменение одной заявленной задаче;
• нет ли временного debug-кода и тестовых адресов;
• добавлены ли новые файлы, изображения и проверки;
• не ослаблены ли permissions, firewall или валидация;
• обновлена ли инструкция владельца;
• понятен ли откат без удаления пользовательских данных.

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

Отправьте ветку без принудительной перезаписи

Команда отправляет локальную ветку main в удалённый репозиторий origin. Выполняйте её только после успешных проверок и итогового просмотра:

git push origin main

Если push отклонён, сначала получите информацию о состоянии remote. Не применяйте force к общей production-ветке как быстрый способ убрать конфликт. Защищённая ветка и pull request полезны команде, но даже одиночный владелец должен просматривать diff и результат проверок.

Не храните SSH private key в репозитории и не печатайте токен в URL команды. Доступ Git должен быть отдельным от ключа полного администрирования VPS.

После push сравните локальную и удалённую ревизии. Deployment должен получить именно этот commit, а не просто «последнее состояние main» спустя неизвестное время. Если публикация запускается позже, повторно зафиксируйте ожидаемый hash.

Сохраните этот hash в журнале публикаций.

Свяжите публикацию с точным коммитом

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

git rev-parse HEAD
git status --porcelain
git branch --show-current

Deploy прекращается при грязном рабочем дереве, неожиданной ветке и расхождении истории. Допустим только fast-forward к проверенному origin/main либо публикация явно переданного commit.

Удобный идентификатор релиза объединяет UTC-время и hash, например:

20260904T120000Z-a1b2c3d

Это пример формата, не фактический commit. Сохраните его в имени каталога и при необходимости в публичном безопасном version-маркере.

Что Git не сможет восстановить

Возврат commit помогает при ошибке кода, если данные и инфраструктура совместимы. Он не возвращает:

• удалённую базу;
• старую DNS-запись;
• TLS private key;
• системную конфигурацию вне репозитория;
• состояние после компрометации root;
• пакет, обновлённый отдельно от проекта.

Поэтому rollback релиза, backup данных и восстановление сервера — разные процедуры.

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

• Проверять только git diff и пропускать untracked-файл.
• Коммитить изменившийся lock-файл без review.
• Смешивать несколько независимых задач.
• Использовать --force на production-ветке.
• Публиковать локальное состояние без commit.
• Считать Git единственным backup.
• Включать private key в deploy-скрипт.

Commit можно публиковать только после чистой локальной сборки и просмотра staged diff. Если проверка нашла пароль или ключ, удаление строки недостаточно: значение нужно отозвать по процедуре работы с секретами.

Источники

• Recording changes — Pro Git
• git status — Git documentation
• git diff — Git documentation
• git push — Git documentation