git-workflow-release

分类: 文档与知识管理 | 上传者: ucdavis | 下载: 0 | 版本: v1.0（最新）

提交更改和发布新版本的标准化流程。包括在包文件中更改版本、更新 CHANGELOG.md、确保 README.md 是最新的以及创建 git 发布标签的步骤。当用户要求“准备发布”、“升级版本”或“发布新版本”时使用。

更新日志: Source: GitHub https://github.com/ucdavis/ai-skills-registry

目录结构

当前层级: tree/main/.agent/skills/git-workflow-release/

📄 SKILL.md 2.8 KB

SKILL.md

---
name: git-workflow-release
description: Standardized process for committing changes and releasing a new version. Includes steps for bumping versions in package files, updating the CHANGELOG.md, ensuring the README.md is up to date, and creating git release tags. Use when the user asks to "prepare a release", "bump the version", or "release a new version".
---

# Git Workflow: Release Process

Follow these instructions to safely and consistently release a new version of the project.

## 1. Verify Clean Workspace and Tests
- Ensure there are no untracked files or uncommitted changes (unless they are part of the release).
- Ensure all tests pass (`npm test` or the language equivalent).

## 2. Update Documentation
- **README.md**: Ensure the `README.md` reflects any new features, installation steps, or usage examples introduced since the last release.
- **CHANGELOG.md**: 
  - Add a new section at the top of the changelog for the new version (e.g., `## [1.2.0] - YYYY-MM-DD`).
  - Categorize changes into `Added`, `Changed`, `Deprecated`, `Removed`, `Fixed`, or `Security`.
  - Review recent commit messages (`git log`) to capture all user-facing changes.

## 3. Bump the Version Number
- Consult the current version using `package.json` (or the language equivalent, such as `pyproject.toml` or `Cargo.toml`).
- Determine the new version number using Semantic Versioning (SemVer):
  - **MAJOR** version for incompatible API changes.
  - **MINOR** version for adding functionality in a backward-compatible manner.
  - **PATCH** version for backward-compatible bug fixes.
- Update the version number in all necessary files. For Node.js projects, use `npm version <major|minor|patch> --no-git-tag-version` if appropriate, or edit `package.json` manually.

## 4. Commit the Release Changes
- Stage the `package.json`, `CHANGELOG.md`, `README.md`, and any other updated metadata files.
- Commit with a standard release message subject, and explicitly list the summarized release changes (e.g. from the `CHANGELOG.md`) in the commit body using a multi-line format or multiple `-m` flags:
  ```bash
  git commit -m "chore(release): bump version to v<NEW_VERSION>" -m "Changed: Updated dependencies and added SemVer guidelines."
  ```

## 5. Tag the Release
- Create an annotated git tag for the new version.
  ```bash
  git tag -a v<NEW_VERSION> -m "Release v<NEW_VERSION>"
  ```

## 6. Push Changes
- Push the release commit and the new tag to the remote repository.
  ```bash
  git push origin main
  git push origin v<NEW_VERSION>
  ```
- *Note: Replace `main` with the appropriate default branch if different.*

## Edge Cases
- **Hotfixes**: If releasing a critical bug fix, bump the PATCH version and ensure the changelog explicitly calls out the fix.
- **Pre-releases**: Use `-alpha`, `-beta`, or `-rc` suffixes (e.g., `1.2.0-beta.1`) if preparing a pre-release version for testing.

登录后下载/点赞/收藏 ❤ 5 | ★ 0

git-workflow-release

目录结构

SKILL.md

举报内容

提示