Skip to content
Automation
Skill

/git-workflow

This skill should be used when the user asks to "create git commit", "manage branches", "follow git workflow", "use Conventional Commits", "handle merge conflicts", or asks about git branching strategies, version control best practices, pull request workflows. Provides

From plugin
claude-scholar
5.1k45 skills6 agents65 commands5 hooks
Install
$ npx -y skills add Galaxy-Dawn/claude-scholar --skill git-workflow --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/git-workflow

Context preview

The summary Claude sees to decide when to auto-load this skill.

This skill should be used when the user asks to "create git commit", "manage branches", "follow git workflow", "use Conventional Commits", "handle merge conflicts", or asks about git branching strategies, version control best practices, pull request workflows. Provides

SKILL.md

git-workflow.SKILL.md
name: git-workflow
description: This skill should be used when the user asks to "create git commit", "manage branches", "follow git workflow", "use Conventional Commits", "handle merge conflicts", or asks about git branching strategies, version control best practices, pull request workflows. Provides comprehensive Git workflow guidance for team collaboration.
version: 1.2.0

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

| Type | Description | Example | | :--- | :--- | :--- | | `feat` | New feature | `feat(user): add user export functionality` | | `fix` | Bug fix | `fix(login): fix captcha not refreshing` | | `docs` | Documentation update | `docs(api): update API documentation` | | `refactor` | Refactoring | `refactor(utils): refactor utility functions` | | `perf` | Performance improvement | `perf(list): optimize list performance` | | `test` | Test related | `test(user): add unit tests` | | `chore` | Other changes | `chore: 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 Type | Naming Convention | Description | Lifecycle | | :--- | :--- | :--- | :--- | | master | `master` | Main branch, releasable state | Permanent | | develop | `develop` | Development branch, latest integrated code | Permanent | | feature | `feature/feature-name` | Feature branch | Delete after completion | | bugfix | `bugfix/issue-description` | Bug fix branch | Delete after fix | | hotfix | `hotfix/issue-description` | Emergency fix branch | Delete after fix | | release | `release/version-number` | Release branch | Delete 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

| Feature | Merge | Rebase | | :--- | :--- | :--- | | History | Preserves complete history | Linear history | | Use case | Public branches | Private branches | | Recommended for | Merging to main branch | Syncing 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
Read more
Ships withclaude-scholar

Semi-automated research assistant for academic research and software development. Supports Claude Code, Codex CLI, Kimi Code CLI, and OpenCode across ideation, coding, experiments, writing, and publication.

Get the whole plugin