Как задать версию модуля в Git

Управление версиями модулей в Git: от тегов до подмодулей

В Git нет встроенной системы управления версиями модулей в традиционном смысле (как package.json или pom.xml), но есть несколько эффективных подходов, которые я использую в DevOps-практике для контроля версий компонентов.

Основные подходы к версионированию

1. Git Tags (Теги) — самый простой и распространённый метод

Теги позволяют помечать конкретные коммиты как релизные версии. Это идеально для версионирования всего репозитория как единого модуля.

# Создание аннотированного тега (рекомендуется)
git tag -a v1.2.3 -m "Release version 1.2.3: добавлена фича X"

# Создание легковесного тега
git tag v1.2.3-rc1

# Пуш тегов на удалённый репозиторий
git push origin v1.2.3

# Пуш всех тегов
git push origin --tags

# Просмотр всех тегов
git tag -l

# Получение конкретной версии
git checkout v1.2.3

Семантическое версионирование (SemVer) — стандарт, который я настоятельно рекомендую: MAJOR.MINOR.PATCH (например, 2.1.0).

2. Git Submodules (Подмодули) — для композитных проектов

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

# Добавление подмодуля
git submodule add https://github.com/user/module.git path/to/module

# Инициализация и обновление подмодулей (после клонирования)
git submodule init
git submodule update

# Обновление подмодуля до конкретной версии
cd path/to/module
git checkout v1.0.0
cd ../..
git add path/to/module
git commit -m "Зафиксировал module версии 1.0.0"

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

3. Файлы манифеста версий

Для сложных систем я создаю файлы конфигурации, которые явно указывают версии всех зависимостей:

# version-manifest.yaml
modules:
  - name: auth-service
    version: v2.1.0
    commit: abc123def456
    repository: https://github.com/company/auth-service.git
  
  - name: payment-gateway
    version: v1.3.5
    commit: xyz789ghi012
    repository: https://github.com/company/payment-gateway.git

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

1. Автоматизация через CI/CD:

   • Автоматическое создание тегов при мерже в main/master
   • Проверка соответствия SemVer в пайплайнах
   • Генерация CHANGELOG.md на основе тегов

2. Git Hooks для контроля:

   # .git/hooks/pre-commit (пример проверки формата тега)
   #!/bin/bash
   # Проверка, что сообщение коммита содержит версию при необходимости
   

3. Использование Git Flow или аналогичных методологий:

   • feature/ ветки для разработки
   • release/v1.2.3 ветки для подготовки релиза
   • Теги только из main/master веток

4. Интеграция с системами сборки:

   # Dockerfile пример
   FROM base:latest
   ARG MODULE_VERSION=v1.0.0
   RUN git clone --branch ${MODULE_VERSION} https://github.com/user/module.git
   

Сравнение подходов

Продвинутые практики

В production-средах я дополнительно использую:

• Signed Tags (подписанные теги) для безопасности
• Release Branches для поддержки multiple версий
• Git LFS для версионирования больших бинарных файлов
• Интеграцию с артефакт-репозиториями (Nexus, Artifactory)

Ключевой принцип: версия в Git должна быть однозначной, воспроизводимой и содержать достаточно информации для идентификации конкретного состояния кода. Выбор метода зависит от сложности проекта, но теги с SemVer покрывают 90% случаев в современной DevOps-практике.