lklimek Merge Base Branch
Merge the remote base branch into the current feature branch: pre-merge analysis, intelligent conflict resolution, behavioral change report.
Output philosophy: be concise — summaries, not diffs or source code. Never dump raw diffs, full file contents, or initial state unless explicitly requested; the user will ask for details.
Phase 1: Sync with Remote
Fetch all remotes and pull tracked branch changes (merge mode, never rebase).
CURRENT_BRANCH=$(git branch --show-current)
TRACKING=$(git rev-parse --abbrev-ref @{upstream} 2>/dev/null || echo "")
git fetch --all --prune
if [ -n "$TRACKING" ]; then
git pull --no-rebase
fi
If the pull produces conflicts, resolve them (see Phase 4) before continuing.
Phase 2: Identify the Base Branch
From PR metadata, using the git-and-github skill:
BASE_BRANCH=$(gh pr view --json baseRefName -q .baseRefName 2>/dev/null)
If no PR exists, fall back to the repo default branch:
BASE_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@')
If neither works, ask the user.
Merge from origin/$BASE_BRANCH (the remote-tracking ref, already updated by fetch) — not the local base branch, which may be stale.
Phase 3: Pre-Merge Analysis
Read diffs and logs internally to build context for conflict resolution and behavioral analysis (per Output philosophy — no diff/source output).
MERGE_BASE=$(git merge-base origin/$BASE_BRANCH HEAD)
# Our changes
git log --oneline $MERGE_BASE..HEAD
git diff --stat $MERGE_BASE..HEAD
git diff $MERGE_BASE..HEAD
# Their changes
git log --oneline $MERGE_BASE..origin/$BASE_BRANCH
git diff --stat $MERGE_BASE..origin/$BASE_BRANCH
git diff $MERGE_BASE..origin/$BASE_BRANCH
Overlap and semantic analysis
Identify files modified on both sides:
comm -12 \
<(git diff --name-only $MERGE_BASE..HEAD | sort) \
<(git diff --name-only $MERGE_BASE..origin/$BASE_BRANCH | sort)
Also find semantic overlaps — no textual conflict but behavior changes (e.g., upstream changed a function signature or default value that local code relies on).
Report a brief summary to the user:
- What each side changed (1-2 sentences per side)
- Overlapping files (if any)
- Semantic overlaps identified (if any)
Phase 4: Execute the Merge
git merge origin/$BASE_BRANCH --no-edit
If no conflicts
The merge commits automatically. Proceed to Phase 5.
If conflicts occur
For each conflicted file:
- Read the conflict markers — understand both sides using Phase 3 context
- Resolve intelligently — preserve both sides' intent; when ambiguous, prefer preserving existing behavior
- Stage the resolution —
git add <file> - Present to the user — a table summarizing the conflict, not raw source:
| Area | Ours | Theirs | Resolution |
|---|---|---|---|
function_name() |
Added X | Changed Y | Combined: X + Y |
Ask for approval before continuing. After all conflicts are resolved and approved:
git commit --no-edit
If the user rejects a resolution, apply their feedback and re-present.
Phase 5: Behavioral Change Report
The most important deliverable. Analyze the merge result for anything that could change runtime behavior — read merged files internally, no diff dumps.
Assign an overall Risk Factor (0-100%) — likelihood the merge introduced unintended behavioral changes:
- 0-20%: routine merge, disjoint changes, no behavioral overlap
- 21-50%: minor touches — new defaults, added parameters (backward-compatible)
- 51-80%: significant — modified control flow, changed defaults affecting existing callers, schema changes
- 81-100%: breaking — incompatible signatures, algorithm swaps, data format changes
What to look for
- Function signatures — parameters added/removed/reordered upstream affecting local callers
- Default values — config defaults, function defaults, env var fallbacks changed upstream
- Control flow — conditionals, early returns, error handling paths in overlapping code
- Types/schemas — struct fields, API shapes, database schemas changed on either side
- Dependency versions — lock files merged with potentially incompatible versions
- Import/module resolution — new upstream imports that shadow or conflict with local ones
- Test expectations — tests that may now fail due to changed behavior from either side
Upstream attribution
For conflicted files and files flagged under "Changes Requiring Attention", identify the upstream authors whose changes directly caused conflicts or semantic issues — not every contributor.
Report format
## Behavioral Change Report — Risk: <N>%
### Safe Changes
- <file> — <what changed, why it's safe>
### Changes Requiring Attention
- <file> — <what changed, potential impact>
### Relevant Upstream Contributors
| Author | Key Changes |
|---|---|
| @<github-handle> | <PR(s) that caused conflicts or semantic issues> |
### Recommended Follow-up
- [ ] <action items, if any>
Safe changes first, so the user confirms routine items quickly and focuses on what matters. If clean (risk ~0%), say so in one line and skip the sections.
Error Recovery
On any mid-merge failure:
git merge --abort
Report what happened and let the user decide how to proceed.