Everything you need to know about version control — explained for Business Solution Engineers, not developers.
Chapter 1
Why Does a BSE Need Git?
You're not becoming a developer. You're becoming a Business Solution Engineer — someone who understands customer intent, shapes context, and evaluates AI-built solutions. But here's the thing: those solutions live in code, and code lives in Git.
Think of it this way: Git is like Google Docs for code. Multiple people can work on the same project, you can see every change ever made, and you can always go back to a previous version. GitHub is where those "documents" are stored and shared online.
The BSE Workflow
As a BSE, your job follows a clear pattern:
1. Intent — Understand what the customer actually needs (not just what they say)
2. Context — Gather and shape the problem context for the AI agent
3. Evaluation — Build evaluation methods so the AI's solution can be automatically validated
4. Agent Builds → Git Tracks — The AI agent (Claude Code, Cursor, Codex) writes the code, and Git records every step
You don't need to write code. You need to navigate, review, and manage the code that AI writes. That's why Git matters.
Real-World Scenario
A client asks for a payment workflow change
The AI agent builds the solution in a Git branch. You review the changes, confirm they match the client's intent, and approve the merge. Without Git literacy, you're blind to what changed — and that's how things break.
What Git Lets You Do
Track every change — see exactly what was modified, when, and by whom (or which AI)
Experiment safely — try things in a branch without touching the working version
Review AI output — see exactly what the AI agent changed before it goes live
Roll back mistakes — if something breaks, revert to a known-good state in seconds
Collaborate — work alongside developers and AI tools using the same system
Quick Check: Why is Git important for a BSE?
BSEs need to write code from scratch
BSEs need to review and manage code that AI agents write
Git is only for senior developers
GitHub is a social media platform
Chapter 2
Core Concepts
Git vs GitHub
Git is the "Track Changes" feature — it runs on your computer and records every edit. GitHub is "OneDrive/Google Drive" — it stores your project in the cloud so teams can collaborate.
You can use Git completely offline. GitHub is where you share and collaborate. They work together, but they're not the same thing.
Key Terms (Plain English)
Repository ("repo")
A project folder with superpowers. It stores all your files and remembers every change ever made. Like a filing cabinet that never forgets.
Commit
A snapshot of your project at a moment in time. Like pressing "Save" but with a note about what changed. Each commit has a message like "Add payment form" or "Fix header bug."
Branch
A parallel version of your project. Like making a photocopy of a document to experiment on — the original stays safe. When your experiment works, you merge it back.
Pull Request (PR)
A proposal to merge changes from one branch into another. It's a review step — someone (or you) checks the changes before they go live. Like sending a doc for approval before publishing.
Clone
Downloading a complete copy of a GitHub project to your computer. Like downloading a shared Google Doc to work offline.
Fork
Creating your own copy of someone else's project on GitHub. Like duplicating a Google Doc into your own Drive — you can modify freely without affecting the original.
Match the Term
Drag each Git term to its matching definition:
Commit
Branch
Repository
Pull Request
Drop here
A project folder that tracks every change
Drop here
A saved snapshot with a description of what changed
Drop here
A parallel copy for safe experimentation
Drop here
A review step before merging changes
What's the difference between Git and GitHub?
They're the same thing
Git tracks changes locally; GitHub hosts projects in the cloud
GitHub is the free version of Git
Git only works with GitHub
Chapter 3
The Git Workflow
Every change in Git follows a simple flow. Click each step to learn more:
📝
Edit
Change your files
→
📦
Stage
Pick what to save
→
💾
Commit
Save a snapshot
→
☁️
Push
Share to GitHub
Restaurant analogy: You prepare ingredients (edit), plate the dish (stage), take a photo for the menu (commit), and post it to Instagram (push). Each step is intentional.
Why Not Just Save Directly?
The staging step might seem unnecessary, but it gives you control. Imagine you changed 10 files but only want to save 3 of them right now. Staging lets you choose exactly what goes into each commit.
This is especially useful when an AI tool generates many changes at once — you might want to commit the bug fix now but hold off on the new feature until you've reviewed it.
The Commands
Step
Command
What It Does
Check status
git status
See what's changed
Stage
git add .
Stage all changed files
Commit
git commit -m "message"
Save snapshot with a note
Push
git push
Send commits to GitHub
What's the correct order of the Git workflow?
Commit → Stage → Push → Edit
Push → Commit → Edit → Stage
Edit → Stage → Commit → Push
Stage → Edit → Push → Commit
Chapter 4
Try It Yourself
This is a simulated terminal. Type the commands below to walk through a real Git workflow. Don't worry — you can't break anything here!
Git Simulator — BSE Project
Welcome to the Git simulator! Let's set up a new project.
Type the commands below to practice. Try: git init
$
💡 Hint: Start with git init to initialize a repository
Commands to Try (In Order)
git init — Initialize a new repository
git status — Check the current state
git add . — Stage all files
git commit -m "First commit" — Save a snapshot
git log — View commit history
git checkout -b feature — Create a new branch
git branch — List all branches
git push — Push to GitHub
Deep Dive: What does git init actually do?
When you run git init, Git creates a hidden folder called .git inside your project directory. This folder contains the entire history database for your project — every commit, every branch, every change.
You never need to look inside .git directly, but knowing it's there helps explain why deleting that folder would erase all your project history (don't do that!).
Which command saves a snapshot of your staged changes?
git add .
git commit -m "message"
git push
git status
Chapter 5
Branches & Pull Requests
Branch = a separate draft. Imagine writing a proposal. Instead of editing the final version, you make a copy, try some changes, and only replace the original when you're happy. That's branching.
Why Branches Matter for BSEs
When an AI agent builds a solution for a client, it should work in a branch — never directly on the main (production) code. This way:
The working product stays safe while experiments happen
You can review every change before it goes live
Multiple solutions can be developed simultaneously
If something goes wrong, you just delete the branch — no harm done
The Branch Lifecycle
1. Create a branch → git checkout -b my-feature
2. Work on it (make changes, commit) → git add . && git commit -m "..."
3. Push to GitHub → git push origin my-feature
4. Open a Pull Request on GitHub (review step)
5. Merge into main after approval
Pull Requests: The Review Gate
A Pull Request (PR) is where the magic happens for BSEs. It's a side-by-side view of everything that changed. Green lines = additions. Red lines = deletions. You can:
See exactly what the AI agent changed
Leave comments on specific lines
Request changes before merging
Approve and merge when satisfied
BSE Scenario
Client wants a new onboarding workflow
You define the intent and context. The AI agent creates branch feature/new-onboarding and builds the solution. You open the Pull Request, see the AI added 3 new files and modified 2 existing ones. You check the changes match the client's requirements, approve, and merge. The production site updates automatically.
Deep Dive: What are merge conflicts?
A merge conflict happens when two branches change the same part of the same file differently. Git doesn't know which version to keep, so it asks you to choose.
Think of it like two people editing the same sentence in a Google Doc at the same time — someone has to decide which version wins.
In practice, Git marks the conflicting sections clearly:
<<<<<<< HEAD
Your version of the line
=======
The other branch's version
>>>>>>> feature-branch
You pick which to keep (or combine them), remove the markers, and commit. Most code editors highlight these visually to make it easy.
When should AI agents make changes directly to the main branch?
Always — it's faster
When the change is small
Rarely or never — use branches and PRs for review
Only on Fridays
Chapter 6
Git + AI Coding Tools
This is the reason BSEs need Git. AI coding tools are transforming how solutions get built — and Git is the backbone they all rely on.
The AI Tools BSEs Work With
Claude Code (Anthropic)
A command-line AI coding agent. It reads your project, understands context, and writes code directly. It creates commits, branches, and PRs — all in Git. As a BSE, you provide the intent and context; Claude Code does the building.
Cursor
An AI-powered code editor. It uses Git to track all changes. You can see exactly what the AI modified, accept or reject changes per-file, and commit when ready.
Codex / ChatGPT Code Interpreter
OpenAI's coding tools. When connected to a GitHub repo, they can read context, suggest changes, and create PRs.
GitHub Copilot
Lives inside your code editor and suggests code as you type (or as the AI agent works). All suggestions get tracked through Git.
The BSE ↔ AI ↔ Git Loop
You define Intent — "The client needs an expense report that auto-categorizes receipts"
You shape Context — client requirements, existing codebase, constraints
You set Evaluation criteria — "Must handle PDF and JPG receipts, categorize into 5 expense types"
AI Agent builds — Works in a Git branch, makes commits as it goes
You review via PR — Check the diff, run evaluations, approve or request changes
Without Git, this loop doesn't work. You'd have no way to track what the AI changed, review its work, or safely revert if something goes wrong.
GitHub Issues & Projects
Beyond code, GitHub has built-in project management tools that BSEs use daily:
Issues — Track tasks, bugs, and feature requests. Each issue can be linked to a branch and PR.
Projects — Kanban boards to organize work. Drag issues from "To Do" to "In Progress" to "Done."
Discussions — Threaded conversations for decisions that don't need code changes.
BSE Scenario
Managing an AI-built solution end to end
You create a GitHub Issue: "Client needs automated invoice matching." You add context and evaluation criteria in the issue description. The AI agent picks up the issue, creates a branch feature/invoice-matching, and works through the solution. When done, it opens a PR linked to the issue. You review, approve, merge — and the issue auto-closes. Full traceability from request to delivery.
How do AI coding tools like Claude Code relate to Git?
They replace Git entirely
They can only work without version control
They use Git to track, commit, and share the code they write
Git is only needed for manual coding
Chapter 7
Advanced Topics
These topics go beyond the basics. You don't need to master them now, but knowing they exist will help you navigate real projects.
.gitignore — What NOT to Track
Not every file should be in Git. A .gitignore file tells Git which files to skip. Common things to ignore:
Secrets — API keys, passwords, tokens (.env files)
If the command line feels intimidating, GitHub Desktop does everything through a visual interface. You click buttons instead of typing commands. It's 100% legitimate — many professionals use it daily.
GitHub Desktop gives you:
Visual diff viewer (see changes highlighted in color)
One-click commits, pushes, and branch creation
Easy PR creation
No terminal required
Download free at desktop.github.com
GitHub Pages — Free Website Hosting
GitHub can turn any repository into a live website for free. Perfect for:
Landing pages and marketing sites
Documentation sites
Client demos and prototypes
Internal tools and dashboards
Just go to your repo's Settings → Pages → select your branch → your site goes live at yourusername.github.io/repo-name.
Static vs Dynamic Sites
Static (GitHub Pages) Landing pages, docs, portfolios. Same content for everyone. Free hosting.
Dynamic (Vercel, Railway) Apps with logins, databases, real-time features. Needs a server. Usually costs money.
Deep Dive: Common Git Mistakes (and How to Avoid Them)
Editing main directly — Always use branches. Main should only change through approved PRs.