agentleFS
pivoshenkopivoshenko/pivoshenko.ai/skills/git-branch-sync/SKILL.md

git-branch-sync

Skill6 starsChanged 44 days agoMITView on GitHub

Fetch the latest base branch and rebase the current branch onto it, surfacing conflicts clearly. Use when the user asks to sync, rebase, update from main, pull latest changes, or /git-branch-sync. Also trigger on "catch up with main", "rebase onto main", "update my branch", or whenever the user signals their branch is stale vs base. Runs immediately without asking for confirmation.

  • Deletes or force-pushes
  • Commits and pushes

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 4 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Very specific:

    No remote -> skip the fetch, git rebase <base> (local ref).

    line 25
  2. Distinctive:

    Stop + surface. No auto-resolve

    line 28
  3. Distinctive:

    Leave stash in place. Tell user to pop after resolve

    line 30
  4. Very specific:

    Always rebase, never merge.

    line 37
  5. Distinctive:

    Never force-push here. Pushed branch rebased -> tell user git push --force-with-lease.

    line 38
  6. Distinctive:

    Never git rebase --skip / drop commits to "make it work".

    line 39
  7. Very specific:

    Never --no-verify. Why -> hooks gate broken state.

    line 40
  8. Very specific:

    No upstream -> sync vs origin/<base>.

    line 41

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Git Branch Sync

Catch current branch up to base. Rebase only. Surface conflicts.

Flow

  1. Parallel:
    • git status --porcelain
    • git branch --show-current
    • git rev-parse --abbrev-ref --symbolic-full-name @{u} (upstream if any)
    • Rebase/merge already in progress (git status says so) or detached HEAD (git branch --show-current empty) -> stop with a one-line explanation. Why -> a second git rebase on top of a half-finished one errors confusingly, and there is no current branch to sync
  2. Base: user names one -> verbatim. Else detect: git symbolic-ref --short refs/remotes/origin/HEAD -> strip the origin/; ref missing -> git remote set-head origin -a, re-read; no remote -> main, fall back master. Why -> rebasing onto main in a develop-based repo replays the branch onto the wrong parent and manufactures conflicts that aren't real
  3. Dirty -> stash: git stash push -u -m "sync-branch auto-stash". Pop later. Unsafe (unresolved merge) -> stop + tell user
  4. On base -> git pull --ff-only origin <base>. Fails (local base diverged) -> pop the stash if step 3 made one (nothing was rewritten), then stop + tell user. No auto-rebase of base itself
  5. Else:
    • git fetch origin <base>
    • git rebase origin/<base>
    • No remote -> skip the fetch, git rebase <base> (local ref). Local <base> absent too -> nothing to sync against; pop the stash if step 3 made one, stop + say so
  6. Conflicts:
    • git status -> list conflicted paths
    • Stop + surface. No auto-resolve
    • Tell user: resolve, git add <paths>, git rebase --continue. Mention git rebase --abort escape
    • Leave stash in place. Tell user to pop after resolve
  7. Rebase done (clean or aborted) -> pop stash if created
  8. Print one-liner: branch, base, commits replayed (git rev-list --count origin/<base>..HEAD before the rebase vs after), force-push needed? (yes = upstream exists and history was rewritten)
    • 0 commits replayed (already up to date) -> say so explicitly; don't mention force-push (nothing rewritten)

Rules

  • Always rebase, never merge. Why -> user workflow preference; linear history. Don't offer merge as alternative even on shared branches; surface the risk (force-push needed) and let user decide
  • Never force-push here. Pushed branch rebased -> tell user git push --force-with-lease. Let user run
  • Never git rebase --skip / drop commits to "make it work". Surface conflict
  • Never --no-verify. Why -> hooks gate broken state; skipping just defers the failure
  • No upstream -> sync vs origin/<base>. Note branch not pushed
  • Pop stash you made on rebase clean OR abort. Pop blocked by conflicts -> leave stashed + tell user

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.