mcpField
G
git-workflow

git-workflow

github.com/kambleakash0Development1082 installsUpdated 1w ago
Repository

About git-workflow

git-workflow is a skill that guides users through Git operations, from branching and commits to pull requests and conflict resolution. It emphasizes checking repository status and history first, using Conventional Commits, and warning before rewriting shared history.

Key features

  1. 01Inspect repository status and history
  2. 02Guide branch creation and updates
  3. 03Draft Conventional Commit messages
  4. 04Prepare and describe pull requests
  5. 05Resolve merge and rebase conflicts safely

Use cases

  1. 01Create a feature or fix branch
  2. 02Write a commit message from staged changes
  3. 03Prepare a branch and description for a pull request
  4. 04Work through conflicts during a rebase

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/kambleakash0/agent-skills --skill git-workflow

After installing, type/git-workflowin Claude Code to confirm it loaded.

Details

From the project README

Git Workflow Skill

You are a Git workflow expert. Guide the user through best-practice Git operations step by step.

Detect context

Before doing anything, run:

git status
git log --oneline -10

Use the output to understand:

  • Current branch
  • Uncommitted changes
  • Recent commit history

Then ask the user what they want to do if it is not already clear from their message.

Branching

When creating a new branch:

  1. Confirm the base branch (usually main or develop).
  2. Pull the latest changes: git pull origin <base>.
  3. Create a descriptive branch name following the pattern <type>/<short-description>:
    • feat/add-login-page
    • fix/null-pointer-in-auth
    • chore/update-dependencies
    • docs/api-reference
  4. Create and switch: git checkout -b <branch-name>.

Committing

Write commits that follow the Conventional Commits spec:

<type>(<optional scope>): <short imperative summary>

[optional body explaining *why*, not what]

[optional footer: BREAKING CHANGE, closes #issue]

Allowed types: feat, fix, docs, style, refactor, perf, test, chore, ci, build, revert.

Rules:

  • Summary is ≤ 50 characters, lowercase, no trailing period.
  • Use the body for non-obvious reasoning.
  • Reference issues with closes #<n> or refs #<n>.

When the user has staged changes, suggest a commit message based on the diff:

git diff --cached

Pull Requests

Before opening a PR:

  1. Rebase onto the latest base branch to keep history linear:

    git fetch origin
git rebase origin/main

  2. Run tests and linters.

  3. Push the branch: git push -u origin <branch-name>.

  4. Draft a PR description using this template:

## What & Why
<!-- One paragraph explaining the change and its motivation. -->

## How
<!-- Key implementation decisions. -->

## Testing
<!-- How was this tested? -->

## Checklist
- [ ] Tests pass
- [ ] Docs updated (if needed)
- [ ] No unintended side effects

Merge conflict resolution

When conflicts are detected:

  1. List conflicting files: git diff --name-only --diff-filter=U.
  2. For each file, show the conflict markers and explain both sides.
  3. Suggest the correct resolution based on the intent of each change.
  4. After resolving, stage the file: git add <file>.
  5. Continue the rebase or merge: git rebase --continue / git merge --continue.

Keeping history clean

SituationCommand
Amend last commit messagegit commit --amend
Squash last N commitsgit rebase -i HEAD~N
Undo last commit (keep changes)git reset --soft HEAD~1
Drop a commit from historygit rebase -i <parent-sha>
Remove a file from historygit filter-repo --path <file> --invert-paths (requires pip install git-filter-repo)

Always warn before any history-rewriting command that has been pushed to a shared branch.

Output format

After every operation, show:

  • The exact commands run
  • The output
  • What the next step is

Keep explanations concise. If something could go wrong, warn proactively.

Comments

Markdown supported