Heim

Skill

Codeüberprüfung

pull-changes-resolve-conflicts

cognitedata/builder-skills

Standardarbeitsablauf zum Herunterladen von Aktualisierungen aus der Haupt- oder anderen Branches in Projekten mit mehreren Mitwirkern (einschließlich Flows-Apps), wobei die bisherige Arbeit nicht stillschweigend verworfen wird. Er bietet Anleitungen zum Abrufen und Zusammenführen, verlangt eine explizite Auflistung von Merge-Konflikten, analysiert die Unterschiede zwischen eigenen und fremden Änderungen anhand der Konversationshistorie sowie des Repository-Kontexts, gibt priorisierte Empfehlungen vor und sammelt die Antworten der Benutzer ein, bevor Konfliktmarkierungen geändert oder das Zusammenführen abgeschlossen wird. Auslöser: Pull aus der Haupt-Branch, Zusammenführen mit der Haupt-Branch, Zusammenführen mit der Origin-Branch, Rebase, Merge-Konflikt, unzusammengeführte Patches

...Alle erweitern

Zeit aktualisiert 26. August 2026

# code-review # git # version-control # workflow # Code ReviewGit & Version ControlProductivity & Workflow # merge-conflicts

Über pull-changes-resolve-conflicts

Ein geführter Arbeitsablauf zur Integration einer Branch in eine andere (in der Regel das Pullen oder Mischen von main in eine Feature-Branch) in Projekten mit mehreren Mitwirkern, ohne absichtlich geleistete Arbeit stillschweigend zu ignorieren. Er gilt für jeden auf Git basierenden Team-Arbeitsablauf, wobei Flows/React-Anwendungen als häufiger Fall genannt werden, in dem Konflikte oft in App-Shells, der oberen Navigation, Route-Modulen sowie in gemeinsamen lib-/ oder hooks-/Verzeichnissen auftreten. Das zentrale Prinzip ist, dass bei der Konfliktlösung niemals vorausgesetzt werden darf, dass „main“ oder „unsere Version“ automatisch gewinnt, und dass Abwägungen dem Benutzer vor der Bearbeitung der Konfliktmarkierungen sichtbar gemacht werden müssen.

Der Arbeitsablauf erfolgt in mehreren Schritten: Zunächst wird Daten abgerufen und integriert (vorzugsweise mit git fetch gefolgt von git merge origin/main, sofern kein Rebase angefordert wurde). Anschließend werden alle noch nicht integrierten Dateien mit einer kurzen Erklärung dazu, was sich unterschieden hat, ausgewiesen. Danach erfolgt die Analyse mithilfe der Konversationsgeschichte, von Repo-Signalen wie PRD.md oder aktuellen Commit-Verläufen sowie der Konfliktabschnitte selbst, wobei git show :2:path für unsere Version und git show :3:path für die andere verwendet wird. Konflikte werden als orthogonal (sicher zur Kombination), überlappend (man muss auswählen oder manuell zusammenführen) oder mit Korruptionsrisiko (doppelte Blöcke durch fehlerhafte Merges) klassifiziert. Die Ergebnisse werden anschließend als priorisierte Empfehlungen sowie klare Fragen dargestellt, geordnet von P0 (strukturelle/produktbezogene Änderungen wie entfernte Routen, gestrichene Funktionen oder geänderte Daten bzw. API-Verträge) bis P3 (präsentationstechnische Anpassungen wie Abstände und Klassennamen).

Strenge Regeln verhindern eine stillschweigende Lösung: Konfliktmarkierungen werden nicht entfernt und git add wird nicht ausgeführt, solange der Benutzer dem Plan nicht zustimmt oder die Empfehlungen nicht ausdrücklich annimmt. Die Funktion stoppt bei Konflikten, anstatt große Dateien einfach durchzuziehen, und ermöglicht das Abbrechen über git merge --abort oder git rebase --abort. Zudem werden zu vermeidende Anti-Muster aufgelistet, wie das Auswählen von --ours oder --theirs im gesamten Repo oder das Verstecken einer Konfliktliste in einem langen Code-Auszug ohne kurze Zusammenfassung. Optionale Befehlsbeispiele sowie ein Meldungsvorlage für das Mischen befinden sich in dem begleitenden reference.md.

FAQ

Wann sollte ich diese Funktion verwenden?

Immer dann, wenn Sie eine andere Branch (in der Regel main) in Ihre aktuelle Feature-Branch integrieren oder wenn git status nach einem Merge oder Rebase noch nicht integrierte Pfade anzeigt. Sie gilt für jeden auf Git basierenden Team-Arbeitsablauf, wobei Flows/React-Anwendungen ein häufiger Fall sind.

Löst sie Konflikte automatisch ohne meine Zustimmung?

Nein. Eine strenge Regel verbietet eine stillschweigende Lösung: Sie wird weder Konfliktmarkierungen entfernen noch git add ausführen, solange Sie dem Plan nicht zustimmen oder ausdrücklich die Empfehlungen anwenden lassen. Sie stoppt bei Konflikten und meldet diese zunächst.

Wie entscheidet sie, welche Konflikte zuerst besprochen werden sollen?

Konflikte werden nach ihrem Einflussgrad geordnet, von P0 (strukturelle/produktbezogene Änderungen wie entfernte Routen, gestrichene Funktionen oder geänderte Daten und API-Verträge) bis P3 (präsentationstechnische Anpassungen wie Abstände, Klassennamen und Texte).

Welche Informationen verwendet sie zur Analyse eines Konflikts vor der Bearbeitung?

Sie nutzt die Konversationsgeschichte darüber, welche Funktionen in der Branch enthalten waren, Repo-Signale wie PRD.md oder aktuelle Commit-Verläufe sowie die Datei-Eigentümer, sowie die Konfliktabschnitte selbst über git show :2:path für unsere Version und git show :3:path für die andere.

Was passiert, wenn ich das Mischen einfach abbrechen möchte?

Die Funktion unterstützt das Ausführen von git merge --abort oder git rebase --abort je nach Situation und teilt mit, dass dadurch der aktuelle Integrationszustand für diese Operation verloren geht.

Alle Dateien

2 Dateien reference.md 0,7 KB Ansicht SKILL.md 5,5 KB Ansicht

Auf GitHub ansehen

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 run git add on 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 fetch then git merge origin/main (or the named branch) unless the user asked for rebase.
If merge is already in progress, run git status and 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 and git diff without 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 shared lib/).
Conflict hunks — git show :2:path (ours) vs git 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 --abort or git rebase --abort as appropriate; confirm they lose in-progress integration state for that operation.

Anti-patterns (do not do)

Picking --ours / --theirs on 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 with git 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/ or hooks/.

For optional command snippets and a merge message template, see reference.md.

Alle Dateien

0 Dateien