3.3 KiB

Raw Blame History

Правила работы агента

Общий принцип

Работа ведется этапами.

После завершения каждого смыслового этапа агент:

кратко фиксирует, что сделано
предлагает пользователю название коммита
ждет явного подтверждения на коммит
только после подтверждения выполняет git commit

Коммиты не должны идти бессистемным потоком.

Каждый коммит должен визуально читаться по заголовку и сразу показывать:

какой это слой изменений
к какому направлению относится этап
что именно сделано на этом этапе

Формат названия коммита

Формат:

<ТИП> - МЕЖПРОЕКТНАЯ КОММУНИКАЦИЯ: <НАЗВАНИЕ ЭТАПА>

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

Использовать верхний уровень по смыслу изменений:

UI — если изменения в интерфейсе, текстах, навигации, отображении, UX
ФУНКЦИИ — если изменения в прикладной логике, API, действиях, синхронизации, обработчиках
АРХ — если изменения в архитектуре, структуре данных, инфраструктурных правилах, каркасе реализации

Если этап затрагивает несколько слоев, выбирать доминирующий.

Правило предложения коммита

После каждого завершенного этапа агент должен предлагать пользователю готовое название коммита.

Пример:

UI - МЕЖПРОЕКТНАЯ КОММУНИКАЦИЯ: переименование модуля во внутренний контур

Пользователь отвечает подтверждением в духе:

коммитить
да, коммить
ок, коммит

Только после этого агент делает коммит.

Примеры

UI - МЕЖПРОЕКТНАЯ КОММУНИКАЦИЯ: переименование модуля во внутренний контур
ФУНКЦИИ - МЕЖПРОЕКТНАЯ КОММУНИКАЦИЯ: создание запроса в целевой проект
ФУНКЦИИ - МЕЖПРОЕКТНАЯ КОММУНИКАЦИЯ: синхронизация статусов источника и цели
АРХ - МЕЖПРОЕКТНАЯ КОММУНИКАЦИЯ: каркас source-target связи
АРХ - МЕЖПРОЕКТНАЯ КОММУНИКАЦИЯ: регламент этапов и именования коммитов

Дополнение

Если пользователем не сказано иное:

не делать amend
не переписывать историю
не объединять несколько отдельных этапов в один коммит постфактум

3.3 KiB Raw Blame History Unescape Escape