Разрешение конфликтов ответственности при параллельном редактировании одного артефакта агентами

Цель

Сведения актуальны на 25 октября 2026 года. Восстановить согласованное состояние после того, как параллельные агенты изменили один артефакт, исходя из несовместимых предположений. Заново проверьте правила слияния в репозитории, текущие требования и фактическую изоляцию рабочих каталогов. Эта процедура начинается с конфликта ответственности; она не служит общим введением в рабочие деревья или объединение независимых результатов.

Предварительные условия

Определите ответственного за интеграцию, текущую целевую редакцию, редакции конкурирующих вариантов и требования, порученные каждому участнику. Сохраните локальную работу, прежде чем менять целевое состояние. Рабочие деревья Git предоставляют отдельные рабочие каталоги и индексы при общих данных репозитория; не считайте рабочее дерево границей безопасности и не предполагайте, что внешние ресурсы сборки изолированы.

Шаги

1. Зафиксируйте конфликтующие варианты. Не позволяйте затронутым участникам изменять общий целевой артефакт. Сохраните каждый вариант как неизменяемый коммит или сохранённый патч, включив относящиеся к нему незакоммиченные изменения и неотслеживаемые файлы. Запишите его базовую редакцию, поставленную цель, изменённые пути и подтверждения проверок. Продолжайте несвязанную работу только там, где она не может изменить спорные входные данные.
2. Назначьте одного ответственного за каждый артефакт. Зафиксируйте, кто вправе принять или заменить окончательную версию. Другие агенты могут предлагать исправления, но интеграция относится к обязанностям этого ответственного. Публикуйте изменения в целевое состояние последовательно и отклоняйте результаты, ссылающиеся на устаревшую принятую редакцию. Сообщение участника о завершении — это предложение, а не передача ответственности.
3. Определите характер разногласия. Отделите пересечение текстовых изменений от несовместимости поведения. Сравните общие интерфейсы, значения настроек по умолчанию, зависимости, генерируемые результаты и их исходники. Например, если поставщик данных переименовал поле, а потребитель сохранил старое имя, их нужно согласовать, даже когда изменения находятся в разных файлах. Прежде чем разрешать конфликты строк, явно сформулируйте спорное требование.
4. Разрешайте конфликт на основе требований и подтверждений. Запросите у участников обоснование каждого несовместимого решения. Ответственный должен выбрать или подготовить вариант, соответствующий принятому контракту, и зафиксировать, какая альтернатива отклонена и почему. Если проект предусматривает такой процесс, заново сгенерируйте производные артефакты из выбранного исходника. Сохраните целевую регрессионную проверку спорного поведения; не ослабляйте проверки, чтобы оба варианта казались совместимыми.
5. Интегрируйте из состояния, к которому можно вернуться. Используйте чистый рабочий каталог для интеграции и зафиксируйте коммиты вариантов и целевого состояния. Документация Git по слиянию предупреждает, что прерывание слияния может не восстановить незакоммиченные изменения, существовавшие до него. Явно изучите конфликты. Если используете --no-commit для паузы перед проверкой, учитывайте слияния fast-forward: согласно документации Git, они на этой паузе не останавливаются.
6. Проверьте согласованный артефакт и закрепите итоговое решение. Выполните git diff --name-only --diff-filter=U, чтобы получить список неразрешённых записей слияния. После разрешения конфликтов используйте git diff --check BASE, заменив BASE записанным исходным коммитом целевого состояния. Git diff проверяет появившиеся маркеры конфликтов и ошибки пробельных символов; он не подтверждает правильность поведения. Выполните необходимые проверки проекта на объединённом варианте, включая спорный интерфейс. Зафиксируйте принятый коммит и сообщите участникам, какие варианты он заменяет.

Ожидаемый результат

Конфликт завершается решением с известным ответственным, воспроизводимым вариантом и проверкой, привязанной к его точной редакции. Запоздавшие результаты требуют нового сравнения с принятым артефактом. Удаляйте временные рабочие каталоги после подтверждения, что принятая работа и необходимые проверочные материалы сохранены.

Ограничения и основание проверки

Эта процедура здесь не проверялась. Испытайте её на безопасных конкурирующих изменениях, которые сливаются на уровне текста, но расходятся в интерфейсе. Для успешного восстановления нужно обнаружить это расхождение и не допустить повторной подачи устаревшего варианта. Слияние репозитория не заменяет сверку результатов внешних действий, уже выполненных агентами; эти результаты нужно фиксировать отдельно.