Git & GitHub

Why version control

Picture the folder of a project that grew without version control: analysis.py, analysis_v2.py, analysis_final.py, analysis_final_v3_REALLY.py. Nobody remembers what changed between them, two people overwrite each other's edits, and the version that actually worked got deleted last Tuesday. Version control removes all of this pain.

Git gives you three superpowers:

Install & configure

First confirm git is installed, then tell it who you are — every snapshot you make is stamped with your name and email, so do this once before your first commit.

git --version                                  # confirm git is installed

git config --global user.name "Your Name"      # who you are (use your real name)
git config --global user.email "you@example.com"  # use your GitHub email

git config --global init.defaultBranch main    # name the first branch "main"
git config --list                              # review what's now set

Your first repo

Git has three areas, and understanding them is 80% of "getting" git. A change moves through them in order: you edit files in your working directory, you stage the ones you want to save, then you commit the staged set as a permanent snapshot.

Let's make a repository and put a file under version control. Type these in order:

cd ~
mkdir git-practice
cd git-practice
git init                       # turn this folder into a git repo (creates .git/)

echo "# Git Practice" > README.md   # create a file in the working directory
git status                     # see what git notices

Now stage the file and commit it — moving it through all three areas:

git add README.md              # stage it (working dir → staging area)
git status                     # README.md is now "Changes to be committed"
git commit -m "Add project README"   # snapshot it (staging → history)

Seeing history

The whole point of committing is that you can look back. Make one more change so there's a history to explore:

echo "A repo for practicing git." >> README.md   # add a line
git diff                       # what changed since the last commit?
git add README.md
git commit -m "Describe the repo in the README"

git log --oneline              # the history, one commit per line

Four commands cover almost every day of git use:

Branches & merging

A branch lets you work on something without touching the known-good version. You branch off main, experiment freely, and only merge back when it works. Mentally, a branch is just a movable pointer to a commit — making a new commit slides the pointer forward.

Walk through it: create a branch, make a change, commit it there, then merge it back into main.

git branch                     # list branches — the * marks where you are (main)
git switch -c add-license      # create AND switch to a new branch "add-license"

echo "MIT License" > LICENSE   # do some work on the branch
git add LICENSE
git commit -m "Add MIT license file"

git switch main                # hop back to main — LICENSE disappears from disk!
git merge add-license          # bring the branch's work into main
ls                             # LICENSE is back, now part of main

Once a branch is merged, you can delete it with git branch -d add-license — the commits stay in history; you're just removing the now-redundant label.

GitHub: putting your repo in the cloud

So far everything lives only on your laptop. GitHub is the remote — a copy of your repo in the cloud that you push to and pull from. Here's the loop you'll live in every day:

On GitHub, click New repository, name it git-practice, leave it empty (no README — you already have one), and create it. GitHub shows you a URL; connect your local repo to it:

# use the URL GitHub shows you (HTTPS shown here)
git remote add origin https://github.com/YOUR-USERNAME/git-practice.git
git remote -v                  # confirm the remote named "origin" is set

git push -u origin main        # push main to GitHub; -u remembers it for next time

To get an existing GitHub repo onto a new machine, you don't init — you clone it, which downloads the whole repo with its full history and remote already wired up:

git clone https://github.com/YOUR-USERNAME/git-practice.git

.gitignore — what NOT to commit

Not everything belongs in version control. A .gitignore file lists patterns git should pretend don't exist — they'll never be staged or committed. Get this right and you avoid three classic disasters:

• Secrets — API keys and passwords in a .env file. Commit one once and it's in your history forever, even if you delete it later.
• Data files — raw CSVs, databases, and exports bloat the repo and don't belong in code history.
• Virtualenvs & caches — generated folders like .venv/ and __pycache__/ are rebuilt from your code; committing them is noise.

Create a .gitignore at the repo root. Here's a solid starter for the data work in this course:

# secrets — never commit these
.env

# python caches & virtual environments
__pycache__/
.venv/

# local data & databases — keep them out of git
data/
*.duckdb

Apply it: your mini-griddp repo

Time to use this for real. Open the mini-griddp project you started in Course 1, give it a .gitignore, commit it, and push the whole thing to GitHub.

cd ~/mini-griddp            # your project from Course 1
git init                    # if it isn't a repo yet

# create the .gitignore (paste the starter from the section above)
cat > .gitignore <<'EOF'
.env
__pycache__/
.venv/
data/
*.duckdb
EOF

git add .                   # stage everything NOT ignored
git status                  # sanity-check: no .env, no data/, no .venv/
git commit -m "Add project files and .gitignore"

# create an empty "mini-griddp" repo on GitHub first, then:
git remote add origin https://github.com/YOUR-USERNAME/mini-griddp.git
git push -u origin main

✓ Check yourself

• Can you name the three areas and describe how a change moves through them?
• Can you explain the difference between git and GitHub?
• Do you know the daily loop: pull → edit → add → commit → push?
• Could you list three things that should go in a .gitignore and why?

git switch -c update-readme          # 1) new branch
echo "Updated by me." >> README.md   # 2) change the README
git add README.md
git commit -m "Add a note to the README"   # 3) commit on the branch

git switch main                      # 4) back to main
git merge update-readme              #    bring the change in
git branch -d update-readme          #    tidy up the merged branch

git push                             # 5) push main to GitHub

Next

Your work is now tracked, reversible, and backed up in the cloud. Next we install the language every pipeline is written in and a modern tool to manage it cleanly. → The Python Toolchain