graph LR
A[Edited<br>Files] -- "git add" --> B(Staged<br>Changes)
B -- "git commit" --> C[(Local<br>Repository)]
Why we use code and why we should use version control
January 21, 2026
Applied Economics Analysis
Instructor
TA
What is your name?
Where are from?
What do you think your field in economics will be?
A fun one:
Prepare you with practical skills for 2nd year on.
Replication 1
Final Project and Presentation
Replication 2
I will give more information on each of these assignments later.
One “problem set” (really, a coding exercise) due each week.
These will be due:
The goal is to…
The first assignment is due next class.
The goal for lectures:
Lecture
In class activity or coding exercise
Lecture
Live coding example
This will adjust depending on the topic being covered.
Please bring your computers to class!
You will fill out a survey at the end of each lecture.
These will ask some questions about…
These are not graded, but filling them out counts as your participation grade.
If you miss class, do not fill out the survey.
All of the material for this course lives on a course website.
I will be updating the website throughout the course.
Link on Canvas and on my website.
Why do we program instead of simply open Excel, highlight the right data, hit the “regress” button?
Many reasons, but a main one…
Programs are reproducible documents of the steps we took and decisions we made.
Reproducibility is becoming more and more important in economics.
Reproducibility: same data \(\implies\) same results
Replicability: new data \(\implies\) same results
I will be using these terms interchangeably, but we are focused on reproducubility, specifically computational reproducibility.
More categories and desription in A framework for evaluation reproducibility and replicability in economics (2023), Dreber, Anna, Magnus Johannesson.
Writing reproducible code allows
others to trust your results.
you to know what you did six months ago.
Code keeps a reproducible state of our current project.
But what about the decisions we made before hand?
What if we decide we preferred the model we ran 6 months ago?
One solution: make copies of all your files with “_vXX”
Better solution: use version control
Version control keeps track of files at different states (“commits”),
by storing the differences between the file in one “commit” and the next.
This allows us to
graph LR
A[Edited<br>Files] -- "git add" --> B(Staged<br>Changes)
B -- "git commit" --> C[(Local<br>Repository)]
git add: select which edited files to include in the next commit
git commit: save staged changes as a new commit in the repository
Once you have some commits, you can view the history of your repository.
And we can look at the difference between the current version of the file, and any of the saved commits.
The changes from the “Updated data source” commit:

Git: version control stored on your computer
GitHub: version control stored online
We will be using GitHub extensively in this course.
All of your problem sets will be submitted on GitHub.
Your final project will be a GitHub respository,
and will be graded in part by its commit history.
And we will see how GitHub also makes it easy to host websites.
From now on, think of Git and GitHub grouped together.
We won’t use one without the other.
Partner with someone near you
Navigate to Grant McDermott’s GitHub page: https://github.com/grantmcdermott
Explore a commit history on one of his repositories
Be prepared to share with the class one commit
graph LR A[(GitHub<br>Repository)] -. "git clone" .-> B[(Local<br>Repository)] subgraph Local Computer B[(Local<br>Repository)] end
This is the process you will be using for your homework assignments. I will show an example at the end of class.
Once you edit a file, Git will notice a change.
I edited my previous script “run_regressions.R” and added “new_script.R”.
Once you are at a point to commit, first you stage your changes.
This allows you to select the changes you wish to commit at this time.

You always have to write a message with every commit.
They also have a character length limit, so they have to be short.
But try to make them useful!
Don’t use:
Do use:
Here’s one for our example:
Remember, you will be looking back at your Git messages, so try to write something helpful!
Then you hit “commit”!
And a new commit is added to the history.
Now that you have a new commit you can push it to GitHub.
You can push after one or multiple local commits.
graph LR subgraph Local Computer A[Edited<br>Files] -- "git add" --> B(Staged<br>Changes) B -- "git commit" --> C[(Local<br>Repository)] C --> A end C -- "git push" --> D[(GitHub<br>Repository)]
Always track:
Sometimes track:
Never track:
For files you do not want Git to track, use a .gitignore file.
Simply a text file named .gitignore in your project folder.
When you initialize Git in a folder,
.git folder is createdWhen you commit changes,
Think: “If I had to explain what I just did to someone, would it be one clear sentence?”
A tour of github.com
Showing the Git workflow
Take a look at Assignment 1 together