Git и SemVer: история изменений и версии

Во время сбоя команда должна быстро выяснить, какой код сейчас работает и что изменилось с предыдущего выпуска. Папка project_final_v3 на чьём-то ноутбуке на эти вопросы не отвечает. Нужна связь между историей кода, проверками, сборкой и выкладкой.

Git хранит историю, а не объясняет её за автора

Commit фиксирует изменение файлов. Хорошее сообщение помогает понять его цель: «Исправить повторное списание при повторе запроса» полезнее, чем «fix».

В Git хранят не только приложение, но и Dockerfile, pipeline, конфигурацию инфраструктуры, Ansible playbook и рабочие инструкции. Секреты туда не относятся: доступ к репозиторию и история Git не заменяют хранилище секретов.

Pull request или merge request позволяет обсудить правку до объединения с основной веткой. В нём нужны цель, способ проверки и важные риски. Например, если меняется формат ответа API, стоит прямо указать, какие потребители могут пострадать.

commit → pull request → проверки и review → merge

Review не сводится к оформлению кода. Автоматический линтер проверит часть формальных правил, а коллега может заметить пропущенный сценарий или несовместимость.

Размер изменения и поиск причины

В одном pull request лучше решать связанную задачу. Если вместе с исправлением оплаты переписать логирование и обновить несколько библиотек, проверяющему будет сложнее оценить последствия.

Маленький diff не гарантирует безопасность: одна строка может удалить данные. Его преимущество в том, что проще понять намерение, проверить границы изменения и связать его с результатом.

Что обещает SemVer

Semantic Versioning описывает версии через совместимость публичного API. Формат — MAJOR.MINOR.PATCH:

• PATCH: обратно совместимое исправление ошибки.
• MINOR: новая обратно совместимая возможность.
• MAJOR: несовместимое изменение публичного API.

Исправление ошибки может изменить поведение, которое было неверным. Поэтому PATCH не означает «пользователь вообще ничего не заметит».

Представим API версии 2.4.1. Исправление неверного округления суммы при сохранении контракта может стать 2.4.2. Добавление необязательного поля, которое потребители умеют игнорировать, — 2.5.0. Удаление обязательного поля или изменение его типа потребует несовместимого обновления, например 3.0.0.

Версия помогает понять намерение автора, но не заменяет тест совместимости. Правила работают, если публичный API определён и участники их соблюдают. Отдельные правила SemVer действуют для начальной разработки 0.x и предварительных версий; в примерах курса используем стабильные версии от 1.0.0 (спецификация SemVer).

Как связать версию с работающим приложением

Для каждой выкладки полезно хранить commit, идентификатор сборки и версию артефакта. Тогда запись о deploy укажет не просто «обновили сервис», а что именно было установлено.

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

Откат, или rollback, — возврат к известному рабочему состоянию. Возврат к предыдущему commit не восстанавливает удалённые данные и не гарантирует совместимость старого приложения с новой схемой базы. Код, артефакт и состояние данных нужно рассматривать отдельно.

Вопрос перед следующим релизом

Сможет ли другой инженер по записи о выкладке найти исходный commit, результаты проверок и предыдущий артефакт? Если нет, начните с этой связи, а не с более сложной схемы названий веток.