Skip to main content

docs-website-update

Sync docs commits from `master` out to the live docs branches in the nx repo: cherry-picks `docs(` / `feat(nx-dev)` commits onto `website-<major>` AND the latest `<major>.<minor>.x` release branch. Use when "update the docs branch", "update nx.dev", "push the latest docs changes out", "cherry-pick docs commits", "sync website-23", "ship docs to the website branch", "update the docs website", "get docs onto the release branch", or any request to move already-merged docs commits from master onto the branches that deploy them.

Source facts

Repository
nrwl/nx
Last source activity
September 9, 2026 at 19:26
Detected SKILL.md language
English
Stars
29,436
Forks
2,972

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
docs-website-update
description
Sync docs commits from `master` out to the live docs branches in the nx repo: cherry-picks `docs(` / `feat(nx-dev)` commits onto `website-<major>` AND the latest `<major>.<minor>.x` release branch. Use when "update the docs branch", "update nx.dev", "push the latest docs changes out", "cherry-pick docs commits", "sync website-23", "ship docs to the website branch", "update the docs website", "get docs onto the release branch", or any request to move already-merged docs commits from master onto the branches that deploy them.
# Update Docs Website This skill works in the `nx` repo only. CRITICAL: - If you are not in the `nx` repo, say so and stop working! - If there are uncommitted/untracked files, say so and stop working! ## Why two branches Docs commits must land on BOTH: - `website-<major>` (e.g. `website-23`) - deploys nx.dev for the current major - the latest release branch `<major>.<minor>.x` (e.g. `23.1.x`) - used for patch releases, and the release pipeline overwrites the `website-<major>` branch from it If only `website-23` gets the commit, the next patch release from `23.1.x` wipes it. ## How to Update ### 1. Determine the branches The `+` on each refspec is required. A release force-pushes `website-<major>` from the release branch, so a non-forced fetch is rejected as non-fast-forward and leaves `origin/website-<major>` pointing at the pre-release commit. ```bash git fetch origin '+refs/heads/master:refs/remotes/origin/master' git fetch origin '+refs/heads/website-*:refs/remotes/origin/website-*' git fetch origin '+refs/heads/*.x:refs/remotes/origin/*.x' ``` - **Website branch**: highest `origin/website-<N>` where `<N>` is an integer. Exclude `website-master` and any branch with extra path segments (e.g. `website-19-cherry-01/...`). ```bash git for-each-ref --format='%(refname:short)' 'refs/remotes/origin/website-*' \ | grep -E '^origin/website-[0-9]+$' | sort -V | tail -1 ``` - **Release branch**: highest `origin/<N>.<minor>.x` with the SAME major `<N>` as the website branch. ```bash git for-each-ref --format='%(refname:short)' 'refs/remotes/origin/*.x' \ | grep -E "^origin/${MAJOR}\.[0-9]+\.x$" | sort -V | tail -1 ``` If no release branch exists for that major, say so and continue with the website branch only. Confirm the remote-tracking refs actually match the remote before touching them: ```bash git ls-remote origin refs/heads/<website-branch> refs/heads/<release-branch> git rev-parse origin/<website-branch> origin/<release-branch> ``` If the shas differ, the fetch did not take - stop and re-fetch. Every later step (the anchor commit, the cherry-pick list, any conflict) is wrong otherwise. Report both branch names before doing any work. ### 2. Sync the branches ```bash git checkout master && git reset --hard origin/master git checkout <website-branch> && git reset --hard origin/<website-branch> git checkout <release-branch> && git reset --hard origin/<release-branch> ``` ### 3. Build the cherry-pick list (from the website branch) 1. On `<website-branch>`, get the last commit subject -> `/tmp/last-website-commit.txt` 2. Back on `master`, find the commit whose subject matches `/tmp/last-website-commit.txt` -> sha in `/tmp/last-master-sha.txt` 3. On `master`, list commits between that sha and `HEAD`, filtered to subjects starting with `docs(` or `feat(nx-dev)` -> `/tmp/commits-to-cherry-pick.txt` (oldest at bottom, as `git log` prints it) ### 4. Cherry-pick onto the website branch On `<website-branch>`, oldest to newest: ```bash git cherry-pick <sha> ``` - On failure: record in `/tmp/failed-website.txt`, `git cherry-pick --abort`, move on. - If the pick is empty (already applied): `git cherry-pick --skip`, record as skipped. ### 5. Cherry-pick the SAME list onto the release branch The release branch was cut from `master` at a different point, so some commits may already be there. 1. Skip any commit whose subject already appears in the release branch's log: ```bash git log <release-branch> --format='%s' | grep -Fxq "<subject>" ``` 2. Cherry-pick the rest oldest to newest, same rules as step 4. - Failures -> `/tmp/failed-release.txt` - Empty picks -> `git cherry-pick --skip` Conflicts are more likely here than on the website branch - do NOT try to resolve them, just abort and report. ### 6. Report Print a per-branch breakdown: | Branch | Cherry-picked | Already present / skipped | Failed | | ------ | ------------- | ------------------------- | ------ | List failed shas with subjects so they can be handled manually. Do NOT push. End by reminding which branches have unpushed commits, e.g.: ``` git push origin website-23 git push origin 23.1.x ```
View on GitHub