git-workflow_skill

This skill enforces standardized git workflows by guiding branch naming, PR processes, and mandatory feature branches before changes.

TypeScript

0

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill ponpon55837/mariokartworldparams --skill git-workflow

SKILL.md8.5 KB

Overview

This skill enforces a standardized Git branch naming and workflow policy to ensure consistent team collaboration and version control best practices. It defines branch naming formats, commit message conventions, Pull Request flow, and safeguards to prevent direct modifications to the main branch. It applies to any task that adds, edits, or deletes project files.

How this skill works

It requires developers to always check the current branch and create a feature branch using the format <type>/<developer-name>/<feature-description> before making changes. All work is committed and tested on the feature branch, then merged via Pull Request after reviewer confirmation. Direct commits or edits on main are blocked by policy — changes must be pushed only after user verification and testing.

When to use it

Creating any new Git branch
Making file additions, edits, or deletions
Fixing bugs or implementing new features
Preparing changes for code review
Updating documentation, styles, tests, or project chores

Best practices

Never modify or commit directly on main; always create a feature branch from main first
Use branch format: <type>/<developer-name>/<feature-description> with lowercase and hyphens
Keep branches short-lived and focused: one branch, one feature or fix
Run full local tests and confirm the app starts successfully before notifying reviewers
Wait for user/reviewer confirmation before pushing your branch to remote and opening a PR

Example use cases

Start a new frontend feature: git checkout -b feat/alex/add-language-selector, develop and test locally, then open PR
Fix a bug: git checkout -b fix/alex/login-button-crash, commit fixes, test, notify reviewer, then push after approval
Refactor code: git checkout -b refactor/alex/improve-state-management and rebase regularly on main
Docs or style updates: git checkout -b docs/alex/update-readme or style/alex/adjust-button-styles and follow same PR flow

FAQ

Use feat, fix, refactor, docs, style, test, chore; use hotfix for critical urgent fixes.

Can I push immediately after committing locally?

No — you must test locally and notify the user/reviewer. Only push after they confirm testing is acceptable.

What language should commit messages use?

Commit type labels remain English (e.g., feat, fix). By default, write subject and body in Traditional Chinese unless the project requires English for international collaboration.

How do I keep a long-running feature branch up to date?

Regularly fetch origin/main and rebase your branch onto origin/main to minimize merge conflicts before opening the PR.