dsh-git-conventions：为 DeepSeek Harness 配置 Git 提交、推送与 PR 规范
dsh-git-conventions 是 DeepSeek Harness 的静态插件，用于自动化执行 Git 提交、推送及 PR 规范检查。它支持配置化规则，覆盖 `git commit`、`git push` 和 `gh pr create` 命令。核心功能包括：对 `-m` 内联提交信息进行 Conventional Commits 结构校验，不合规即拒绝；在启用安全选项时，提示使用 `--force-with-lease` 替代裸 `--force` 推送；以及强制要求 `gh pr create` 必须包含标题和描述，缺失则拦截。插件规则通过设置页配置并持久化，支持中英文，若规则留
Read More# Standard Conventional Commits Written with the `writing-commit-messages` Skill
### Translated English Abstract: This article introduces the `writing-commit-messages` section in spencerpauly/awesome-cursor-skills: how to use Agent Skill to constrain commit messages to follow Conventional Commits specifications (including type prefixes, scopes, body content, and BREAKING CHANGE sections). It verifies the rules in SKILL.md, good and bad examples, commit granularity requirements, as well as the installation methods for Cursor skills: manually installing to the `.cursor/skills/` directory, and using `npx skills add` to install to both Cursor and Claude Code. This guide is suitable for teams that need standardized collaboration and automated changelog generation.
Read MoreGit Commit Message Template: Standardizing Team Collaboration Submission Norms
### Why Unified Commit Specification is Needed? A unified commit specification addresses issues like difficult code reviews, chaotic version iterations, and failed automation tools. It ensures clarity on the purpose and content of each change, facilitating team collaboration. ### Specification Format (Conventional Commits) - **Type** (Required): E.g., `feat` (new feature), `fix` (bug fix), `docs` (documentation). Incorrect types mislead version management. - **Description** (Required): Concise (≤50 characters), verb-starting (e.g., "optimize", "fix"), avoiding ambiguity. - **Body** (Optional): After a blank line, detail the reason for the change, implementation details, or problem-solving process. - **Footer** (Optional): Link to issues (e.g., `Closes #123`) or note breaking changes. ### How to Create a Commit Template? - **Global Template**: Create `.gitmessage` in the user’s root directory and configure Git with `git config --global commit.template ~/.gitmessage`. - **Project-level Template**: Create `.gitmessage` in the project root and run `git config commit.template .gitmessage`. ### Tool Assistance for Enforcing the Specification - **Commit
Read MoreGit Commit Message Specification: Enhancing Team Collaboration Efficiency
In daily development, standardized Git commit messages are crucial for team collaboration and issue tracking, as non-standardized messages can lead to version history chaos. The current mainstream specification is Conventional Commits, with the following structure: mandatory type (e.g., `feat` for new features, `fix` for bug fixes, `docs` for documentation), optional scope (limiting module scope, e.g., `user module`), brief description (core content), optional body (detailed explanation), and optional footer (linking to issues or indicating breaking changes). Tools can help develop this habit: `commitizen` (interactive tool) or `commitlint + husky` (automatic pre-commit checks). The benefits of standardization include improved collaboration efficiency, automated version log generation, clear issue tracking, and early warning of breaking changes, making it worthwhile for teams to adopt.
Read MoreGit Commit Message Guidelines: Why Write a Clear Commit Message?
Have you ever encountered vague Git commit messages like "modified" or "fixed a bug", making it difficult to review the details of changes? Clear commit messages can solve this problem. They serve as a "diary" for code changes, needing to explain "what was done" and "why it was done". There are four key benefits to writing standardized commit messages: quick recall (understand changes even after half a year), team collaboration (members quickly locate feature changes), automated tool support (generate version logs, automatically upgrade version numbers), and rapid bug localization (use `git bisect` to quickly narrow down issues during production problems). Start with simplicity for standardization: at minimum, include a "type + description". Common types include `fix` (bug fixes) and `feat` (new features). For advanced usage, consider the Conventional Commits specification, with the format `<type>[optional scope]: <description>`, which can include a body and footer. Beginners can start with "type + description" and use tools like `cz-cli` for assistance. Spend 10 seconds clarifying the core content before each commit, and consistency will improve code management efficiency.
Read More