Skip to content

git-city

git city

The branch-workflow commands Git forgot.

Start features, keep a whole stack in sync, and land your work — as a handful of boring, guessable commands. Rebase-first, forge-agnostic, and every command previews with --dry-run and reverses with undo.

Install → Quick start → Commands →

The whole daily rhythm:

git city new add-login        # branch off an up-to-date trunk
# ...hack, commit...
git city sync                 # main moved on? rebase add-login onto it
git city land                 # fast-forward main, push, clean up

See where you are at any time:

$ git city info
git-city · my-project
  trunk:  main
  remote: origin

on  ● add-login   (feature, parent: main)
    working tree: clean
    vs main:  ↑2 ↓0

stack:
main  (trunk)
└─ ● add-login  ↑2 ↓0

Why git-city

  • Forge-agnostic

    No pull-request host required. Every command works on a plain Git remote — or no remote at all.

    → Forge-agnostic

  • Rebase-first

    Branches and stacks stay linear. sync rebases onto the parent with --force-with-lease, so it never clobbers unseen remote work.

    → Rebase-first sync

  • Bulletproof undo

    Every command is a list of reversible steps. git city undo reverses the last one — and refuses rather than destroy your work.

    → Reversible operations

  • Two ideas, not seven

    Just trunk and feature branches, each knowing its parent. That is the whole mental model.

    → The mental model

Stacks, first-class

Build a branch on top of another, then sync the whole stack in one command — parents before children.

$ git city tree
main  (trunk)
└─ api  ↑3 ↓0
   └─ ● ui  ↑2 ↓0

→ Stacked changes

Status: early

The local workflow — branches, stacks, sync, land, undo — is complete and heavily tested. Forge integration (pull/merge requests, patch series) is intentionally not built yet; git-city works fully with a plain Git remote, or none. See the roadmap.