Sending work back
Commit, push, and what a push does — and does not — do on umicat.
Work on your machine stays on your machine until you push it. Commit as you
normally would, then ask your assistant to push to umicat — or run
git push yourself, if you set that up.
Pushing sends commits. Anything you have edited but not committed stays behind, which is deliberate: the alternative is a tool guessing what you meant to include.
Only fast-forwards are accepted
umicat refuses any push that would discard commits already on the project. That is not caution for its own sake — the hosted agent, a collaborator, or you on another device all write to the same branch, so "my push replaced someone else's work" is a real way to lose real work.
If your push is refused, the project moved while you were away:
git pull --rebase
npm run build # the merge can produce a tree neither side built
git pushA forced push will not help — it is refused by the server, because it is exactly the operation that could throw away someone else's change. A rejection is not an obstacle to get around; it is the project telling you it moved.
The habit that avoids all of this: pull before you start, especially if you have been working in the umicat editor in between.
What a push does
- If the game is open in the umicat editor, it pulls and rebuilds by itself — the preview updates within seconds, nothing to refresh.
- If it is not open, nothing builds yet. It rebuilds the next time you open the project.
- Every commit you pushed appears in the game's change history.
- The game is marked as having unpublished changes.
A push is not a publish
Your players keep seeing the last published build. Making a change live is a separate, deliberate step you take in umicat, and it goes through the listing and review flow like any other release — see Publishing.
So a successful push means the project has your change. It does not mean anybody playing the game can see it yet.