Система управления версиями
Общие сведения
Для управления версиями исходного кода конфигураций 1С можно использовать:
- Хранилище 1С — встроенный механизм платформы 1С:Предприятие
- Git — распределённая система управления версиями
Сравнение подходов
| Критерий | Хранилище 1С | Git |
|---|---|---|
| Интеграция с платформой | Встроенная | Требует дополнительных инструментов |
| Работа с конфигурацией | Нативная | Через выгрузку в файлы |
| CI/CD интеграция | Ограниченная | Полная |
| Ветвление | Не поддерживается | Полная поддержка |
| Распределённая работа | Требуется соединение | Полная автономность |
Соглашение о коммитах
Все помещения изменений должны быть осмысленно описаны. Главным ориентиром является популярное соглашение Conventional Commits.
Важно
Это соглашение применяется как для хранилища 1С, так и для Git.
Формат сообщения коммита
[Тип](необязательный контекст): [Короткое описание] (номер задачи)
[необязательное тело]
[необязательная(ые) сноска(и)]
Примечание
При использовании методологии gitflow в тексте коммита не указывается номер задачи. Достаточно указать его один раз — в заголовке или теле запроса на слияние (Merge Request / Pull Request).
Типы коммитов
Чтобы изменения автоматически включались в список изменений (CHANGELOG.md), необходимо выбирать правильный тип:
| Тип | Emoji | Описание |
|---|---|---|
feat | 🚀 Features | Новая функция (новый документ, обработка, отчёт, изменение команды и т.д.) |
fix | 🐛 Bug Fixes | Исправление багов/ошибок (ошибка в ЖР, баг от заказчика, замечание от QA) |
docs | 📚 Documentation | Изменяется только документация (справка в конфигураторе или каталог doc) |
perf | ⚡ Performance | Изменение кода, повышающее производительность (оптимизация запросов, блокировки) |
refactor | 🚜 Refactor | Рефакторинг кода (изменение без исправления ошибки или добавления функций) |
style | 🎨 Styling | Изменения, не влияющие на смысл кода (форматирование, пробелы) |
test | 🧪 Testing | Добавление или исправление тестов |
chore | ⚙️ Miscellaneous | Другие изменения, не влияющие на исходный код или тесты |
ci | ⚙️ Miscellaneous | Настройка CI/CD (Pipeline) |
revert | ◀️ Revert | Отмена прошлых изменений |
Служебные коммиты (не включаются в CHANGELOG)
| Тип | Описание |
|---|---|
chore(release): prepare for x.x.x.x | Подготовка к релизу |
chore(deps.*) | Обновление зависимостей |
chore(pr) | Служебные изменения PR |
chore(pull) | Служебные изменения при слиянии |
Специальные коммиты
| Тип | Emoji | Описание |
|---|---|---|
chore(release): version x.x.x.x | 📌 | Выпуск релиза |
Коммит с security в теле | 🛡️ Security | Исправление безопасности |
Примечание
Таблица приведена в качестве справки. Актуальную конфигурацию смотрите в файле cliff.toml каждого проекта (сайт проекта git-cliff).
Рекомендации
- Описывайте изменения при каждом коммите — не откладывайте описание на потом
- Делайте атомарные коммиты — не накапливайте несвязанные изменения. Каждый коммит должен решать одну задачу (одна логическая единица работы)
- Пишите понятные описания — с точки зрения пользователя, не разработчика
- Не смешивайте типы изменений — например, изменение в отчете по остаткам и документа платежное поручение
- Используйте scope — для указания области (Бюджетирование, Администрирование, Интеграция, Казначейство)
- Указывайте номер задачи — для связи с системой управления задачами (не для метадологии gitflow)
- Описание на русском языке — краткое и понятное
Подробная документация
Работа с хранилищем 1С
Работа с Git
- Основные команды Git — справочник команд
- Настройка SSH ключей — безопасная аутентификация
- .gitignore — настройка игнорируемых файлов
- Git LFS — работа с большими файлами
- Git Submodules — работа с вложенными репозиториями
- Git Flow — стратегии ветвления
- Работа с Git в IDE — использование Git через графические интерфейсы