Git for Vibe Coders

Enterprise Onboarding: Connecting to Your Codebase

Every commit you make carries a name and email — your digital signature. Before anything else, Git needs to know who you are.

In an enterprise, traceability is paramount. Every commit must be tied to a specific individual. Using your correct enterprise name and email is non-negotiable.

git config --global user.name "Your Name"
git config --global user.email "your-enterprise-email@company.com"

Don't want to use the terminal? No problem. VS Code will prompt you to configure your identity the first time you commit — answer the prompt and it runs those two commands for you. (There's no palette command for this; the prompt or the terminal are the two paths.)

To see what's already configured — or double-check what you just set — read it back:

git config user.name          # One value
git config --global --list    # Everything you've set globally

While you're here, four more one-time settings pay for themselves many times over:

# New repos start on 'main' (matches GitHub; becomes Git's own
# built-in default in Git 3.0)
git config --global init.defaultBranch main

# Git messages open in VS Code instead of a terminal editor
git config --global core.editor "code --wait"

# First push of a new branch just works - no upstream error
git config --global push.autoSetupRemote true

# When you pull into local commits, replay yours on top
# (you'll meet the alternative in Part 3)
git config --global pull.rebase true

Try It: Introduce Yourself to Git

Meet your constant companion for the rest of this course: the Git Playground — a real Git repository running entirely in your browser. Nothing you type here can touch your actual machine, and most lessons from here on end with one of these, so you can practice each concept the moment you learn it. First exercise: the config commands you just read.

Your company's code lives in a private repository. To access it, you need to prove you're allowed in — and GitHub removed password authentication for Git back in 2021. Today there are two ways to authenticate: over HTTPS with a token, or over SSH with a key pair.

Option 1: HTTPS with a Personal Access Token

A Personal Access Token (PAT) is a generated secret that acts as your password, but with scoped permissions and an expiration date. GitHub now recommends fine-grained tokens, which can be limited to specific repositories:

1. Go to GitHub Settings → Developer settings → Personal access tokens → Fine-grained tokens
2. Click Generate new token and name it descriptively (e.g., "Work Laptop")
3. Set an expiration (90 days recommended)
4. Under Repository access, choose Only select repositories and pick your project
5. Under Permissions, set Contents to Read and write
6. Click Generate token and copy it immediately — you won't see it again

git clone https://github.com/Your-Enterprise/your-project.git
# Username: your-github-username
# Password: your-personal-access-token

Storing Your Credentials

# macOS - usually preconfigured to use the Keychain; if not:
git config --global credential.helper osxkeychain

# Windows - Git for Windows ships with Credential Manager; if not:
git config --global credential.helper manager

# Linux - install Git Credential Manager (git-credential-manager),
# then:
git config --global credential.helper manager
# Lightweight alternative (holds credentials in memory ~15 min):
git config --global credential.helper cache

Option 2: SSH Keys

SSH flips the model. Instead of pasting a secret, you generate a key pair: a private key that never leaves your machine, and a public key you upload to GitHub. Set it up once and every clone, pull, and push just works — no tokens to renew. It's the classic "set it and forget it" choice for a machine you develop on daily.

ssh-keygen -t ed25519 -C "your-enterprise-email@company.com"
# Press Enter to accept the default file location,
# then choose a passphrase (recommended)

# macOS - store the passphrase in your Keychain
eval "$(ssh-agent -s)"
ssh-add --apple-use-keychain ~/.ssh/id_ed25519

# Windows (Git Bash) & Linux
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Host *
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/id_ed25519

# macOS
pbcopy < ~/.ssh/id_ed25519.pub

# Windows (Git Bash)
cat ~/.ssh/id_ed25519.pub | clip

# Linux - print it, then copy the output
cat ~/.ssh/id_ed25519.pub

Then go to GitHub Settings → SSH and GPG keys → New SSH key, paste the key, and save. Verify the connection works:

ssh -T git@github.com
# Hi your-username! You've successfully authenticated...

With SSH, repository URLs look different — use the SSH tab of the green Code button when copying a clone URL:

git clone git@github.com:Your-Enterprise/your-project.git
# No username or token prompt - your key authenticates you

Which One Should You Use?

The Modern Shortcut: GitHub CLI

In practice, many developers today never copy a token at all. The GitHub CLI (gh) is GitHub's official command-line tool. Where git talks to the repository, gh talks to GitHub itself — authentication, pull requests, issues, releases — all without leaving your terminal. Download it from cli.github.com or install it with your package manager:

# macOS
brew install gh

# Windows
winget install --id GitHub.cli

# Linux - see cli.github.com for your distro's instructions

Then one command handles the entire authentication setup interactively — including generating and uploading an SSH key if you ask it to:

gh auth login
# Pick HTTPS or SSH, sign in through your browser,
# and it configures Git for you

And if you're using VS Code, it handles GitHub authentication the same way — when you clone a private repo or push for the first time, it opens your browser to sign in. No tokens to generate, copy, or store:

VS Code Expand

Your team's code exists on a remote server. Cloning is the act of bringing the entire project — every file, every branch, every commit in its history — right onto your machine.

To get a copy of the project on your machine, run the clone command with the repository URL your team shared with you:

git clone https://github.com/Your-Enterprise/your-project.git
cd your-project   # The clone lands in a NEW folder named after the repo

That new folder is the repository — specifically, the hidden .git directory inside it holds the entire history, every branch, all of it. Delete .git and you're left with an ordinary folder of files. (And the #1 "Git is broken!" beginner moment: running git commands from the parent folder — check you actually cd'd in.)

The VS Code Way

1. Open VS Code. Click "Clone Repository" on the Welcome page
2. Or use the Command Palette (Cmd+Shift+P / Ctrl+Shift+P) and type Git: Clone
3. Paste the HTTPS URL. VS Code handles authentication automatically
4. Choose a save location, then open the folder

VS Code Expand

One thing to keep in mind after cloning:

The Core Safety Loop: Your "Save Game" for AI Coding

You just prompted the AI to refactor a module, and it went silent for a moment. What exactly did it touch? Before you do anything, you need situational awareness.

git status is your "heads-up display." The output shows three categories:

On branch feature/login
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   src/auth.py

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
        modified:   src/routes.py

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        src/session_store.py

The good news? You don't actually need to type git status in the terminal. VS Code shows you all of this visually. Just click the Source Control icon in the Activity Bar (the branch icon on the left sidebar). The badge shows how many files changed, and each file is labeled M (modified), U (untracked), or D (deleted):

VS Code Expand

You can also spot changes right in the editor without opening the Source Control panel. VS Code adds colored indicators in the gutter (the narrow strip to the left of your code): green for added lines, blue for modified lines, and a red triangle for deleted lines. Click any indicator to preview the change inline:

VS Code Expand

Now you know what changed. The next step is the most important one: reviewing the AI's work line by line, and only approving what you trust. This is staging — your quality gate.

Step Zero: Actually Read the Diff

git status tells you which files changed; git diff shows you what changed inside them — removed lines in red with a -, added lines in green with a +. It's the terminal twin of the VS Code Diff Editor you'll meet below, and it's the command every AI agent runs before staging (Part 6 makes it a rule).

git diff            # Unstaged changes: working directory vs staging area
git diff --staged   # Staged changes: what the next commit will contain

Option 1: Stage All (the "trusting" add)

git add .

Option 2: Stage One File (the "surgical" add)

git add src/my_file.py

Option 3: Stage Parts of a File (the "AI-first developer's" add)

Here's how to start an interactive staging session:

git add --patch  # or git add -p

For each hunk, Git asks: y (stage), n (skip), s (split into smaller pieces), q (quit). In the Try It: The Complete Loop playground (next section), git add -p is simplified to file-by-file staging — type y or n on the next line for each file.

The VS Code Way: Visual Staging

This is where VS Code really shines. Instead of typing cryptic y/n/s/q responses in the terminal, you get a beautiful side-by-side Diff Editor. To stage an entire file, just hover over it and click the + button:

VS Code Expand

When you click a file in the Changes list, VS Code opens the Diff Editor -- a side-by-side view showing the old version (left) and new version (right). This makes it easy to review exactly what changed before staging:

VS Code Expand

For even more precision, click a file to open the Diff Editor, then select specific lines and right-click → "Stage Selected Ranges". This is the visual equivalent of git add -p, but far easier to use:

VS Code Expand

You've reviewed the changes and staged the ones you trust. Now it's time to freeze this moment in time — a commit is your permanent save point that you can always travel back to.

git commit -m "feat: add user authentication endpoint"

The command itself is simple, but the message you write matters more than you might think.

Where the "Why" Actually Goes: the Body

The subject line above says what changed. The "why" lives in the commit body — a blank line after the subject, then as many lines of context as the change deserves. Run git commit with no -m and Git opens your editor (VS Code, if you set core.editor in Part 1) for exactly this:

fix(auth): reject expired tokens before the DB lookup

The AI's first fix checked expiry after loading the user, which
let expired tokens trigger a full query. Checking first avoids
the load and matches how the session middleware already behaves.

Save and close the editor tab, and the commit completes. (Changed your mind? Close it with an empty message and Git aborts the commit.)

One last habit: prove to yourself the save point exists. Right after committing, run git log --oneline -1 — one line, your hash and message. (That's also the final step Part 6 teaches agents: commit, then report the hash.)

In VS Code, committing is just as simple: type your message in the input box at the top of the Source Control panel and click the Commit button (or press Cmd+Enter / Ctrl+Enter). Notice the sparkle icon next to the input -- click it to let AI generate a commit message from your staged changes:

VS Code Expand

Here's the AI commit message feature in action. After staging your changes, click the sparkle icon and Copilot will analyze your diff and write a descriptive message for you:

VS Code Expand

Try It: The Complete Loop

You asked the AI to scaffold your project, and it delivered: dependencies installed, an .env file holding your API keys, and a working app. Then it helpfully runs git add . — and now your secrets, your node_modules folder, and a stray .DS_Store are all staged for your next commit. You just learned how permanent a commit is — before you freeze that mistake into history, you need to teach Git what to ignore.

A .gitignore file is a plain text file at the root of your repository that lists patterns of files Git should pretend don't exist. Ignored files never show up as "untracked" in git status, and git add . silently skips them. The file itself gets committed, so the whole team — and every AI agent working in the repo — shares the same guardrail.

# Dependencies
node_modules/
.venv/
__pycache__/
*.pyc

# Secrets & local config
.env
.env.*
!.env.example

# Build output
dist/
build/
coverage/

# Logs & caches
*.log
.cache/

# AI tool local state (personal settings stay personal)
.claude/settings.local.json
CLAUDE.local.md
.cursor/
.aider*

(Purely personal noise like .DS_Store or .idea/ belongs in your global ignore file instead — see the end of this section. And while a repo's main .gitignore lives at the root, you can drop extra ones in any subfolder to scope rules to just that corner of the project.)

Pattern Syntax Essentials

• *.log — a glob: matches any file ending in .log, in any directory
• dist/ — a trailing slash matches only directories (and everything inside them)
• /config.json — a leading slash anchors the pattern to the repository root
• docs/**/*.tmp — ** matches any depth of nested directories
• !.env.example — a leading ! negates a pattern, re-including a file an earlier rule excluded (it can't re-include anything inside an excluded directory, though)

The Gotcha: Already-Tracked Files Stay Tracked

.gitignore only affects untracked files. If a file was already committed before you added it to .gitignore, Git keeps tracking it — and keeps committing your changes to it. To stop tracking a file without deleting it from your disk, remove it from the staging area (which Git's own messages call the index — same thing, older name):

git rm --cached .env
# For a whole directory:
git rm -r --cached node_modules

# Then commit the removal
git commit -m "chore: stop tracking ignored files"

A Global Ignore File for OS and Editor Junk

Files like .DS_Store (macOS) or Thumbs.db (Windows) are about your machine, not the project. Instead of asking every repository to ignore them, configure a global ignore file that applies to all your repositories:

git config --global core.excludesFile ~/.gitignore_global

echo ".DS_Store" >> ~/.gitignore_global
echo "Thumbs.db" >> ~/.gitignore_global

Line Endings: the Cross-Platform Papercut

Windows ends lines with CRLF, macOS and Linux with LF. On a mixed team this produces the classic horror diff: every line of the file "changed" because a teammate's editor rewrote the endings — and AI agents reformatting files make it worse. The team-level fix is a committed .gitattributes file, which overrides everyone's personal settings:

# Commit LF, let Git normalize what each OS checks out
* text=auto

# Files that must keep exact bytes, no conversion ever
*.png binary
*.webp binary

(You may also see core.autocrlf in older guides — that's the per-machine version of the same idea. Prefer .gitattributes: it lives in the repo, so it protects teammates and agents who never configured anything. If a diff ever claims every line changed, check line endings before anything else.)

Parallel Universes: Branching for AI Experiments

You have a feature idea — or maybe an ambitious AI prompt that might refactor half your codebase. Before you do anything, create a branch where it's safe to experiment.

First, make sure you're on main and it's up to date. Then create your branch:

git switch -c feature/my-new-idea
# Older equivalent: git checkout -b feature/my-new-idea

In VS Code, this is even easier. Look at the bottom-left corner of your window -- you'll see the current branch name (e.g., "main"). Click it and you'll get a dropdown where you can switch to existing branches or select "+ Create new branch..." to make a new one:

VS Code Expand

When you click the branch name, VS Code opens a Quick Pick menu listing all your branches. Select "+ Create new branch..." at the top, type a name like feature/my-new-idea, and you're immediately switched to it:

VS Code Expand

Try It: Oops — Committed to Main

You're not working in a vacuum. While you've been building your feature, your teammates have been merging theirs. Staying in sync is how you avoid painful surprises later.

Before diving into the commands, here's how the three main remote operations relate to each other:

Fetch downloads without merging. Pull = fetch + merge. Push uploads your commits.

Option 1: The "Safe" Sync (fetch + merge)

git fetch origin        # Download new commits (doesn't apply them)
git merge origin/main   # Merge the updates into your branch

Option 2: The "Easy" Sync (pull)

git pull origin main    # Fetch + merge in one command

VS Code makes syncing visual. Look at the status bar at the bottom of your window -- you'll see small arrows with numbers showing how many commits are incoming (to pull) and outgoing (to push). Click the sync icon (circular arrows) to pull and push in one step:

VS Code Expand

You'll also see a prominent "Sync Changes" button right in the Source Control panel. It shows the exact count of incoming and outgoing commits, so you always know what's about to happen:

VS Code Expand

Try It: Fetch and Merge Remote Updates

Your feature is built, tested, and committed. But you don't just push it into production — you propose it. A pull request is a conversation: "Here's what I built. Let's review it together."

Once your feature is ready, push your branch to the remote so your teammates can see it:

git push -u origin feature/my-new-idea
# -u links your local branch to the remote branch

Then on GitHub, you'll see a yellow banner: "feature/my-new-idea had recent pushes. Compare & pull request." Click it to create your PR.

The Modern PR Arc: Draft → Ready → Review → Merge

Open work-in-progress as a draft PR — visible to the team, CI running, but explicitly not asking for review yet. Click "Ready for review" when it is. Drafts stopped being a nicety in the agent era: every cloud coding agent (GitHub Copilot's coding agent, Claude, Codex, Devin) delivers its work as a draft PR for you to review — so this arc is the one you'll live in daily.

Two more things you'll meet on your first real PR:

• The merge button is a menu. "Merge commit" preserves your branch's commits; "Squash and merge" (the most common team default) collapses the whole PR into one clean commit on main; "Rebase and merge" replays them individually. Squash is why messy WIP commits on your branch are fine — they vanish at the gate.
• An AI reviewer may get there first. Many repos auto-request a review from GitHub Copilot (or a similar bot). Read it like a helpful-but-junior teammate: it only ever leaves comments — it never counts toward the required human approval, and it's sometimes wrong. Push back when it is.

Writing a good PR description can feel tedious, but AI tools can help with that too:

After the Merge: Leave the Campsite Clean

git switch main
git pull                  # Bring the merged work home
git branch -d feature/my-new-idea   # Delete the merged branch (-d is safe:
                                    # it refuses if work isn't merged)
git fetch --prune         # Drop tracking refs for branches deleted on GitHub

(GitHub can auto-delete the remote branch on merge — repo Settings → General → "Automatically delete head branches." Turn it on; nobody misses stale branches.)

You don't even need to leave VS Code to create a PR. Install the GitHub Pull Requests extension and you can create PRs, review diffs, add comments, approve, and merge -- all without opening your browser:

VS Code Expand

Try It: Branch, Commit, and Push

The "Undo" Toolkit: Reversing AI Mistakes

The AI just rewrote half your file and it's completely wrong. You haven't committed anything yet. This is the simplest undo — just throw it all away and go back to your last save point.

The fix is simple -- one command wipes the slate clean and takes you back to your last commit:

git restore .              # Discard edits to tracked files
git restore src/bad_file.py  # Discard a single file

One blind spot: git restore only rewinds files Git already tracks. Brand-new files the AI scaffolded are untracked, so they survive it. Preview the leftovers with git clean -n (a dry run), then delete them with git clean -fd.

And one more trick for the road — restore doesn't have to stop at "the last commit." The most common real-world rescue is one file, from an older commit: the AI broke src/parser.py three commits ago and you only just noticed. No reset, no history surgery:

git restore --source=HEAD~3 src/parser.py
# The file's content is now as it was 3 commits ago;
# everything else stays untouched. Review it, then commit.

In VS Code, you don't need the terminal for this. In the Source Control panel, hover over the file you want to discard under "Changes" and click the curved arrow icon. To discard ALL changes at once, click the curved arrow next to the "Changes" header. You can also right-click any file and choose "Discard Changes".

You hit git add . a bit too quickly and staged files you didn't mean to include. No worries — unstaging is completely harmless and doesn't touch your code.

No worries -- unstaging is a safe operation that simply moves a file back out of the staging area:

git restore --staged src/bad_file.py
# Older equivalent: git reset HEAD src/bad_file.py

In VS Code, this is a one-click fix. In the Source Control panel, look under "Staged Changes", hover over the file you want to unstage, and click the − (minus) button. The file moves right back to "Changes":

VS Code Expand

Try It: Unstage Dangerous Files

You just committed — and immediately realized you forgot a file, or there's a typo in the message. Instead of creating a messy "oops" commit, you can quietly fix the last one.

Instead of creating a whole new commit, you can tack the missing file onto the one you just made:

git add src/forgotten_file.py   # Stage the missed file
git commit --amend --no-edit     # Add it to the last commit

# Or just fix the message:
git commit --amend

In VS Code, click the dropdown arrow next to the Commit button and select "Commit (Amend)". This adds your newly staged files to the last commit without needing the terminal. You can also find this under the ... menu → Commit → Commit Staged (Amend).

Sometimes the AI experiment was a dead end — three commits deep, and none of it is salvageable. If you haven't pushed yet, you can erase those commits entirely and start fresh.

This is where the nuclear option comes in. A hard reset rolls your branch back as if those commits never happened:

git reset --hard HEAD~3   # Remove last 3 commits + all changes

"Remove," not quite "delete": the commits vanish from your branch, but Git keeps them around for ~30 days and the reflog (section 4.9) can bring them back. The truly unrecoverable loss is different — see the --hard card below.

The "Safer" Resets

This is the "oh no" moment — you pushed a bad commit and your teammates already pulled it. You can't erase history, but you can create a new commit that perfectly reverses the damage.

The WRONG Solution: You cannot use git reset. It rewrites history that others have, causing repository divergence.

The RIGHT Solution: Create a new commit that undoes the bad commit. This is a revert.

Here's how to create that revert commit in the terminal:

git log --oneline           # Find the hash: a1b2c3d
git revert --no-edit a1b2c3d # Create an inverse commit
git push                    # Push the revert

Without --no-edit, Git opens your editor so you can customize the revert message — fine once you expect it, startling the first time (especially if that editor turns out to be vim).

Notice that you're not erasing anything -- you're adding a new commit on top that reverses the damage:

VS Code has this built in too. Open the ... menu in the Source Control panel -- this is your gateway to all advanced Git operations. From here you can access Commit, Changes, Pull, Push, Branch, Stash, and more:

VS Code Expand

For reverting pushed commits, use the Source Control Graph: right-click any commit and select "Revert Commit" to create the inverse commit safely.

You rewrote local history with a reset or amend — and now Git refuses to push because local and remote have diverged. This is the emergency tool: a force push with a built-in safety net.

You have two flavors of force push, and picking the right one matters a lot:

One subtlety: the lease compares the remote against what you last fetched — so run git fetch first, review what changed on the remote, and only then push.

Try It: Reset and Force Push

Before moving to advanced topics, here's a quick-reference matrix summarizing every undo technique and when to use it:

Try It: The Undo Toolkit

You (or the agent) checked out an old commit hash to see how the code looked before a refactor — and the terminal barks back: "You are in 'detached HEAD' state." It sounds like an injury. It isn't. It's Git telling you exactly where you are: in the past.

Normally, HEAD points at a branch, and the branch moves forward with every commit. When you check out a commit hash directly, HEAD points at that commit instead — no branch is along for the ride. Looking around is completely safe:

git log --oneline        # Find the commit you want to visit
git checkout HEAD~2      # Detach HEAD two commits back
cat src/app.py           # Look around — reading is 100% safe

The catch is committing while detached. Any commits you make there belong to no branch — the moment you switch away, nothing points at them anymore and they become orphaned. They don't disappear instantly (the reflog still remembers them — see section 4.9), but they vanish from git log and real Git will eventually garbage-collect them.

There are exactly two escape hatches, and choosing is easy:

# Made something worth keeping? Put a branch under your feet:
git switch -c inspect-v02

# Just sightseeing? Go back to the present:
git switch main

Try It: Time-Travel and Escape

The agent ran git reset --hard and the log now looks like two days of work never happened. Before you panic: those commits are not gone. Git keeps a private journal of every place HEAD has ever been — the reflog — and it's about to save your week.

git log only shows commits reachable from your branches. The reflog shows everywhere HEAD has moved, reachable or not. Here's how to read it:

git reflog

a9f8e21 HEAD@{0}: reset: moving to HEAD~2         <- where you are NOW
4c7d3b9 HEAD@{1}: commit: feat: add caching layer <- one move ago (the "lost" work!)
8e2f1a0 HEAD@{2}: commit: feat: add ranking algorithm
1d0c5f4 HEAD@{3}: commit (initial): Initial commit

HEAD@{n} means "where HEAD was n moves ago" — HEAD@{0} is now, HEAD@{1} is one move back. Each line also shows the short hash, so you have two ways to name any point in time. Pick your recovery recipe:

# 1. Undo the reset entirely — move the branch back:
git reset --hard HEAD@{1}

# 2. Rescue a single lost commit onto your current branch
#    (cherry-pick gets its own section in 5.4):
git cherry-pick 4c7d3b9

# 3. Inspect first — park a rescue branch on the lost commit:
git switch -c rescue 4c7d3b9

Try It: Rescue Lost Commits

The reflog answers "where did my commits go?" Its sibling question — "which commit broke this?" — has its own tool: git bisect binary-searches your history. Mark one commit as bad and one as good, and Git checks out midpoints for you to test — 1,000 commits take ten rounds, not a thousand. In the agent era this is the tool for "somewhere in the bot's forty commits, the tests started failing."

Try It: Find the Bad Commit

Advanced Scenarios: Managing a Multi-Branch Workflow

You're deep in a feature branch with ten modified files when your manager says "urgent bug on main." You can't commit half-finished work, and you can't lose it either. The stash is your escape hatch.

The stash is a temporary, private holding area for your dirty changes.

# 1. Stash your changes (-u includes brand-new files)
git stash push -u -m "WIP: refactoring pipeline, AI changes"

# 2. Fix the urgent bug
git switch main
git pull
git switch -c hotfix/urgent-bug
# ... fix, test, commit, push, create PR ...

# 3. Return to your work
git switch feature/A
git stash pop

git stash pop re-applies your changes and removes them from the stash. Use git stash apply to keep the stash entry for reuse.

In VS Code, you can do all of this without memorizing commands. Open the ... menu in the Source Control panel -- you'll see a Stash submenu with all the options you need:

VS Code Expand

Choose "Stash (Include Untracked)" to save all your work. When you're ready to come back, go to ... → Stash → "Pop Latest Stash" to restore everything exactly where you left off.

Try It: The Stash Workflow

Your feature branch has been alive for a few days and main has moved on without you. Now you need to catch up — and Git offers two philosophies with very different trade-offs.

You have two options for catching up with main, and each tells a different story in your commit history.

VS Code supports both approaches. Use the ... menu in Source Control → "Pull (Rebase)" to rebase instead of merge when pulling. For merging, use the Command Palette (Cmd+Shift+P / Ctrl+Shift+P) → "Git: Merge Branch..." and select the branch to merge.

One config gem while you're here: git config --global rebase.autostash true makes Git stash your uncommitted work automatically before a rebase (or pull --rebase) and pop it after — dissolving the "Git blocked my switch" problem 5.1 opened with, for the rebase case at least.

Try It: Merge vs. Rebase

Rebase has one more trick: git rebase -i (interactive) lets you rewrite your own branch's history commit by commit — squash five "wip" commits into one, reword a sloppy message, drop an experiment entirely. It's how a messy working branch becomes a clean, reviewable PR. The Golden Rule applies double here: only ever on commits that haven't been shared.

Try It: Squash the WIP

This is the moment every developer dreads the first time — and handles calmly by the tenth. Two people changed the same lines, and Git needs a human to decide which version wins.

Don't panic -- conflicts look intimidating at first, but they follow a simple pattern. Git inserts special markers into your file to show you exactly where the disagreement is.

The Conflict Markers

<<<<<<< HEAD
x = 10
# AI refactor
=======
x = 5
# teammate fix
>>>>>>> main

Everything between <<<<<<< HEAD and the ======= divider is your side (here, the AI's refactor on your branch). Everything below the divider is the incoming side — the label after >>>>>>> names where it came from — the branch you merged (like main here; after a pull it can be a commit id or a longer label instead).

Delete all the markers (<<<, ===, >>>) and edit the code to be the correct final version, then stage and commit. In the playground, you can write the resolved file with echo 'x = 10' > src/model.py.

Not ready to deal with it? There's an eject button here too: git merge --abort cancels the merge and returns your branch to exactly how it was before you ran git merge — the same guilt-free escape you'll meet again with rebase (5.5) and cherry-pick (5.4).

The VS Code Way (The Superior Way)

Editing conflict markers by hand works, but VS Code makes the whole process much more visual and less error-prone.

VS Code Expand

For complex conflicts with multiple overlapping changes, click "Resolve in Merge Editor" to open the full 3-way view. This gives you the most control over the final result:

VS Code Expand

Try It: Resolving a Merge Conflict

Your AI experiment branch is a mess — half-finished rewrites, abandoned TODOs, dead ends. But buried in the middle is one brilliant commit: a currency rounding fix that actually works. You don't want the branch. You want that one commit.

git cherry-pick copies one commit's changes onto your current branch as a new commit — same change, same message, but a brand-new hash, because it now sits on a different parent. The original commit stays untouched on its branch.

git log --oneline --all      # Find the gem's hash on the experiment branch
git switch main              # Stand on the branch that should receive it
git cherry-pick e4f5a6b      # Copy exactly that commit here
git log --oneline            # The fix is on main — the junk is not

For an audit trail, add -x: it appends "(cherry picked from commit e4f5a6b...)" to the message, so anyone reading main later can trace where the fix came from. Perfect for the reject-the-PR workflow below.

When to prefer it over merging: merge when the whole branch is worth keeping; cherry-pick when only part of it is. And because a cherry-picked commit replays changes onto code that may have moved on, conflicts can happen here too — the escape hatches mirror rebase exactly:

# Fix the conflicted file, then:
git add <file>
git cherry-pick --continue

# Or walk away as if nothing happened:
git cherry-pick --abort

Try It: Cherry-Pick the Gem

Section 5.2 sold you on rebase for clean history — but it skipped the scary part. Your feature branch tuned src/config.py, main changed the same lines, and halfway through the rebase Git slams the brakes. Here's how to read the wreck and drive out of it.

Remember what rebase does: it replays your commits one at a time on top of the latest main. If a replayed commit touches lines that main also changed, Git can't guess the winner — so it pauses mid-replay and hands you the keys. Run git status to see the paused state: it reports a rebase in progress and lists the conflicted files under "unmerged paths". The files contain the conflict markers you learned to read in section 5.3 — with one crucial twist.

<<<<<<< HEAD
TIMEOUT = 10     # main's version (HEAD during a rebase!)
=======
TIMEOUT = 120    # your commit, being replayed
>>>>>>> a1b2c3d (feat: raise the worker timeout)

From here, it's a three-step ritual — the same one every time:

# 1. Fix the file — remove the markers, keep the right code
echo 'TIMEOUT = 120' > src/config.py

# 2. Tell Git the conflict is resolved
git add src/config.py

# 3. Resume the replay
git rebase --continue

If more commits remain, Git keeps replaying — and may pause again on the next conflict. Just repeat the ritual until the rebase completes. And if at any point you're lost, confused, or late for dinner, there's a guilt-free eject button:

git rebase --abort   # Everything returns EXACTLY as it was before the rebase

Try It: Survive a Rebase Conflict

Branches move — every commit drags them forward. But some moments deserve a permanent name: the commit you shipped, the version that passed the audit, the last known-good state before a big AI refactor. That's what tags are: labels that stick to one commit, forever.

Git has two kinds of tags, and the choice matters more than it looks:

Naming convention: most projects use semantic versioning — MAJOR.MINOR.PATCH. Bump MAJOR when you break existing users (v1.x → v2.0.0), MINOR when you add features compatibly (v1.0 → v1.1.0), and PATCH for pure bug fixes (v1.1.0 → v1.1.1). One glance at a version tells users how scared to be.

git tag -a v1.1.0 -m "Release: import support"   # Tag HEAD
git tag                                          # List all tags
git log --oneline                                # Tags appear as decorations
git show v1.0.0                                  # Inspect what a release points at

One surprise: in real Git, git push does not send tags. You push them explicitly — git push origin v1.1.0 for one tag, or git push origin --tags for all of them — though beware: --tags throws every tag at the remote, including private bookmarks like the pre-refactor checkpoint below. git push --follow-tags is the discerning version: it sends only annotated tags on commits you're pushing — which is exactly why this section told you to annotate releases and keep bookmarks lightweight. Need to remove a tag? git tag -d v1.1.0 deletes it locally — and if you deleted one by mistake, just re-tag the same commit (find it with git log --oneline, or fetch the tag back from the remote if you'd already pushed it).

Try It: Cut a Release

Git for AI Agents: Rules, Guardrails, and Scale

The next level is not just using Git to manage AI — it's encoding your Git workflow so agents follow it automatically. Modern tools share a simple pattern: always-on project instructions for conventions that apply everywhere, plus skills for detailed procedures that load only when relevant.

A complete AGENTS.md you can steal

Theory is nice, but what does a Git constitution actually look like? Here's a complete, copy-pastable example. Drop it in your repo root, adjust the branch prefixes and test command to match your project, and every agent that opens the repo inherits your rules.

# Git Rules for AI Agents

## Branches
- Never commit directly to main. Always work on a branch.
- Branch names: feature/<topic> for features, fix/<topic> for
  bug fixes, agent/<topic> for autonomous or experimental work.
- One branch per task. Do not reuse branches across tasks.

## Before staging anything
- Run `git status` and `git diff` first. Read the diff.
- Stage only files you intentionally changed. Never `git add .`
  when the diff contains files you don't recognize.

## Commits
- Use Conventional Commits with a scope:
  feat(auth): ..., fix(api): ..., refactor(parser): ...,
  docs(readme): ..., test(payments): ..., chore(deps): ...
- Keep commits small and focused: one logical change per commit.
- Run the test suite (`npm test`) before every commit.
  If tests fail, fix them or ask — do not commit broken code.

## Pushing and history
- Never use `git push --force`. If a push is rejected after a
  rebase, use `git push --force-with-lease` — and only on your
  own feature branches, never on main or shared branches.
- Never rewrite history that has been pushed and shared
  (no rebase/reset/amend on public commits — use `git revert`).

## When unsure
- Stop and ask before any destructive command
  (reset --hard, clean, filter-repo, branch -D).

For multi-step procedures, a skill keeps the detail out of your always-on instructions. Here's a small worked example: a "save-game checkpoint" skill that encodes the status-review-stage-commit ritual from Part 2 so the agent runs it the same way every time.

---
name: save-game-checkpoint
description: Create a clean Git checkpoint after a working change.
---

# Save-game checkpoint

1. Run `git status` — list every modified and untracked file.
2. Run `git diff` and summarize the changes for the user.
3. Flag anything unexpected (unrelated files, debug prints,
   secrets, lockfile churn) before proceeding.
4. Stage only the files that belong to this change:
   `git add <file> <file>` — never `git add .`
5. Commit with a Conventional Commit message and scope, e.g.
   `git commit -m "feat(payments): add refund endpoint"`
6. Confirm with `git log --oneline -1` and report the hash.

Reviewing large AI diffs

Even well-instructed agents produce big diffs, and a 40-file diff read top-to-bottom is where review discipline goes to die. Triage instead: run git diff --stat first to see which files changed and by how much — that one screen tells you whether the change matches the task you assigned. Then review file by file with git diff <file>, starting with the files you'd least expect to change. When only part of the work is good, use git add -p to stage the keepers hunk by hunk and discard the rest.

Who Wrote This — You or the Machine?

Six months from now, someone running git blame will want to know whether a human decided this line or an agent generated it. Three layers of attribution, weakest to strongest:

• Trailers. Claude Code and Copilot append Co-Authored-By: lines to their commits by default — you'll see these in your own history. Useful as a hint, but easy to strip or forget, so never treat them as a measurement of anything.
• Per-worktree identity. Running agents in worktrees (6.3)? Give each its own name so blame tells Agent A from Agent B: git config extensions.worktreeConfig true, then git config --worktree user.name "Agent A (auth)" inside each worktree.
• Signing. The strong claim runs the other way: commits you sign are verifiably yours. Modern setup is SSH-based and reuses the key from Part 1 (gpg.format ssh + commit.gpgsign true); GitHub shows "Verified" badges, and its vigilant mode flags anything unsigned that claims to be you. In a world of agents committing under borrowed names, "the human signed off here" is worth making cryptographic.

You told your agent: "always run the tests before committing." It did — for the first three commits. Then, deep in a refactor, it forgot, and a broken commit landed in history. Rules that live in a prompt are suggestions. Rules that live in Git are law. That's what hooks are for.

A Git hook is a script that Git runs automatically at a specific moment — before a commit is created, after a merge, before a push. Hooks live in the .git/hooks/ directory of your repository, where Git puts a set of .sample files to get you started. One crucial detail: the .git directory is never committed, so hooks are not versioned — they don't travel with a clone. We'll fix that in a moment.

A Minimal pre-commit Hook

The pre-commit hook runs before Git creates a commit. If the script exits with a non-zero status, the commit is blocked. Create a file named .git/hooks/pre-commit (no file extension) and make it executable:

#!/bin/sh
echo "Running checks before commit..."

npm run lint || { echo "Lint failed - commit blocked." >&2; exit 1; }
npm test || { echo "Tests failed - commit blocked." >&2; exit 1; }

chmod +x .git/hooks/pre-commit

From now on, every git commit in this repository runs your lint and test suite first. If either fails, nothing gets committed — no exceptions, no forgetting.

Enforcing Commit Message Standards

The commit-msg hook receives the path to a file containing the proposed commit message. Here's a compact one that enforces Conventional Commits (messages like feat: add login form):

#!/bin/sh
# Git's own merge and revert commits ("Merge branch ...", "Revert ...")
# also pass through this hook - wave them through.
grep -qE '^(Merge|Revert)' "$1" && exit 0

if ! grep -qE '^(feat|fix|docs|style|refactor|perf|test|build|ci|chore)(\(.+\))?!?: .+' "$1"; then
  echo "Commit message must follow Conventional Commits, e.g. 'feat: add login form'" >&2
  exit 1
fi

Making Hooks Shareable

Since .git/hooks/ isn't versioned, your teammates (and their agents) won't get your hooks automatically. The lightweight fix is a committed hooks folder plus core.hooksPath:

mkdir .githooks
# move your hook scripts into .githooks/, then:
git config core.hooksPath .githooks

# commit the folder - each teammate runs the config command once

In the JavaScript world, Husky is the popular tool that automates exactly this — it wires up the hooks path when anyone runs npm install:

npm install --save-dev husky
npx husky init

# init already created .husky/pre-commit (it runs "npm test").
# Overwrite it with whatever checks you want:
echo "npm run lint && npm test" > .husky/pre-commit

One escape hatch to know about: git commit --no-verify skips the pre-commit and commit-msg hooks entirely. It exists for genuine emergencies — a broken hook blocking a critical hotfix — but use it sparingly. Every --no-verify is a hole in your safety net, and it's a habit you especially don't want your agents learning.

Try It: The Hooks Say No

Here's the endgame scenario: you want Agent A refactoring the auth module while Agent B builds the payments feature — in the same repository, at the same time. If both agents share one working directory, they'll trample each other's files, and every git switch by one agent yanks the floor out from under the other. Worktrees solve this.

A worktree is an extra working directory attached to the same repository. All worktrees share one .git database — same commits, same branches, same remotes — but each directory has its own checked-out branch, its own files on disk, and its own staging area. Creating one takes a second, because nothing is copied except the files of the branch you check out.

# From your main checkout (~/repos/proj on main)
git worktree add ../proj-auth feature/auth-refactor
git worktree add ../proj-payments feature/payments

# See every working directory attached to this repo
git worktree list
# /Users/you/repos/proj           abc1234 [main]
# /Users/you/repos/proj-auth      def5678 [feature/auth-refactor]
# /Users/you/repos/proj-payments  9ab0cde [feature/payments]

# Open a terminal in each directory and start one agent per worktree:
#   Terminal 1: cd ../proj-auth      -> Agent A refactors auth
#   Terminal 2: cd ../proj-payments  -> Agent B builds payments

If the branch doesn't exist yet, git worktree add -b feature/payments ../proj-payments creates it in one step. Note that a branch can only be checked out in one worktree at a time — Git enforces this, which is exactly the isolation guarantee you want: two agents can never be editing the same branch's files.

Every worktree commits into the same repository — the branches just live in different folders until they're merged.

Why not just clone the repo twice? Clones work, but worktrees are better on every axis: the object database is shared (no duplicated gigabytes), creation is instant, remotes and config come along for free, and a commit made in one worktree is immediately visible from all the others — no pushing and pulling between your own directories. When both agents are done, merging their branches is the normal PR flow from Part 3: push each branch, open a pull request, review the diff, merge. Nothing about worktrees changes how integration works.

A few habits keep this tidy: name each worktree directory after its branch (proj-auth for feature/auth-refactor) so you always know which terminal belongs to which agent, and clean up when a branch merges.

# Remove a worktree you're done with (its branch survives)
git worktree remove ../proj-auth

# If you deleted a worktree folder manually, clear the stale record
git worktree prune

And a sign of how central this pattern has become: the agent tools now create worktrees for you. Claude Code has claude --worktree (agents get isolated worktrees under .claude/worktrees/, auto-cleaned when untouched), Cursor spins up a worktree per parallel agent, and desktop agent apps do it per session. When you find a mystery directory or a worktree-quiet-fox branch, that's what it was — git worktree list is how you audit them, and now you know how to clean them up.

Two monorepo-scale companions worth knowing by name: git sparse-checkout set pkg/api materializes only the directories an agent actually needs (a worktree per agent, a package per worktree, nothing else on disk), and git maintenance start schedules background housekeeping — worth turning on once a fleet of agents starts churning out objects faster than any human team ever did.

Try It: One Repo, Three Working Directories

Your AI-Assisted Cockpit: Mastering Git in VS Code

This single panel replaces a dozen terminal commands. Status, staging, committing, branching — it's all here in one visual interface that makes Git feel approachable.

Everything you've learned maps directly to the UI:

Here's what it looks like in action. Press Ctrl+Shift+G to open the Source Control panel from anywhere — and yes, it's Ctrl even on a Mac (⌘⇧G is taken by search):

VS Code Expand

Below the commit area, you'll find the Source Control Graph -- a visual representation of your commit history and branch structure. This is incredibly helpful for understanding how branches relate to each other:

VS Code Expand

When you're staring at a line of code and wondering "who changed this, and why?" — VS Code has the answer built right in. Timeline and GitLens turn your editor into a time machine.

Open any file, then look in the Explorer panel for the "Timeline" pane at the bottom. This shows the complete commit history for that specific file. Click any commit to see a diff of what it changed. The Timeline also mixes in Local History snapshots of your saves — and those entries have a right-click → "Restore Contents" that can rescue even changes you never committed.

Here's the Timeline in action. Each entry represents a commit that touched this file -- click any entry to see exactly what changed in that commit:

VS Code Expand

VS Code also has built-in Git Blame. Put your cursor on any line of code and the status bar shows who last changed it and when (an always-on inline annotation is one setting away — search Settings for "blame"). The GitLens extension goes deeper — rich line history, comparisons across branches and commits — though many of its advanced features now sit behind a paid Pro plan. Start with the built-ins; add GitLens when you hit their ceiling:

VS Code Expand

We touched on merge conflicts earlier -- now let's look at the tool that makes resolving them almost enjoyable.

When a conflict occurs, VS Code highlights the conflicting files in the Source Control view. Clicking one opens it with the inline conflict markers you know from section 5.3 — look for the "Resolve in Merge Editor" button in the corner to switch to the 3-way view with three panes:

Here's the merge editor in action. Use the checkboxes next to each change to select which version you want to keep -- or manually edit the Result pane at the bottom for a custom resolution:

VS Code Expand

And if you have GitHub Copilot installed, there's an even easier option. VS Code can use AI to analyze both sides of a conflict and suggest an intelligent resolution. Look for the "Resolve with AI" option in the merge editor:

VS Code Expand

Ship It: CI, Bots, and Releases

CI — Continuous Integration — is the fix, and the idea is almost embarrassingly simple: every time anyone pushes, a robot builds the project from scratch and runs every check against it. Not "when someone remembers." Every push, every PR, every time. On GitHub the robot service is called GitHub Actions: each run spins up a runner — a fresh, disposable Linux machine in the cloud — that clones your repo, installs dependencies from the lockfile, and works through the checklist. If everything passes, your PR gets the green checkmark. If anything fails, you get a red X and a log pointing at the failure — minutes after pushing, not weeks later in production.

The checklist itself is just a YAML file committed to your repo, which means it's versioned, reviewed, and branch-protected like everything else. A real, minimal one:

name: CI
on:
  pull_request:
  push:
    branches: [main]

jobs:
  checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci        # install EXACTLY the lockfile versions
      - run: npm run lint  # style + suspicious patterns
      - run: npm test      # the whole suite, every time
      - run: npm run build # prove a production build works

Read it top to bottom: on these triggers, run these steps. That's the entire programming model. The steps are the same commands you (or the hooks you wrote in Automating with Hooks) run locally — the difference is where and always. A pre-commit hook is a seatbelt you buckle on your own machine, and --no-verify unbuckles it. CI runs on a machine nobody can sweet-talk. Hooks are the seatbelt; CI is the law.

Branch protection (the rulesets from Pull Requests) is what wires the checkmark to the merge button: no green, no merge — for you, your teammates, and every agent equally.

The sibling acronym, CD — Continuous Delivery or Deployment — is what happens after green: code that reaches main ships to users automatically. Many projects (including this site) deploy on every merge — a second workflow builds the app and publishes it the moment a PR lands. That immediacy is exactly why the gate in front of main matters: when merging is shipping, "we'll fix it before the release" is not a sentence that exists.

Once CI guards the gate, something clever becomes possible: you can let robots propose changes, because no proposal — human, agent, or bot — gets through without passing the same checks. A bot's PR is a completely ordinary PR: a branch, a diff, a conversation, a checkmark. You already know how to review one. Meet the three coworkers you'll see most.

Dependabot is configured with — you guessed it — a YAML file in the repo. The one setting worth knowing on day one is grouping, which turns thirty tiny weekly PRs into one digestible one:

version: 2
updates:
  - package-ecosystem: npm
    directory: /
    schedule:
      interval: weekly
    groups:
      minor-and-patch:
        update-types: ["minor", "patch"]
        # major bumps stay separate — those need real review

Two quieter pieces complete the safety net. The lockfile (package-lock.json) pins the exact version of every package and every package's packages, so your laptop, CI, and production all install byte-identical dependencies — it's why the lockfile belongs in Git even though you never edit it by hand. And supply-chain pinning: careful repos reference third-party Actions by full commit hash instead of a friendly tag. You know from Tags & Releases that a tag is just a movable label — and if an attacker compromises an Action's repo, they can quietly move v4 to malicious code. A commit hash can't be moved. Same Git concept, now a security boundary.

Here's what a healthy history looks like with the robots at work — one of these commits was written by a human:

git log --oneline -n 4
e4f5a6b feat: add csv export
b7c8d9e chore(deps): bump the npm group with 3 updates
a1b2c3d chore(main): release 1.4.2 (#118)
9f8e7d6 fix: handle empty header row

Try It: Review the Robot's PR

A green merge says the code is good. A release answers two different questions: what do we call this state, and what changed since the last one? In Tags & Releases you did this by hand — decided a version number, wrote an annotated tag. This lesson is about the grammar behind those version numbers, and the robot that does the paperwork.

Semantic Versioning: the number is a promise

A version like 2.4.1 reads as major.minor.patch, and each position carries a promise to whoever upgrades: a patch bump (2.4.1 → 2.4.2) means "bug fixes only, upgrade blind"; a minor bump (2.4 → 2.5) means "new features, nothing you rely on changed"; a major bump (2 → 3) means "something breaks — read the notes before touching it." That's why Dependabot's major-version PRs deserve your full attention while patch bumps barely need a glance: the versioning scheme is literally telling you how scared to be.

Conventional Commits: the payoff

Since Committing you've been writing feat: and fix: prefixes, and in Automating with Hooks a hook started enforcing them. Here's the payoff: those prefixes map straight onto SemVer. fix: means the next release is at least a patch. feat: promotes it to a minor. A feat!: or a BREAKING CHANGE: footer forces a major. Your commit history stopped being prose and became data — which means a machine can read it.

release-please: the release accountant

release-please (Google's oddly polite release bot) watches main and keeps a running draft of the next release. It reads every conventional commit since the last tag, computes the right version bump, and opens — a pull request. The PR contains exactly two things: an updated CHANGELOG.md grouping your commits into Features and Bug Fixes, and the version bump. As more commits land on main, the bot quietly amends its own PR. When you decide it's release time, you merge the PR like any other — and the bot tags the commit and publishes a GitHub Release. If you've ever wondered what a commit like chore(main): release 1.1.0 (#42) is: that's someone merging the accountant's paperwork.

The changelog it maintains is the memory half of this chapter at its purest — the human-readable answer to "what changed since 1.0.0?", assembled from messages you were already writing:

## 1.1.0 (2026-07-17)

### Features

* add csv export (#31)

### Bug Fixes

* handle empty header row (#33)

Try It: Be release-please for a Day

Conclusion: Best Practices for AI-Augmented Teams

This is your new "save game" loop — the practical rhythm between you and your agent. Follow these 8 steps for every piece of work. Encode your Git conventions once in the repo (see Teaching AI Git) so agents follow them automatically instead of re-explaining branch rules in every chat. And remember: you can practice any step of this loop in the Git Playground — real Git commands, right in your browser.

Here's what each step looks like in practice, along with the commands you'll use.

Keep this handy. It covers the most common Git tasks with both the terminal command and the VS Code equivalent, so you can use whichever feels more natural.

Reading is not knowing. Here's the exam — one repository, three simultaneous messes, no step-by-step instructions. Everything you need is in Parts 2 through 5, and the playground will tell you the moment you've won.

Try It: The Final Challenge

The Skill Checklist

Beyond the challenge, here's the honest self-test. Check each item only when you could do it right now, without looking anything up. (Saved locally in your browser — nobody's grading you but you.)

You've practiced everything here in a real repository — but Git is deep, and the best references are worth knowing by name. These six will cover you from quick lookups to true mastery:

GitHub Is a Choice, Not a Given

This guide uses GitHub because it's where most of the industry (and most of the AI-agent ecosystem) lives — but here's an honest secret: almost nothing you learned is GitHub-specific. Git itself is decentralized; every clone carries the full history, and the "forge" — GitHub, or any of the sites below — is just the hosting and collaboration layer on top. Even the pull request is a forge invention, not a Git feature. Switching forges is one command (git remote set-url origin <new-url>) and a push. The alternatives worth knowing:

(Also out there: Azure DevOps in Microsoft-stack enterprises, and experimental peer-to-peer forges like Radicle with no central server at all. Wherever you land: same Git, same commands, same you.)