name	update-from-upstream-main
description	Update the current Remotion branch with the latest canonical main branch. Use when asked to update or sync from upstream main, merge the latest main into a feature branch, fast-forward local main, or bring a pull request branch up to date without rewriting published history.

Update From Upstream Main

Update from the canonical remotion-dev/remotion repository while preserving local work and published branch history.

Workflow

Inspect the repository before changing it:
```
git status --short --branch
git branch --show-current
git remote -v
```
Stop and report the state if the working tree contains uncommitted changes, the current checkout is detached, or an operation such as a merge or rebase is already in progress. Do not stash or discard changes automatically.
Select the canonical remote whose URL points to remotion-dev/remotion. Prefer upstream when it exists; otherwise use origin. If neither remote points to the canonical repository, stop and ask before adding or changing a remote.
Fetch the latest main branch without changing the working tree:
```
git fetch <canonical-remote> main
```
Update the checked-out branch:
- On main, require a fast-forward:
```
git merge --ff-only <canonical-remote>/main
```
- On a feature branch, merge main without opening an editor:
```
git merge --no-edit <canonical-remote>/main
```
Do not rebase, reset, or force-push. A merge keeps published branch history intact and can be pushed normally.
If the merge conflicts, resolve each file deliberately and preserve both the feature intent and upstream changes. Do not accept ours or theirs across the entire merge. Check every resolved file for leftover conflict markers before staging:
```
rg -n '^(<{7}|={7}|>{7})' -- <resolved-files>
```
Inspect and remove any matches that are conflict markers. Then stage only the resolved files and finish the merge with:
```
git commit --no-edit
```
Validate the result. Always run git diff --check. If conflicts were resolved or the combined changes could affect behavior, run the relevant package tests. For broad changes, run:
```
bun run build
bun run stylecheck
```
Push only when the user asked to update a published branch or pull request. Use a normal push and stop if it is rejected:
```
git push <canonical-remote> HEAD
```
Never force-push.
Report the previous and new commit, whether the update was a fast-forward or merge, any conflicts resolved, validation performed, and whether the branch was pushed.

Update From Upstream Main

Update from the canonical remotion-dev/remotion repository while preserving local work and published branch history.

Workflow

Inspect the repository before changing it:

git status --short --branch
git branch --show-current
git remote -v

Stop and report the state if the working tree contains uncommitted changes, the current checkout is detached, or an operation such as a merge or rebase is already in progress. Do not stash or discard changes automatically.

Select the canonical remote whose URL points to remotion-dev/remotion. Prefer upstream when it exists; otherwise use origin. If neither remote points to the canonical repository, stop and ask before adding or changing a remote.

Fetch the latest main branch without changing the working tree:

git fetch <canonical-remote> main

Update the checked-out branch:

On main, require a fast-forward:

git merge --ff-only <canonical-remote>/main

On a feature branch, merge main without opening an editor:
```
git merge --no-edit <canonical-remote>/main
```

Do not rebase, reset, or force-push. A merge keeps published branch history intact and can be pushed normally.

If the merge conflicts, resolve each file deliberately and preserve both the feature intent and upstream changes. Do not accept ours or theirs across the entire merge. Check every resolved file for leftover conflict markers before staging:

rg -n '^(<{7}|={7}|>{7})' -- <resolved-files>

Inspect and remove any matches that are conflict markers. Then stage only the resolved files and finish the merge with:

git commit --no-edit

Validate the result. Always run git diff --check. If conflicts were resolved or the combined changes could affect behavior, run the relevant package tests. For broad changes, run:

bun run build
bun run stylecheck

Push only when the user asked to update a published branch or pull request. Use a normal push and stop if it is rejected:

git push <canonical-remote> HEAD

Never force-push.

Report the previous and new commit, whether the update was a fast-forward or merge, any conflicts resolved, validation performed, and whether the branch was pushed.

update-from-upstream-main