home / skills / questnova502 / claude-skills-sync / git-workflow

This skill guides teams in adopting Git workflow best practices, enabling effective branching, conventional commits, PR quality, and CI/CD integration.

npx playbooks add skill questnova502/claude-skills-sync --skill git-workflow

Review the files below or copy the command above to add this skill to your agents.

Files (8)
SKILL.md
2.0 KB
---
name: git-workflow
description: "Agent Skill: Git workflow best practices for teams and CI/CD. Use when establishing branching strategies, implementing Conventional Commits, configuring PRs, or integrating Git with CI/CD. By Netresearch."
---

# Git Workflow Skill

Expert patterns for Git version control: branching, commits, collaboration, and CI/CD.

## Expertise Areas

- **Branching**: Git Flow, GitHub Flow, Trunk-based development
- **Commits**: Conventional Commits, semantic versioning
- **Collaboration**: PR workflows, code review, merge strategies
- **CI/CD**: GitHub Actions, GitLab CI, branch protection

## Reference Files

Detailed documentation for each area:

- `references/branching-strategies.md` - Branch management patterns
- `references/commit-conventions.md` - Commit message standards
- `references/pull-request-workflow.md` - PR and review processes
- `references/ci-cd-integration.md` - Automation patterns
- `references/advanced-git.md` - Advanced Git operations
- `references/github-releases.md` - Release management, immutable releases

## Conventional Commits (Quick Reference)

```
<type>[scope]: <description>
```

**Types**: `feat` (MINOR), `fix` (PATCH), `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert`

**Breaking change**: Add `!` after type or `BREAKING CHANGE:` in footer.

## Branch Naming

```bash
feature/TICKET-123-description
fix/TICKET-456-bug-name
release/1.2.0
hotfix/1.2.1-security-patch
```

## GitHub Flow (Default)

```bash
git checkout main && git pull
git checkout -b feature/my-feature
# ... work ...
git push -u origin HEAD
gh pr create && gh pr merge --squash
```

## Verification

```bash
./scripts/verify-git-workflow.sh /path/to/repository
```

## GitHub Immutable Releases

**CRITICAL**: Deleted releases block tag names PERMANENTLY. Get releases right first time.

See `references/github-releases.md` for prevention and recovery patterns.

---

> **Contributing:** https://github.com/netresearch/git-workflow-skill

Overview

This skill provides practical, battle-tested Git workflow guidance for teams and CI/CD pipelines. It covers branching strategies, commit conventions, pull request workflows, and integration patterns for automation and releases. Use it to standardize developer workflows and reduce release risk.

How this skill works

The skill inspects your current branching and commit practices, recommends a branching model (Git Flow, GitHub Flow, or trunk-based) based on team size and release cadence, and enforces Conventional Commits to drive semantic versioning. It also maps PR requirements and branch protection rules to CI/CD jobs and offers release patterns that avoid destructive changes to published releases.

When to use it

  • Establishing a team-wide branching strategy for new or existing projects
  • Implementing Conventional Commits to enable automated versioning and changelogs
  • Configuring pull request templates, review rules, and merge strategies
  • Integrating Git branches with CI/CD pipelines and branch protection
  • Planning release management to prevent or recover from immutable-release mistakes

Best practices

  • Choose a branching model that matches team size and release frequency: GitHub Flow for continuous deploy, trunk-based for fast iteration, Git Flow for complex release needs
  • Adopt Conventional Commits to automate changelogs and semantic versioning; keep messages short and scoped
  • Protect main branches with required status checks, required reviews, and signed commits where appropriate
  • Prefer fast-forward or squash merges to keep history readable; use merge commits only when they add value
  • Automate verification: run linting, tests, and release validation in CI before allowing merges
  • Treat published releases as immutable; test release creation workflows in a staging area before production

Example use cases

  • Onboarding a new team and standardizing branch names and PR templates
  • Setting up CI to bump versions and create changelogs from commit messages
  • Defining branch protection rules and required CI checks for main and release branches
  • Switching from ad-hoc commits to Conventional Commits to enable automated releases
  • Recovering from accidental modification of a published release by restoring immutable tags and documenting prevention steps

FAQ

Which branching model should we pick?

Choose based on release cadence and team size: GitHub Flow for continuous deployment, trunk-based for rapid iteration with feature flags, Git Flow for formal release management.

How do Conventional Commits map to version bumps?

Use types: feat -> minor, fix -> patch, and include BREAKING CHANGE or ! to indicate a major version bump.