Menu

Individual skill

git-rebase

0upvotes

Rebase branches and resolve cross-commit conflicts while preserving changes. Excludes merge-commit workflows, cherry-picking, and repository setup.

extensions/spec-cycle/skills/git-rebase/SKILL.md

Read pinned source

Source commit 14f57173e5cae483392cce90a06098fd04dcfda0

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
No
Repository scan complete
No
Skill scan complete
No
Observed behavior
Not checked yet
Last checked
Nov 3, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
2,858
Repository last updated
Nov 8, 2026
License
MIT

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

# Git Rebase

Carry out the requested rebase while preserving both sides' intended behavior and unrelated work. A rebase request does not by itself authorize squashing, dropping commits, changing global Git settings, or publishing a rewritten branch.

1. Inspect status, current branch, target, and any in-progress rebase. Reuse a known target and current fetch evidence. Preserve dirty work; do not auto-stash, reset, checkout, clean, or stage unrelated paths. Use an isolated checkout when needed.
2. Before starting a new rebase, record HEAD and keep a backup ref when rewriting valuable history. `bash <skill-dir>/scripts/pre-rebase-backup.sh` creates a backup for a clean branch without modifying tracked files. An existing verified backup needs no duplicate.
3. Rebase onto the requested target directly by default. Use interactive/squash/reorder operations only when the user requested that history change; commit count is not a reason to squash. Consult `references/strategies.md` for an actual strategy decision.
4. When conflicts occur, inspect the replayed commit, base, and both sides. During rebase, `ours` is the target plus commits already replayed; `theirs` is the commit being replayed. Trace changed APIs and preserve intended security, state, and compatibility contracts rather than accepting one side wholesale.
5. Resolve the affected files, inspect their diff, stage only those resolved paths, then continue. Reuse valid observations for repeated conflicts. Do not add merge-history comments to production code or run a full suite after every file.
6. At the completed rebase, inspect the resulting patch series/diff and run checks for affected behavior plus the project's required delivery gate. Tests that expose a regression require a production fix, not weaker assertions.
7. Publish only when already authorized. Use `--force-with-lease` for a rewritten remote branch, and follow the project's current-head CI policy. If the lease fails, inspect the new remote commits; do not replace it with unconditional force.

Use `references/resolution-patterns.md` for semantic conflicts and `references/troubleshooting.md` for diagnosed operational failures. Helpers live under this skill's actual `scripts/` path; `analyze-conflicts.sh`/`validate-merge.sh` are optional aids after checking their repository assumptions. They do not replace the owning tests or gate. Recovery that discards work still needs the repository's explicit permission; a backup ref is evidence, not permission to reset.