Git and GitHub: saving and sharing your work · Building AI

There are two reasons to use Git, and only one of them is about collaboration. The first reason — true even if you never share code with anyone — is that Git lets you save a project’s history. Every time you reach a clean state, you take a snapshot. Three weeks later, when an experiment goes badly wrong, you can step back to any snapshot and start again from there. The second reason — useful, but secondary — is that Git plus GitHub lets other people see your code, copy it, suggest changes. For the rest of this track, we treat Git as a safety net. Treating it as a portfolio comes later.

Installing Git

Most macOS and Linux machines already have Git. To check:

git --version

If you see a version number, you are done. If you see “command not found”:

macOS: brew install git, or install the Xcode Command Line Tools when prompted.
Windows: download from git-scm.com — accept the defaults during install.
Linux: sudo apt install git (or your distribution’s equivalent).

Then tell Git who you are. Once, ever, on each machine:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

The email will appear on every commit you make. Use a real one — ideally the same one you use for GitHub.

The three commands that do almost everything

Most of your day-to-day Git work uses three commands. From inside your project folder:

git init           # turn this folder into a Git project (once, ever)
git add .          # stage all current files for the next snapshot
git commit -m "..." # take the snapshot with a short message

That is the whole loop. Make changes, git add ., git commit -m "describe what changed". Repeat. Your project now has a history.

To see the history:

git log

To see what has changed since the last commit:

git status   # which files have been touched
git diff     # line-by-line differences

You will use status and diff constantly. They are the cheap, fast way to remember “what was I doing before lunch?”.

A `.gitignore` — what NOT to save

Some things in your project folder should never be committed. The virtual environment from the last section (.venv/) is the obvious one — it is huge, platform-specific, and recreatable from requirements.txt. Same for caches, secret keys, and large data files.

In the root of your project, create a file called .gitignore:

.venv/
__pycache__/
*.pyc
.ipynb_checkpoints/
data/raw/
.env
*.log

Git looks at this file before each git add and silently skips anything matching one of the patterns. The .env file is especially important — it is where you will store API keys in Chapter 5, and those must not end up in a public commit.

Pushing to GitHub

GitHub is a website where Git projects live. The free tier is generous — you can host unlimited public and private repositories — and creating an account takes a minute.

On github.com, sign up. Verify your email.
Click “New repository”. Give it a name (e.g. building-ai-notes). Leave it empty (no README, no .gitignore — you already have one).
GitHub shows you a block of commands. The ones you want are roughly:

git remote add origin git@github.com:yourname/building-ai-notes.git
git branch -M main
git push -u origin main

If you set up SSH keys (recommended — GitHub has a one-page guide), this just works. If you use HTTPS, GitHub will ask for a personal access token the first time — easier to set up but slightly more annoying to type. Either is fine.

After that first push, the daily routine is:

git add .
git commit -m "describe what you did"
git push

Your work is now on GitHub. If your laptop dies, your work survives. If a friend wants to see what you have been building, send them the URL.

Pulling, branching, and the parts we will skip for now

There is much more to Git — branch, merge, rebase, pull, fetch, cherry-pick — and you will learn it as you need it. For Course 01, the three commands above (add, commit, push) cover almost everything. Branching becomes useful when you start collaborating; we will come back to it in Course 05 when we ship a real app.

One command you may need sooner: if you work on two machines, you will sometimes need to pull down changes you pushed from the other one:

git pull

That fetches and merges any changes that exist on GitHub but not locally. If you work alone on one machine, you may go weeks without using it.

Commit messages: a small craft

The single message you type with each commit becomes a tiny piece of your project’s diary. Good messages save real time later.

Bad:

fixed stuff
asdf
update

Good:

Add NEPSE CSV reader and unit conversion to NPR lakhs
Fix off-by-one in vendor totals
Switch matplotlib output dpi from 100 to 200

The shape that works: a short imperative phrase (“Add X”, “Fix Y”, “Switch from A to B”). Read in past tense (“if applied, this commit will add X”). One line is usually enough; if you need more, leave a blank line and write a longer body.

The smallest realistic workflow, end to end

Putting it together. A fresh project, from zero to GitHub:

mkdir nepse-alerts
cd nepse-alerts

python3 -m venv .venv
source .venv/bin/activate
pip install pandas requests
pip freeze > requirements.txt

git init
# create .gitignore with .venv/, __pycache__/, .env, etc.

# write some code...

git add .
git commit -m "Initial NEPSE alerts script and dependencies"

# on github.com: create empty repo "nepse-alerts"
git remote add origin git@github.com:yourname/nepse-alerts.git
git branch -M main
git push -u origin main

Ten commands. Fifteen minutes the first time, five minutes once it is muscle memory. From now on, every project you start in this track follows this shape.

Check your understanding

Quick check

—

You committed a `.env` file containing your Anthropic API key three days ago and pushed it to a public GitHub repository. You realise the mistake today. Which is the most accurate description of your situation?

Just delete the file and commit the deletion — the key is now safe.
Delete the file from the repo, but treat the key as compromised: rotate it in your Anthropic console immediately, because it has been publicly visible in commit history for three days.
GitHub auto-scans for secrets, so it has already been protected.
Force-push over the bad commit and pretend it never happened.