git-commit

分类: 工具与效率 | 上传者: signnow | 下载: 0 | 版本: v1.0（最新）

当准备在此存储库中提交更改或起草 git 提交消息时使用。 --- # Git 提交和提交消息（SignNow MCP 服务器）## 关键规则 * **切勿直接提交到 `main` 或 `master`。** 始终在专用分支上工作。 * 除非**所有必需的检查**通过（见下文），否则不要提交。 * 保留每次提交**一个逻辑更改**（单一更改类型）。 * 提交消息遵循**常规提交**。 ## 工作流程 0. **创建（或切换到）功能分支 — 强制** * 切勿直接提交到 `main` 或 `master`。 * 如果尚未在功能分支上，请创建一个： * `git checkout -b <type>/<short-description>` （例如，`feat/add-embedded-editor`、`fix/token-refresh`） * 分支命名：`<type>/<short-description>` 使用与提交类型相同的类型词汇。 1. **检查更改的内容** * `git status -sb` * 如果更改是混合的，请使用 `git add -p` 分成单独的提交。 2. **查看暂存差异** * 暂存属于此提交的内容。 * 检查： `git diff --cached` 3. **运行所需的检查（必须为绿色）** ```bash pytesttests/unit/ -v ruff check src/tests/ ruff format --check src/tests/``` * 如果任何命令失败，请修复问题并重新运行 **所有** 检查。 4. **撰写提交消息** ### 主题格式 `<type>(<scope>)?: <subject>` ### 主题规则 * 命令式语气（“添加”、“修复”、“删除”、“防止”...） * 无尾随句点 * 首选 **≤ 72 个字符** ### 正文（可选） * 解释 **为什么**，而不仅仅是解释什么。 * 在大约 80 个字符处换行。 ### 重大变更（如果适用） * 在类型/范围后添加 `!`：`feat!: ...` 或 `feat(tools)!: ...` * 添加页脚：* `重大变更：<什么中断和迁移说明>` 5. **提交** * 单行（不需要正文/页脚）： * `git commit -m "..."` * 否则： * `git commit` 并在编辑器中编写主题 + 正文。 6. **提交后健全性** * `git show --stat` * 确保没有意外文件被提交。 7. **推送** * `git push` 8. **创建 Pull Request（如果不存在）** * 推送后，检查 PR 是否已存在

更新日志: Source: GitHub https://github.com/signnow/sn-mcp-server

目录结构

当前层级: tree/main/.github/skills/git-commit/

📄 SKILL.md 3.6 KB

SKILL.md

---
name: git-commit
description: >
  Use when preparing to commit changes or drafting a git commit message in this repo.
---

# Git Commit & Commit Message (SignNow MCP Server)

## Critical rules

* **NEVER commit directly to `main` or `master`.** Always work on a dedicated branch.
* Do not commit unless **all required checks** pass (see below).
* Keep each commit **one logical change** (single change type).
* Commit message follows **Conventional Commits**.

## Workflow

0. **Create (or switch to) a feature branch — MANDATORY**

* NEVER commit to `main` or `master` directly.
* If not already on a feature branch, create one:
  * `git checkout -b <type>/<short-description>` (e.g., `feat/add-embedded-editor`, `fix/token-refresh`)
* Branch naming: `<type>/<short-description>` using the same type vocabulary as commit types.

1. **Check what changed**

* `git status -sb`
* If changes are mixed, split into separate commits using `git add -p`.

2. **Review staged diff**

* Stage what belongs to this commit.
* Inspect: `git diff --cached`

3. **Run required checks (must be green)**

```bash
pytest tests/unit/ -v
ruff check src/ tests/
ruff format --check src/ tests/
```

* If any command fails, fix the issue and rerun **all** checks.

4. **Compose the commit message**

### Subject format

`<type>(<scope>)?: <subject>`

### Subject rules

* Imperative mood ("Add", "Fix", "Remove", "Prevent", ...)
* No trailing period
* Prefer **≤ 72 chars**

### Body (optional)

* Explain **why**, not just what.
* Wrap lines at ~80 chars.

### Breaking changes (if applicable)

* Add `!` after type/scope: `feat!: ...` or `feat(tools)!: ...`
* Add footer:

  * `BREAKING CHANGE: <what breaks and migration notes>`

5. **Commit**

* One-liner (no body/footer needed):

  * `git commit -m "..."`
* Otherwise:

  * `git commit` and write subject + body in editor.

6. **Post-commit sanity**

* `git show --stat`
* Ensure no accidental files were committed.

7. **Push**

* `git push`

8. **Create Pull Request (if none exists)**

* After pushing, check whether a PR already exists for the current branch:
  * Use the GitHub MCP tool (`search_pull_requests`) to check.
* If **no PR exists** → create one immediately.

### PR title format

`<title>` must be a short imperative summary of the **whole task** (not just the last commit). To understand what the task is about, read the corresponding plan file in `.plans/` (e.g., `.plans/Plan-{TASK_NAME}.md`).

Examples:
* `Add embedded editor tool`
* `Fix token refresh loop on expired OAuth2 JWT`

### PR body

Fill in:
* **Summary** — one-paragraph description of what was changed and why
* **Changes** — bullet list of what was added/changed/removed
* **Tests** — note whether tests were added or why they were not needed

9. **PR alignment**

* Branch name: short descriptive name matching the task (e.g., `add-embedded-editor`, `fix-token-refresh`).
* PR title must be **exactly the same** as the intended final commit message (squash title).

## Type selection

* `feat` — new capability/behavior
* `fix` — bug fix
* `refactor` — no behavior change
* `docs` — docs only
* `test` — tests only
* `chore` — tooling/CI/deps/maintenance

## Scope suggestions (optional)

Use a stable domain/component name: `tools`, `client`, `auth`, `models`, `cli`, `config`, `tests`, `ci`, `docker`.

## Examples

* `feat(tools): Add update_document_fields tool`
* `fix(auth): Prevent token refresh loop on expired OAuth2 JWT`
* `refactor(client): Simplify document group mixin error handling`
* `test(tools): Add invite_status business logic coverage`
* `docs: Update README tools section`
* `chore: Update ruff lint config`

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

git-commit

目录结构

SKILL.md

举报内容

提示