Version Control with Git & GitHub

The Plan

• The problem version control solves, and what it buys you
• The core loop of edit, stage, commit, and push, shown three ways
• Why a research paper is really a repository

You Already Have a Version Control System

You may have used one that looks like:

analysis.R
analysis_v2.R
analysis_final.R
analysis_final_FINAL.R
analysis_final_revised(3).R

What Version Control Buys You

• History — every saved version is kept, with a note on what changed and when
• Undo — roll back to any past state when today’s idea turns out worse
• Collaboration — several people edit the same project without clobbering each other
• Backup — pushed to the cloud

Git vs. GitHub

They are two different things, and the names blur together.

• Git does the tracking, locally, with or without the internet
• GitHub is a place to store a copy, share it, and collaborate

The Mental Model

A change moves through four places:

working dir → staging → commits → remote
 (edits)      (marked)   (saved)  (GitHub)

• Working directory — your files as you edit them right now
• Staging area — the changes you have marked to go into the next snapshot
• Local repo — the committed history, saved on your machine
• Remote — the copy on GitHub that others can see

A Commit Is a Labeled Snapshot

• A commit records the state of your staged files at a moment, with a message
• Think of it as a save point you can name and return to
• The message is a note to your future self: what changed and why
• The history is a chain of these snapshots, newest on top

Writing a Good Message

• The message is the part of git most people do worst, and it matters most later
• Say what changed and why, not “stuff” or “update”
• Present tense, one line, specific enough to skim in a list six months on

Good:  Add robust SEs to the wage regression
Bad:   updates

Way A: The Command Line

The same four steps as typed commands.

git add 03_estimation.r   # stage one file
git commit -m "Add robust SEs"   # snapshot
git push                  # send to GitHub
git pull                  # get others' commits

• git status shows what is staged, changed, or untracked — run it constantly
• This is the most direct view of what git is doing, and the most portable

Way B: RStudio’s Git Pane

RStudio has git built in — no terminal needed.

• A Git tab appears in the top-right pane when your project is a repo

• Stage a change by checking its box

• Click Commit, type a message in the dialog, confirm

• Push and Pull are buttons with up/down arrows

• Same loop, same words (stage, commit, push), just with checkboxes

Way C: GitHub Desktop

A standalone app, fully graphical, for when you want no terminal at all.

• Shows your changes as a readable list with the exact lines added and removed
• Type a commit message in a box, click Commit to main
• One button to Push origin, one to Pull

Which One Should You Use?

• Pick one to start.
• Learn a little command line eventually — it demystifies the buttons

Starting from an Existing Project

To get a copy of a repo that already exists, clone it.

git clone https://github.com/you/project.git

• Cloning downloads the whole project and its full history

Pull Before You Push

• When you collaborate, the remote moves without you — someone else pushed
• Always pull their commits before you push yours

git pull      # get their changes, merge them in
git push      # now send yours

What to Commit, and What Not To

• Commit: code, scripts, main.r, the manuscript source, the README
• Do not commit: raw data, large outputs, R artifacts like .Rhistory
• .gitignore (from W6) lists what to leave out, so it never gets staged by accident

Branches, Lightly

• A branch is a parallel line of work that does not disturb main
• Try a risky change on a branch; if it works, merge it back; if not, throw it away

git switch -c try-idea   # new branch + switch
# ... edit, commit ...
git switch main          # main untouched

• For solo assignments you can live on main and be fine

Recap

• Git tracks versions locally; GitHub hosts a shared copy in the cloud
• The loop is always edit → stage → commit → push, with a message that explains the change