Concurrent Branches
Resolve conflicts and merges when several branches are open against one repo at the...
Install
npx skills add kajisho5/ffmpeg-skill --skill concurrent-branches -g -a claude-code -y- Repository
- kajisho5/ffmpeg-skill4.3k
- Category
- Testing
- Updated
- 4d ago
- License
- MIT
- Context cost
- Mediumabout 2,610 tokens
- Runs scripts
- No, instructions only
What it does
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.
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.
# 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:
<<<<<<< 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:
