using-git-branchless
- Repo stars 0
- Author updated Live
- Author repo plugins
- Domain
- Engineering
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @0-xcf · no license declared
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- External requests
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: using-git-branchless
description: Use when working in a git repo that uses git-branchless or stacked-diffs workflow. Triggers - gi…
category: engineering
runtime: no special runtime
---
# using-git-branchless output preview
## PART A: Task fit
- Use case: Use when working in a git repo that uses git-branchless or stacked-diffs workflow. Triggers - git sl in CLAUDE.md, branchless in git config, user mentions stacks or stacked diffs, need to rebase/move/reorder commits, submit stacked PRs..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Mental Model / Command Quick Reference / Critical Distinctions” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Use when working in a git repo that uses git-branchless or stacked-diffs workflow. Triggers - git sl in CLAUDE.md, branchless in git config, user mentions stacks or stacked diffs, need to rebase/move/reorder commits, submit stacked PRs.”.
- **02** When the source has headings, the agent prioritizes “Mental Model / Command Quick Reference / Critical Distinctions” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; may access external network resources; usually needs no extra API key.
## Running Rules
- read files, write/modify files; may access external network resources; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “Mental Model / Command Quick Reference / Critical Distinctions”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: using-git-branchless
description: Use when working in a git repo that uses git-branchless or stacked-diffs workflow. Triggers - gi…
category: engineering
source: 0-xcf/plugins
---
# using-git-branchless
## When to use
- Use when working in a git repo that uses git-branchless or stacked-diffs workflow. Triggers - git sl in CLAUDE.md, bra…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Mental Model / Command Quick Reference / Critical Distinctions” and keep inference separate from source facts.
- read files, write/modify files; may access external network resources; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "using-git-branchless" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Mental Model / Command Quick Reference / Critical Distinctions
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | may access external network resources
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} git-branchless
Stacked-diffs workflow for Git. Commits are the unit of work, not branches. Think Mercurial/Phabricator-style development.
Mental Model
- Stack: a chain of draft commits off
main()/master. Stacks can branch. - Draft commits: your in-progress work. Visible in smartlog even without branch names.
- Public commits: merged into main. Immutable.
- Rebases happen in-memory first (fast, safe). Falls back to on-disk only if needed.
git undocan reverse almost any operation.
Command Quick Reference
| Task | Command |
|---|---|
| View commit graph | git sl |
| Go to specific commit | git checkout <hash> or git branchless switch <hash> |
| Navigate down stack (relative) | git prev [n] (interactive if stack branches) |
| Navigate up stack (relative) | git next [n] (interactive if stack branches) |
| Fuzzy-search checkout | git branchless switch -i |
| Create commit | git record -m "msg" |
| Insert commit mid-stack | git record --insert -m "msg" |
| Amend HEAD commit | git amend (stage changes first) |
| Amend + keep descendants identical | git amend --reparent |
| Reword commit message | git reword -m "new msg" |
| Move/rebase commits | git move -s <src> -d <dest> |
| Reorder: swap A and B | git move -x <B> -d <parent-of-A> |
| Squash into dest | git move -x <src> -d <dest> --fixup |
| Insert between dest and children | git move -s <src> -d <dest> --insert |
| Fix orphaned commits after amend | git restack |
| Sync all stacks onto updated main | git sync --pull |
| Sync without fetching | git sync |
| Push existing PR branches | git submit |
| Create new PR branches | git submit --create |
| Push as draft PRs | git submit --create --draft |
| Hide/discard a stack | git hide -r <commit> |
| Recover hidden commits | git unhide <commit> |
| Undo last operation | git undo |
Critical Distinctions
git sync vs git restack - agents confuse these constantly:
git sync= rebase stacks onto updated main (runsgit fetch+ in-memory rebase, NOTgit pull- sobranch.autosetuprebaseis irrelevant)git restack= fix orphaned descendants after you amend/reword a mid-stack commit- After amending mid-stack:
git restack - After fetching new main:
git sync --pull
git move modes:
-s/--source: move commit and all descendants-b/--base: move entire branch from merge-base (default if nothing specified)-x/--exact: move only specified commits, leave descendants in place
Revset Language
Revsets select commits. Used by git sl, git move, git submit, git query, etc.
Essential Functions
| Revset | Meaning |
|---|---|
@ |
HEAD |
stack() |
Current stack (default for many commands) |
draft() |
All draft (non-public) commits |
main() |
Tip of main branch |
ancestors(x) / ::x |
All ancestors of x |
descendants(x) / x:: |
All descendants of x |
children(x) |
Immediate children |
parents(x) |
Immediate parents |
branches(pattern) |
Commits with matching branch names |
message(pattern) |
Commits matching message text |
paths.changed(pattern) |
Commits touching matching file paths |
author.date(pattern) |
Commits by date |
Operators
| Op | Meaning |
|---|---|
x + y, x | y |
Union |
x & y |
Intersection |
x - y |
Difference (spaces required! foo-bar = branch name) |
x % y |
Only: ancestors of x not ancestors of y |
Date/Text Patterns
author.date("after:1 week ago") # relative dates
author.date("before:2025-01-01") # absolute dates
message("substr:fix") # substring (default)
message("regex:feat.*auth") # regex
paths.changed("glob:src/**/*.ts") # glob
Common Workflows
Amend a mid-stack commit
git checkout <hash> # go to the target commit (or git prev N for relative)
# make edits, git add
git amend # amend in place
git restack # rebase descendants onto amended commit
git checkout <stack-tip> # return to where you were
Create a new stack for independent work
git branchless switch master # go to main
# make changes
git record -m "feat: new thing" -c my-branch # commit + create branch
Submit stacked PRs to GitHub
git submit --create --forge github # first time: create PRs
git submit # subsequent: update existing PRs
Sync after main branch updated
git sync --pull # fetch + rebase all stacks onto new main
Move a stack on top of another
git move -s <root-of-stack-2> -d <tip-of-stack-1>
What NOT To Do
- Don't use
git rebase -ifor reordering/squashing. Usegit moveinstead. - Don't create branches manually for stacked work. Commits are the unit; branches are created at submit time.
- Don't confuse
git restackwithgit sync. Restack = fix orphans. Sync = update to new main. - Don't use
git mergefor incorporating upstream changes. Usegit sync --pull.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review