git-workflow

Define a three-branch Git workflow with main, dev, and insiders branches.

Updated Apr 14, 2026
One-click install
npx skills add https://github.com/robpitcher/eShopOnWeb --skill git-workflow-robpitcher
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: git-workflow
Source: https://github.com/robpitcher/eShopOnWeb/tree/main/.copilot/skills/git-workflow
Command: npx skills add https://github.com/robpitcher/eShopOnWeb --skill git-workflow-robpitcher

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill standardizes a three-branch Git workflow (main, dev, insiders) and explicit conventions to minimize merge conflicts, streamline releases, and improve team collaboration.

Core Features & Use Cases

  • Defines a dev-first workflow with an insiders preview channel and clear branch purposes
  • Provides naming conventions for feature work and issue tracking, plus guidance for PRs and promotions
  • Supports collaboration patterns including parallel worktrees and multi-repo coordination to reduce conflicts

Quick Start

Explain the squad dev-first Git workflow and demonstrate how to create feature branches from dev using the squad/{issue-number}-{slug} naming convention.

Frequently Asked Questions about git-workflow

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

FAQPage Schema
What is a dev-first Git workflow with main, dev, and insiders branches?

A dev-first Git workflow uses main, dev, and insiders branches to manage release channels, where feature work targets dev before promotion to main, ensuring predictable releases and a dedicated insiders preview channel.

How do I name feature branches for issue tracking in a team Git workflow?

Feature branches should follow the squad/{issue-number}-{slug} naming convention to link branches directly to tracked issues, streamlining pull request reviews and parallel worktree management within the team.

How do Git worktrees help with parallel issue handling?

Git worktrees allow developers to check out multiple branches simultaneously in separate directories, enabling parallel issue handling without stashing changes or disrupting the primary working branch.

What's the best way to manage multi-repo coordination in a team Git workflow?

Managing multi-repo coordination involves standardizing branch purposes and promotion pipelines across repositories, using explicit conventions for pull requests and merges to reduce conflicts and align release schedules.

Can I use this Git branching strategy for small teams without a release pipeline?

This Git branching strategy targets team-based software development scenarios involving code reviews and parallel issue handling, so small teams without formal release pipelines may find the three-branch structure unnecessarily complex.