AEM 6850

Empirical Methods for Applied Economists

Prof. Ariel Ortiz-Bobea

7 · Version control with git

Tuesday, September 15, 2026

Objectives

By the end of this session you can:

• Explain what a repository is: a folder whose history git records, with one copy on your laptop and one on GitHub.
• Create a repository on GitHub and copy it to your laptop as an RStudio project.
• Save a change into the history: edit a file, git add it, git commit it with a message, and git push it to GitHub.
• Bring a change made on GitHub down to your laptop with git pull.
• Read git status and tell whether a change is only on disk, staged for the next commit, or already committed.
• Read a diff and say what changed, including a change a coding assistant made.
• Undo: throw away an edit, unstage a file, fix the message of your last commit.
• Explain what a branch and a pull request are.

Plan for today

1. Why version control
2. A repository is a folder plus a timeline
3. Two copies: your laptop and GitHub
4. One change, from your editor to GitHub
5. Choosing what a snapshot contains
6. Undoing at each place
7. Pull, and the push that is refused
8. Branches, pull requests, and what stays out of a repository

A folder without version control

analysis_v1.R
analysis_v2.R
analysis_FINAL.R
analysis_FINAL_v2.R
analysis_REALLY_FINAL.R
analysis_FINAL_USE_THIS.R

• Which one made Table 2?
• What changed between FINAL and FINAL_v2?
• Which one still runs?

Everyone has this folder. The cost is not the clutter. It is that you made a choice somewhere in there that you cannot reconstruct.

Three questions version control answers

• What did I change since the version that worked? You, four months later, when a coefficient moved.
• What exactly did this edit change? A coauthor, or a tool that writes forty lines in ten seconds, hands you a file. The change is what you review, not the file.
• Who changed this line, when, and why? Two people, one script, no emailing of paper_v3_jane_edits.R.

The second one is why this matters more this year than last. When something else writes code for you, the difference between before and after is the only thing you can actually check.

What a coding assistant’s edit looks like

A coding assistant (Copilot, ChatGPT, Claude) was asked to add one check to a three-line script. This is what it did.

 # analysis.R -- days above the PM2.5 standard
-STANDARD <- 35
+STANDARD <- 9
 pm <- read.csv("data/epa_pm25_la_fires_2024_2025.csv")
+stopifnot(nrow(pm) > 0)

• You asked for the last line.
• Nobody asked for the -/+ pair in the middle: 35 became 9.
• What did the assistant change? That is the question for the rest of the day.

By “the model” I mean the assistant; some of you have not used one yet. Green is added, red is removed. Git prints three more lines above this; they come when we run a diff ourselves. You asked for a check; you also got a different air-quality standard. Nine is a real EPA number, the annual one. A model that corrects your constant is not being malicious; it is being confident. This picture does not care about confidence. You read your first one of these in ten minutes.

git and GitHub are two different things

	git	GitHub
What	a program on your laptop	a website
Does	takes and keeps snapshots of a folder	keeps a copy of the snapshots and shows them in a browser
Needs the internet	no	yes
You have used it	not yet	once: add my intro, before class

Every commit you have made so far, GitHub made for you. Today you make them yourself, and you see what the button was doing.

A repository is a folder plus a timeline

A repository is a folder plus a timeline of snapshots. Every git command either moves a change toward that timeline, or copies the timeline between your laptop and GitHub.

Left is the folder you already know: git-practice, one file, README.md. Right is the part that is new: a line of snapshots, oldest to newest, each with a message. Two of them, and you made the second. Each snapshot is the whole folder at one moment, a photo of the desk, not a list of what moved; git works out the difference between any two when you ask. The timeline is stored inside the folder, in a hidden subfolder called .git. Folder plus timeline. That is a repository. Next: where those two snapshots came from.

Make a repository

• github.com → + → New repository. Name git-practice. Private. Tick Add a README file. Create repository.
• One file, one snapshot. GitHub wrote Initial commit. A repository is born with a timeline of length one.
• Pencil on README.md → one line → Commit changes… → message add my intro. Two snapshots. You did exactly this before class.

Live, on my own account: Before class step 5 with the words on. Watch the front page after Create: one file, and a link that says 1 Commit. GitHub photographed a folder with one file in it and wrote the caption. Then the pencil, the line, Commit changes, my own caption: the second photo. That click is the only git you have used so far, and it was git. Next three slides: this repository, three ways.

Your repository on GitHub

1. Name — owner / repository
2. Files — README.md, the only file
3. main — the timeline’s name
4. 2 Commits — two snapshots
5. Code — where a copy comes from

The repository we just made, on its front page; reload the live page, the screenshot is the fallback. Yours looks the same. The name is the owner, a slash, the repository: your username, then git-practice. Every repository starts with one timeline, and it is called main. You clicked the green button before class, for the address. Everything you have done with this page so far treated it as a folder on a website. Item 4 is what makes it not a folder.

The history: the Commits page

• Message: add my intro. The only part a human wrote.
• Author and when: your username, the date.
• Hash: seven characters of a forty-character ID.
• <>: the whole folder as it was then.

Newest on top. Two snapshots. The bottom one GitHub made a minute ago, when the repository was created, and GitHub wrote its message. The top one is yours: the pencil, the line, Commit changes. That click took a snapshot and wrote your message on it. From now on you write every one.

One commit, opened: the diff

• +2 −1 — two lines added, one removed
• red - / green + — the line as it was, as it is
• @@ — where in the file
• a diff — two snapshots, line by line. Spot the difference.

This is the most important picture of the day. A commit is a photo of the whole folder, not a note about what moved. GitHub shows the difference from the photo before, because the difference is what a person can read: spot the difference between two photos. Read this one. The title line shows once red and once green: nobody edited it; the file had no line ending, adding a line below gave it one, and git shows the old line and the new. Then the line you added. Yours says the same, or +1 if your editor kept the ending. Say what changed, then ask whether you meant it. The title pair you did not mean, and it is harmless.

How to read a diff

--- a/analysis.R
+++ b/analysis.R
@@ -1,3 +1,4 @@

• --- a/ is the old version, +++ b/ the new.
• @@ ... @@ says where in the file. You rarely need the numbers.
• A changed line shows as one - and one +. Read them as a pair. A pure addition is + alone.
• Read every - first. A removal you did not ask for is the dangerous one.
• Ask of every diff: is this the change I meant, and only that?

Rule four is the one to remember. Additions are usually what you asked for. Removals are where the surprises hide.

Local and remote: two copies of one timeline

• Clone makes the first copy, once. Git calls the copy it came from origin.
• Push hands your new snapshots to GitHub. Pull brings GitHub’s down.
• Not Dropbox. Nothing moves until you type push or pull, and git status never looks at GitHub.

Two albums: yours and the shared one. Photos move only when you hand them over, push, or ask for them, pull. A pencil edit in the browser is a photo in the shared album; nothing arrives on your laptop until you pull. Name the thing everyone is picturing: this is not Dropbox. That is a feature, and it is the one that will surprise you at least once today.

The address of a repository

• The URL is the repository’s address. Every clone, push and pull uses it.
• It ends in .git. That is part of the address, not the hidden folder.
• Use the HTTPS tab, not SSH and not GitHub CLI. The token from Before class is what makes HTTPS work.

Clone into an RStudio project

• File → New Project → Version Control → Git. Paste the URL. Subdirectory: Browse… to github.
• Create Project runs one command, git clone. The clone lands in github/git-practice.
• The .Rproj marks the top folder; R reads paths from there.

Live: paste the address, Browse to the github folder, Create Project. Clone means: download the whole album, and remember which shared album it came from. The dialog is a wrapper on one command, git clone and the address, which every tutorial and every AI assistant will tell you to type; it is printed on the page. You did this before class; do not do it again now, RStudio refuses a folder that exists. And notice: the folder can land anywhere on your disk. Your scripts still run, because the .Rproj marks the top folder and R reads paths from there.

The Terminal tab and the Git pane

• Tools → Terminal → New Terminal. The prompt shows the project’s name, then % or $. Type after it, press Enter.
• The Git pane top-right shows the same state. Watch it, do not click it, for now.
• For the next ten minutes, watch. You type in the exercise.

Everything from here is typed at that prompt. The Git pane is a window onto the same state; it changes every time we run something. For the next ten minutes, watch. You do all of this yourself in the exercise, with the slide on screen.

git status: where things stand

git status
#> On branch main
#> Your branch is up to date with 'origin/main'.
#>
#> Untracked files:
#>   (use "git add <file>..." to include in what will be committed)
#>         .gitignore
#>         git-practice.Rproj
#>
#> nothing added to commit but untracked files present (use "git add" to track)

Lines without #> you type. Lines with #> are what git prints.

• Line 1: the branch. Line 2: yours versus GitHub’s (origin).
• Untracked: git sees the file; the timeline never has. .gitignore lists files git should never track (last slide).
• The parentheses name the command that moves each file: the manual.

status is the one command that can never hurt you. It reads, it never writes. When you are lost, type it. Git’s word for a timeline is branch; you have one. origin is git’s name for GitHub’s copy.

git log –oneline: read the timeline

git log --oneline
#> 6a952cb (HEAD -> main, origin/main, origin/HEAD) add my intro
#> 6a25190 Initial commit

• One line per snapshot, newest first: the ID, then the message. Same two hashes as the Commits page.
• HEAD -> main: where you are. origin/main: where GitHub’s copy is. Same place, for now. origin/HEAD: the branch GitHub opens by default. Ignore it.
• If the screen fills and the prompt disappears, that is the pager. Press q.

This is the folder-plus-timeline picture from slide 8, as text. The verb for ‘show me the timeline’ is log. Same hashes as the browser: that is the proof a clone is the timeline, not a download.

Exercise 1

• Exercise
• Solution

# Exercise 1 (7 minutes). Your git-practice repository, on your laptop.
#
# 1. Save any open scripts first: switching projects restarts R
#    and empties the Environment. Then open the project you cloned
#    before class: File > Recent Projects > git-practice.
#    Not cloned before class? Use the browser path under this box now;
#    clone tonight with Before class step 5, and bring the laptop to
#    office hours if it still fails.
#
# 2. Tools > Terminal > New Terminal, then:   git log --oneline
#    How many commits? Which one did you make in the browser?
#
# 3. git status
#    Under which heading are the two files RStudio made?
#
# Two answers to compare with the room: the number of commits, and the
# heading the two RStudio files sit under.

git log --oneline
#> 6a952cb (HEAD -> main, origin/main, origin/HEAD) add my intro    # your hashes differ
#> 6a25190 Initial commit
git status
#> On branch main
#> Your branch is up to date with 'origin/main'.
#>
#> Untracked files:
#>   (use "git add <file>..." to include in what will be committed)
#>         .gitignore
#>         git-practice.Rproj
#>
#> nothing added to commit but untracked files present (use "git add" to track)

Two commits; both RStudio files under Untracked files.

Debrief (1 min). Three or four commits: they edited the README more than once in the browser, or committed the RStudio files before class. Fine; the count is theirs. Only the .Rproj listed: RStudio did not write a .gitignore on that laptop; one file, same heading.

When it fails, say:

• Repository not found or a password prompt: the token did not take, or the username in the URL is wrong. Browser fallback now, Before class step 4 again tonight; no laptop is debugged during class.
• RStudio says git is not found, or there is no Git pane: Tools → Global Options → Git/SVN, the Git executable box (Before class step 2). Browser fallback now.
• The Terminal prompt does not end in the project name: Tools → Terminal → New Terminal opens a fresh one inside the project.
• The screen fills and the prompt is gone: the pager. q.
• git: 'stauts' is not a git command: a typo; git suggests the nearest command on the next line.

Three places a change lives

A change is in exactly one of three places on your laptop. Think of a camera. The working folder is your desk as it is right now: the files as you see them in RStudio. The staging area is what you have put in the frame. git commit -m presses the shutter: one photo of the whole folder, with a caption on the back. History is the album. Two verbs move a change to the right: add, then commit. diff is desk against frame; diff --staged is frame against the last photo, what the shutter will see. status looks at all three and touches nothing. The fourth column is not on your laptop: push hands the new photos to the shared album on GitHub, pull brings down the ones you do not have, and status never looks there. That is the whole model. Every command in the next ten minutes is one arrow on this picture. Same rule as before: watch now, type in the exercise.

Edit a file: git status

git status
#> ...
#> Changes not staged for commit:
#>   (use "git add <file>..." to update what will be committed)
#>   (use "git restore <file>..." to discard changes in working directory)
#>         modified:   README.md
#>
#> Untracked files:
#>         .gitignore
#>         git-practice.Rproj

• modified: a file the timeline knows, changed on disk. On the desk and nowhere else. (...: lines seen on an earlier slide.)
• The two untracked files are still listed. Git names everything undecided, every time, and does nothing about it.
• The hints name the verb for each move. Git pane: a blue M beside the two yellow ?.

Live: in RStudio open README.md, add the line I cloned this repository to my laptop. at the end, save. Then git status. One change, one place. Nothing is in the frame yet, nothing is in the album. Read the hints: git prints the verb for each move right next to the file. The page shows one more hint line with -a in it; ignore -a today, it skips the step we are here to learn.

git diff: what changed in the working folder

git diff
#> diff --git a/README.md b/README.md
#> index 863ff77..57434f7 100644
#> --- a/README.md
#> +++ b/README.md
#> @@ -1,2 +1,3 @@
#>  # git-practice
#>  Ariel Ortiz-Bobea, Dyson School, Cornell.
#> +I cloned this repository to my laptop.

• Start reading at ---; the two lines above are bookkeeping. Two lines of context, then one + and no -.
• Say it in one sentence: one line added, none removed, at the end of the file. That sentence is the whole review.
• In the Terminal git colours - red and + green; the slide cannot, so read the first character of each line.

diff is the desk against the frame. Nothing is in the frame, so the frame equals the last photo, and this is everything that changed since that photo. Read it once, out loud: one line added, none removed, at the end of the file. If you cannot say that sentence about a diff, do not commit it.

git add: put a change in the frame

git add README.md
git status
#> ...
#> Changes to be committed:
#>   (use "git restore --staged <file>..." to unstage)
#>         modified:   README.md
#>
#> Untracked files:
#>         .gitignore
#>         git-practice.Rproj

• add prints nothing. Silence is success.
• Changes to be committed: the staging area. README.md is in the frame; the two untracked files are not, because you did not name them.
• Nothing is permanent yet. The hint names the undo for this step. Git pane: the Staged box beside README.md is ticked.

The verb for “this goes in the next photo” is add. You name the file. Naming files is the habit that keeps data out of a repository: a file you never name never gets in. Nothing has been photographed; the frame is set, that is all.

git commit: take the snapshot

git commit -m "Note the clone in README"
#> [main 8dd074b] Note the clone in README
#>  1 file changed, 1 insertion(+)
git status
#> On branch main
#> Your branch is ahead of 'origin/main' by 1 commit.
#>   (use "git push" to publish your local commits)
#> ...

• -m is the caption. Every commit has one. It says why.
• The receipt: the timeline, the new ID, what went in. One file, one line: the diff, counted.
• Ahead of origin/main by 1: your timeline is one photo longer than GitHub’s.
• Forgot -m? A screen asks for the caption: Esc, :q!, Enter backs out (Windows: close Notepad); then -m.

Press the shutter. The receipt has the hash and a count of what changed; if the count ever surprises you, you skipped the diff. Status now says two things: nothing pending on the desk except the two files we never framed, and GitHub is behind by one. That second line is the cue for the next command. The page shows the screen you get when you forget -m.

git push: send your snapshots to GitHub

git push
#> Enumerating objects: 5, done.                  # progress lines vary
#> ...
#> To https://github.com/ArielOrtizBobea/git-practice.git
#>    6a952cb..8dd074b  main -> main
git status
#> On branch main
#> Your branch is up to date with 'origin/main'.

• push hands GitHub every photo it does not have. The last line reads from this hash to that hash.
• Ahead of origin/main is gone. GitHub now shows exactly what git log shows.
• This is the Commit changes button, from the other side. One click before class; three steps now, each one read.

Before class the browser took the photo and put it straight in the shared album, in one click. Now you framed it, pressed the shutter, and handed it over, and you could read each step before taking the next. From now on, push is how work leaves your laptop.

GitHub after the push

Three commits, and the README ends with your line: what git log shows, in the browser.

Reload. (Reload the real page live; the screenshot is the fallback if the wifi is slow.)

Exercise 2

• Exercise
• Solution

# Exercise 2 (9 minutes). In your git-practice project, Terminal tab,
# browser open on your repository.
#
# 1. Open README.md in RStudio. Add one line at the end:
#      My first commit from the terminal.
#    Save.
#
# 2. git status. Under which heading is README.md?
#    (The two RStudio files stay untracked; Practice 1 commits them.)
#
# 3. git diff. How many added lines (a single + at the left edge,
#    green)? (If the prompt disappears, press q.)
#
# 4. git add README.md
#    git commit -m "First commit from my laptop"
#    Read the second line of the reply.
#
# 5. git push
#    Then reload your repository's page on GitHub. How many commits?
#
# Two answers to compare with the room: the second line of git commit's
# reply in step 4, and the commit count after step 5.

git status
#> ...
#> Changes not staged for commit:
#>         modified:   README.md
#>
#> Untracked files:
#>         .gitignore
#>         git-practice.Rproj
git diff
#> diff --git a/README.md b/README.md
#> ...
#> +++ b/README.md
#> ...
#> +My first commit from the terminal.
git add README.md
git commit -m "First commit from my laptop"
#> [main <new>] First commit from my laptop      # your hash differs
#>  1 file changed, 1 insertion(+)
git push
#> ...
#>    <old>..<new>  main -> main                  # your two hashes

1 file changed, 1 insertion(+); 3 Commits on the front page.

Debrief (1 min). One file, one commit, one push: your snapshot went up, and the browser shows it. The two RStudio files are still untracked; git does not nag, and Practice 1 commits them. The message on top of your log is one you wrote. The other half of the loop, a snapshot coming down, comes after the next pass; Practice 7 is where you do it.

When it fails, say:

• nothing to commit after git add: the file was never saved in RStudio.
• A screen of text and no prompt after git commit: they forgot -m. Esc, :q!, Enter, then git commit -m "…" (Notepad: close the window empty).
• *** Please tell me who you are.: Before class step 3 was skipped. In the same Terminal: git config --global user.name "Your Name" and git config --global user.email "you@cornell.edu", then run the commit again.
• A paragraph starting Your name and email address were configured automatically: the commit went through under a made-up address. Run the two git config --global lines; the next commits carry your name. Leave this one alone.
• git push asks for a username and password: stop here. Your commit is safe on the laptop and pushes once the token is stored (Before class step 4 tonight). Press Ctrl+C if the prompt is still waiting. Do not type your GitHub password; it fails with Authentication failed.
• A browser sign-in window opens during git push (Windows): that is the credential manager; sign in once and the push continues.
• ! [rejected] … (fetch first): they edited in the browser earlier today. git pull, then git push: shown a few slides on. If an editor screen opens, keep the message (Esc, :wq, Enter; Notepad: close the window).
• fatal: Need to specify how to reconcile divergent branches.: Before class step 3 was skipped: git config --global pull.rebase false, then git pull again.

A new file: git diff –staged

git add analysis.R
git diff --staged
#> diff --git a/analysis.R b/analysis.R
#> new file mode 100644
#> index 0000000..a3eb8fb
#> --- /dev/null
#> +++ b/analysis.R
#> @@ -0,0 +1,3 @@
#> +# analysis.R -- days above the PM2.5 standard
#> +STANDARD <- 35
#> +pm <- read.csv("data/epa_pm25_la_fires_2024_2025.csv")

• A new file is untracked, and untracked files are not diffed. status lists it; add frames it.
• diff --staged: the frame against the last photo, the next commit exactly. /dev/null is the old version of a file that did not exist.
• Read --staged before every commit: what the shutter will see.

Live: File → New File → R Script, paste the three lines of analysis.R from the clipboard, never typed, Cmd+S, name it analysis.R in the project. git status lists it under Untracked with the other two; git diff shows nothing for it, because there is no old version. Stage it, then look at the frame. diff is the arrow between columns one and two; diff --staged is the arrow between two and three. The second one is the last look before you press.

git commit: one change per commit

git commit -m "Add analysis.R with the standard"
#> [main 4977c8d] Add analysis.R with the standard
#>  1 file changed, 3 insertions(+)
git add .gitignore git-practice.Rproj
git diff --staged
#> ...
#> +.Rproj.user
#> +.Rhistory
#> +.RData
#> +.Ruserdata
#> ...                                     # the .Rproj: fourteen lines of settings

• One file, three lines: the last diff, counted.
• The two RStudio files, as their own commit. .gitignore is four patterns: files git should never track (last slide).
• Two logical changes, two photos. If a caption needs the word “and”, it is two.

analysis.R first, alone. Then the two RStudio files together: they are one logical change, the project’s scaffolding. Look at what is in the frame before pressing: four patterns and fourteen lines of settings, nothing else, and now you have read the mystery file with the yellow question mark. Yours stay untracked until Practice 1; nothing breaks in the meantime.

The timeline so far, and the second push

git commit -m "Add the files RStudio made for the project"
#> [main 7c91799] Add the files RStudio made for the project
#>  2 files changed, 18 insertions(+)
git log --oneline
#> 7c91799 (HEAD -> main) Add the files RStudio made for the project
#> 4977c8d Add analysis.R with the standard
#> 8dd074b (origin/main, origin/HEAD) Note the clone in README
#> 6a952cb add my intro
#> 6a25190 Initial commit
git push
#> ...
#>    8dd074b..7c91799  main -> main

• Five photos. HEAD -> main is where you are; origin/main sat two below it until the push.
• Read the captions bottom to top and you have the story of the project. That only works if the sentences say something.

Same commands, three times now. It will be the same commands in December. Read the captions bottom to top: the diary of this project. The page has a table of captions that say why and captions that say nothing. And say the picture back to me: save puts a change on the desk, add frames it, commit presses the shutter, push hands the photo over.

The assistant edited your script: read the diff

git status
#>         modified:   analysis.R
git diff
#> diff --git a/analysis.R b/analysis.R
#> index a3eb8fb..816aaff 100644
#> --- a/analysis.R
#> +++ b/analysis.R
#> @@ -1,3 +1,4 @@
#>  # analysis.R -- days above the PM2.5 standard
#> -STANDARD <- 35
#> +STANDARD <- 9
#>  pm <- read.csv("data/epa_pm25_la_fires_2024_2025.csv")
#> +stopifnot(nrow(pm) > 0)

• Asked for: the stopifnot. Got: that, and a different standard.
• The - line is the tell. Read removals first.
• The transcript says what was meant. The diff says what happened.

This is the diff from slide 6, in my own repository, twenty seconds after the edit. Live: change the 35 to a 9, add the stopifnot line, save, then git status and git diff. Nobody found it by reading the transcript, because there is no transcript. There is a diff.

git restore: discard the edit

git restore analysis.R
git status
#> On branch main
#> Your branch is up to date with 'origin/main'.
#>
#> nothing to commit, working tree clean

• restore puts the file back to what is staged; nothing is staged, so that is the newest snapshot. No output, then clean. Look at the editor: RStudio reloads the file, the edit is gone.
• Destructive. Edits never committed are gone for good. Run git diff first, every time, so you know what you are deleting.

Put the desk back the way the last photo shows it. That is the undo slide 6 promised, and it took ten seconds. Then you redo the one good line by hand; the page shows it, after the pull section.

Three undo verbs, one per place

The change is in	To undo	Command
the working folder	put the desk back to the last photo; the edit is gone	git restore <file>
the staging area	take it out of the frame; it stays on the desk	git restore --staged <file>
the last commit, not pushed	rewrite the caption, before it reaches the shared album	git commit --amend -m "…"

<file> is the file’s name, no brackets: git restore analysis.R.

One undo per column. The first row you just watched. restore is the one that destroys; git only remembers what you photographed. restore and restore --staged share a word: read the line back before Enter. --staged keeps your edit; no flag throws it away. Amend only before you push. Anything else, stop and ask. The other two rows are on the page and in the practice set.

A commit made on GitHub

• The pencil and the upload button both make a snapshot on GitHub’s copy.
• GitHub wrote Update README.md. A message nobody chose, again.
• Your laptop does not know yet.

Live, on GitHub: click README.md, then the pencil. Add the line Edited in the browser. at the end. Click Commit changes…, keep the default message Update README.md, leave Commit directly to the main branch selected, click Commit changes. This is the coauthor, or the other laptop, or the upload button. GitHub’s copy is one snapshot ahead of mine, and mine has no idea.

git pull: bring GitHub’s snapshots down

git status
#> ...
#> nothing to commit, working tree clean
git pull
#> ...
#> From https://github.com/ArielOrtizBobea/git-practice
#> Updating 7c91799..a7c1838
#> Fast-forward
#>  README.md | 1 +
#>  1 file changed, 1 insertion(+)

• git status said up to date and was wrong. status never asks GitHub.
• pull downloads what GitHub has that you do not, and applies it. Fast-forward: GitHub’s album was yours plus one photo, so git added it to the end of yours.
• Open README.md in RStudio: the line is there. Pull when you sit down, push when you stand up.

A commit made in the browser, on your other laptop, or by a coauthor comes down the same way. Then you read it: git log --oneline has a line you did not write.

When push is refused

git push
#> To https://github.com/ArielOrtizBobea/git-practice.git
#>  ! [rejected]        main -> main (fetch first)
#> error: failed to push some refs to 'https://github.com/ArielOrtizBobea/git-practice.git'
#> hint: Updates were rejected because the remote contains work that you do not
#> hint: have locally. This is usually caused by another repository pushing to
#> hint: the same ref. If you want to integrate the remote changes, use
#> hint: 'git pull' before pushing again.

• GitHub has a photo you do not: a browser edit, a coauthor, your other laptop. Each album has one the other lacks.
• The fix is two words: pull, then push. Git may open an editor for a message; keep the suggested one.
• If pull says CONFLICT: stop and ask. Rare in a solo project, and not a disaster.

Anyone who edits in the browser one day and pushes from the laptop the next meets this line. Read it; it names its own fix: pull, then push.

A branch is a second timeline

• A branch starts at a snapshot and grows its own snapshots. main keeps working while you experiment.
• Merge joins the branch back. Delete it instead and main never knew.
• analysis_v2.R, done right: the experiment lives beside the working version. Solo, rarely: an experiment, a rewrite, anything a coauthor should read first.

The timeline can fork. Nothing on the branch touches main until you merge. This is the folder from slide 4 without the file names: the experiment gets its own line, and when it works you merge it instead of renaming it FINAL. You will not need this for homework. You need to recognise the word when a coauthor or a tool makes one.

A pull request is a merge with a review attached

• A manuscript under review. The branch is the submission; comments on lines are the referee’s; Merge pull request is the editor’s accept. Only then does it land on main.
• Not git pull. git pull downloads the issue after it is out. A pull request proposes, and waits for a person.

GitHub’s feature, not git’s, and the way most code written by more than one person gets reviewed. You will not open one for homework; you need the word when a coauthor or a tool does. Shared word, opposite ends of the process.

.gitignore: what git should not track

# Data is downloaded by your script; never upload it.
data/

# R session artifacts
.Rhistory
.RData
.Rproj.user/

• The do-not-photograph list. A file on it never reaches the frame, the album, or GitHub. Data goes on the list; the script that downloads the data goes in the album.
• One pattern per line; a trailing / is a folder and everything in it. An ignored file never appears in git status.
• .gitignore is itself committed, so every clone gets the same rules. RStudio wrote the four-line one I committed; yours sits in the Git pane with a yellow ? until Practice 1.

This is why a reader can clone a repository and rebuild everything: the data is not in the timeline, the script that fetches it is. Data lives in data/ inside the project, and this file keeps it out of the album. And one rule with no command: never keep a repository inside Dropbox, iCloud Drive, OneDrive or Google Drive.

Practice

Ten exercises on the session page, with solutions behind a click. All of them run in your git-practice clone or a sandbox repository you make — never in a homework repository.

• 1–3 The loop: add, commit, push, and stage only part of a change
• 4–6 Undoing: discard, unstage, amend
• 7–8 Pull and read: a browser commit, and the push that is refused
• 9–10 A new project with its .gitignore; an assistant’s diff, printed

Terms: the repository and its copies

Term	One line
repository	a folder plus its timeline of snapshots; the timeline lives in the hidden .git
commit, snapshot	one photo of the whole folder, with a caption, an author and a hash
commit message	the caption: one sentence that says why
hash	the photo’s serial number; seven characters are enough to name it
diff	two snapshots side by side, spot the difference: - as it was, + as it is
branch, main	git’s word for a timeline; every repository starts with one, called main
HEAD	where you are on the timeline
local, remote, origin	your copy; a copy elsewhere; git’s name for the GitHub copy it was cloned from
clone	download the whole album and remember where it came from
push, pull	hand your new photos to the shared album; bring down the ones you lack
fast-forward	a pull that only had to add GitHub’s new photos to the end of yours
rejected push	GitHub has a photo you do not; pull, then push

Terms: a change and its places

Term	One line
working folder	the desk: the files as you see them in RStudio; git says working tree
staging area	the frame: what the next snapshot will include, each file as it was when you typed add
untracked	a file git sees that the timeline has never had
modified	a tracked file that differs on disk from the newest snapshot
staged	in the frame; part of the next commit
clean	the desk matches the newest photo; nothing pending
discard, unstage, amend	put the desk back to the last photo; take a file out of the frame; rewrite the last caption, before pushing
merge	join a branch back into the one it came from
pull request	a merge proposed on GitHub with a review attached; not git pull
merge conflict	two snapshots changed the same line; git stops and asks you to choose
.gitignore	the do-not-photograph list; a file on it never reaches the frame, the album, or GitHub
token, pager	what GitHub accepts from a program instead of a password; the screen for long output, q leaves it

Every word from today, in the picture we used all hour. The same table, with a link to the section that defines each one, is on the page under Quick reference.

Quick reference

A repository is a folder plus a timeline of snapshots. Every git command either moves a change toward that timeline, or copies the timeline between your laptop and GitHub.

Every command from today, one line each, on the session page — with the four-places picture next to it, the things that bite, and every term with a link to the section that defines it.