iso-push

iso-push

Push what is committed, open a PR a person can read, and promote it through the environment branches — leaving a single linear history and rewriting nothing that has been published without asking first.

Invocation: /iso-push [--pr] [--cascade test|prod] [--no-merge] [--stay].

flag	effect
(none)	push the current branch, nothing else
--pr	push, open a PR against dev, integrate it once CI is green, then cut the release
--cascade test	promote dev → test
--cascade prod	promote dev → test → prod
--no-merge	open the PRs and stop; integrate nothing
--stay	stay on the feature branch after a landing instead of returning to the base

--cascade works with or without --pr. Without it, dev is promoted exactly as it currently stands.

The work is finished at dev. The landing there is where the ticket closes, the version is cut and tagged, and you are put back on dev. test and prod are a cascade of that same commit, run once dev has proved itself; they cut nothing and close nothing.

A pure cascade — --cascade with no --pr — runs from the base, not from a feature branch. It has no branch to land: it reads only origin/* refs and promotes dev as it is. That is also where step 9 leaves you at the end of the previous run, so the two compose. With --pr the opposite holds — there is a branch to land, and dev cannot open a PR into itself.

you are on	--cascade	--cascade --pr
dev / develop	✅ the right place	❌ refused, or rescued¹
a feature branch	❌ refused, "add --pr"	✅ the right place
test / prod	❌ refused, or rescued¹	❌ refused, or rescued¹

¹ A protected branch carrying its own commits is rescued, not refused.

A commit made while standing on dev, test or prod is stranded: iso-push cannot push those branches, and a cascade promotes origin/* and so never sees it. The only way out used to be a hand-typed git reset --hard at the end of a working session, which is the worst possible moment to improvise one.

So preflight names a branch after the work, moves the commits onto it, resets the protected branch back to its remote, and leaves you on the new branch. The run then continues normally — preflight echoes the new branch, so every later step sees it.

The name comes from the oldest commit above the base, read as a conventional subject — the one that started the work, not whatever you happened to commit last:

subject	branch
feat(wiki)!: add note and supersede, delete destroys bytes	feat/wiki-add-note-and-supersede-delete-destroys
fix: reject tokens with a future iat	fix/reject-tokens-with-a-future-iat
random subject with no type at all	chore/random-subject-with-no-type-at-all

An unrecognised type becomes chore/, which is what the version bump would treat it as anyway — the branch name agrees with what the release will do rather than guessing something prettier. The slug is cut at a word boundary at 48 characters, never mid-word.

On test or prod this is also the documented remedy for an environment defect: the stray commit lands on a feature branch whose base is dev, which is exactly where step 1 says to get it.

Two states are still refused:

• Dirty tree. The move ends in git reset --hard, which would discard uncommitted work. Commit or stash first.
• The target branch already exists. Check it out and merge, or rename it.

The branch is created before the reset, so every commit is reachable from a second ref before anything moves. A failure between the two steps loses nothing.

A protected branch with no commits of its own is refused exactly as before — there is nothing to move, and the invocation is simply wrong.

After anything lands, you end up on the base. A merged feature branch is a dead lane — GitHub will never move it again, so a commit made there starts a second head and git pull fetches a ref frozen at the merge. --stay keeps you on it, for the case where the branch is a base for follow-up work you are about to push again.