一键导入
git
Git workflow rules for this repository.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Git workflow rules for this repository.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | git |
| description | Git workflow rules for this repository. |
| allowed-tools | Read, Write, Edit, Glob, Grep, AskUserQuestion |
| user-invocable | true |
--no-ff. Important.development on its way to main, with --no-ff at every hop.Feature branches merge into development. Releases go:
release/vX.Y.Z -> development -> main
Never merge a release branch straight into main — development has to carry the
release state too, or the next feature branch starts from a base that is missing it.
# 1. cut the release branch from development, commit the version bumps
git checkout development
git checkout -b release/vX.Y.Z
git commit -am "Prepare vX.Y.Z"
# 2. release branch -> development
git checkout development
git merge --no-ff release/vX.Y.Z -m "Merge release prep for vX.Y.Z"
# 3. development -> main
git checkout main
git merge --no-ff development -m "Merge development for vX.Y.Z"
# 4. tag the main merge commit, then push
git tag vX.Y.Z
git push origin development
git push origin main
git push origin vX.Y.Z
The tag belongs on the step-3 merge commit on main, not on the release branch and not
on development. Pushing the tag is what triggers the wrapper publish workflows, which
read the version from the tag.
If the work is already on main, make a normal commit and tag that commit. Do not rewrite history just to avoid a merge commit.
git merge --ffgit pull --ff-only as a default recommendation for this repo's merge policymain when the intended release source of truth is mainmain, skipping developmentThe repo wants explicit history. Release commits should be easy to find, easy to audit, and clearly connected to the branch that introduced them.