update-from-upstream-main

Name: update-from-upstream-main
Author: remotion-dev

54kstars3.9kforks

How to install update-from-upstream-main?

remotion-dev/remotion/update-from-upstream-main

$npx -y skills add remotion-dev/remotion --skill update-from-upstream-main

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	# Update From Upstream Main
2
3	Update from the canonical `remotion-dev/remotion` repository while preserving local work and published branch history.
4
5	## Workflow
6
7	1. Inspect the repository before changing it:
8
9	```bash
10	git status --short --branch
11	git branch --show-current
12	git remote -v
13	```
14
15	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.
16
17	2. 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.
18
19	3. Fetch the latest main branch without changing the working tree:
20
21	```bash
22	git fetch <canonical-remote> main
23	```
24
25	4. Update the checked-out branch:
26	- On `main`, require a fast-forward:
27
28	```bash
29	git merge --ff-only <canonical-remote>/main
30	```
31
32	- On a feature branch, merge main without opening an editor:
33
34	```bash
35	git merge --no-edit <canonical-remote>/main
36	```
37
38	Do not rebase, reset, or force-push. A merge keeps published branch history intact and can be pushed normally.
39
40	5. 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:
41
42	```bash
43	rg -n '^(<{7}\|={7}\|>{7})' -- <resolved-files>
44	```
45
46	Inspect and remove any matches that are conflict markers. Then stage only the resolved files and finish the merge with:
47
48	```bash
49	git commit --no-edit
50	```
51
52	6. 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:
53
54	```bash
55	bun run build
56	bun run stylecheck
57	```
58
59	7. Push only when the user asked to update a published branch or pull request. Use a normal push and stop if it is rejected:
60
61	```bash
62	git push <canonical-remote> HEAD
63	```
64
65	Never force-push.
66
67	8. 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.

People who liked this also viewed

6 picks

Type

update-from-upstream-main

54kstars3.9kforks

View on GitHub

How to install update-from-upstream-main?

remotion-dev/remotion/update-from-upstream-main

$npx -y skills add remotion-dev/remotion --skill update-from-upstream-main

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Update From Upstream Main
2
3	Update from the canonical `remotion-dev/remotion` repository while preserving local work and published branch history.
4
5	## Workflow
6
7	1. Inspect the repository before changing it:
8
9	```bash
10	git status --short --branch
11	git branch --show-current
12	git remote -v
13	```
14
15	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.
16
17	2. 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.
18
19	3. Fetch the latest main branch without changing the working tree:
20
21	```bash
22	git fetch <canonical-remote> main
23	```
24
25	4. Update the checked-out branch:
26	- On `main`, require a fast-forward:
27
28	```bash
29	git merge --ff-only <canonical-remote>/main
30	```
31
32	- On a feature branch, merge main without opening an editor:
33
34	```bash
35	git merge --no-edit <canonical-remote>/main
36	```
37
38	Do not rebase, reset, or force-push. A merge keeps published branch history intact and can be pushed normally.
39
40	5. 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:
41
42	```bash
43	rg -n '^(<{7}\|={7}\|>{7})' -- <resolved-files>
44	```
45
46	Inspect and remove any matches that are conflict markers. Then stage only the resolved files and finish the merge with:
47
48	```bash
49	git commit --no-edit
50	```
51
52	6. 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:
53
54	```bash
55	bun run build
56	bun run stylecheck
57	```
58
59	7. Push only when the user asked to update a published branch or pull request. Use a normal push and stop if it is rejected:
60
61	```bash
62	git push <canonical-remote> HEAD
63	```
64
65	Never force-push.
66
67	8. 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.

People who liked this also viewed

6 picks

Type