Two Branching Models, Different AI Behaviors
Trunk-based development: the main branch is the single source of truth. Developers: create short-lived feature branches (hours to 1-2 days), merge to main via PR, and delete the branch. No develop branch. No release branches. Releases: deploy from main (every merge is: potentially deployable). Feature flags: hide incomplete features behind flags rather than long-lived branches. The model is: simple, fast, and encourages small frequent merges. Used by: Google, Facebook, and most modern startups.
GitFlow: multiple long-lived branches. main: production-ready code. develop: integration branch for the next release. feature/*: one per feature (branched from develop, merged back to develop). release/*: preparation for a release (branched from develop, merged to both main and develop). hotfix/*: emergency fixes (branched from main, merged to both main and develop). The model is: structured, explicit, and designed for scheduled releases. Used by: enterprise teams with release cycles, mobile apps with app store review periods.
AI agents create branches and commit. Without a branching rule: Claude Code may create feature/add-auth (GitFlow style) when the team uses trunk-based (should be: add-auth, branched from main, merged quickly). Or: branch from main when the team uses GitFlow (should be: branch from develop). The branching model determines: which branch to branch from, which branch to merge to, and how long the branch lives. One rule aligns: every AI-created branch with the team model.
Trunk-Based Development Rules for AI
Trunk-based AI rule: "Git: trunk-based development. Branch from main. Branch name: descriptive-kebab-case (add-bcrypt-auth, fix-login-redirect, update-user-schema). Branch lifetime: under 2 days. Merge to main via PR. Delete branch after merge. No develop branch. No release branches. Releases: deploy from main. Incomplete features: behind feature flags, not long-lived branches."
Why trunk-based rules matter for AI agents: Claude Code in agentic mode may: implement a feature in 30 minutes, create a branch, commit changes, and propose a PR. With trunk-based rules: the branch comes from main, the PR targets main, and the branch is: small and focused (one feature, one PR, merged quickly). Without the rule: the AI may create a feature/user-settings branch (GitFlow naming) that targets a non-existent develop branch.
Trunk-based with feature flags: "For features that take more than 1 day: use a feature flag. const ENABLE_NEW_SETTINGS = process.env.FEATURE_NEW_SETTINGS === 'true'. Code behind the flag: is merged to main but not visible to users until the flag is enabled. This allows: merging incomplete code to main daily (trunk-based principle) without exposing incomplete features to users." The AI should: generate feature flag checks when the feature is too large for a single PR.
- Branch from main, merge to main, delete after merge. No develop or release branches
- Branch naming: descriptive-kebab-case (add-bcrypt-auth). No feature/ prefix in trunk-based
- Branch lifetime: under 2 days. Longer features: use feature flags, not long-lived branches
- Feature flags: merge incomplete code behind flags rather than keeping a branch alive for weeks
- AI agent: creates branch from main, implements, commits, opens PR to main, suggests merge
Trunk-based: features that take more than 1 day go behind a feature flag. The code merges to main daily (behind the flag). No branch alive for weeks accumulating merge conflicts. The flag enables the feature when ready. Branches for isolation. Flags for incomplete features.
GitFlow Rules for AI
GitFlow AI rule: "Git: GitFlow branching model. Feature branches: branch from develop, merge to develop. Naming: feature/short-description (feature/add-bcrypt-auth). Release branches: branch from develop when ready for release, merge to both main AND develop. Naming: release/v1.2.0. Hotfix branches: branch from main for emergency fixes, merge to both main AND develop. Naming: hotfix/fix-login-crash. Main: production only. Develop: integration for next release."
Why GitFlow rules matter for AI agents: Claude Code implementing a feature must: branch from develop (not main), use the feature/ prefix in the branch name, and target the PR to develop (not main). Without the GitFlow rule: the AI branches from main and targets main (wrong branch for features in GitFlow). The merge target is: the most critical GitFlow rule for AI. feature → develop, release → main + develop, hotfix → main + develop.
GitFlow complexity for AI: the AI must know: which branch to start from (features from develop, hotfixes from main), which branch to merge to (features to develop, releases to main + develop), and how to name branches (feature/, release/, hotfix/ prefixes). This is: more complex than trunk-based (one branch, one target) but the rules are: well-defined. If the AI follows the naming and targeting rules: the branching model works correctly.
- Feature: branch from develop, merge to develop. Name: feature/description
- Release: branch from develop, merge to main AND develop. Name: release/vX.Y.Z
- Hotfix: branch from main, merge to main AND develop. Name: hotfix/description
- Main: production only (never commit directly). Develop: integration branch
- AI agent: must know which branch to start from AND which branch to merge to
AI Agent Branching Behavior
Claude Code branching rule: "Before making changes: create a new branch. Branch from: [main/develop depending on model]. Branch naming: [convention]. Commit to the branch (never to main/develop directly). After completing the task: suggest creating a PR to [target branch]. Do not push to main or develop directly. Do not merge without PR approval."
Why explicit branching rules for AI agents: without the rule, Claude Code may: commit directly to main (no branch, no PR, no review — dangerous), create a branch but target the wrong branch for the PR, use a branch name that does not match the convention (random-branch-123 instead of feature/add-auth), or forget to push and create the PR (the changes exist locally but no one can review them). The branching rule: makes every git operation explicit and correct.
The safety aspect: the most important git rule for AI agents is: "Never commit directly to main or develop. Never push to main or develop without a PR. Always create a branch first." This rule prevents: the most dangerous AI git operation (pushing untested, unreviewed code to the production branch). With branch protection rules on the server: this is enforced at the git level. The AI rule: adds the same protection at the generation level (the AI does not attempt the dangerous operation in the first place).
- Always branch first: never commit directly to main or develop (most important AI git rule)
- Push to branch, create PR: never push directly to protected branches
- Branch naming matches convention: feature/ for GitFlow, descriptive for trunk-based
- PR target: main (trunk-based) or develop (GitFlow features) — must match the branching model
- Server enforcement: branch protection rules catch what the AI rule misses
The most important AI git rule: 'Never commit directly to main or develop. Always create a branch. Always open a PR.' This prevents: pushing untested, unreviewed code to production. Branch protection on the server: catches violations. The AI rule: prevents the AI from attempting it in the first place.
Which Model for Your Team?
Choose trunk-based when: you deploy continuously (every merge to main can deploy — Vercel, Netlify auto-deploy from main), your team is small to medium (under 50 developers — coordination overhead of GitFlow is not justified), you prefer simplicity (one branch, one target, short-lived branches), or you use feature flags (incomplete features are: hidden behind flags, not isolated in branches). Trunk-based is: the default for web applications deployed continuously.
Choose GitFlow when: you have scheduled releases (mobile apps with app store review, enterprise software with quarterly releases), your team needs explicit release preparation (a release branch for: final testing, version bumping, and release notes), your team is large (50+ developers across multiple features that may conflict), or regulatory requirements mandate: a formal release process with distinct preparation and production branches. GitFlow is: the default for products with formal release cycles.
For most web projects in 2026: trunk-based development. The reasons: continuous deployment is the default (Vercel deploys on every merge to main), feature flags are mature (LaunchDarkly, Flagsmith, or simple env var flags), and trunk-based is simpler for AI agents (one branch to branch from, one branch to target). GitFlow adds: complexity that most web projects do not need. Mobile apps and enterprise software: GitFlow remains relevant due to release cycle requirements.
Web apps in 2026: deploy continuously from main (Vercel auto-deploys). Feature flags for incomplete work. Trunk-based is simpler for AI agents (one branch, one target). Mobile apps: app store review requires release branches. Enterprise: quarterly releases need release preparation. GitFlow exists for formal release cycles.
Branching Model Summary
Summary of trunk-based vs GitFlow AI rules.
- Trunk-based: branch from main, merge to main, short-lived branches, feature flags for incomplete work
- GitFlow: feature from develop, release to main+develop, hotfix from main, long-lived branches
- AI agent safety: never commit directly to main/develop. Always branch first. Always PR before merge
- Branch naming: trunk = descriptive-kebab. GitFlow = feature/description, release/vX.Y.Z, hotfix/description
- Merge target: trunk = main. GitFlow = develop (features), main+develop (releases, hotfixes)
- 2026 web default: trunk-based (continuous deployment, feature flags, simpler for AI agents)
- GitFlow when: scheduled releases, mobile apps, large teams, regulatory requirements
- One rule: tells the AI which branch to create from, which to merge to, and how to name it