Chapter 31: Version Control Workflows

"Version control is the backbone of professional software development. In the age of AI-assisted coding, that backbone must be stronger and more flexible than ever before."

Learning Objectives

By the end of this chapter, you will be able to:

1. Remember the core Git concepts and commands that form the foundation of version control in AI-assisted development workflows. (Bloom's: Remember)
2. Understand how vibe coding changes traditional version control patterns, including commit frequency, diff sizes, and collaboration dynamics. (Bloom's: Understand)
3. Apply branching strategies, commit conventions, and merge techniques appropriate for teams using AI coding tools. (Bloom's: Apply)
4. Analyze the trade-offs between different Git workflows (trunk-based, Gitflow, feature branches) in the context of AI-assisted development. (Bloom's: Analyze)
5. Evaluate pull request quality, merge strategies, and release management practices for AI-generated code. (Bloom's: Evaluate)
6. Create Git hooks, automation scripts, and custom workflows that integrate AI assistance into every stage of the version control lifecycle. (Bloom's: Create)

Introduction

Version control is the single most important practice separating professional software development from amateur tinkering. It provides a safety net, a collaboration framework, and a historical record of every decision made during the life of a project. Git, the dominant version control system, has been the industry standard for over a decade. But the rise of AI-assisted development, what we call vibe coding, has fundamentally changed how developers interact with Git.

Consider the differences. A traditional developer might write 50 lines of code over an hour, carefully testing and committing incrementally. A vibe coder working with an AI assistant might generate 200 lines in ten minutes, then spend the next hour reviewing, refining, and restructuring that code. The rhythm is different. The commit patterns are different. The diffs are larger. The need for careful review is greater.

This chapter addresses version control from the perspective of developers who use AI tools daily. You will learn not just the mechanics of Git, which we assume you have encountered before, but the workflows, conventions, and strategies that make version control effective when AI is generating significant portions of your code. We will cover everything from branching strategies and commit conventions to merge conflict resolution with AI assistance, Git hooks, release management, and advanced workflows.

Whether you are working solo or on a team, whether your project is a single-file script or a monorepo with dozens of packages, the practices in this chapter will help you maintain a clean, navigable, and reliable version history.

Let us begin.

31.1 Git in the AI Development Era

How Vibe Coding Changes Version Control

Traditional version control workflows were designed around a simple model: a human developer writes code, tests it, and commits it. The commits are small, the diffs are readable, and the commit messages describe the developer's intent. AI-assisted development disrupts every one of these assumptions.

Larger diffs. When an AI generates an entire module, a complete test suite, or a full-featured API endpoint in a single interaction, the resulting diff can be hundreds of lines. Traditional code review practices, where a reviewer reads every line of a diff, become strained when the volume increases dramatically.

More frequent commits. Experienced vibe coders learn to commit frequently, creating save points before and after each AI interaction. This protects against AI-generated code that breaks existing functionality and makes it easy to roll back to a known-good state.

AI-generated commit messages. AI tools can now generate commit messages from diffs, a convenience that raises questions about message quality, consistency, and whether developers truly understand what they are committing.

Blurred authorship. When an AI writes the code and a human reviews it, who is the author? This question has implications for blame annotations, code ownership, and intellectual property.

Key Concept: The AI Commit Paradox

AI-assisted development creates a paradox: you can generate code faster than ever, but you need more version control discipline, not less. The speed of generation makes it tempting to skip commits, delay reviews, and push large, untested changes. Resist this temptation. The faster you generate code, the more checkpoints you need.

The Fundamental Git Mental Model

Before discussing advanced workflows, let us ensure the mental model is solid. Git tracks content through a directed acyclic graph (DAG) of commits. Each commit is a snapshot of the entire project at a point in time, not a set of changes. The diff you see is computed by comparing two snapshots.

┌──────────┐     ┌──────────┐     ┌──────────┐
│ Commit A │────▶│ Commit B │────▶│ Commit C │
│ (snap 1) │     │ (snap 2) │     │ (snap 3) │
│ abc1234  │     │ def5678  │     │ 9ab0cde  │
└──────────┘     └──────────┘     └──────────┘
                                       │
                                       ▼
                                  HEAD (main)

Branches are simply pointers to commits. Creating a branch is nearly free, which is why branching strategies are so central to Git workflows. Tags are also pointers, but unlike branches, they do not move.

The Three Areas of Git

Understanding Git's three areas is essential for working effectively:

1. Working Directory — The files you see and edit on disk. AI tools modify files here.
2. Staging Area (Index) — A holding area for changes you intend to commit. Selective staging is one of the most powerful yet underused features of Git.
3. Repository (.git) — The complete history of your project, stored as a DAG of commits.

┌─────────────┐    git add    ┌──────────────┐   git commit   ┌────────────┐
│   Working   │──────────────▶│   Staging    │───────────────▶│ Repository │
│  Directory  │               │  Area/Index  │                │   (.git)   │
│             │◀──────────────│              │                │            │
└─────────────┘  git restore  └──────────────┘                └────────────┘

When working with AI tools, this three-area model becomes especially important. AI tools modify your working directory. You must then decide what to stage, what to commit, and what to discard. Never blindly git add . after an AI interaction. Always review the changes first.

Best Practice: The Pre-Commit Review

After every AI code generation session, run git diff to see exactly what changed. Then use git add -p (patch mode) to selectively stage only the changes you have reviewed and approved. This practice prevents accidental commits of debug code, hardcoded credentials, or unfinished experiments that the AI may have introduced.

31.2 Branching Strategies for AI-Assisted Work

Feature Branch Workflow

The feature branch workflow is the most common Git workflow and remains highly effective for AI-assisted development. Each new feature, bug fix, or experiment gets its own branch.

main ─────●─────────●─────────●─────────●─────── (stable)
           \       /           \       /
feature-a   ●───●              │      │
                               │      │
feature-b                      ●──●──●

Advantages for vibe coding: - Each AI interaction can be isolated to a branch, making it easy to discard experiments that go wrong. - Feature branches provide natural boundaries for code review. - Parallel work is straightforward; multiple AI sessions can happen on different branches.

Naming conventions matter. Adopt a consistent naming scheme:

feature/add-user-authentication
bugfix/fix-login-redirect
experiment/try-fastapi-instead-of-flask
refactor/extract-database-layer
ai-generated/new-test-suite

The ai-generated/ prefix is a convention some teams adopt to flag branches where AI tools produced the majority of the code, signaling that extra review scrutiny is warranted.

Trunk-Based Development

Trunk-based development (TBD) minimizes long-lived branches. Developers commit to main (or trunk) frequently, using short-lived feature branches that last hours, not days.

main ─────●──●──●──●──●──●──●──●──●──●──●──── (continuous)
           \  /     \  /        \  /
            ●        ●          ●
         (short)  (short)    (short)

Advantages for vibe coding: - Encourages small, frequent commits, which is exactly what vibe coding needs. - Reduces merge conflict risk because branches are short-lived. - Pairs well with continuous integration and continuous deployment (CI/CD).

Trade-offs: - Requires strong CI/CD to catch broken code quickly. - Less forgiving of large, AI-generated changes that have not been fully reviewed. - Feature flags may be needed to hide incomplete work.

When to Use What

Use trunk-based development when your team has strong CI/CD, automated testing, and disciplined review practices. The fast pace of AI-assisted development pairs naturally with TBD's emphasis on small, frequent commits.

Use feature branches when AI interactions produce large, complex changes that need extended review, or when team members are still building confidence with AI tools and need the safety net of isolated branches.

Gitflow

Gitflow uses multiple long-lived branches (main, develop, release/*, hotfix/*) with strict rules about when and how code flows between them.

main     ─────●──────────────────────●───────────●────
               \                    /             /
develop   ──●───●──●──●──●──●──●──●───●──●──●──●────
              \       /       \       /
feature-a      ●───●          │     │
                              │     │
feature-b                     ●──●──●

In the AI era, Gitflow has fallen out of favor for most teams. Its complexity adds overhead without proportional benefit, especially when AI tools can generate release automation scripts, hotfix patches, and feature implementations rapidly. However, Gitflow remains relevant for:

• Teams with strict release schedules (mobile apps, embedded systems).
• Projects where regulatory compliance requires formal release processes.
• Organizations where multiple versions must be maintained simultaneously.

Choosing a Strategy

31.3 Commit Message Conventions

Why Commit Messages Matter More with AI

When AI generates code, commit messages become the primary record of human intent. The diff tells you what changed, but the commit message tells you why. In AI-assisted development, the "why" is more important than ever because the "what" can be surprisingly large and complex.

Conventional Commits

The Conventional Commits specification provides a structured format for commit messages:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Types:

Writing Good Commit Messages

Follow the seven rules of a great commit message:

1. Separate subject from body with a blank line.
2. Limit the subject line to 50 characters.
3. Capitalize the subject line.
4. Do not end the subject line with a period.
5. Use the imperative mood in the subject line ("Add feature" not "Added feature").
6. Wrap the body at 72 characters.
7. Use the body to explain what and why, not how.

Bad commit messages in AI-assisted development:

# Too vague
git commit -m "AI-generated changes"

# Too technical, no context
git commit -m "Update 47 files"

# Describes what AI did, not what the change accomplishes
git commit -m "Copilot suggestions accepted"

Good commit messages:

feat(auth): add JWT token refresh mechanism

Implement automatic token refresh when the access token expires
within 5 minutes. The refresh happens transparently in the HTTP
client middleware, so no changes are needed in consuming code.

The token refresh logic was generated with AI assistance and
reviewed for security implications. Rate limiting prevents
refresh storms.

Closes #234

Best Practice: AI-Assisted Commit Messages

Use AI to draft commit messages from your diffs, but always review and edit them. An AI can summarize what changed, but only you know why you made the change. The best workflow: let AI generate the first draft, then add the intent, context, and any relevant issue references yourself.

Attributing AI Contributions

Some teams adopt conventions for noting AI involvement in commits:

feat(api): add rate limiting middleware

Implemented token bucket rate limiting for all API endpoints.
Configurable per-route limits with Redis-backed storage.

AI-assisted: Initial implementation generated by Claude,
reviewed and modified for production readiness.

Co-authored-by: Claude <noreply@anthropic.com>

This attribution is not legally required in most jurisdictions, but it serves as valuable metadata for future developers who may need to understand the provenance of the code.

31.4 Pull Request Workflows

The Pull Request as a Quality Gate

Pull requests (PRs) are the primary mechanism for code review in most Git workflows. In AI-assisted development, PRs serve an additional critical function: they are the checkpoint where human judgment validates AI-generated code before it enters the shared codebase.

Anatomy of an Effective PR

A well-structured PR contains:

1. Title — A concise, descriptive summary (under 70 characters).
2. Description — Context, motivation, approach, and testing notes.
3. Linked issues — References to the issues or tickets being addressed.
4. Test plan — How the changes were tested.
5. Screenshots or demos — For UI changes.
6. AI disclosure — A note about which parts were AI-generated (if your team follows this convention).

PR description template:

## Summary
Brief description of the changes and their purpose.

## Motivation
Why these changes are needed. Link to relevant issues.

## Changes Made
- Bullet point list of specific changes
- Grouped logically

## AI Assistance
- Which AI tools were used
- Which sections were AI-generated vs. human-written
- What review was performed on AI-generated code

## Testing
- [ ] Unit tests pass
- [ ] Integration tests pass
- [ ] Manual testing performed
- [ ] Edge cases considered

## Screenshots
(if applicable)

## Checklist
- [ ] Code follows project style guidelines
- [ ] Self-review completed
- [ ] Documentation updated
- [ ] No hardcoded secrets or credentials
- [ ] AI-generated code reviewed for correctness

PR Size Guidelines

Research consistently shows that smaller PRs receive better reviews. The ideal PR is under 400 lines of changes. AI-assisted development makes it tempting to submit larger PRs because code generation is fast. Resist this temptation.

┌────────────────────────────────────────────────┐
│           PR Size vs. Review Quality           │
│                                                │
│  Review    ████                                │
│  Quality   ████████                            │
│            ████████████                        │
│            ██████████████                      │
│            ████████████████                    │
│            ████████████████████                │
│            ██████████████████████████          │
│            ████████████████████████████████    │
│            ─────────────────────────────────   │
│            50   100  200  400  800  1600+      │
│                    Lines Changed               │
│                                                │
│  Smaller PRs = More thorough reviews           │
└────────────────────────────────────────────────┘

Strategies for keeping PRs small with AI tools:

• Split AI output across multiple PRs. If you ask an AI to generate an entire feature, break the result into logical PRs: data model first, then business logic, then API endpoints, then tests.
• Use stacked PRs. Create a chain of dependent PRs, each building on the previous one.
• Commit AI experiments separately. Exploratory AI interactions that inform the final implementation do not need to be in the same PR.

Code Review for AI-Generated Code

Reviewing AI-generated code requires a different mindset than reviewing human-written code. Common issues to watch for:

1. Plausible but incorrect logic. AI-generated code often looks correct at first glance but contains subtle bugs. Pay special attention to edge cases, off-by-one errors, and boundary conditions.

2. Outdated patterns. AI models are trained on historical data. The code may use deprecated APIs, outdated libraries, or patterns that were common years ago.

3. Security vulnerabilities. AI models may generate code with SQL injection vulnerabilities, hardcoded secrets, insufficient input validation, or insecure cryptographic practices.

4. Missing error handling. AI-generated code often focuses on the happy path. Look for missing try/except blocks, unchecked return values, and unhandled edge cases.

5. Over-engineering. AI tools sometimes generate unnecessarily complex solutions when a simpler approach would suffice.

Warning: The LGTM Trap

The most dangerous pattern in AI-assisted development is rubber-stamping AI-generated code with a quick "LGTM" (Looks Good To Me). Because the code is syntactically correct and superficially logical, reviewers may lower their guard. Treat AI-generated code with the same rigor you would apply to code from a talented but inexperienced junior developer.

31.5 Merge Strategies and Conflict Resolution

Three Merge Strategies

Git offers three primary strategies for integrating changes from one branch into another:

1. Merge Commit (--no-ff)

Creates a merge commit that preserves the full branch history.

main     ─────●─────────────●─────── (merge commit M)
               \           / \
feature         ●───●───●     │
                              ▼
                            HEAD

Advantages: Complete history, easy to revert entire features, clear branching points. Disadvantages: Can clutter the log with many merge commits.

2. Rebase

Replays commits from the feature branch on top of the target branch, creating a linear history.

Before rebase:
main     ─────●──●──●
               \
feature         ●───●───●

After rebase:
main     ─────●──●──●
                       \
feature                 ●'──●'──●' (replayed commits)

Advantages: Clean, linear history. Easy to read and bisect. Disadvantages: Rewrites history (never rebase shared branches). Can be confusing for beginners.

3. Squash Merge

Combines all commits from the feature branch into a single commit on the target branch.

Before squash:
feature    ●───●───●───●  (4 commits)

After squash merge:
main     ─────●──────●  (single squash commit S)
                      S = all changes from feature

Advantages: Clean main branch history. Each feature is one commit. Disadvantages: Loses individual commit history from the feature branch.

Choosing a Merge Strategy for AI-Assisted Work

Recommendation: Squash for AI Experiments

When you create a branch to experiment with AI-generated code, your commit history will likely be messy: "try approach A," "revert approach A," "try approach B," "fix approach B," "final cleanup." A squash merge collapses this into a single, clean commit with a meaningful message.

Conflict Resolution with AI Assistance

Merge conflicts are inevitable in collaborative development. AI tools can help resolve them, but you must understand what is happening to use them effectively.

Understanding conflict markers:

<<<<<<< HEAD
def calculate_total(items: list[Item]) -> Decimal:
    """Calculate the total price of all items."""
    return sum(item.price * item.quantity for item in items)
=======
def calculate_total(items: list[Item], discount: float = 0.0) -> Decimal:
    """Calculate the total price with optional discount."""
    subtotal = sum(item.price * item.quantity for item in items)
    return subtotal * Decimal(1 - discount)
>>>>>>> feature/add-discounts

AI-assisted resolution approach:

1. Show the AI both versions along with the context of what each branch was trying to achieve.
2. Ask the AI to merge the intent, not just the text. In the example above, the correct resolution preserves the discount feature while maintaining the original function's contract.
3. Test the resolution before committing. AI-merged code should always be tested.

# Correct resolution: combines both intents
def calculate_total(
    items: list[Item],
    discount: float = 0.0,
) -> Decimal:
    """Calculate the total price of all items with an optional discount.

    Args:
        items: List of items to calculate total for.
        discount: Discount percentage (0.0 to 1.0). Defaults to 0.0.

    Returns:
        The total price after discount.
    """
    subtotal = sum(item.price * item.quantity for item in items)
    return subtotal * Decimal(1 - discount)

Best Practice: Prevent Conflicts Before They Happen

The best conflict resolution is conflict prevention. When multiple team members are using AI tools simultaneously, coordinate on which files each person is modifying. AI-generated code tends to touch many files at once, increasing conflict risk. Regular rebasing from the main branch keeps your feature branch current and reduces the scope of potential conflicts.

31.6 AI-Assisted Git Operations

Using AI to Generate Commit Messages

AI tools can analyze your staged changes and generate commit messages. Here is a workflow:

# Stage your changes
git add -p

# Show the diff to your AI tool
git diff --staged

# Ask the AI: "Generate a conventional commit message for these changes"

The AI will produce something like:

feat(auth): add password reset flow with email verification

- Add PasswordResetRequest model with expiry timestamp
- Implement email sending via SendGrid integration
- Add rate limiting (3 requests per hour per user)
- Create reset confirmation endpoint with token validation

Always review AI-generated commit messages for accuracy. AI tools sometimes mischaracterize the intent of changes or miss important context.

Using AI to Write PR Descriptions

PR descriptions benefit enormously from AI assistance. Provide the AI with:

1. The full diff (git diff main...HEAD)
2. The issue or ticket being addressed
3. Any relevant design decisions or context

The AI can then generate a structured PR description that covers the changes, motivation, testing notes, and potential risks.

Using AI for Git Bisect

git bisect is a powerful tool for finding the commit that introduced a bug. AI can help by:

1. Writing the bisect test script. If the bug can be detected programmatically, ask the AI to write a script that exits with 0 (good) or 1 (bad).
2. Interpreting bisect results. Once bisect identifies the problematic commit, ask the AI to analyze the diff and explain what likely caused the bug.

# Start bisecting
git bisect start
git bisect bad HEAD
git bisect good v1.2.0

# Let AI write a test script
# Save the AI-generated script to /tmp/test-bug.sh
git bisect run /tmp/test-bug.sh

Using AI to Understand Repository History

AI tools excel at summarizing and explaining Git history:

# Generate a summary of recent changes
git log --oneline --since="1 week ago"

# Ask AI: "Summarize these changes and identify any patterns or concerns"

# Understand a specific file's evolution
git log --follow -p -- path/to/file.py

# Ask AI: "Explain how this file has evolved and why"

Tool Tip: AI-Powered Git Aliases

Create Git aliases that pipe output to AI tools for instant analysis: bash [alias] explain = "!f() { git log --oneline -20 | ai-tool summarize; }; f" review-diff = "!f() { git diff $1 | ai-tool review; }; f" While the specifics depend on your AI tool, the pattern of piping Git output to AI analysis is universally applicable.

31.7 Monorepo vs. Multi-Repo Strategies

What Is a Monorepo?

A monorepo stores all of a project's code in a single repository. Google, Meta, and Microsoft use monorepos for large portions of their codebases.

my-project/
├── packages/
│   ├── frontend/        # React application
│   ├── backend/         # FastAPI server
│   ├── shared/          # Shared types and utilities
│   └── mobile/          # React Native app
├── tools/
│   ├── scripts/         # Build and deployment scripts
│   └── ci/              # CI/CD configuration
├── docs/                # Documentation
└── package.json         # Root workspace configuration

Multi-Repo Strategy

A multi-repo strategy stores each component in its own repository:

org/frontend-app        # React application
org/backend-api         # FastAPI server
org/shared-types        # Shared types package
org/mobile-app          # React Native app
org/deployment-scripts  # Infrastructure code

Monorepo and AI-Assisted Development

Monorepos have specific advantages for vibe coding:

Advantages: - Unified context. AI tools can see the entire codebase, enabling better cross-component suggestions. - Atomic changes. A single commit can update the API, the frontend, and the shared types together. - Consistent tooling. Linters, formatters, and test runners are configured once for all packages. - Easier refactoring. AI-assisted refactoring across package boundaries is straightforward.

Challenges: - Repository size. Large repos can slow down Git operations and AI tool indexing. - CI/CD complexity. Changes to one package trigger builds for packages that may not need rebuilding. - Access control. Fine-grained permissions are harder to manage in a monorepo.

AI-specific consideration: Most AI coding tools work better with monorepos because they can index the entire codebase and understand cross-component relationships. If your AI tool has a context window limitation, a monorepo allows it to see the relevant interfaces between components without needing to reference external repositories.

Practical Guidance: When to Choose What

Choose a monorepo when: - Your components share types, utilities, or configuration. - Your team is small to medium (under 50 developers). - You want AI tools to have full codebase context. - You practice continuous deployment.

Choose multi-repo when: - Components are truly independent with stable, versioned interfaces. - Different teams own different components with different release schedules. - Repository size would make Git operations impractical. - Security requires strict access control between components.

Monorepo Tools

If you choose a monorepo, consider these tools:

31.8 Release Management

Semantic Versioning (SemVer)

Semantic versioning uses a three-part version number: MAJOR.MINOR.PATCH.

v2.4.1
│ │ │
│ │ └── PATCH: Bug fixes, no API changes
│ └──── MINOR: New features, backward compatible
└────── MAJOR: Breaking changes

Rules: - Increment PATCH for backward-compatible bug fixes. - Increment MINOR for backward-compatible new features. - Increment MAJOR for incompatible API changes. - Pre-release versions use suffixes: v2.4.1-beta.1, v2.4.1-rc.1.

Calendar Versioning (CalVer)

Some projects use calendar-based versioning: YYYY.MM.DD or YYYY.MM.MICRO.

2025.06.1    # First release in June 2025
2025.06.2    # Second release in June 2025
2025.07.1    # First release in July 2025

CalVer works well for projects with regular release cadences, such as Ubuntu (24.04) or pip (24.0).

Release Workflows

A typical release workflow with AI assistance:

1. Create release branch
   git checkout -b release/v2.5.0 develop

2. AI generates changelog from commit history
   git log v2.4.0..HEAD --oneline | ai-tool generate-changelog

3. Bump version numbers
   # AI can find and update all version references

4. Final testing and bug fixes on release branch
   git commit -m "fix(release): correct typo in error message"

5. Merge to main and tag
   git checkout main
   git merge --no-ff release/v2.5.0
   git tag -a v2.5.0 -m "Release v2.5.0"

6. Merge back to develop
   git checkout develop
   git merge --no-ff release/v2.5.0

Changelog Generation

AI excels at generating changelogs from commit history, especially when commits follow the Conventional Commits format:

# Changelog

## [2.5.0] - 2025-06-15

### Added
- OAuth2 login flow with Google and GitHub providers (#234)
- Rate limiting middleware for all API endpoints (#256)
- Dark mode support in the web dashboard (#278)

### Fixed
- Payment gateway null response handling (#245)
- Memory leak in WebSocket connection manager (#261)

### Changed
- Upgraded FastAPI from 0.104 to 0.109 (#270)
- Refactored database connection pooling (#275)

### Security
- Patched XSS vulnerability in user profile rendering (#280)

Automation Tip: AI-Powered Release Notes

Combine git log with AI to generate human-readable release notes automatically: bash git log v2.4.0..v2.5.0 --pretty=format:"%h %s" | \ ai-tool "Generate release notes from these commits. Group by type. \ Highlight breaking changes. Use clear, non-technical language."

31.9 Git Hooks and Automation

What Are Git Hooks?

Git hooks are scripts that run automatically at specific points in the Git workflow. They live in the .git/hooks/ directory (or can be managed by tools like pre-commit, husky, or lefthook).

Essential Hooks for AI-Assisted Development

Pre-commit hooks run before a commit is created. They catch issues before they enter the repository.

#!/bin/bash
# .git/hooks/pre-commit

# Run linter
echo "Running linter..."
python -m flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics
if [ $? -ne 0 ]; then
    echo "Linting failed. Fix errors before committing."
    exit 1
fi

# Check for hardcoded secrets
echo "Checking for secrets..."
python -m detect_secrets_hook --baseline .secrets.baseline
if [ $? -ne 0 ]; then
    echo "Potential secrets detected. Review before committing."
    exit 1
fi

# Run type checker on changed files
echo "Running type checker..."
git diff --cached --name-only --diff-filter=ACM | grep '\.py$' | xargs -r python -m mypy
if [ $? -ne 0 ]; then
    echo "Type checking failed. Fix errors before committing."
    exit 1
fi

Commit-msg hooks validate the commit message format.

#!/bin/bash
# .git/hooks/commit-msg

# Validate conventional commit format
commit_msg=$(cat "$1")
pattern="^(feat|fix|docs|style|refactor|test|chore|perf|ci|build)(\(.+\))?: .{1,50}"

if ! echo "$commit_msg" | head -1 | grep -qE "$pattern"; then
    echo "ERROR: Commit message does not follow Conventional Commits format."
    echo "Expected: <type>(<scope>): <description>"
    echo "Example:  feat(auth): add OAuth2 login flow"
    echo ""
    echo "Your message: $(head -1 "$1")"
    exit 1
fi

Pre-push hooks run before code is pushed to a remote.

#!/bin/bash
# .git/hooks/pre-push

# Run full test suite before pushing
echo "Running tests before push..."
python -m pytest tests/ -x -q
if [ $? -ne 0 ]; then
    echo "Tests failed. Fix before pushing."
    exit 1
fi

Managing Hooks with pre-commit Framework

The pre-commit framework provides a standardized way to manage hooks:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.5.0
    hooks:
      - id: trailing-whitespace
      - id: end-of-file-fixer
      - id: check-yaml
      - id: check-added-large-files
        args: ['--maxkb=500']

  - repo: https://github.com/psf/black
    rev: 24.3.0
    hooks:
      - id: black

  - repo: https://github.com/PyCQA/flake8
    rev: 7.0.0
    hooks:
      - id: flake8

  - repo: https://github.com/pre-commit/mirrors-mypy
    rev: v1.9.0
    hooks:
      - id: mypy
        additional_dependencies: [types-requests]

  - repo: https://github.com/Yelp/detect-secrets
    rev: v1.4.0
    hooks:
      - id: detect-secrets
        args: ['--baseline', '.secrets.baseline']

Install and run:

pip install pre-commit
pre-commit install
pre-commit run --all-files  # Run on all files once

AI-Specific Hook: Large Diff Warning

Consider adding a custom hook that warns when a commit's diff exceeds a threshold. AI-generated code can produce large diffs, and this hook serves as a reminder to review carefully:

```bash

!/bin/bash

Warn if staged changes exceed 500 lines

lines_changed=$(git diff --cached --stat | tail -1 | grep -oP '\d+(?= insertion)' || echo 0) if [ "$lines_changed" -gt 500 ]; then echo "WARNING: This commit changes $lines_changed lines." echo "Large commits from AI-generated code should be split into smaller commits." read -p "Continue anyway? (y/N) " confirm if [ "$confirm" != "y" ]; then exit 1 fi fi ```

31.10 Advanced Git Workflows

Cherry-Pick

Cherry-picking applies a specific commit from one branch to another without merging the entire branch.

# Apply commit abc1234 from feature branch to main
git checkout main
git cherry-pick abc1234

Use case in vibe coding: You generate a useful utility function on an experimental branch but decide not to merge the whole branch. Cherry-pick just the commit with the utility function.

Git Bisect

git bisect uses binary search to find the commit that introduced a bug:

git bisect start
git bisect bad                    # Current commit is bad
git bisect good v2.3.0            # v2.3.0 was good
# Git checks out a commit halfway between
# Test it, then:
git bisect good                   # or git bisect bad
# Repeat until Git identifies the culprit
git bisect reset                  # Return to original state

AI-enhanced bisect: Write an automated test script with AI assistance:

# AI generates a test script for the specific bug
git bisect run python -c "
from myapp.calculator import calculate_tax
result = calculate_tax(100.0, 'CA')
assert result == 8.25, f'Expected 8.25, got {result}'
"

Git Worktrees

Worktrees allow you to check out multiple branches simultaneously in different directories:

# Create a worktree for a feature branch
git worktree add ../my-project-feature feature/new-ui

# Create a worktree for a hotfix
git worktree add ../my-project-hotfix hotfix/security-patch

# List worktrees
git worktree list

# Remove a worktree when done
git worktree remove ../my-project-feature

Use case in vibe coding: You are working on a feature with AI assistance when an urgent bug report comes in. Instead of stashing your work or committing half-finished code, create a worktree for the hotfix. You can have two AI sessions running simultaneously, one in each worktree, without interference.

Interactive Rebase

Interactive rebase lets you rewrite commit history: reorder, squash, edit, or drop commits.

git rebase -i HEAD~5

This opens an editor with the last 5 commits:

pick abc1234 feat(auth): add login form
pick def5678 fix(auth): correct validation regex
pick 9ab0cde wip: debugging login issue
pick 1234567 fix(auth): handle empty password
pick 890abcd refactor(auth): clean up login logic

You can change pick to: - squash (or s) — Combine with previous commit. - fixup (or f) — Like squash, but discard this commit's message. - reword (or r) — Change the commit message. - drop (or d) — Remove the commit entirely. - edit (or e) — Pause to amend the commit.

Vibe coding use case: After an AI-assisted development session, your commit history might look messy. Interactive rebase lets you clean it up before creating a PR:

pick abc1234 feat(auth): add login form
squash def5678 fix(auth): correct validation regex
drop  9ab0cde wip: debugging login issue
squash 1234567 fix(auth): handle empty password
squash 890abcd refactor(auth): clean up login logic

Result: A single, clean commit that tells the story of the feature, not the story of how the AI generated it.

Reflog: Your Safety Net

The reflog records every change to HEAD, even operations like rebase and reset that rewrite history:

# View reflog
git reflog

# Output:
# abc1234 HEAD@{0}: rebase: feat(auth): add login form
# def5678 HEAD@{1}: rebase: start
# 9ab0cde HEAD@{2}: commit: wip: debugging login issue
# ...

# Recover a "lost" commit
git checkout HEAD@{2}

# Or create a branch from it
git branch recovery-branch HEAD@{2}

Safety Net: Always Know About Reflog

The reflog is your ultimate safety net. Almost nothing in Git is truly permanent. If a rebase goes wrong, if you accidentally delete a branch, if you reset when you should not have, the reflog lets you recover. It keeps entries for 90 days by default.

Stashing

Git stash temporarily saves uncommitted changes:

# Stash current changes
git stash push -m "WIP: AI-generated auth module"

# List stashes
git stash list

# Apply most recent stash
git stash pop

# Apply a specific stash
git stash apply stash@{2}

Vibe coding pattern: Before starting a new AI interaction that might modify files extensively, stash your current work. If the AI output is not what you wanted, pop the stash to restore your previous state.

Submodules and Subtrees

For projects that depend on other Git repositories:

Submodules link to a specific commit in another repository:

git submodule add https://github.com/org/shared-lib.git lib/shared
git submodule update --init --recursive

Subtrees merge another repository's history into your repository:

git subtree add --prefix=lib/shared https://github.com/org/shared-lib.git main --squash
git subtree pull --prefix=lib/shared https://github.com/org/shared-lib.git main --squash

Subtrees are generally preferred over submodules because they are simpler to manage and do not require special commands for cloning or updating.

Putting It All Together: A Complete Vibe Coding Git Workflow

Here is a complete workflow that integrates the practices from this chapter:

1. Start a New Feature

# Update main
git checkout main
git pull origin main

# Create feature branch with descriptive name
git checkout -b feature/add-user-dashboard

# Set up branch protection rules (via GitHub/GitLab settings)
# - Require PR reviews
# - Require CI to pass
# - Require up-to-date branch

2. Develop with AI Assistance

# Before each AI interaction, commit current state
git add -A && git commit -m "chore: checkpoint before AI session"

# After AI generates code, review the diff
git diff

# Selectively stage reviewed changes
git add -p

# Commit with a meaningful message
git commit -m "feat(dashboard): add user activity chart component

AI-generated React component with Chart.js integration.
Reviewed for correctness and accessibility compliance."

3. Keep Branch Current

# Regularly rebase on main to stay current
git fetch origin
git rebase origin/main

# Resolve any conflicts (with AI assistance if needed)

4. Create Pull Request

# Push feature branch
git push -u origin feature/add-user-dashboard

# Create PR with AI-generated description
gh pr create --title "Add user dashboard with activity charts" \
  --body "$(git log main..HEAD --oneline | ai-tool generate-pr-description)"

5. Address Review Feedback

# Make requested changes
git commit -m "fix(dashboard): address PR review feedback

- Add error boundary for chart rendering failures
- Fix accessibility issue with color contrast
- Add loading skeleton for chart data fetch"

git push

6. Merge and Clean Up

# Squash merge via GitHub/GitLab UI (preferred for clean history)
# Or via command line:
git checkout main
git merge --squash feature/add-user-dashboard
git commit -m "feat(dashboard): add user activity chart component (#123)"

# Delete feature branch
git branch -d feature/add-user-dashboard
git push origin --delete feature/add-user-dashboard

# Tag if it is a release
git tag -a v2.5.0 -m "Release v2.5.0: User Dashboard"
git push origin v2.5.0

Common Pitfalls and How to Avoid Them

Chapter Summary

Version control in the age of AI-assisted development requires greater discipline, not less. The speed at which AI tools generate code makes it tempting to cut corners on commits, reviews, and branching strategies. But the practices in this chapter, from conventional commits and thoughtful branching to automated hooks and careful merge strategies, are what separate professional development from chaotic experimentation.

The key insight is this: AI changes the speed of development but not the principles. Good commit messages still matter. Small PRs still get better reviews. Clean branch history still makes debugging easier. And the safety net of version control, the ability to roll back, bisect, and recover, becomes more valuable, not less, when AI is generating significant portions of your code.

Master these workflows, and you will be able to harness the speed of AI-assisted development without sacrificing the reliability and maintainability that professional software demands.

What is Next

In Chapter 32, we will explore how teams collaborate effectively when using AI coding tools, covering code ownership, communication patterns, knowledge sharing, and the human dynamics of AI-assisted development.