playbooks

home / skills / yuniorglez / gemini-elite-core / git-flow

git-flow skill

/skills/git-flow

This skill enforces trunk-based development and stacked changes to accelerate reviews and maintain a linear, deployable main branch.

npx playbooks add skill yuniorglez/gemini-elite-core --skill git-flow

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

Files (4)
SKILL.md
3.8 KB
---
name: git-flow
id: git-flow
version: 1.1.0
description: "Senior Workflow Architect. Master of Trunk-Based Development, Stacked Changes, and 2026 Branching Strategies."
---

# 🌊 Skill: Git Flow & Workflow Architect (v1.1.0)

## Executive Summary
The `git-flow` architect is responsible for the structural integrity and velocity of the repository. In 2026, where deployment cycles are measured in minutes, choosing the right workflow is a competitive advantage. This skill focuses on **Trunk-Based Development** for speed, **Stacked Changes** for review efficiency, and maintaining a linear, forensic-ready history.

---

## 📋 Table of Contents
1. [Core Workflow Philosophies](#core-workflow-philosophies)
2. [The "Do Not" List (Anti-Patterns)](#the-do-not-list-anti-patterns)
3. [Trunk-Based Development (TBD)](#trunk-based-development-tbd)
4. [Stacked Changes (Graphite/Stack)](#stacked-changes-graphitestack)
5. [Enterprise Branching Strategies](#enterprise-branching-strategies)
6. [Repository Automation Standards](#repository-automation-standards)
7. [Reference Library](#reference-library)

---

## 🏗️ Core Workflow Philosophies

1.  **Linear History**: Prefer `rebase` over `merge` for feature branches to keep a clean line of progression.
2.  **Short-Lived Branches**: Any branch existing for more than 48 hours is a risk to integration.
3.  **Deployability**: The `main` branch must ALWAYS be deployable. Broken `main` is an emergency.
4.  **Verifiability**: No code merges without a green CI status and a positive "Critic Agent" or human review.

---

## 🚫 The "Do Not" List (Anti-Patterns)

| Anti-Pattern | Why it fails in 2026 | Modern Alternative |
| :--- | :--- | :--- |
| **Long-Lived Features** | Leads to "Integration Hell" and massive conflicts. | Use **Feature Flags** and TBD. |
| **Mega Pull Requests** | Reviews are superficial and slow. | Use **Stacked Changes**. |
| **Direct Commits to Main**| Bypasses CI and quality gates. | Use **Branch Protection Rules**. |
| **Merge Commits (Noise)** | Clutters the history and breaks bisect. | Use **Rebase & Squash**. |
| **Manual Versioning** | Error-prone and slow. | Use **Semantic Release / Changesets**. |

---

## ⚡ Trunk-Based Development (TBD)

The gold standard for 2026 velocity.
-   **Step 1**: Tiny commits to `main` (via short-lived PRs).
-   **Step 2**: 100% automated test coverage.
-   **Step 3**: Decouple deployment from release via **Feature Flags**.

*See [References: Trunk-Based Development](./references/trunk-based-development.md) for the workflow.*

---

## 🔨 Stacked Changes (Graphite/Stack)

Master the art of high-volume, low-friction reviews.
-   Break 1 giant feature into 5 dependent PRs.
-   Reviewers approve 100 lines at a time.
-   Restack automatically when parents change.

*See [References: Stacked Changes](./references/stacked-changes-graphite.md) for details.*

---

## 🏢 Enterprise Branching Strategies

When TBD isn't enough:
-   **One-Flow**: For structured but simple environments.
-   **Git Flow (Legacy)**: For rigid, scheduled release cycles.
-   **GitLab Flow**: For complex environment-based deployments.

---

## 🤖 Repository Automation Standards

-   **Pre-merge Checks**: Lint, Types, Tests, Security Scan.
-   **Auto-merge**: Use "Merge when pipeline succeeds" for low-risk PRs.
-   **Stale Branch Cleanup**: Automated scripts to prune merged or abandoned branches.

---

## 📖 Reference Library

Detailed deep-dives into Workflow Architecture:

- [**Trunk-Based Development**](./references/trunk-based-development.md): The high-velocity blueprint.
- [**Stacked Changes**](./references/stacked-changes-graphite.md): Reviewing at 2026 speeds.
- [**Branching Strategies**](./references/branching-strategies-2026.md): Choosing the right flow for your team.

---

*Updated: January 22, 2026 - 19:00*

Overview

This skill codifies senior workflow architecture for modern Git teams, specializing in Trunk-Based Development, Stacked Changes, and 2026-era branching strategies. It helps teams maintain linear, forensic-ready history while maximizing velocity and review throughput. The guidance is pragmatic, focusing on automated gates, short-lived branches, and predictable release separation via feature flags.

How this skill works

The skill inspects and recommends a repository's branching and merge practices, CI gate configuration, and automation hooks. It enforces principles like rebase-first history, short-lived PRs, required CI passes, and stacked-change patterns for decomposing large work. It also suggests enterprise alternatives when trunk-based approaches are unsuitable and prescribes automation for stale branches, auto-merge, and pre-merge checks.

When to use it

  • You need sub-10-minute deployment cycles and minimal integration friction.
  • Code review bottlenecks are caused by large, monolithic PRs.
  • Main branch stability must be guaranteed and auditable.
  • You want a repeatable, automated release separation without long-lived feature branches.
  • Scaling review throughput across many concurrent contributors.

Best practices

  • Prefer rebase and squash to preserve a linear, searchable history.
  • Keep branches short-lived — aim for under 48 hours active lifetime.
  • Gate all merges with green CI and an explicit review (human or critic agent).
  • Decompose large features into stacked changes so reviewers handle 100-line increments.
  • Separate deployment from release using feature flags and decouple rollout from merge.
  • Automate stale branch cleanup, security scans, linting, and auto-merge when safe.

Example use cases

  • Enable trunk-based workflows for a fast-moving product team deploying multiple times per day.
  • Introduce stacked-change workflows to a codebase suffering from slow, superficial PR reviews.
  • Design branching for a regulated enterprise that needs linear history and traceability.
  • Automate repository hygiene: stale branch pruning, pre-merge security scans, and merge-on-green policies.
  • Transition a legacy Git Flow project to One-Flow or GitLab Flow where environment complexity requires it.

FAQ

What if my team cannot adopt trunk-based development immediately?

Start with short-lived feature branches, enforce CI and reviews, and introduce stacked changes. Migrate incrementally by reducing branch lifetime and adding feature flags to decouple release from deploy.

How long should a stacked change sequence be?

Keep individual stacked PRs small—reviewable within minutes, typically under 100–200 lines. The overall stack can be longer, but each commit should deliver a verifiable, test-covered step.