Дом
pull-changes-resolve-conflicts
cognitedata/builder-skills
Стандартный рабочий процесс загрузки обновлений с основной или других веток в проектах с участием нескольких авторов (включая приложения Flows), при котором работа не теряется без ведома пользователя. В руководстве описаны шаги загрузки и слияния данных, необходимость явного указания конфликтов при слиянии, анализ наших и чужих изменений с использованием истории обсуждений и контекста репозитория, предоставление рекомендаций с указанием приоритетов, а также получение ответов от пользователя перед редактированием маркеров конфликтов или завершением процесса слияния. Триггеры: загрузка данных с основной ветки, слияние с основной веткой, слияние с веткой origin, ребейс, конфликт при слиянии, неслиянные патчи.
...Расширить всеО функции pull-changes-resolve-conflicts
Это пошаговый рабочий процесс для интеграции одной ветки в другую (обычно ветки main в функциональную ветку) в проектах с несколькими участниками, при котором не происходит незаметного удаляния сделанных работ. Он применим к любому рабочему процессу команды, основанному на Git; особенно часто такие проблемы возникают в приложениях на Flows/React, где конфликты склонны сосредотачиваться в оболочках приложений, верхнем меню навигации, модулях маршрутов, а также в общих каталогах lib/ или hooks/. Основной принцип заключается в том, что при разрешении конфликтов нельзя сразу предполагать, что «ветка main победила» или «наша ветка победила», и что любые компромиссы должны быть явно показаны пользователю перед тем, как будут изменены маркеры конфликтов.
Рабочий процесс проходит по этапам: сначала загружаются данные и осуществляется интеграция (предпочтительно с использованием команд git fetch, затем git merge origin/main, если не было запроса на rebase), после чего приводится отчет о каждом неинтегрированном файле с кратким описанием того, в чем произошло расхождение. Затем проводится анализ с использованием истории обсуждений, сигналов репозитория (например, документа PRD.md или недавних коммитов), а также самих фрагментов конфликтов с помощью команд git show :2:path (наш вариант) и git show :3:path (их вариант). Конфликты классифицируются как ортогональные (можно безопасно объединять), перекрывающиеся (необходимо выбрать один вариант или объединить вручную) или с риском повреждения данных (дублированные блоки из некорректных объединений). Результаты анализа представляются в виде рекомендаций с указанием приоритета и конкретных вопросов, распределенных от P0 (структурные/функциональные изменения, такие как удаление маршрутов, отказ от функций, изменение данных или условий API) до P3 (корректировки визуального оформления, такие как расстояния между элементами и имена классов).
Существуют строгие правила, запрещающие незаметное разрешение конфликтов: маркеры конфликтов не удаляются, а команда git add не выполняется до тех пор, пока пользователь не согласится с предложенным планом или явно не примет рекомендации. Инструмент останавливается на уровне конфликтов, не пытаясь принудительно обработать большие файлы, и позволяет отменить процесс с помощью команд git merge --abort или git rebase --abort. Также указываются антипаттерны, которых следует избегать, например выбор вариантов --ours или --theirs для всего репозитория или скрытие списка конфликтов в длинном блоке кода без краткого резюме. Примеры команд и шаблоны сообщений для объединения содержатся в сопроводительном файле reference.md.
Часто задаваемые вопросы
Когда следует использовать этот инструмент?
Каждый раз, когда вы интегрируете другую ветку (обычно main) в текущую функциональную ветку, или когда команда git status показывает неинтегрированные пути после объединения или rebase. Он применим к любому рабочему процессу команды, основанному на Git; особенно часто такие проблемы возникают в приложениях на Flows/React.
Будет ли он автоматически разрешать конфликты без моего участия?
Нет. Существует строгое правило, запрещающее незаметное разрешение конфликтов: инструмент не удаляет маркеры конфликтов и не выполняет команду git add до тех пор, пока вы не согласитесь с предложенным планом или явно не скажете использовать его рекомендации. Он останавливается на уровне конфликтов и сначала сообщает о них.
Как он определяет, какие конфликты обсуждать в первую очередь?
Конфликты сортируются по степени влияния, от P0 (структурные/функциональные изменения, такие как удаление маршрутов, отказ от функций или изменение данных и условий API) до P3 (корректировки визуального оформления, такие как расстояния между элементами, имена классов и текст).
Какую информацию он использует для анализа конфликта перед его редактированием?
Для анализа используется история обсуждений относительно того, что содержалась в ветке, сигналы репозитория, такие как документ PRD.md или недавние коммиты, а также информация об авторстве файлов. Также анализируются сами фрагменты конфликтов с помощью команд git show :2:path для нашего варианта и git show :3:path для их варианта.
Что делать, если я просто хочу отменить процесс объединения?
Инструмент позволяет использовать команды git merge --abort или git rebase --abort в зависимости от ситуации, и сообщает, что при этом будет потеряно текущее состояние интеграции.
Все файлы
2 файла reference.md — 0,7 КБ — Просмотреть SKILL.md — 5,5 КБ — Просмотреть
Use this skill whenever integrating another branch (usually main) into the current feature branch, or when git status shows unmerged paths after a merge or rebase. Applies to any Git-based team workflow; Flows/React apps are a common case where conflicts cluster in app shells and shared libraries.
Goals
- Preserve intentional work on the current branch; do not assume “main wins” or “ours wins” without analysis.
- Make trade-offs visible to the user before any conflict resolution edits.
- Order discussion by impact: structural / feature / API / data-model changes before styling, copy, or spacing.
Hard rules
- No silent resolution — Do not remove
<<<<<<</=======/>>>>>>>or rungit addon conflicted files until the user has agreed to the plan (or explicitly says “use your recommendations”). - Stop at conflicts — If a merge or rebase introduces conflicts, pause and report; do not bulldoze through large files by picking one side wholesale unless the user explicitly requests that.
- Prioritize impact — When presenting conflicts, group and order roughly as:
- P0 — Structural / product: removed routes, deleted modules, dropped features, changed data or API contracts, SDK or schema changes, auth or routing shell.
- P1 — Behavior: logic, hooks, queries, filters, error handling, loading states.
- P2 — UI structure: layout regions, new or removed sections, navigation.
- P3 — Presentation: tokens, spacing, class names, copy tweaks.
Workflow
1. Fetch and integrate (or diagnose)
- Prefer
git fetchthengit merge origin/main(or the named branch) unless the user asked for rebase. - If merge is already in progress, run
git statusand list every unmerged file.
2. Report conflicts to the user (explicit)
Output a clear list:
- Branch state: current branch, target branch (e.g.
origin/main), merge vs rebase. - Unmerged files: paths only, then optionally
git diff --name-only --diff-filter=U. - Per file (short): one line on what diverged (e.g. “
AlertsPage— layout + new data scope”) if inferable from paths andgit diffwithout resolving.
3. Analyze before editing
Use all of:
- Conversation history — What was the user or team trying to ship on this branch?
- Repo signals — Product or architecture docs if present (e.g.
PRD.md), recent commits on the current branch, file ownership (e.g. large feature module vs sharedlib/). - Conflict hunks —
git show :2:path(ours) vsgit show :3:path(theirs) during merge, or read conflict markers; identify duplicated vs orthogonal changes.
Classify each conflicted area as:
- Orthogonal — safe to combine (e.g. import sort + new prop).
- Overlapping — must choose or manually merge (same lines).
- Corruption risk — duplicated blocks (common after bad merges); flag and recommend reconstructing from one side then re-applying the other side’s intent manually.
4. Recommendations + questions (required)
Present to the user:
- Summary table or bullets — file → recommended side or “manual merge” → one-line why.
- Ordered by P0 → P3 — call out anything that removes a feature or changes public behavior first.
- Explicit questions — anything ambiguous (e.g. “Keep main’s global behavior or the branch’s scoped variant?”).
- Ask for direction — e.g. “Reply with: (a) follow recommendations, (b) keep branch for file X, (c) keep main for file Y, (d) abort merge.”
Only after the user confirms (or gives a precise mapping), apply resolutions:
- Prefer small, surgical edits; preserve both sides’ intent when possible.
- Re-run
git status; ensure no conflict markers remain; run tests or lint the user cares about for touched areas.
5. If the user wants to abort
git merge --abortorgit rebase --abortas appropriate; confirm they lose in-progress integration state for that operation.
Anti-patterns (do not do)
- Picking
--ours/--theirson the whole repo without user approval. - “Resolving” by deleting a feature branch’s work because main touched the same file.
- Hiding conflict lists inside a long code dump without a short executive summary.
- Fixing low-impact style conflicts first while leaving P0 decisions implicit.
Quick reference
- Ours vs theirs (merge): stage 2 = current branch (
HEAD), stage 3 = incoming (MERGE_HEAD). Verify withgit checkout --conflict=merge <file>if needed. - Typical high-touch paths in full-stack or Flows apps: root app shell, top navigation, route modules, and shared
lib/orhooks/.
For optional command snippets and a merge message template, see reference.md.
Все файлы
0 файловУстановить pull-changes-resolve-conflicts
Скачайте файлы с навыками и извлеките их в папку .claude/skills/.
Скачать ZIPКлонируйте репозиторий и скопируйте файлы навыка в свой проект.
git clone https://github.com/cognitedata/builder-skills/blob/main/skills/pull-changes-resolve-conflicts/SKILL.md # Copy SKILL.md to your .claude/skills/ directory
Копировать
