Token导航 LogoToken导航

Agent Skill · 开发

git-workflow(Git 工作流)

git-workflow 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要围绕仓库状态、代码变更或协作事项进行整理时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

git-workflow 是开发类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为需要联网;许可证信息还不明确,第三方扫描已通过,按安装量在开发类的 21,746 个 Skill 里排第 11,561。

总安装 1,693周安装 72GitHub Stars 3,506下载 593核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:git-workflow(Git 工作流)
来源仓库:https://github.com/galaxy-dawn/claude-scholar
仓库路径:skills/git-workflow
安装命令:
npx skills add https://github.com/galaxy-dawn/claude-scholar --skill git-workflow
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/galaxy-dawn/claude-scholar --skill git-workflow

这个 Skill 是做什么的

开发类 Skill 面向写代码、改代码和排查问题,一般会读写仓库文件,部分还会执行构建或测试命令。

定义 Git 标准流程,包括提交规范、分支策略和合并规则。适用于团队协作开发、代码质量维护和版本管理场景。可提升协作效率,简化发布与修复流程。安装命令:npx skills add https://github.com/galaxy-dawn/claude-scholar --skill git-workflow。

使用前应统一团队规范,避免混合使用不同分支策略。

来源仓库内路径:skills/git-workflow

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/galaxy-dawn/claude-scholar --skill git-workflo…;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要需要联网,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

git-workflow 怎么安装?

在终端执行 npx skills add https://github.com/galaxy-dawn/claude-scholar --skill git-workflow。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

git-workflow 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

git-workflow 需要什么权限?

权限级别是需要联网。该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

git-workflow 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

git-workflow 用的人多吗?

公开数据是累计安装 1,693 次,近一周安装 72 次,下载 593 次,GitHub 3,506 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

git-workflow 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 第三方扫描已通过,常见的高风险行为没有命中。
  • 来源仓库有 3,506 星,维护活跃度相对可查。

先想清楚的地方

  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理开发类任务、又不想每次都手写提示词的人。

不太适合

  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

开发类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
skill-vetter

技能审查员 · OpenClaw

8,779,018986操作浏览器MIT-0通过
ontology

本体论 · OpenClaw

6,636,960576只读MIT-0通过
entra-app-registration

内部应用程序注册 · Codex、Claude

6,631,872764接触敏感数据未明确通过
entra-app-registration

内部应用程序注册 · Codex、Claude

3,757,680201接触敏感数据未明确通过
nano-banana-pro

纳米香蕉专业版 · OpenClaw

3,526,898364接触敏感数据MIT-0有提醒
git-workflow

Git 工作流 · 本页

1,6933,506需要联网未明确通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

Git Workflow Standards

This document defines the project's Git usage standards, including commit message format, branch management strategy, workflows, merge strategies, and more. Following these standards improves collaboration efficiency, enables traceability, supports automation, and reduces conflicts.

Commit Message Standards

The project follows the Conventional Commits specification:

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

<body>

<footer>

Type Reference

TypeDescriptionExample
featNew featurefeat(user): add user export functionality
fixBug fixfix(login): fix captcha not refreshing
docsDocumentation updatedocs(api): update API documentation
refactorRefactoringrefactor(utils): refactor utility functions
perfPerformance improvementperf(list): optimize list performance
testTest relatedtest(user): add unit tests
choreOther changeschore: update dependency versions

Subject Rules

  • Start with a verb: add, fix, update, remove, optimize
  • No more than 50 characters
  • No period at the end

For more detailed conventions and examples, see references/commit-conventions.md.

Branch Management Strategy

Branch Types

Branch TypeNaming ConventionDescriptionLifecycle
mastermasterMain branch, releasable statePermanent
developdevelopDevelopment branch, latest integrated codePermanent
featurefeature/feature-nameFeature branchDelete after completion
bugfixbugfix/issue-descriptionBug fix branchDelete after fix
hotfixhotfix/issue-descriptionEmergency fix branchDelete after fix
releaserelease/version-numberRelease branchDelete after release

Branch Naming Examples

feature/user-management          # User management feature
feature/123-add-export          # Issue-linked feature
bugfix/login-error              # Login error fix
hotfix/security-vulnerability   # Security vulnerability fix
release/v1.0.0                  # Version release

Branch Protection Rules

master branch:

  • No direct pushes allowed
  • Must merge via Pull Request
  • Must pass CI checks
  • Requires at least one Code Review approval

develop branch:

  • Direct pushes restricted
  • Pull Request merges recommended
  • Must pass CI checks

For detailed branch strategies and workflows, see references/branching-strategies.md.

Workflows

Daily Development Workflow

# 1. Sync latest code
git checkout develop
git pull origin develop

# 2. Create feature branch
git checkout -b feature/user-management

# 3. Develop and commit
git add .
git commit -m "feat(user): add user list page"

# 4. Push to remote
git push -u origin feature/user-management

# 5. Create Pull Request and request Code Review

# 6. Merge to develop (via PR)

# 7. Delete feature branch
git branch -d feature/user-management
git push origin -d feature/user-management

Hotfix Workflow

# 1. Create fix branch from master
git checkout master
git pull origin master
git checkout -b hotfix/critical-bug

# 2. Fix and commit
git add .
git commit -m "fix(auth): fix authentication bypass vulnerability"

# 3. Merge to master
git checkout master
git merge --no-ff hotfix/critical-bug
git tag -a v1.0.1 -m "hotfix: fix authentication bypass vulnerability"
git push origin master --tags

# 4. Sync to develop
git checkout develop
git merge --no-ff hotfix/critical-bug
git push origin develop

Release Workflow

# 1. Create release branch
git checkout develop
git checkout -b release/v1.0.0

# 2. Update version numbers and documentation

# 3. Commit version update
git add .
git commit -m "chore(release): prepare release v1.0.0"

# 4. Merge to master
git checkout master
git merge --no-ff release/v1.0.0
git tag -a v1.0.0 -m "release: v1.0.0 official release"
git push origin master --tags

# 5. Sync to develop
git checkout develop
git merge --no-ff release/v1.0.0
git push origin develop

Merge Strategy

Merge vs Rebase

FeatureMergeRebase
HistoryPreserves complete historyLinear history
Use casePublic branchesPrivate branches
Recommended forMerging to main branchSyncing upstream code

Recommendations

  • Feature branch syncing develop: Use rebase
  • Feature branch merging to develop: Use merge --no-ff
  • develop merging to master: Use merge --no-ff
# ✅ Recommended: Feature branch syncing develop
git checkout feature/user-management
git rebase develop

# ✅ Recommended: Merge feature branch to develop
git checkout develop
git merge --no-ff feature/user-management

# ❌ Not recommended: Rebase on public branch
git checkout develop
git rebase feature/xxx  # Dangerous operation

Project convention: Use --no-ff when merging feature branches to preserve branch history.

For detailed merge strategies and techniques, see references/merge-strategies.md.

Conflict Resolution

Identifying Conflicts

<<<<<<< HEAD
// Current branch code
const name = 'Alice'
=======
// Branch being merged
const name = 'Bob'
>>>>>>> feature/user-management

Resolving Conflicts

# 1. View conflicting files
git status

# 2. Manually edit files to resolve conflicts

# 3. Mark as resolved
git add <file>

# 4. Complete the merge
git commit  # merge conflict
# or
git rebase --continue  # rebase conflict

Conflict Resolution Strategies

# Keep current branch version
git checkout --ours <file>

# Keep incoming branch version
git checkout --theirs <file>

# Abort merge
git merge --abort
git rebase --abort

Preventing Conflicts

  1. Sync code regularly - Pull latest code before starting work each day
  2. Small commits - Commit small changes frequently
  3. Modular features - Implement different features in different files
  4. Communication - Avoid modifying the same file simultaneously

For detailed conflict handling and advanced techniques, see references/conflict-resolution.md.

.gitignore Standards

Basic Rules

# Ignore all .log files
*.log

# Ignore directories
node_modules/

# Ignore directory at root
/temp/

# Ignore files in all directories
**/.env

# Don't ignore specific files
!.gitkeep

Common.gitignore

node_modules/
dist/
build/
.idea/
.vscode/
.env
.env.local
logs/
*.log
.DS_Store
Thumbs.db

For detailed.gitignore patterns and project-specific configurations, see references/gitignore-guide.md.

Tag Management

Uses Semantic Versioning:

MAJOR.MINOR.PATCH[-PRERELEASE]

Version Change Rules

  • MAJOR: Incompatible API changes (v1.0.0 → v2.0.0)
  • MINOR: Backward-compatible new features (v1.0.0 → v1.1.0)
  • PATCH: Backward-compatible bug fixes (v1.0.0 → v1.0.1)

Tag Operations

# Create annotated tag (recommended)
git tag -a v1.0.0 -m "release: v1.0.0 official release"

# Push tags
git push origin v1.0.0
git push origin --tags

# View tags
git tag
git show v1.0.0

# Delete tag
git tag -d v1.0.0
git push origin :refs/tags/v1.0.0

Team Collaboration Standards

Pull Request Standards

PRs should include:

## Change Description
<!-- Describe the content and purpose of this change -->

## Change Type
- [ ] New feature (feat)
- [ ] Bug fix (fix)
- [ ] Code refactoring (refactor)

## Testing Method
<!-- Describe how to test -->

## Related Issue
Closes #xxx

## Checklist
- [ ] Code has been self-tested
- [ ] Documentation has been updated

Code Review Standards

Review focus areas:

  • Code quality: Clear and readable, proper naming, no duplicate code
  • Logic correctness: Business logic correct, edge cases handled
  • Security: No security vulnerabilities, sensitive information protected
  • Performance: No obvious performance issues, resources properly released

For detailed collaboration standards and best practices, see references/collaboration.md.

Common Issues

Amending the Last Commit

# Amend commit content (not yet pushed)
git add forgotten-file.ts
git commit --amend --no-edit

# Amend commit message
git commit --amend -m "new commit message"

Push Rejected

# Pull then push
git pull origin master
git push origin master

# Use rebase for cleaner history
git pull --rebase origin master
git push origin master

Rollback to Previous Version

# Reset to specific commit (discards subsequent commits)
git reset --hard abc123

# Create reverse commit (recommended, preserves history)
git revert abc123

Stash Current Work

git stash save "work in progress"
git stash list
git stash pop

View File Modification History

git log -- <file>             # Commit history
git log -p -- <file>          # Detailed content
git blame <file>              # Per-line author

Best Practices Summary

Commit Standards

✅ Recommended:

  • Follow Conventional Commits specification
  • Write clear commit messages describing changes
  • One commit for one logical change
  • Run code checks before committing

❌ Prohibited:

  • Vague commit messages
  • Multiple unrelated changes in one commit
  • Committing sensitive information (passwords, keys)
  • Developing directly on main branch

Branch Management

✅ Recommended:

  • Use feature branches for development
  • Regularly sync main branch code
  • Delete branches promptly after feature completion
  • Use --no-ff merge to preserve history

❌ Prohibited:

  • Developing directly on main branch
  • Long-lived unmerged feature branches
  • Non-standard branch naming
  • Rebasing on public branches

Code Review

✅ Recommended:

  • All code goes through Pull Requests
  • At least one reviewer approval before merging
  • Provide constructive feedback

❌ Prohibited:

  • Merging without review
  • Reviewing your own code

Additional Resources

Reference Files

For detailed guidance on specific topics:

  • references/commit-conventions.md - Commit message detailed conventions and examples
  • references/branching-strategies.md - Comprehensive branch management strategies
  • references/merge-strategies.md - Merge, rebase, and conflict resolution strategies
  • references/conflict-resolution.md - Detailed conflict handling and prevention
  • references/advanced-usage.md - Git performance optimization, security, submodules, and advanced techniques
  • references/collaboration.md - Pull request and code review guidelines
  • references/gitignore-guide.md -.gitignore patterns and project-specific configurations

Example Files

Working examples in examples/:

  • examples/commit-messages.txt - Good commit message examples
  • examples/workflow-commands.sh - Common workflow command snippets

Summary

This document defines the project's Git standards:

  1. Commit Messages - Follow Conventional Commits specification
  2. Branch Management - master/develop/feature/bugfix/hotfix/release branch strategy
  3. Workflows - Standard processes for daily development, hotfixes, and releases
  4. Merge Strategy - Use rebase to sync feature branches, merge --no-ff to merge
  5. Tag Management - Semantic versioning, annotated tags
  6. Conflict Resolution - Regular syncing, small commits, team communication

Following these standards improves collaboration efficiency, ensures code quality, and simplifies version management.

平台分布

Codex

35.57%
按下载量换算211

Claude

28.67%
按下载量换算170

Cursor

17.44%
按下载量换算103

Gemini CLI

10.07%
按下载量换算60

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills