# Concurrent Branches

Resolve conflicts and merges when several branches are open against one repo at the...

- Repository: https://github.com/kajisho5/ffmpeg-skill (4279 stars)
- Category: Testing
- License: MIT
- Last updated: 2026-10-31
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add kajisho5/ffmpeg-skill --skill concurrent-branches -g -a claude-code -y`
Codex: `npx skills add kajisho5/ffmpeg-skill --skill concurrent-branches -g -a codex -y`
Cursor: `npx skills add kajisho5/ffmpeg-skill --skill concurrent-branches -g -a cursor -y`
Gemini CLI: `npx skills add kajisho5/ffmpeg-skill --skill concurrent-branches -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add kajisho5/ffmpeg-skill`

## Description

Resolve conflicts and merges when several branches are open against one repo at the same time, the hotspot files every change must touch (registry manifests, a single version field, shared tool config, one aggregated test module, tracked build output), union-vs-recompute-vs-rebuild as three different correct resolutions, generated artifacts that must never be merged, non-deterministic serialization that makes every branch conflict, renumbered identifiers that git cannot show you, and why a clean auto-merge is not a passing test. Use when rebasing or merging a long-lived branch, resolving conflict markers, reviewing a merge commit, deciding what a repo should commit vs generate, or setting up a repo that will take parallel contributions.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Merging Concurrent Branches

When several branches are open against the same repo at once, the conflicts do
not land in the code you were thinking about. They land in a small, predictable
set of **hotspot** files that nearly every change has to touch, a registry
manifest, a version field, shared tool config, one aggregated test module, a
tracked build output.

Each hotspot has exactly one correct resolution, and they are not the same rule.
"Take ours" / "take theirs" is right for almost none of them. Worse, getting one
wrong is silent: the dropped entry, the collided version, the stale bundle all
merge green and are found later by someone who cannot reproduce them.

## Find the hotspots before you need to resolve them

Files touched by nearly every commit are the files your branch will conflict on.

```bash
# the 15 files most commits touch, your hotspot list
git log --format= --name-only -n 200 | sort | uniq -c | sort -rn | head -15
```

Write the resolution rule for each one into the contributing docs. Under
conflict pressure, with a stale branch and a red CI run, nobody re-derives
"the version field is recomputed, not merged" correctly.

## Additive registries: union both sides, never choose one

A manifest that lists every component, plugin entries, module paths, exported
names, a feature list. Two branches each append an entry, and the conflict spans
both additions:

```jsonc
<<<<<<< HEAD
    "./components/exporter",
    "./components/importer"        // theirs, already merged to main
=======
    "./components/exporter",
    "./components/validator"       // yours
>>>>>>> feature/validator
```

Both sides are correct and neither is a substitute for the other. Resolve by
keeping **every** entry from both sides. Taking a side deletes a component that
is still fully present in the tree, the code compiles, the tests pass, and the
component is simply never registered or installed.

Nothing catches that unless you check the registry against the filesystem:

The rest: https://github.com/kajisho5/ffmpeg-skill/blob/HEAD/.claude/skills/concurrent-branches/SKILL.md