Area 07 // DeploymentLesson 107 / 14014 min read

Git and GitHub for deployment

Git records every change to your code as a commit, branches let you work on changes safely, and GitHub hosts the repository so teammates can review pull requests and automation can test and deploy each change, which makes git history the backbone of every deployment.

On this page

Think of it like this
The problem it solves
How it works, step by step
See it in code
A real example
The easy way
Trade-offs
Common mistakes
Interview questions
Quiz
Key terms
Before and after

Think of it like this

Analogy

Writing a book with co-authors. Every saved draft is numbered (commits). Each author writes a new chapter in their own copy (a branch). When ready, they send it to the editor with a note (a pull request); the editor reviews, and a proofreading machine checks spelling (CI). Only then does it go into the master copy (main), and "Edition 1.2" is stamped on the version sent to the printer (a tag).

The problem it solves

Deployment is about getting a specific version of your code safely onto servers. Without version control you can't say what's running, who changed what, or how to go back. Without a shared host and review process, broken or insecure code reaches production straight from someone's laptop. Git and GitHub give every change an identity, a reviewer and an automated test run before it ships.

How it works, step by step

Create a repository and commit early: git init, git add, git commit -m "message". Each commit has a unique SHA (like 5642e6e).
Ignore what doesn't belong: .env, .venv/, caches, build output, model weights and big datasets go in .gitignore (secrets). Large files go to object storage, a model registry or Git LFS.
Branch for each change: git switch -c feature/health-check, commit small, focused steps with clear messages.
Push to GitHub and open a pull request (PR): describe what and why; teammates review the diff.
CI runs on the PR: tests, linting, eval gates and image builds report pass or fail (GitHub Actions).
Protect main: branch rules require passing checks and approvals; no direct pushes, no force pushes.
Merge (merge commit or squash) once green and approved; delete the branch.
Release from main: tag versions (v1.1.0), and have the pipeline deploy a specific SHA or tag, recording it in the running app (e.g. APP_VERSION) so /health shows exactly what's live.
Roll back by redeploying the previous tag, or with git revert for a new commit that undoes a bad one (never rewrite shared history).

Every change flows through a branch, a reviewed pull request and CI before it reaches main and gets deployed.

See it in code

Install: Install Git from git-scm.com
Needs: Git 2.30+. Run in an empty folder.

A tiny but complete branch → commit → tag → merge cycle, with the history it produces.

git_flow.sh

git init -b main
echo 'print("hello")' > app.py
git add app.py && git commit -m "First version"
 
git switch -c feature/health-check          # a branch for one change
# ... edit app.py to add a health() function ...
git add -A && git commit -m "Add health check"
git tag v1.1.0                              # mark the release
 
git switch main
git merge --no-ff feature/health-check -m "Merge feature/health-check"
git log --oneline --graph --all

Output

*   a36ac5d Merge feature/health-check
|\
| * 5642e6e Add health check
|/
* a6abc44 First version

On GitHub you'd git push -u origin feature/health-check and open a pull request instead of merging locally; the merge button only turns green once checks pass and a reviewer approves. Your SHAs will differ: they're computed from content, author and time.

A real example

Example

What's running in production?

A team's chatbot started giving odd answers on a Friday. Their deploys were done by copying files from a laptop, so nobody could say which version was live. After the incident they moved to a simple rule: only the CI pipeline deploys, only from tagged commits on protected main, and the app reports its commit SHA on /health. The next time answers changed unexpectedly, /health showed the SHA, git log showed the prompt change in that commit's PR, and redeploying the previous tag fixed it in four minutes.

The easy way

Start here

Use one repo, a .gitignore from GitHub's Python template, a branch per change, and pull requests even if you work alone (CI still runs on them). Turn on branch protection for main with "require status checks to pass".

When you grow: the production setup

Teams use trunk-based development with short-lived branches, required reviews (CODEOWNERS for sensitive paths like prompts and infra), signed commits, required status checks, merge queues for busy repos, semantic version tags and release notes, secret scanning with push protection, and deploys pinned to SHAs with the SHA visible in health checks, traces and logs.

Trade-offs

What you gain

Every change is traceable, reviewable and reversible.
CI on pull requests catches problems before they merge.
Deploying exact SHAs makes rollbacks trivial.

What it costs you

Process overhead for tiny projects.
Merge conflicts on long-lived branches.
Git handles big binary files poorly.

When not to use it

There's no good reason to skip version control; even solo notebooks benefit from it.

Common mistakes

Committing .env files, keys or model weights.
Long-lived branches that drift far from main.
Deploying from laptops instead of from CI.
Force-pushing to shared branches.
Prompt changes made outside git, so they can't be reviewed or rolled back.

Interview questions

Try answering out loud first, then open the model answer.

Describe a good Git workflow for a team shipping an AI app.

Model answer

Short-lived feature branches off main; small commits; pull requests with description and review; CI on every PR running tests, eval gates and builds; branch protection requiring checks and approvals; merging to main triggers deployment to staging, with tagged releases promoted to production; prompts, configs and infrastructure code live in the repo so they get the same review; rollbacks redeploy a previous tag or use git revert.

git revert vs git reset?

Model answer

git revert creates a new commit that undoes a previous one, keeping history intact; it's safe on shared branches. git reset moves the branch pointer back, rewriting history; it's fine for local, unpushed work but dangerous on shared branches because it breaks other people's copies.

How do you handle large model files and datasets with Git?

Model answer

Keep them out of normal git. Store them in object storage, a model registry or dataset versioning tools, referenced by version or hash in code and config; or use Git LFS for moderately sized files. Git tracks the code and the references, not the bytes.

Quiz

Pick an answer to see whether it’s right and why.

0 of 5 answered

Key terms

Git: A version control system that records every change to your files as commits, so you can see history, work on branches and go back to any earlier version.
Commit: A saved snapshot of changes in Git, with a message and a unique ID (SHA).
Branch: A separate line of work in Git, so you can make changes without affecting the main code until they are reviewed and merged.
Pull request (PR): A request to merge one branch into another, where teammates review the changes and automated checks run before merging.
Tag (release): A fixed name attached to a specific commit, such as v1.2.0, used to mark releases.
GitHub: A website that hosts Git repositories and adds pull requests, code review, issues and automation (GitHub Actions).

Before and after

Read first

046 Capstone: build a small RAG app from scratch