status: active
timestamp: 2026-06-20
tags: [runbook, git, submodule, workflow]
Bump a submodule pointer in master
Bump master submodule pointer after feature lands
Bump a submodule pointer in master
The master oriz repo references each oriz-* site as a git
submodule. Every change inside a site lands as two commits: the
feature commit inside the submodule, and a chore: bump commit in
master that moves the pointer.
Steps
-
Enter the submodule.
cd sites/oriz-<name> -
Verify you’re on
main. Perone-branch-only.md, no other branch should exist.git status # confirms branch and clean tree git rev-parse --abbrev-ref HEAD # must print "main" -
Commit the feature inside the submodule. Use a conventional commit message that describes the actual change.
git add -A git commit -m "feat(<scope>): <one-line summary>" -
Push the submodule — but only when the user has explicitly authorised pushing this turn. See
.git push origin main -
Capture the short SHA of the submodule HEAD.
SHORT_SHA=$(git rev-parse --short HEAD) echo "$SHORT_SHA" -
Return to master and stage the new pointer.
cd ../.. git add sites/oriz-<name> -
Commit the pointer bump with a
chore(submodule)message that names the submodule and the new short SHA.git commit -m "chore(submodule): bump oriz-<name> to ${SHORT_SHA}" -
Push master — again, only when authorised.
git push origin main
Why two commits
The submodule’s history records the actual change. The master commit records which version of the submodule the family is shipping. They serve different audiences (engineers reading the submodule’s git log vs. operators rolling back the family) and should not be squashed.