Guide for rebasing feature branches onto main in the Fusion Framework monorepo, including handling pnpm-lock.yaml conflicts
73
58%
Does it follow best practices?
Impact
97%
1.42xAverage score across 3 eval scenarios
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./.agents/skills/custom-rebase/SKILL.mdThis skill helps you rebase feature branches onto the latest main branch, handling common conflicts in a pnpm monorepo.
When rebasing a feature branch, you'll often encounter conflicts in pnpm-lock.yaml due to parallel dependency changes. The correct approach is to regenerate the lockfile rather than manually resolving conflicts.
# Navigate to your worktree or branch
cd /path/to/worktree
# Ensure you're on the correct branch
git branch
# Fetch latest changes from origin (including main)
git fetch origin
git fetch origin main:refs/remotes/origin/main# Rebase your branch onto the latest main
git rebase origin/mainCRITICAL: When pnpm-lock.yaml has conflicts during rebase:
# Regenerate it from package.json files
pnpm install
# Stage the regenerated lockfile
git add pnpm-lock.yaml
# Continue the rebase
git rebase --continueWhen you encounter a "Version Packages (next)" commit with conflicts:
This happens when your feature branch has pre-release versions (e.g., 2.0.0-next.0) but main has been updated with newer regular versions.
Resolution strategy:
--ours (HEAD version from main)--ours (HEAD changelog from main)# For all package.json conflicts, keep HEAD version
git checkout --ours "packages/*/package.json"
git add "packages/*/package.json"
# For all CHANGELOG.md conflicts, keep HEAD changelog
git checkout --ours "packages/*/CHANGELOG.md"
git add "packages/*/CHANGELOG.md"
# Also check other affected files
git checkout --ours "vue-press/package.json" 2>/dev/null || true
git add "vue-press/package.json" 2>/dev/null || true
# Continue the rebase
git rebase --continueWhy? The main branch has the authoritative versions and changelogs. Your feature branch's pre-release versions will be regenerated when you create a new changeset after rebasing.
For conflicts in source files (.ts, .tsx, etc.):
# Manually resolve conflicts in the files
# Then stage the resolved files
git add path/to/resolved-file.ts
# Continue the rebase
git rebase --continueAfter all commits are rebased successfully:
# Verify the branch is clean
git status
# Force push to update the remote branch
git push --force-with-lease origin YOUR_BRANCH_NAMEIf .changeset/pre.json exists (pre-release mode), align initialVersions to current package versions for packages changed by the rebase:
# From repo root
node .agents/skills/custom-rebase/scripts/align-pre-initial-versions.cjsWhat it does:
.changeset/pre.json to get the tag (e.g., next)initialVersions when the current package version does NOT end with -TAG.NUMBER (e.g., 2.0.0 or 2.1.0)-TAG.NUMBER (e.g., 2.0.0-next.0), preserving ongoing pre stateBefore pushing, verify local rebase result against the remote branch.
# Ensure you have latest remote
git fetch origin
# Set a helper var for current branch
BRANCH=$(git rev-parse --abbrev-ref HEAD)
# Quick overview of what will change on the remote
git diff --stat origin/$BRANCH...HEAD
# See the file list (useful to spot unintended changes)
git diff --name-only origin/$BRANCH...HEAD | sort
# Review commit differences (left/right) without merges
git log --oneline --left-right --cherry --no-merges origin/$BRANCH...HEAD
# Optional: preview the push without sending any data
git push --force-with-lease --dry-run origin $BRANCHProceed to push only if the changes match expectations.
Run the data extraction script:
# From repo root
node .agents/skills/custom-rebase/scripts/generate-rebase-report.cjs --no-fetchThis generates .tmp/skills/custom-rebase/<timestamp>-rebase-report.md with raw data:
zod: ^3.23.8 → ^4.3.5)@azure/search-documents: ^12.2.0)After the raw report is generated, the AI agent will automatically:
.tmp/skills/custom-rebase/<timestamp>-rebase-report.mdThe summary will be displayed in the chat for review before you push.
Open the SUMMARY.md file in your editor to review before pushing.
If your local branch has diverged incorrectly:
# Fetch latest
git fetch origin
# Hard reset to remote branch
git reset --hard origin/YOUR_BRANCH_NAMEIf you need to start over:
git rebase --abort# After resolving conflicts and staging changes
git rebase --continueOnly if the commit is no longer needed:
git rebase --skiporigin/mainpnpm-lock.yaml conflicts:
git rm pnpm-lock.yamlpnpm install to regenerategit add pnpm-lock.yamlgit rebase --continue--force-with-leaseThe lockfile contains exact dependency resolutions for the entire monorepo. During a rebase:
By regenerating with pnpm install:
package.json files (including your changes)Your local branch has commits that aren't on remote. Common causes:
Fix: Reset to remote and rebase:
git fetch origin
git fetch origin main:refs/remotes/origin/main
git reset --hard origin/YOUR_BRANCH_NAME
git rebase origin/mainYou may be rebasing in the wrong direction. Ensure:
git rebase origin/mainCheck:
package.json changes are staged/committedpackage.json files# 1. Navigate and prepare
cd /Users/odin.rochmann/dev/GitHub/fusion-framework.worktree/react-19
git fetch origin
git fetch origin main:refs/remotes/origin/main
# 2. Ensure clean state
git status # Should show "nothing to commit, working tree clean"
# 3. Start rebase
git rebase origin/main
# 4. If pnpm-lock.yaml conflict appears:
git rm pnpm-lock.yaml
pnpm install
git add pnpm-lock.yaml
git rebase --continue
# 5. Repeat step 4 for each commit with lockfile conflicts
# 6. When rebase completes:
git push --force-with-lease origin react-19fusion-dependency-review - Review dependency pull requests that need branch refresh or conflict follow-up060e3af
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.