Commit Руководство по коммитам

В данном документе определены правила оформления Git-коммитов для проекта YaoXiang, направленные на поддержание понятной, читаемой и легко анализируемой истории коммитов.

Содержание

Формат коммита
Типы коммитов
Полный справочник Emoji
Области видимости
Управление версиями
Правила сообщений
Языковые соглашения
🔖 Коммит релиза
Примеры
Использование Commit Template
Часто задаваемые вопросы

Формат коммита

Очень важно!!!!!!!! Нельзя забывать!!!!!! Все сообщения коммитов должны следовать следующему формату:

:emoji-код: type(scope): тема (на русском)

[Необязательное тело]

[Необязательный футер]

⚠️ Важно: Необходимо использовать emoji-код (например, :sparkles:) вместо прямого ввода emoji-символов.
Рекомендуется использовать русский язык для сообщений коммитов в целях единообразия командной коммуникации.

Составляющие части

Часть	Описание	Обязательно
emoji-код	Иконка, идентифицирующая тип коммита	✅
type	Тип коммита	✅
scope	Область влияния	✅
subject	Краткое описание (на русском, до 50 символов)	✅
body	Подробное описание (необязательно)	❌
footer	Breaking changes или закрытие issues (необязательно)	❌

Типы коммитов

emoji-код	type	Описание
✨	feat	Новая функциональность
🐛	fix	Исправление бага
📝	docs	Только изменения в документации
💄	style	Форматирование кода (без влияния на функционал)
♻️	refactor	Рефакторинг кода
⚡	perf	Оптимизация производительности
✅	test	Добавление или изменение тестов
🔧	chore	Изменения в инструментах сборки, вспомогательных инструментах
🏗️	build	Изменения в системе сборки
🚀	ci	Изменения в CI-конфигурации

Полный справочник Emoji

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

emoji	emoji-код	описание коммита
🎨	`:art:`	Улучшение структуры/форматирования кода
⚡️	`:zap:` / `:racehorse:`	Повышение производительности
🔥	`:fire:`	Удаление кода или файлов
🐛	`:bug:`	Исправление бага
🚑	`:ambulance:`	Критический патч
✨	`:sparkles:`	Внедрение новой функциональности
📝	`:memo:`	Написание документации
🚀	`:rocket:`	Развёртывание функциональности
💄	`:lipstick:`	Обновление UI и файлов стилей
🎉	`:tada:`	Первый коммит
✅	`:white_check_mark:`	Добавление тестов
🔒	`:lock:`	Исправление проблем безопасности
🍎	`:apple:`	Исправление для macOS
🐧	`:penguin:`	Исправление для Linux
🏁	`:checkered_flag:`	Исправление для Windows
🤖	`:robot:`	Исправление для Android
🍏	`:green_apple:`	Решение проблем для iOS
🔖	`:bookmark:`	Релиз/версия
🚨	`:rotating_light:`	Удаление предупреждений линтера
🚧	`:construction:`	Работа в процессе
💚	`:green_heart:`	Исправление проблем сборки CI
⬇️	`:arrow_down:`	Понижение зависимости
⬆️	`:arrow_up:`	Повышение зависимости
📌	`:pushpin:`	Закрепление зависимости на конкретной версии
👷	`:construction_worker:`	Добавление CI-системы сборки
📈	`:chart_with_upwards_trend:`	Добавление аналитики или кода отслеживания
♻️	`:recycle:`	Рефакторинг кода
🔨	`:hammer:`	Масштабный рефакторинг
➖	`:heavy_minus_sign:`	Удаление зависимости
🐳	`:whale:`	Работа, связанная с Docker
➕	`:heavy_plus_sign:`	Добавление зависимости
🔧	`:wrench:`	Изменение конфигурационных файлов
🌐	`:globe_with_meridians:`	Интернационализация и локализация
✏️	`:pencil2:`	Исправление опечатки
💩	`:hankey:`	Написание кода с ошибками, требующего улучшения
⏪️	`:rewind:`	Откат изменений
🔀	`:twisted_rightwards_arrows:`	Слияние веток
📦	`:package:`	Обновление скомпилированных файлов или пакетов
👽	`:alien:`	Обновление кода из-за изменений внешнего API
🚚	`:truck:`	Перемещение или переименование файлов
📄	`:page_facing_up:`	Добавление или обновление лицензии
💥	`:boom:`	Внесение критических изменений
🍱	`:bento:`	Добавление или обновление ассетов
👌	`:ok_hand:`	Обновление кода после код-ревью
♿️	`:wheelchair:`	Повышение доступности
💡	`:bulb:`	Документирование исходного кода
🍻	`:beers:`	Написание кода в состоянии опьянения
💬	`:speech_balloon:`	Обновление текста и надписей
🗃️	`:card_file_box:`	Выполнение изменений, связанных с базой данных
🔊	`:loud_sound:`	Добавление логирования
🔇	`:mute:`	Удаление логирования
👥	`:busts_in_silhouette:`	Добавление контрибьюторов
🚸	`:children_crossing:`	Улучшение пользовательского опыта/удобства использования
🏗️	`:building_construction:`	Внесение архитектурных изменений
📱	`:iphone:`	Работа над адаптивным дизайном
🤡	`:clown_face:`	Высмеивание вещей
🥚	`:egg:`	Добавление пасхалки
🙈	`:see_no_evil:`	Добавление или обновление .gitignore
📸	`:camera_flash:`	Добавление или обновление снэпшотов

Области видимости

Области видимости основаны на структуре каталога src/ проекта, необходимо использовать следующие определённые scopes:

Топовые модули

Область видимости	Соответствующий каталог	Описание
`frontend`	`src/frontend/`	Фронтенд: лексический анализ, синтаксический анализ, проверка типов
`middle`	`src/middle/`	Средний слой: IR, оптимизация, мономорфизация
`backends`	`src/backends/`	Бэкенды: интерпретатор, runtime, REPL
`std`	`src/std/`	Стандартная библиотека
`formatter`	`src/formatter/`	Форматтер кода
`lsp`	`src/lsp/`	LSP — протокол языкового сервера
`package`	`src/package/`	Менеджер пакетов
`util`	`src/util/`	Утилиты: диагностика, кэширование, i18n

Подмодули фронтенда

Область видимости	Соответствующий каталог	Описание
`parser`	`src/frontend/core/parser/`	Синтаксический анализатор
`lexer`	`src/frontend/core/lexer/`	Лексический анализатор
`typecheck`	`src/frontend/core/typecheck/`	Проверка типов
`types`	`src/frontend/core/types/`	Определения системы типов

Подмодули среднего слоя

Область видимости	Соответствующий каталог	Описание
`codegen`	`src/middle/passes/codegen/`	Генерация кода (байткод)
`monomorphize`	`src/middle/passes/monomorphize/`	Обработка мономорфизации
`lifetime`	`src/middle/passes/lifetime/`	Анализ времени жизни

Подмодули бэкенда

Область видимости	Соответствующий каталог	Описание
`repl`	`src/backends/dev/repl/`	REPL интерактивная командная строка
`shell`	`src/backends/dev/shell.rs`	Обработка Shell-команд
`runtime`	`src/backends/runtime/`	Движок выполнения runtime

Области видимости документации

Область видимости	Описание
`docs`	Обновление общей документации
`design`	Спецификации дизайна языка (RFC)
`plan`	Документация плана реализации

Другие области видимости

Область видимости	Описание
`build`	Система сборки, конфигурация Cargo
`ci`	CI/CD конфигурация (GitHub Actions)
`test`	Тестирование
`release`	Релиз
`meta`	Мета-конфигурация проекта (.claude, .gitignore и др.)

Правила сообщений

Управление версиями

Версия определена в поле version файла Cargo.toml в корневом каталоге проекта:

toml

[package]
version = "0.7.2"

Используется семантическое версионирование MAJOR.MINOR.PATCH:

Тип версии	Описание	Пример
major	Крупное обновление, несовместимые изменения API	0.7.2 → 1.0.0
minor	Новая функциональность, обратная совместимость	0.7.2 → 0.8.0
patch	Исправление багов, обратная совместимость	0.7.2 → 0.7.3

⚠️ При релизе обновите версию в Cargo.toml на ветке dev, после PR в main CI автоматически создаст tag и Release. Не создавайте tag вручную, иначе CI пропустит процесс релиза.

CI Процесс релиза

Релиз автоматически выполняется через GitHub Actions (release.yml) по следующему процессу:

1. Обновить поле version в Cargo.toml на ветке dev
2. cargo build для обновления Cargo.lock
3. Коммит по формату релиза (см. ниже 🔖 Коммит релиза)
   - commit message должен содержать все изменения с момента предыдущего релиза
     (т.е. полное содержимое PR)
4. Создать PR из dev в main
5. Слить PR в main
6. CI автоматически проверяет:
   - Читает версию из Cargo.toml → "v{version}"
   - Проверяет, существует ли этот tag
   - Не существует → запускает полный процесс релиза
   - Существует → пропускает (не будет повторной публикации)
7. CI автоматически выполняет:
   - Параллельно: кроссплатформенная сборка (Linux/Windows/macOS)
     + аудит безопасности + тесты
   - После успеха всех: создание tag, упаковка артефактов,
     публикация GitHub Release

Ключевые правила

Правило	Описание
Не создавать tag вручную	CI решает, публиковать ли, на основе наличия tag; ручное создание tag приведёт к пропуску CI
Bump версии на dev	Коммит релиза делается на dev, через PR в main
Коммит релиза содержит полный changelog	commit message должен содержать все изменения для этого релиза, так как он служит описанием PR
Не сливать main обратно в dev	После слияния PR dev автоматически синхронизируется, обратное слияние не требуется

Правила сообщений

Языковые соглашения

Рекомендуется использовать русский язык для сообщений коммитов в целях единообразия командной коммуникации.

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

Subject (Тема)

Использовать русский язык, кратко и ясно
Длина не более 50 символов
В конце не ставить точку

Body (Тело)

Подробно описать причину и способ изменений
Каждая строка не более 72 символов
Использовать - или * для перечисления пунктов

Breaking changes: начинается с BREAKING CHANGE:
Закрытие Issue: использовать Закрыть #123 или Исправить #456

Примеры

✨ feat — Новая функциональность

:sparkles: feat(parser): Добавить поддержку синтаксического анализа замыканий

Реализация синтаксического анализа выражений замыканий:
- Поддержка сокращённого синтаксиса |args| body
- Поддержка семантики захвата move
- Добавление вывода типов для замыканий

Закрыть #42

🐛 fix — Исправление бага

:bug: fix(repl): Исправить неработающий автодополнятель при многострочном вводе

SessionREPL неправильно регистрировал дополнятель в многострочном режиме,
из-за чего дополнение по Tab не срабатывало.

Исправить #128

📝 docs — Обновление документации

:memo: docs(design): Обновить спецификацию модели владения и системы типов

Синхронизация последних изменений дизайна из RFC-009 и RFC-011.

♻️ refactor — Рефакторинг

:recycle: refactor(typecheck): Разделить примитивные типы значений и семантику поверхностного копирования Dup

Разделение типов значений и семантики копирования в MonoType,
устранение специальных случаев в ветках match.

⚡️ perf — Оптимизация производительности

:zap: perf(types): Оптимизировать вычисление const generic

Добавлен лимит глубины рекурсии (по умолчанию 128)
для избежания переполнения стека при обработке вредоносных
выражений типов.

✅ test — Тестирование

:white_check_mark: test(typecheck): Дополнить тесты изменчивости VarInfo для scope

Покрытые сценарии:
- Только для чтения при неизменяемом связывании
- Отслеживание изменчивости для mut связываний
- Распространение изменчивости через границы областей видимости

🔧 chore — Разное

:wrench: chore(build): Обновить rand, hashbrown, tempfile, ron, clap

Обновление 6 production-зависимостей до последних стабильных версий.

🚀 ci — CI конфигурация

:rocket: ci: Исправить проблему слишком низкой версии Rust для nightly-сборки

Обновление RUST_TOOLCHAIN с 1.91.0 до 1.96.0
для соответствия требованиям rust-version в Cargo.toml.

💄 style — Форматирование

:lipstick: style(frontend): Применить форматирование cargo fmt

Унификация стиля переноса строк в сигнатурах функций.

🔖 Коммит релиза

Когда текущий коммит является релизом (Release), необходимо следовать следующим правилам:

Формат коммита релиза

:bookmark: V<версия>: <заголовок релиза>

## 📦 Информация о версии

**Дата релиза:** YYYY-MM-DD

**Версия:** <старая версия> → <новая версия>

---

## ✨ Новая функциональность

### <модуль функциональности>
- :sparkles: feat(<scope>): <описание функции>

---

## ♻️ Рефакторинг и оптимизация

- :recycle: refactor(<scope>): <описание рефакторинга>

---

## 🐛 Исправление багов

- :bug: fix(<scope>): <описание исправления>

---

## 🔧 Другие изменения

- :wrench: chore: <описание изменения>

---

## 📦 Новые файлы

- `<путь к файлу>` - <описание файла>

---

## 📝 История коммитов

| Коммит | Описание |
|:---:|------|
| `<hash>` | :bookmark: V<версия> |
| `<hash>` | <сообщение коммита> |

Требования к релизу

Заголовок сообщения: Необходимо использовать формат :bookmark: + V<версия>
Версия: Следовать семантическому версионированию
Полнота содержимого: Необходимо включить все коммиты с момента предыдущего релиза
Классификация по типам: Организовать по типам feat, fix, refactor, chore и т.д.
История коммитов: Перечислить хеши и описания всех связанных коммитов

Пример релиза

:bookmark: V0.7.2: Переработка REPL и улучшение системы типов

## 📦 Информация о версии

**Дата релиза:** 2026-06-01

**Версия:** 0.7.1 → 0.7.2

---

## ✨ Новая функциональность

- :sparkles: feat(typecheck): Реализовать автоматический вывод параметров обобщённых типов
- :sparkles: feat(typecheck): Добавить структурированное представление обобщённых типов MonoType::Generic
- feat: Подключить CLI REPL команды к SessionREPL

---

## ♻️ Рефакторинг и оптимизация

- :recycle: refactor(backends): Удалить модуль tui_repl, переписать в SessionREPL
- :recycle: refactor(typecheck): Внедрить VarInfo для отслеживания изменчивости переменных scope
- :recycle: refactor(typecheck): Разделить примитивные типы значений и семантику Dup

---

## 🐛 Исправление багов

- :bug: fix(repl): Настроить историю REPL по умолчанию, исправить shell evaluate_code
- :bug: fix(repl): Зарегистрировать дополнятель и исправить многострочный ввод
- :bug: fix(repl): Удалить лишнюю точку с запятой в wrap_code для сохранения значения выражения

---

## ⚡ Оптимизация производительности

- :zap: perf(types): Добавить лимит глубины рекурсии для вычисления const generic

---

## 🔧 Другие изменения

- :wrench: chore(build): Обновить rand, hashbrown, tempfile, ron, clap, owo-colors
- :white_check_mark: test(typecheck): Дополнить тесты изменчивости VarInfo для scope

---

## 📝 История коммитов

| Коммит | Описание |
|:---:|------|
| `f438aab` | :sparkles: feat(typecheck): Реализовать автоматический вывод параметров обобщённых типов |
| `bf0c121` | :zap: perf(types): Лимит глубины рекурсии |
| `6edac15` | feat: Подключить CLI REPL к SessionREPL |
| `02cf54f` | :sparkles: feat(typecheck): MonoType::Generic |
| `3160a28` | :recycle: refactor(typecheck): VarInfo для отслеживания изменчивости |
| `f00a2a4` | :recycle: refactor(backends): Удалить модуль tui_repl |
| `afe3e0c` | :bug: fix(repl): История REPL и исправления shell |
| `c4d2242` | :wrench: chore(build): Обновление зависимостей |

Как получить историю коммитов

bash

# Посмотреть все коммиты с момента предыдущего релиза
git log --oneline <коммит предыдущего релиза>..HEAD

# Или последние N коммитов
git log --oneline -20

Эталонный шаблон

Документацию релиза см. в шаблоне release.md.

1. Настройка Commit Template

bash

# Выполнить в корневом каталоге проекта
git config commit.template .gitmessage.txt

2. Файл Template

Формат файла .gitmessage.txt в корневом каталоге проекта:

# emoji-код type(scope): тема (на русском)
#
# Тело (необязательно)
#
# Футер (необязательно)
#
# Types: ✨feat, 🐛fix, 📝docs, 💄style, ♻️refactor, ⚡️perf, ✅test, 🔧chore, 🚀ci, 🔖release
# Scopes: frontend, parser, lexer, typecheck, types, middle, codegen,
#         monomorphize, lifetime, backends, repl, shell, runtime,
#         std, formatter, lsp, package, util, docs, design, plan,
#         build, ci, test, release, meta
#
# Примеры:
# ✨ feat(db): Добавить функцию массового удаления задач
# 🐛 fix(provider): Исправить восстановление таймера из фона
#
# Формат релиза: 🔖 V1.0.0: Заголовок релиза

Часто задаваемые вопросы

Q: Как выбрать тип коммита?

feat: Изменения функциональности, видимые пользователю
fix: Исправление проблем, о которых сообщили пользователи
docs: README, комментарии и прочая документация
chore: Обновление зависимостей, конфигурационных файлов
refactor: Оптимизация кода без изменения поведения

Q: Когда следует разделять коммиты?

Каждый коммит должен делать одно дело
Связанные изменения коммится вместе, несвязанные — отдельно
Следовать принципу Atomic Commits

Ссылки

Conventional Commits
gitmoji
emoji.md — Полный список Emoji
release.md — Шаблон релиза

💡 Подсказка: Поддерживайте атомарность коммитов и ясность описаний — это делает код-ревью и откат изменений более эффективными!

Commit Руководство по коммитам ​

Содержание ​

Формат коммита ​

Составляющие части ​

Типы коммитов ​

Полный справочник Emoji ​

Области видимости ​

Топовые модули ​

Подмодули фронтенда ​

Подмодули среднего слоя ​

Подмодули бэкенда ​

Области видимости документации ​

Другие области видимости ​

Правила сообщений ​

Управление версиями ​

CI Процесс релиза ​

Ключевые правила ​

Правила сообщений ​

Языковые соглашения ​

Subject (Тема) ​

Body (Тело) ​

Footer (Футер) ​

Примеры ​

✨ feat — Новая функциональность ​

🐛 fix — Исправление бага ​

📝 docs — Обновление документации ​

♻️ refactor — Рефакторинг ​

⚡️ perf — Оптимизация производительности ​

✅ test — Тестирование ​

🔧 chore — Разное ​

🚀 ci — CI конфигурация ​

💄 style — Форматирование ​

🔖 Коммит релиза ​

Формат коммита релиза ​

Требования к релизу ​

Пример релиза ​

Как получить историю коммитов ​

Эталонный шаблон ​

1. Настройка Commit Template ​

2. Файл Template ​

Часто задаваемые вопросы ​

Q: Как выбрать тип коммита? ​

Q: Когда следует разделять коммиты? ​

Ссылки ​

Commit Руководство по коммитам

Содержание

Формат коммита

Составляющие части

Типы коммитов

Полный справочник Emoji

Области видимости

Топовые модули

Подмодули фронтенда

Подмодули среднего слоя

Подмодули бэкенда

Области видимости документации

Другие области видимости

Правила сообщений

Управление версиями

CI Процесс релиза

Ключевые правила

Правила сообщений

Языковые соглашения

Subject (Тема)

Body (Тело)

Footer (Футер)

Примеры

✨ feat — Новая функциональность

🐛 fix — Исправление бага

📝 docs — Обновление документации

♻️ refactor — Рефакторинг

⚡️ perf — Оптимизация производительности

✅ test — Тестирование

🔧 chore — Разное

🚀 ci — CI конфигурация

💄 style — Форматирование

🔖 Коммит релиза

Формат коммита релиза

Требования к релизу

Пример релиза

Как получить историю коммитов

Эталонный шаблон

1. Настройка Commit Template

2. Файл Template

Часто задаваемые вопросы

Q: Как выбрать тип коммита?

Q: Когда следует разделять коммиты?

Ссылки