Git Sync Check

Git sync pre-flight check

Several writers can touch the same working tree at once: the user, this session, and often a second Claude session that commits, builds and deploys in parallel. Your memory of the tree is stale the moment another writer acts. The point of this check is to learn the CURRENT state before you act on an outdated picture of it.

If the status is already in context

This skill ships with companion pre-flight scripts (see the repo README) that many setups run automatically before each turn, injecting a [git-sync] ... block into context. If you can see a fresh [git-sync] line for the current prompt, do NOT re-run the commands — the snapshot is already in front of you. Jump straight to the decision matrix and act on it.

The check

Run this before the first file edit of the task (one tool call):

git -C  fetch origin --quiet
git -C  status --short
git -C  rev-list --left-right --count HEAD...origin/

When the default branch is unknown, resolve it first (falls back to main):

git -C  symbolic-ref --short refs/remotes/origin/HEAD

Three signals come back: dirty files, ahead count (left), behind count (right).

Decision matrix

| State | What to do | |---|---| | Clean tree, 0 ahead / 0 behind | Proceed. Report at most one line: ✅ git: чисто, синхронизировано | | Behind, tree clean | git pull --rebase origin , then proceed | | Ahead only | Note the unpushed commits. If they are complete work, push; if they look mid-flight (another session may still be working), leave them and say so | | Dirty files | Classify them first — see below. Never blindly commit or revert | | Dirty AND behind | Classify first, then follow the playbook below | | Operation in progress (.git/MERGE_HEAD, .git/rebase-merge/, .git/rebase-apply/, CHERRY_PICK_HEAD) | STOP. Someone is mid-merge/rebase. Don't edit, don't commit, don't git rebase --abort on your own initiative — report it and wait for instructions | | Detached HEAD (git symbolic-ref HEAD fails) | Don't commit onto it silently — a commit there is one GC away from being lost. Create/checkout a branch first, or ask which branch the work belongs on |

Dirty AND behind — the playbook

The riskiest cell. git pull --rebase --autostash is convenient but stashes EVERYTHING — including another session's half-typed work, which can then hit a stash-pop conflict that you (not its author) would have to resolve.

• All dirty files are YOURS (your task touches them) → `git pull --rebase

--autostash` is safe.

• Any dirty file is FOREIGN → do not autostash it. Prefer: rebase only if

the foreign files don't overlap the incoming commits (git fetch then git diff --name-only HEAD..origin/ vs the dirty list). If they overlap, don't pull — tell the user a parallel session's uncommitted work conflicts with incoming commits, and let the humans/other session resolve.

• If an autostash pop ever conflicts, stop and report; never resolve

someone else's stashed work silently.

Classifying dirty files

Uncommitted changes are not necessarily yours:

• Files your current task will touch — fine, continue.
• Files unrelated to your task — likely a parallel session mid-work.

Strong tell: the file changes again while you look at it, or new untracked files keep appearing. Leave these strictly alone: don't stage, don't revert, don't "fix". Mention them in one line and route around.

• Conflict markers — check changed files for >>>>>>). A file with

markers is a broken merge/stash and must never reach a commit. If the file is one YOUR task touches, resolve it (keep both sides' features unless told otherwise). If it's foreign, do NOT edit it — flag it to the user and keep it out of your commit; resolving someone's half-finished merge for them can silently pick the wrong side.

File leases — the multi-session protocol

If the repo's scripts directory has claim.sh / release.sh (or the .ps1 twins from this skill), use them — they turn "guess whose file this is" into knowledge shared through .git/sync-leases:

• Before your first edit, claim the files you're about to touch with a

recognizable session name: claim.sh -s path/a.py path/b.ts

• The pre-flight output lists active leases. A file leased by ANOTHER

session is off-limits: don't edit, don't stage, don't revert it — route around or tell the user it's busy.

• Release when your change is committed: release.sh -s .
• Leases expire on their own (default 30m), so a crashed session never

deadlocks the tree. No scripts in the repo = no protocol; skip silently.

When you detect another ACTIVE writer

Files changing while you watch, fresh foreign leases, mid-flight commits appearing — suggest isolation instead of contention: a separate git worktree per session gives each writer its own tree on its own branch and turns racy edits into ordinary merges. Don't create one unprompted; recommend it to the user once per session.

Later in the same turn

The pre-flight is a snapshot, not a lease. Before you actually commit:

• Re-run git status --short — the tree may have changed under you while

you worked.

• Stage only the files that belong to YOUR change. Never git add -A /

git add . in a shared tree: you will sweep in someone's half-typed code.

• If the push is rejected because the remote moved, git pull --rebase

and push again; resolve conflicts by keeping both sides' features.

Reporting

Healthy state costs the user one short line — don't narrate the commands. Expand only when something needs attention, e.g.:

⚠️ git: 2 чужих незакоммиченных файла (параллельная сессия), отстаём на 1 коммит → сделал rebase, чужие файлы не трогал

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: tuwulalo
• Source: tuwulalo/git-sync-check
• License: MIT

Install and usage instructions live in the source repository linked above.