Git Flow Manager Guide

Your agent for managing git branching strategies — covering Git Flow, GitHub Flow, trunk-based development, release management, and team collaboration workflows.

When to Use This Agent

Choose Git Flow Manager Guide when:

• Implementing or managing a git branching strategy (Git Flow, GitHub Flow, trunk-based)
• Managing release branches, hotfix branches, and version tagging
• Resolving complex merge scenarios and branch conflicts
• Setting up branch protection rules and merge policies
• Training teams on git workflow best practices

Consider alternatives when:

• You need CI/CD pipeline setup — use a DevOps agent
• You need commit message conventions — use a Commit Navigator agent
• You need code review process — use a code reviewer agent

Quick Start

Copy
# .claude/agents/git-flow-manager.yml
name: Git Flow Manager Guide
model: claude-sonnet
tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep
description: Git branching strategy manager for release workflows, branch management, and team collaboration

Example invocation:

claude "Set up a Git Flow branching strategy for our team — configure branch protection for main and develop, create the initial branch structure, and document the workflow for feature, release, and hotfix branches"

Core Concepts

Branching Strategy Comparison

Strategy	Complexity	Release Cycle	Best For
Trunk-Based	Low	Continuous	Small teams, CI/CD mature
GitHub Flow	Low-Medium	Feature-based	Web apps, continuous deployment
Git Flow	High	Scheduled releases	Products with versions
GitLab Flow	Medium	Environment-based	Multiple environments

Git Flow Branch Types

main          ●──────●──────────●──── (production releases)
               \    /          /
release/1.0     ●──●          /
               /    \        /
develop    ●──●──●──●──●──●──●──── (integration branch)
              \  /    \      /
feature/auth   ●      \    /
                    feature/search  ●
                              \
hotfix/fix-login               ●──── (from main, merge to main + develop)

Configuration

Parameter	Description	Default
strategy	Branching strategy (gitflow, github-flow, trunk-based)	github-flow
main_branch	Production branch name	main
develop_branch	Integration branch (Git Flow only)	develop
branch_prefix	Feature branch prefix	feature/
tag_format	Version tag format	v{major}.{minor}.{patch}

Best Practices

1. Choose the simplest strategy that supports your release process. Trunk-based development is ideal for teams with mature CI/CD that deploy continuously. GitHub Flow adds feature branches for code review. Git Flow is needed only for products with scheduled versioned releases. Don't use Git Flow for web apps that deploy daily.

2. Keep feature branches short-lived (< 3 days). Long-lived branches accumulate merge conflicts and diverge from the integration branch. If a feature takes longer than 3 days, break it into smaller increments behind a feature flag.

3. Protect main and develop branches with merge policies. Require pull request reviews, passing CI checks, and linear history (no merge commits or squash commits) on protected branches. This prevents direct pushes, broken builds, and unreviewed code.

4. Use semantic versioning for release tags. Tag releases as v{major}.{minor}.{patch}. Major for breaking changes, minor for features, patch for bug fixes. This communicates the scope and risk of each release to consumers.

5. Rebase feature branches on the target branch before merging. This creates a linear, readable history. git rebase develop before creating a PR ensures your branch includes the latest changes and reduces merge conflicts.

Common Issues

Merge conflicts between long-lived feature branches. Two teams modifying the same files on separate branches will conflict at merge time. Merge develop into feature branches frequently (daily), keep branches short-lived, and coordinate changes to shared files.

Release branch fixes don't make it back to develop. When bugs are fixed on a release branch, those fixes must be merged back to develop. Without this discipline, the same bugs reappear in future releases. Automate this with CI or make it a checklist item.

Team confusion about which branch to base work from. Document clearly: feature branches branch from develop (in Git Flow) or main (in GitHub Flow). Hotfix branches branch from main. Release branches branch from develop. Create this as a one-page reference and share it with the team.