git-workflow

Designs Git branching strategies with merge policies, CI/CD integration, and release processes.

1|Updated Mar 21, 2026
One-click install
npx skills add https://github.com/kalilurrahman/kr-claudiator-skills-original-prompts --skill git-workflow-kalilurrahman
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: git-workflow
Source: https://github.com/kalilurrahman/kr-claudiator-skills-original-prompts/tree/main/01-software-dev/git-workflow
Command: npx skills add https://github.com/kalilurrahman/kr-claudiator-skills-original-prompts --skill git-workflow-kalilurrahman

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams often adopt generic Git workflows that do not match their actual release cadence or team size, leading to merge conflicts, slow hotfixes, and unclear release processes. This Skill produces a tailored branching strategy with concrete merge policies, branch protection rules, and CI/CD integration. ## Core Features & Use Cases - Strategy Selection: Chooses between trunk-based development, Git Flow, GitHub Flow, or GitLab Flow based on team size, release frequency, and deployment model. - Complete Workflow Definition: Outputs branch naming conventions, merge policies per branch type, branch protection rules, and CI/CD pipeline triggers. - Edge Case Handling: Covers hotfix procedures, rollbacks, long-running feature branches, and merge conflict resolution. - Use Case: A 12-person team deploying weekly can get a full Git Flow setup with release branch procedures, semantic version tagging, and Conventional Commits enforcement. ## Quick Start Design a Git workflow for a team of 8 engineers with weekly releases and a staging environment.

Frequently Asked Questions about git-workflow

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I choose a Git branching strategy for my team?

Choose based on team size, release cadence, and deployment model. Trunk-based development fits small teams deploying continuously, Git Flow suits scheduled releases, and GitHub Flow works for continuous deployment with a staging environment.

What is the difference between Git Flow and trunk-based development?

Git Flow uses long-lived develop and release branches for scheduled releases, while trunk-based development merges short-lived feature branches directly into main with continuous deployment. Teams under five people should prefer trunk-based with feature flags.

How should hotfixes be handled in Git Flow?

Create a hotfix branch from main, fix the bug with a regression test, merge to main with an expedited review, then immediately back-merge to develop to prevent regression. Tag the release with a patch version bump like v2.3.1.

What branch protection rules should main have?

Main should require pull requests with two approving reviews, passing status checks for tests, linting, and security scans, up-to-date branches, linear history, and restrictions on force pushes and deletions.

When should I use squash merge versus merge commit?

Use squash and merge for feature branches to keep a clean history with one commit per feature. Use merge commits for release and hotfix branches to preserve release context and enable tagging the merge commit.