git-release

Release, Fix, and Version Backport

When to Use and When Not to Use

This skill is not applicable as a substitute for CodeGuard quality, platform protection, or deployment acceptance. It can be installed standalone; when there is no GitFlow plugin, use read-only Git observation and rule-by-rule verification. It does not depend on adjacent skill files or assume the host automatically loads other skills.

Prerequisites and Authorization

• Git is available and the project directory is clear. First confirm the parent repository's true root and project instructions, and preserve user changes.
• Existing conventions take precedence; no Git, no conventions, detached, shallow history, and unknown provenance need to be explicitly reported.
• Read-only observation and preview may be executed; Git initialization, branch creation/switching, commits, pushes, integration, cleanup, Hook installation, and rule activation are executed within the scope of the user's existing authorization.
• Project Rules and Evidence is a self-contained reference for this skill;Authoritative Directory is used for model and source verification.

Execution Steps

Step 1

First confirm the project model and specific version, and do not conflate release tags, maintenance branches, and environment deployments into the same process.

Step 2

Classic release is from develop, hotfix is from main; start records the exact baseline, naming satisfies project conventions, and does not automatically switch or publish.

Step 3

finish lists all merge-in roles: release→main/develop; hotfix→main/develop, and covers active releases. List each target OID.

Step 4

Target worktree occupancy, dirty state, candidate drift, etc. are handled first. After authorization, integrate target by target and record before/after; conflicts stop at the real target.

Step 5

Microsoft Release Flow fixes on the mainline first and then cherry-picks to maintenance lines; Git maintainer merges upward starting from the oldest applicable maintenance line.

Step 6

Backporting is limited to complete single-parent commit OIDs, checking for already-merged/equivalent patches to avoid duplication. merge commit requires an explicit mainline; do not default to -m 1.

Step 7

Verify that each target contains the fix, the remaining targets, and conflicts; finish does not automatically push/tag/deploy, and version release requires independent authorization and acceptance.

Standalone Tool and Plugin Paths

First locate this skill's scripts/inspect_repository.py, according to contract read the status using the commands in. Python 3.11+ standard library, read-only and does not initialize. Actual commands use the directory where the current skill is located; the mounted example is:

python3 /mnt/skills/user/git-release/scripts/inspect_repository.py /absolute/project

When the GitFlow plugin is available, call the command corresponding to its actual path, see operation examples. Do not treat CLI names that are not installed as existing commands.

Verification and Output

Keep the source branch and logs until all targets are verified. Native workflows do not by default delete branches or publish tags.

Output must distinguish: facts, rule sources, recommendations, user authorization, and unverified items. After write operations, verify the current refs/HEAD/status; plans and previews are not completion evidence. Security boundaries: do not leak credentials, do not upload the working tree; do not expose credentials, entire working tree contents, or sensitive remote URLs in logs.

Positive Example

When hotfix/security is completed, it covers main, develop, and active release/1.0, and any conflict leaves an incomplete list.

Negative Example

Declaring the release complete right after the main merge is done, missing develop; or merging the entire Microsoft maintenance line back to main.

Gotchas (situations prone to misjudgment)

• .git When it is a file, it may still be a valid worktree; query Git/common-dir first.
• Matching the branch pattern does not prove the source is correct; manually created but missing records should be listed separately as unknown.
• Remote tracking and protection configuration text cannot prove that the live remote has implemented it.
• Do not pre-create false long-term refs for a new project's empty history; the initial commit must have a clear bootstrap plan.
• For definition changes, review the active revision first; passing quality checks does not exempt branch rules.
• Do not blindly replay steps that have already completed just because of a timeout with no response; check Git status and the operation log first.

Exception handling

Missing/drifted/corrupted rules, unknown identity, interrupted operations, or insufficient source evidence: stop the related write actions, report unverified and the specific information needed, and continue with read-only work that can be completed independently. Clear naming/flow violations: deny and provide a conservative remediation direction. Git unavailable or network failure: do not auto-install, and do not treat failure as success. Preserve the real scene of conflicts and handle them according to the recovery steps.

Optional handoff

When other responsibilities are needed, invoke them by name and do not assume the skill is installed. For example, workflow selection can be handed off to git-workflow；Install: npx skills add full-stack-skills/git-skills --skill git-workflow. Any handoff must not expand the user's authorization.