Kā jūs organizējāt versiju pārvaldības sistēmu savos…

Использовал Git как основную систему контроля версий.

Рабочий процесс обычно строился на основе Gitflow, либо его упрощенной модели, в зависимости от размера команды и сложности проекта.

Основные ветки:

main (или master): стабильная версия, готовая к развертыванию или уже на продакшене.
develop: интеграционная ветка для всех фич.

Дополнительные ветки:

feature/название-фичи: для разработки функционала.
release/номер-версии: для подготовки новой версии к релизу, исправления последних ошибок.
hotfix/название-исправления: для срочных исправлений на продакшене.

Процесс разработки:

Создание ветки feature от develop.
Разработка и локальные коммиты.
Периодическое rebase на актуальный develop для синхронизации.
Создание pull request (или merge request) в develop.
Сode review другими участниками команды.
Слияние ветки feature в develop.

Для контроля версий самого приложения использовал semantic versioning (Major.Minor.Patch).

Major: несовместимые изменения API.
Minor: добавление функционала с обратной совместимостью.
Patch: исправления ошибок с обратной совместимостью.

Версия проекта хранилась в файле (например, __version__.py или setup.py) и обновлялась при подготовке релиза. Использовал теги Git для обозначения каждой выпущенной версии.

Пример структуры версионирования:

// __version__.py
__version__ = "1.2.3"

Git тег для этой версии: v1.2.3.

Для автоматизации версионирования и создания тегов мог применять инструменты типа bumpversion или python-semantic-release.

Автоматизированные проверки (CI) запускались при каждом push'е и pull request'е для поддержания качества кода и выявления конфликтов на ранних этапах.

Пример .gitignore:

// .gitignore
# Byte-compiled / optimized / DLL files
__pycache__/
*.py[cod]
*$py.class

# Distribution / packaging
.Python
env/
venv/
build/
develop-eggs/
dist/
eggs/
*.egg-info

# Editors
.idea/
.vscode/
*.swp

Kā jūs organizējāt versiju pārvaldības sistēmu savos projektos?