Day 5: Git Workflows for AI Projects | Git & GitHub for AI Projects

What You'll Build

A fully structured AI project repository with semantic versioning tags, a clean branching strategy, a CHANGELOG, and a GitHub release — ready for collaborators or open-sourcing.

Section 1 · 8 min

Semantic Versioning and Tags

Tags mark specific commits as releases. Use semantic versioning: v1.0.0 (major.minor.patch). A major bump breaks backwards compatibility. Minor adds features. Patch fixes bugs.

bashterminal

# Create an annotated tag (preferred — stores metadata)
git tag -a v1.0.0 -m "First stable release: Claude summarization API"

# Push tags to GitHub
git push origin --tags

# List all tags
git tag -l

# Create a GitHub release from the tag
gh release create v1.0.0   --title "v1.0.0 — Initial Release"   --notes "First release. Adds /summarize, /chat, and /analyze endpoints."

# See all releases
gh release list

Section 2 · 10 min

Git Flow for AI Product Development

Large AI projects benefit from a structured branching strategy. Here's a practical version:

Branch Strategy

main

Always deployable. Tagged releases only. Never commit directly.

develop

Integration branch. Merge feature branches here first, then to main when stable.

feature/xxx

One branch per feature. Merge to develop via PR.

fix/xxx

Bug fixes. Merge to both develop and main if urgent (hotfix).

experiment/xxx

Throwaway branches for trying new models, prompts, or approaches.

For solo AI projects: Just use main + feature branches. Git Flow is for teams of 3+. Don't over-engineer it.

Section 3 · 9 min

Monorepo Structure for AI Apps

When you have a backend, frontend, and shared utilities, a monorepo keeps everything in one Git history. Tools like pnpm workspaces and Python namespace packages help manage it.

textrepo structure

my-ai-app/
├── .github/
│   └── workflows/
│       ├── test-backend.yml
│       └── test-frontend.yml
├── backend/
│   ├── app/
│   │   ├── main.py
│   │   └── routes/
│   ├── tests/
│   └── requirements.txt
├── frontend/
│   ├── src/
│   ├── package.json
│   └── .env.local.example
├── shared/
│   └── types.ts        ← shared TypeScript types
├── .gitignore
├── CHANGELOG.md
└── README.md

Section 4 · 8 min

CHANGELOG and Professional Documentation

A CHANGELOG tracks what changed in each version. Follows the Keep a Changelog format. Employers and users read this.

markdownCHANGELOG.md

# Changelog

## [1.1.0] - 2026-04-15
### Added
- Streaming responses in /chat endpoint
- Rate limiting with Redis

### Fixed
- Memory leak in long conversations
- 500 error when Claude returns empty response

## [1.0.0] - 2026-04-01
### Added
- /summarize endpoint using Claude
- /chat with conversation history
- JWT authentication
- Railway deployment

Generate it automatically: Tools like git-cliff or conventional-changelog can auto-generate CHANGELOGs from your commit messages if you follow Conventional Commits format (feat:, fix:, docs:, etc.).

What You Learned Today

Tagged releases with semantic versioning and created GitHub releases
Applied a practical branching strategy appropriate for AI project size
Structured a monorepo with separate backend/frontend directories and shared CI
Wrote a professional CHANGELOG using Keep a Changelog format

Your Challenge

Go Further on Your Own

Set up git-cliff to auto-generate your CHANGELOG from conventional commits
Add a GitHub Actions workflow that creates a release automatically when you push a tag
Write a CONTRIBUTING.md for your repo explaining the branch/PR workflow

Day 5 Complete

Course Complete!

You finished all 5 days. Ready to go deeper?

Reserve Your Bootcamp Seat

← Day 4 Course Overview

Course Progress

100%

Want live instruction and hands-on projects? Join the AI bootcamp — 3 days, 5 cities.