The "Save Game" Analogy

Think of Git like save points in a video game. Every time you "commit," you're creating a save point. You can:

• See the history of every save you've ever made
• Go back to any previous save if something breaks
• Work on different things without messing up your main save

Git vs GitHub

Why use Git instead of just sharing files on OneDrive?

Step 1: Get a GitHub account

If you don't have one yet, ask your team lead or IT admin to add you to the MercuryInsuranceEI GitHub organization. You'll receive an invite email.

If you need to create an account first:

1. Go to github.com and click "Sign up"
2. Use your work email
3. Choose a username (e.g., yourname_MIG)
4. Accept the organization invite when you receive it

Step 2: Authenticate with GitHub CLI

Open your terminal (Terminal on Mac, or the VS Code terminal) and run:

gh auth login

When prompted, choose:

Step 3: Set your identity

Tell Git who you are (this tags your commits with your name):

git config --global user.name "Your Name"
git config --global user.email "yourusername@mercuryinsurance.com"

Step 4: Verify it worked

gh auth status

You should see something like:

github.com
  ✓ Logged in to github.com account yourname_MIG
  - Active account: true
  - Git operations protocol: https

You need all 3 of these tools

Each one does something different — they work together:

Open the VS Code Terminal

All commands in this training are run inside VS Code's built-in terminal. To open it:

Install Git

First, check if it's already installed:

git --version

If you see a version number, you're good! If not:

winget install Git.Git

brew install git

Install GitHub CLI (gh)

Check if installed:

gh --version

If not installed:

winget install GitHub.cli

brew install gh

What is cloning?

Cloning = downloading a copy of a project from GitHub to your machine.

It's like copying a shared folder from OneDrive to your Desktop — except Git remembers where it came from and can sync changes both ways.

How to clone

gh repo clone MercuryInsuranceEI/RepoName

Or using the full URL:

git clone https://github.com/MercuryInsuranceEI/RepoName.git

This creates a folder called RepoName in your current directory with all the project files.

What you'll see:

Cloning into 'RepoName'...
remote: Enumerating objects: 47, done.
remote: Counting objects: 100% (47/47), done.
remote: Compressing objects: 100% (32/32), done.
Receiving objects: 100% (47/47), 15.2 KiB | 7.60 MiB/s, done.
Resolving deltas: 100% (12/12), done.

After cloning

# Move into the project folder
cd RepoName

# See what files are there
dir          # Windows (CMD or PowerShell)
ls           # Mac / Linux / Git Bash

# Open it in VS Code
code .

What each step does

Checking what's going on

At any time, you can see the current state of your project:

git status

This shows you:

• Red files = changed but not staged (not in the envelope yet)
• Green files = staged and ready to commit (in the envelope)
• Nothing = everything is clean, nothing to do

Adding multiple files

# Add specific files
git add server.js public/styles.css

# Or add ALL changed files (be careful with this)
git add .

Writing good commit messages

Rule of thumb: Describe what you changed and why, not how. Future you (or a coworker) should understand the change from just the message.

Adding a new file to the repo

New files work the same way — Git notices them as "untracked":

# Create or copy a new file into your project folder
cp ~/Desktop/new_script.py .

# Git status shows it as "Untracked"
git status

# Add, commit, push — same as before
git add new_script.py
git commit -m "Add new automation script for weekly data pull"
git push

When someone else makes changes

If a coworker pushes changes to GitHub, you need to pull them to get their updates:

git pull

What you'll see:

remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
Unpacking objects: 100% (3/3), 298 bytes | 298.00 KiB/s, done.
From https://github.com/MercuryInsuranceEI/RepoName
   a1b2c3d..e7f8g9h  main     -> origin/main
Updating a1b2c3d..e7f8g9h
Fast-forward
 server.js | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Already up to date.

That's it! Git downloads their changes and merges them with your local copy.

What if pull fails?

If you get a message about conflicts, don't panic! Jump to the Merge Conflicts section.

What are branches?

A branch is like a parallel universe for your code. You can make changes in a branch without affecting the main version. When you're happy with your changes, you merge them back.

When to use branches

• Small solo projects: You can work directly on main — branches are optional
• Team projects: Use branches to avoid stepping on each other's toes
• Big changes: Use a branch so you can experiment without breaking the main code

Branch commands

# Create a new branch and switch to it
git checkout -b my-new-feature

# See all branches (* = current)
git branch

# Switch between branches
git checkout main
git checkout my-new-feature

# Push a branch to GitHub
git push -u origin my-new-feature

# When done, merge back to main
git checkout main
git pull
git merge my-new-feature
git push

Bonus: git stash (save work for later)

Sometimes you're in the middle of changes and need to switch branches, but you're not ready to commit yet. git stash saves your work-in-progress temporarily:

# Save your uncommitted changes
git stash

# Switch to another branch, do whatever you need...
git checkout main
git pull

# Come back and restore your saved changes
git checkout my-feature
git stash pop

git stash = tuck your work in a drawer. git stash pop = take it back out. Your changes reappear exactly as you left them.

Why use Pull Requests?

• Code review — Someone else checks your work before it goes live
• Discussion — Teammates can comment on specific lines and suggest improvements
• Safety — Prevents untested code from going directly into main
• History — PRs create a record of why changes were made and who approved them

Creating a Pull Request (step by step)

Step 1: Create a branch and make your changes:

# Create a branch
git checkout -b fix-login-timeout

# Make your changes, then commit
git add server.js
git commit -m "Fix login timeout on slow connections"

Step 2: Push your branch to GitHub:

git push -u origin fix-login-timeout

remote: Create a pull request for 'fix-login-timeout' on GitHub by visiting:
remote:   https://github.com/MercuryInsuranceEI/RepoName/pull/new/fix-login-timeout
To https://github.com/MercuryInsuranceEI/RepoName.git
 * [new branch]      fix-login-timeout -> fix-login-timeout

Step 3: Open the PR on GitHub — click the link in the output, or go to your repo on github.com and click the yellow "Compare & pull request" banner that appears.

Step 4: Fill in the PR details:

• Title: Short description (e.g., "Fix login timeout on slow connections")
• Description: What you changed, why, and anything reviewers should know
• Click "Create pull request"

Reviewing a Pull Request

When a teammate opens a PR, you'll see it on your repo's Pull requests tab on GitHub. To review:

1. Click the PR to open it
2. Go to the Files changed tab to see what was modified
3. Click on any line to leave a comment
4. Click "Review changes" at the top and choose:
   • Approve — looks good, merge it
   • Request changes — something needs fixing first
   • Comment — just a note, no approval/rejection

Merging a Pull Request

Once approved, click the green "Merge pull request" button on GitHub. Then clean up:

# Switch back to main and get the merged changes
git checkout main
git pull

# Delete the old branch (optional but keeps things tidy)
git branch -d fix-login-timeout

What is a merge conflict?

A conflict happens when two people edit the same line of the same file. Git doesn't know which version to keep, so it asks you to choose.

What a conflict looks like

Git marks the conflicting section in the file:

<<<<<<< HEAD
const timeout = 5000;    // Your version
=======
const timeout = 10000;   // Their version
>>>>>>> main

How to fix it

1. Open the file in VS Code (it highlights conflicts for you)
2. Choose which version to keep (or combine both)
3. Delete the conflict markers (<<<<<<<, =======, >>>>>>>)
4. Save the file
5. Stage and commit the fix:

git add server.js
git commit -m "Resolve merge conflict in timeout value"
git push

What is .gitignore?

A .gitignore file tells Git which files to completely ignore. These files will never be tracked, staged, or pushed — even if you run git add .

Example .gitignore

# Credentials - NEVER commit these
.env
servicenow_config.json
jamf_config.json

# Python cache
__pycache__/
*.pyc

# Node.js dependencies (reinstall with npm install)
node_modules/

# Logs
*.log

# OS files
.DS_Store

The example file pattern

Instead of committing real credentials, create example files with placeholder values:

{
  "username": "jsmith",
  "password": "MyRealPassword123!"
}

{
  "username": "YOUR_USERNAME",
  "password": "YOUR_PASSWORD"
}

When a new team member clones the repo, they:

1. Copy the example file: cp servicenow_config.example.json servicenow_config.json
2. Fill in their own credentials
3. The real file is automatically ignored by Git

What if I already committed a secret?

README files

Every repo should have a README.md file in the root folder. This is the first thing people see when they visit your repo on GitHub. It should include:

• What the project does — a one-sentence description
• How to set it up — install steps, dependencies, config files to create
• How to run it — the command to start the app
• Who maintains it — team or person responsible

Example:

# VIP Dashboard

Weekly VIP ticket tracking dashboard for Desktop Engineering.

## Setup
1. Clone the repo: `gh repo clone MercuryInsuranceEI/VIPDashboard`
2. Install dependencies: `npm install`
3. Copy `config.example.json` to `config.json` and fill in your credentials
4. Start the server: `node server.js`

## Maintained by
Desktop Engineering - Steve Cabrera

Opening the Source Control panel

Click the branch icon in the left sidebar (third icon from top), or press:

This opens the Source Control panel, which shows all your changed files. Here's what it looks like:

The GUI workflow (same 4 steps, just visual)

Pulling updates in the GUI

Click the ... (three dots) menu at the top of the Source Control panel and select Pull. Or just click the sync icon (circular arrows) in the bottom-left status bar — this does both pull and push.

Viewing diffs

Click any changed file in the Source Control panel to see a side-by-side diff — the old version on the left, your changes on the right. This is one of the best features of VS Code's Git integration.

Resolving merge conflicts visually

When a conflict happens, VS Code highlights the conflicting sections and gives you clickable buttons:

• Accept Current Change — keep your version
• Accept Incoming Change — keep the other person's version
• Accept Both Changes — keep both
• Compare Changes — see them side by side

Click the option you want, save the file, stage it, and commit. Much easier than editing conflict markers by hand.

Your repo's home page

Go to github.com/MercuryInsuranceEI/RepoName and you'll see:

• Code tab — Browse all files, click into folders, read any file right in the browser
• README — Displayed automatically below the file list (this is why every repo needs one!)
• Branch dropdown — Switch between branches to see different versions
• Green "Code" button — Copy the clone URL

Viewing commit history

Click the "X commits" link (near the top of the Code tab) to see every change ever made:

• Who made each change (author)
• When it was made (timestamp)
• The commit message (what they described)
• Click any commit to see the exact lines that changed (the diff)

This is incredibly useful for understanding "who changed this and why?"

Key tabs on your repo

Quick edits on GitHub

For tiny changes (typos, config updates), you can edit files directly on github.com without cloning:

1. Navigate to the file on GitHub
2. Click the pencil icon (edit) in the top-right of the file
3. Make your change
4. Write a commit message at the bottom and click "Commit changes"

Staying in the loop: Notifications

GitHub can notify you when things happen in your repos:

• Watch a repo: Click the "Watch" button at the top of any repo to get notified of PRs, issues, and comments
• @ mentions: If someone tags you in a comment (@yourname), you get an email and a notification on github.com
• PR reviews: You're automatically notified when someone requests your review
• Bell icon: Click the bell at the top-right of github.com to see all your notifications

Everyday Commands

Setup Commands (one-time)

Branch Commands

What Claude Code can do with Git

• Stage, commit, and push your changes
• Write good commit messages based on what you actually changed
• Pull updates and resolve merge conflicts
• Create branches and switch between them
• Show you what changed and explain diffs
• Set up .gitignore files
• Fix mistakes (undo commits, unstage files, etc.)

Example prompts you can use

Using the /commit shortcut

Claude Code has a built-in shortcut for committing. Just type:

/commit

Claude will automatically:

1. Look at all your changes
2. Write a clear commit message describing what changed
3. Stage the relevant files and commit

You review the message before it's finalized — Claude won't push without your approval.

Tips for working with Claude Code

• Be specific: "Commit just the server.js changes" is better than "commit stuff"
• Ask questions: "What would happen if I push right now?" — Claude can explain before acting
• Let Claude explain: "Explain what git rebase does in simple terms" — great for learning
• Review before pushing: Claude always shows you what it's about to do — read and approve before it runs

"fatal: not a git repository"

What happened: You ran a git command in a folder that isn't a Git repo.

fatal: not a git repository (or any of the parent directories): .git

Fix: Make sure you cd into your project folder first:

cd RepoName
git status    # should work now

"Your branch is behind 'origin/main'"

What happened: Someone pushed changes to GitHub that you don't have yet.

Your branch is behind 'origin/main' by 3 commits, and can be fast-forwarded.

Fix: Just pull:

git pull

"rejected - failed to push some refs"

What happened: You tried to push, but GitHub has changes you don't have locally.

! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'https://github.com/...'
hint: Updates were rejected because the remote contains work that you do not have locally.

Fix: Pull first, then push:

git pull
git push

If the pull creates a merge conflict, see the Merge Conflicts section.

"Permission denied" or "authentication failed"

What happened: Git can't log in to GitHub. Your credentials may have expired.

remote: Permission to MercuryInsuranceEI/RepoName.git denied to yourname.
fatal: unable to access 'https://github.com/...'

Fix: Re-authenticate with GitHub CLI:

gh auth login

Follow the prompts (same as the Account Setup section). If it still fails, check that you've been added to the MercuryInsuranceEI GitHub organization.

"You have divergent branches"

What happened: You and someone else both made commits, and Git doesn't know how to combine them.

hint: You have divergent branches and need to specify how to reconcile them.

Fix: Tell Git to merge (the default, safest option):

git pull --no-rebase

To avoid this message in the future, set the default once:

git config --global pull.rebase false

"Changes not staged for commit" when you try to commit

What happened: You forgot to git add before committing.

nothing added to commit but untracked files present (use "git add" to track)

Fix: Stage your files first:

git add filename.js
git commit -m "Your message"

The nuclear option: start fresh

If everything is completely broken and you just want a clean slate:

# Go up one directory
cd ..

# Delete the broken folder (WARNING: you lose un-pushed local changes!)
rm -rf RepoName        # Mac / Git Bash
rmdir /s RepoName      # Windows CMD

# Clone fresh from GitHub
gh repo clone MercuryInsuranceEI/RepoName
cd RepoName