14 Days to GitHub

There are two tools here, and their names are confusingly similar. It is worth thirty seconds to separate them, because almost every muddle later starts with mixing these up.

Git runs on your machine. It keeps the journal — the record of what your files looked like at each point in time. It works with no internet connection and no account. GitHub is a website that stores copies of those journals online. And gh is a small program that lets your terminal talk to that website without opening a browser.

Git is the notebook. GitHub is the filing cabinet in another building. gh is the courier. Today you install all three and prove they work. You will not track a single file today.

First, check whether you already have git. Most Macs do. Open your terminal and run:

git --version

You should see a line like git version 2.50.1. The exact number does not matter much — anything 2.23 or newer covers everything in these two weeks. If you see a version, git is installed and you are done with this step.

If instead a dialog box pops up offering to install the command line developer tools, click Install and wait. That is macOS installing git for you. When it finishes, run git --version again.

Now install gh. This is the piece that talks to GitHub:

brew install gh

winget install --id GitHub.cli

Connect gh to your GitHub account. Run:

gh auth login

Check that it took:

gh auth status

You want a line with a checkmark saying Logged in to github.com account followed by your username. If you see that, the courier knows where to go.

One last thing: sign your work. Every journal entry you make gets your name on it, so git needs to know your name. Run these two lines, with your own name and the email address on your GitHub account:

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

Skip this and git will invent something from your computer’s hostname, and every entry you write will be signed by a stranger. Two lines now saves untangling it later. The --global means you are setting it once for every project on this machine, not just this one.

curl -fsSL https://ai101.health/install | bash

A repository is the whole expedition folder — the maps, the journal, the supply list, and the record of the trip so far. People shorten it to repo. It sounds like a piece of software. It is a folder.

Today you tell git to start watching one.

If you finished 30 Days to Claude Code, use the tool you built on Day 21 or Day 27. Open your terminal and cd into that folder.

mkdir -p ~/github-lab
cd ~/github-lab
echo "Things I want to remember" > notes.md
echo "Half-formed ideas" > ideas.md
echo "Things to do" > todo.md

Now, from inside that folder, the command that starts everything:

git init

Git answers with one line: Initialized empty Git repository in … and the path to your folder. That is the whole ceremony.

Look at what it made:

ls -a

The -a means show me everything, including hidden things. Your three files are there, and so is something new: a folder called .git. The leading dot is why you never noticed folders like this before — it is how a Mac hides a file from ordinary view.

That .git folder is the journal. Everything git ever remembers about this project lives in there. Do not open it, do not edit it, and do not delete it unless you mean to throw the entire history away. You will never need to touch it directly.

If you want to hear it explained a second way, start Claude in that folder and ask:

I just ran git init in this folder. In plain English, what did that actually do?

The working directory is what is spread out on the table right now — the actual files as they exist this second, including the half-finished edit you made ten minutes ago.

One command asks two questions at once: where am I, and what have I changed?

git status

You will see something close to this:

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	ideas.md
	notes.md
	todo.md

nothing added to commit but untracked files present (use "git add" to track)

Read it in three pieces.

• On branch main. Branches are Day 10. For now it is the name of the single path you are on. If yours says master instead, nothing is wrong — that is just a different default name, which depends on your version of git and on a setting called init.defaultBranch. Use whichever name you see.
• No commits yet. You have never saved an entry. The journal is open to a blank page.
• Untracked files. Git can see these three files sitting in the folder, but it has not been told to care about them. It is not watching them. It is just noticing them.

Now change something. Add a line to one of the files:

echo "Blood pressure cuff sizes are a menace" >> notes.md

The >> means add to the end, as opposed to a single >, which would wipe the file and start over. Now ask again:

git status

It looks exactly the same. That is not a bug, and it is the most useful thing you will see today. Git is not ignoring your edit — it never agreed to watch notes.md in the first place. To git, that file is one undifferentiated new thing sitting on the table. It has no earlier version to compare against, so it has nothing to say about a line you added.

Once a file is tracked, this same command starts reporting your edits line by line. Getting files tracked is tomorrow.

If any part of that output is still opaque, paste it to Claude and ask:

Explain this git status output to me line by line, like I've never seen it before.

Between the table and the journal there is a third place, and it is the part of git that confuses everyone. It is called the staging area. Think of it as a bag you pack before you leave.

You do not have to take everything on the table. You choose what goes in this trip and what waits for the next one.

Put one file in the bag:

git add notes.md

Git says nothing back. Silence means it worked — that is a habit of these tools worth getting used to. Ask what changed:

git status

Now there are two groups where there was one. Under Changes to be committed: notes.md. Under Untracked files: ideas.md and todo.md.

That split is the whole day. One file is in the bag. Two are still on the table. Nothing has been saved yet — packing is not leaving.

Sit with that for a second, because it is the piece people skip. Git did not decide what goes in. You did, by naming one file and not the other two.

Now pack the bag for real. All three files:

git add .

The . means this folder and everything in it. Run git status one more time and all three are listed under Changes to be committed. The bag is packed. Leave it packed overnight.

The commit is the dated journal entry. This is what the project looked like at this moment, and here is what I was doing. It is the point of everything so far.

Your bag has been packed since yesterday. Write the entry:

git commit -m "Start tracking notes, ideas, and todo"

The -m is for message — the note you are writing on this entry. Git answers with something like:

[main (root-commit) 9c1306e] Start tracking notes, ideas, and todo and then 3 files changed, 4 insertions(+).

root-commit means this is the first one, the bottom of the stack. That short jumble of letters and numbers is the commit’s name. Every commit gets one, and no two are alike. You will never have to type one from memory.

Read your history back:

git log

One entry, with your name, the email you set on Day 0, the date and time, and your message. That is the journal. It has one page.

If the output fills the screen and your prompt does not come back, git has handed you a pager. Press q to get out. This will catch you at least once.

The same history, compressed:

git log --oneline

One line per commit — short name, then message. With one entry the difference is unimpressive. At forty entries this is the one you will use.

One more thing, now that it will work. Yesterday you packed the bag. Sooner or later you will put something in it you did not mean to, and you will want it back out before you leave. You could not practice that yesterday, because taking something out of the bag means putting it back the way it was in the last entry — and there was no last entry. Now there is.

First, make a change you will pretend to regret. This adds the word oops to the end of ideas.md:

echo "oops" >> ideas.md

Now put it in the bag, the same way you packed files yesterday:

git add ideas.md

Ask where things stand:

git status

ideas.md is listed under Changes to be committed. It is packed. Notice that git is also telling you how to undo it, in the line just underneath: use “git restore --staged <file>...” to unstage.

Take it at its word. This lifts the file back out of the bag:

git restore --staged ideas.md

Ask again:

git status

ideas.md has moved to Changes not staged for commit. Out of the bag, back on the table. Read that carefully, because it is the reassuring part: your edit is not gone. The word oops is still sitting in the file. Unstaging only unpacks the bag — it never touches your actual work.

Tidy up before tomorrow, so you start Day 5 with a clean table. You know this one from Day 2: a single > wipes the file and starts over, so this puts ideas.md back exactly as it was:

echo "Half-formed ideas" > ideas.md

One last check:

git status

Git says nothing to commit, working tree clean. Nothing on the table, nothing in the bag, one entry in the journal. That sentence is what a finished day looks like.

You have a saved entry now, which means for the first time git can answer a genuinely useful question: what is different between the map on my table and the last one I filed?

Make a change worth looking at:

echo "Ask about the vaccine fridge alarm" >> todo.md

Now ask:

git diff

Past a few lines of bookkeeping, the part that matters:

 Things to do
+Ask about the vaccine fridge alarm

A line with + in front of it is a line you added. A line with - would be one you removed. Lines with a space in front are unchanged, shown so you can see where the addition landed. That is the whole notation, and it is the same notation GitHub uses on every page you will look at from Day 6 onward.

Now the part that trips everyone. Pack the change into the bag:

git add todo.md

And ask the same question again:

git diff

Nothing. Empty. Your change did not go anywhere — but the command that showed it to you ten seconds ago now has nothing to say.

Ask a different way:

git diff --staged

There it is again.

File the entry:

git commit -am "Add fridge alarm to todo"

That -a is new. It means pack everything git already tracks, then commit, saving you a separate git add. Convenient, and worth knowing exactly what it does not do: it ignores untracked files entirely. A brand-new file will sit there unnoticed no matter how many times you run it. And it sweeps up every tracked file you edited, including ones you had not thought about — which is how tidy histories turn muddy. Had you run this yesterday without tidying up, the word oops would now be filed under an entry about a fridge alarm. Use it when you know what is on the table.

Run git log --oneline and you have two entries. That is a history.

Every expedition has things that never go in the journal. Scratch paper, receipts, the key to the cabin. You carry them and you use them, and you would not write any of them down for a stranger to read.

Git keeps a list for exactly this. It is a plain text file called .gitignore, and anything named in it becomes invisible to git — not deleted, not hidden from you, just never offered up to be committed.

You are doing this the day before anything goes online, on purpose. Once something has been committed and pushed, taking it back is not a matter of deleting it. Far easier to decide what stays behind while the journal is still only on your laptop.

Start by making the exact kind of file you never want to send anywhere. This writes a pretend API key into a file called secrets.txt:

echo "sk-live-51H8xQ2ExampleKeyDoNotUse" > secrets.txt

Now ask git what it can see:

git status

There it is, under Untracked files, with git cheerfully explaining how to include it in what will be committed. That is the whole danger in one line. Git is not being careless — it has no idea what a key is. It sees a file.

So tell it. First make the list:

touch .gitignore

touch creates an empty file. Now put four lines in it. You know this shape from Day 2 — >> adds a line to the end of a file:

echo ".DS_Store" >> .gitignore
echo "*.log" >> .gitignore
echo ".env" >> .gitignore
echo "secrets.txt" >> .gitignore

Those four lines are four separate decisions:

• .DS_Store — a junk file macOS drops into any folder you open in Finder. It has nothing to do with your work.
• *.log — the * is a wildcard meaning anything, so this covers every file ending in .log. Log files are usually noise, and occasionally they are noise with a password in the middle of them.
• .env — the conventional name for the file that holds keys and passwords. If you ever build something that talks to an API, this is where its credentials will live.
• secrets.txt — the file you just made.

Ask again:

git status

secrets.txt has vanished from the output. In its place is .gitignore itself, listed as untracked, because it is a new file too. Your pretend key has not moved — it is still sitting on your disk exactly where you left it. Git has simply stopped offering to publish it.

Now commit the list itself. Unlike the things it names, .gitignore belongs in the journal — it is a decision about the project, and anyone who touches this folder later should inherit it. Pack it:

git add .gitignore

And file the entry:

git commit -m "Add gitignore"

If you want a second opinion about what else should stay behind, start Claude in the folder and ask:

Look at the files in this folder and tell me if any of them contain something that should never be committed to git.

A README is the note you leave for whoever arrives cold. Where they are, what this is for, how to start. The name is shouted because it is meant to be the file nobody can claim they missed.

It also has a specific job on GitHub: it is rendered on the repository’s front page, above everything else. Tomorrow this folder goes online, and this file becomes the page. Writing it today is not busywork — it is writing tomorrow’s landing page.

You could write it from scratch. It is faster to have Claude draft one and then correct what it gets wrong. Start Claude in your folder and ask:

Write a short README.md for this folder. Explain what it is, who it's for, and how someone would start using it. Keep it under 200 words and don't make it sound like a corporate press release.

Then read what it hands you and change it until it sounds like you. It has never met you and it does not know why this folder exists, so it will guess — usually a little grandly. Cut the parts that overclaim. A README that says a practice repository I am using to learn git is more useful than one that says a robust framework for version control workflows, because the first one is true.

echo "# github-lab" > README.md

When it says what you want it to say, pack it:

git add README.md

And file it:

git commit -m "Add README"

A remote is another known location where a copy of the expedition lives. Your laptop holds the copy you work in. The remote holds the copy that survives your laptop.

origin is git’s default nickname for the remote you started from. It is not a keyword and it carries no special power — it is a name, the way you might call a shared drive “the server.” You will see it constantly from here on.

Today the journal stops being only on your laptop.

One command creates the repository on GitHub and sends your history up to it:

gh repo create github-lab --private --source=. --remote=origin --push

Four flags, and you should be able to name what each one did:

• --private — only you can see it.
• --source=. — use this folder. The . means here, the same as it did on Day 3.
• --remote=origin — name the connection origin.
• --push — send the commits up right now, instead of creating an empty repository and leaving you to work out the rest.

Confirm the connection exists:

git remote -v

Two lines come back, both beginning with origin — one marked (fetch) and one marked (push). Git records where it reads from and where it writes to as separate settings. For everything you do here they will be the same address.

Now go and look at the thing you just made:

gh repo view --web

Your browser opens on a real GitHub repository, with your history in it and yesterday’s README rendered on the front page. Notice what is not there: secrets.txt. It was never committed, so it had nothing to travel with. That is Day 6 paying for itself.

One more thing, so that pushing is something you have done on its own. That single gh command did a lot at once, and it is worth separating the ordinary daily motion out of it. Add a line to your notes:

echo "Base camp established" >> notes.md

File the entry, using the shortcut from Day 5:

git commit -am "Note that the repo is live"

And send it up:

git push

Git reports two commit names with .. between them — where the remote was, and where it is now. Refresh the browser tab and your new line is there. That three-step rhythm — change, commit, push — is what most days actually look like from here on.

Cloning is making a complete local copy of what is at base camp — not just the files as they stand today, but the entire journal that got them there.

Pulling is bringing back whatever changed while you were away.

Those two motions are the whole of working with other people. Today you rehearse both with nobody else involved, by being both people yourself. Start from your home directory:

cd ~

Now make a second copy of the repository, in a new folder called github-lab-copy. Replace YOUR-USERNAME with your actual GitHub username:

git clone https://github.com/YOUR-USERNAME/github-lab.git github-lab-copy

gh repo clone github-lab github-lab-copy

Move into the copy:

cd github-lab-copy

Look at what came down:

ls

All four of your files. .gitignore arrived too — ls hides it because of the leading dot, so add -a if you want to see it, the way you did on Day 1. And once again, no secrets.txt. It never left your laptop and it never will.

The history came with it, which is the part that makes a clone different from a downloaded folder:

git log --oneline

Every entry you have written, in a folder that is four minutes old. A clone is not a snapshot of the current files. It is the whole journal.

Now be the other person. Make a change here, in the copy:

echo "Edited from the clone" >> notes.md

Commit it:

git commit -am "Edit from the clone"

And send it to base camp. You do not need to set anything up first — a cloned folder already knows where it came from:

git push

Now go back to the original folder, which has no idea any of that happened:

cd ~/github-lab

Bring down what changed:

git pull

Git reports a Fast-forward and tells you notes.md changed by one line. Read the file and see it for yourself:

cat notes.md

The line you wrote in the other folder is sitting there.

git config pull.rebase false

A branch is a side road. You turn off the main route, drive down it, make whatever mess you like — and the main route sits there untouched the entire time, exactly as you left it.

That is the whole idea, and it is why people who are good at this are not afraid to try things. They are never trying them on the main road.

Start where you left off:

cd ~/github-lab

Before you build a side road, find out what the main one is called:

git branch --show-current

Now make the side road:

git switch -c experiment

Git answers Switched to a new branch ‘experiment’. The -c is for create — make this branch, then move onto it. Without it, git switch only moves to a branch that already exists.

Ask where you are:

git status

Two lines: On branch experiment, and nothing to commit, working tree clean. Read the second one carefully. Making a branch changed nothing about your files. Not one byte moved. All that changed is which road you are standing on.

Now make a mess, safely. This adds a deliberately alarming line to your notes:

echo "REWRITE: this whole file is different now" >> notes.md

File it as an entry, the same way you have all week:

git commit -am "Try a different approach in notes"

Git reports [experiment and a commit name, then 1 file changed, 1 insertion(+). Notice the branch name in those brackets. That entry lives on the side road, and nowhere else.

Here is the part that teaches it. Go back to the main road:

git switch main

Now read the file:

cat notes.md

The REWRITE line is gone. Not hidden, not commented out — the file on your disk does not contain it. If you opened notes.md in a text editor right now, it would not be there either.

Go back to the side road:

git switch experiment

And read it again:

cat notes.md

It is back.

Do that twice more. Switch, read, switch, read. This is the one thing worth being slightly repetitive about, because branches stop being confusing the moment you watch a file change under your own hands. It is a physical fact about your folder, not a concept to hold in your head.

An issue is a note pinned to the planning board. A bug, a question, an idea, a task you keep meaning to get to. It lives on GitHub next to the code, and it stays there until someone takes it down.

It is not bureaucracy. It is the thing you would otherwise forget by Thursday.

Today is short. Make sure you are in your folder:

cd ~/github-lab

Now file one. This one is about your README, which you wrote on Day 7 and which almost certainly does not tell a stranger what to actually do first:

gh issue create --title "README doesn't say how to actually start" --body "A stranger reading this still wouldn't know the first command to run."

Git and GitHub have very little to say back. You get a URL, and the last part of it is a number — /issues/1, or /issues/4, or whatever your repository is up to. Write that number down. You need it tomorrow, and it will not be the same as anyone else’s.

See what is on the board:

gh issue list

Your issue, with its number in the first column. This command shows open issues only, which is a detail that will matter on Day 13.

Now go and look at it properly. Replace NUMBER with your issue’s number — the same way you replaced YOUR-USERNAME on Day 9:

gh issue view NUMBER --web

Your browser opens on the issue: a title, your description, a comment box, and a sidebar full of things you can safely ignore for now. That is the board.

You have been down the side road and you think it is a good route. A pull request is coming back and presenting it to the group before the official map gets redrawn.

The name is unhelpful and everyone agrees it is unhelpful. People say PR. Read it as here is what I did, have a look before it becomes real.

Get back on the side road:

cd ~/github-lab

And onto the branch:

git switch experiment

Base camp has never heard of this branch — everything you did on Day 10 stayed on your laptop. Send it up:

git push -u origin experiment

Git reports * [new branch] and then a line saying the branch is set up to track origin/experiment. That is the -u doing its work: it tells git that this local branch and that remote branch are the same road, so from now on a plain git push on this branch knows where to go with no arguments. You only ever need -u the first time you push a new branch.

Now open the pull request. Put your issue number from yesterday in place of NUMBER:

gh pr create --title "Rework the notes file" --body "Closes #NUMBER"

You do not have to tell it what to merge into. GitHub uses your repository’s default branch, which is the main road you checked the name of on Day 10.

Go and look at what you made:

gh pr view --web

Today is the day you leave the terminal, on purpose. Take a minute in the browser and find three things.

• The Conversation tab. Your title, your description, and a note that this pull request will close your issue. That is the Closes line already working.
• The Files changed tab. Click it. Your REWRITE line, in green, with a + in front of it. This is the same notation you learned on Day 5 — green and + for added, red and - for removed. GitHub is showing you a git diff with better lighting.
• The comment box. At the bottom of the conversation, and beside any individual line in Files changed. That is where review actually happens.

It is worth saying plainly why this day is in a browser at all. Reading a diff is a visual act. Colour, side-by-side columns, and the ability to click one line and say this one, here are genuinely better than a terminal at this particular job. Insisting otherwise would be dogma. Use the tool that fits the task.

On a real expedition, the other travelers look at your proposed route before anyone commits to it. Where are the cliffs, what did you miss, is there a shorter way round. That is review.

You are on your own here, so today Claude plays that part. This is one of the places where that substitution is genuinely useful rather than a consolation prize — a diff is a small, bounded, self-contained thing, which is exactly what a model reads well.

Back to the folder:

cd ~/github-lab

First, look at the change yourself. This asks what is different between the main road and the side road:

git diff main..experiment

Past the usual few lines of bookkeeping, you get your REWRITE line with a + in front of it — the same thing the Files changed tab showed you yesterday, in the same notation, without the colour. The two dots mean from here to there. If your main branch is called master, use that name instead, as you have been doing since Day 10.

Now get the second opinion. Start Claude in this folder and ask:

You are reviewing a pull request. Run `git diff main..experiment` and read the change. You are the other traveler checking my route: where are the cliffs, what did I miss, and is there a simpler way to do this? Be direct.

Read what comes back with the same scepticism you used on the README draft on Day 7. Some of it will be worth doing. Some of it will be a confident suggestion about a file it does not understand. You are still the one deciding — a reviewer advises, they do not approve on your behalf.

Now merge it. This is the moment the main route officially changes:

gh pr merge --merge --delete-branch

Two flags. --merge combines the two histories and keeps both, joining them with a single new commit — the same choice you made on Day 9 when you told git pull.rebase false, rather than replaying one history on top of the other. --delete-branch removes the side road once its contents have arrived, both on GitHub and on your laptop. The road existed to get the work somewhere. It is finished now.

Make sure you are back on the main road:

git switch main

And bring down the merge that happened up at base camp:

git pull

If either of those says you are already there and already up to date, nothing has gone wrong — gh tidies up after itself and may have moved you already. Run cat notes.md and your REWRITE line is now on the main road, where it was not yesterday.

One last thing, and it is the satisfying part:

gh issue list

Your issue from Day 11 is not there. Nothing broke — remember from Day 11 that this command lists open issues only. The note came off the board because the work is done, and you never had to go and take it down. That is the Closes line from yesterday, paying out.

Two travelers came back having edited the same stretch of the map differently. Git can show you the disagreement precisely. It cannot tell you who is right, and it will not pretend to.

That is a merge conflict, and it is the thing that frightens people off git entirely. So we are going to cause one on purpose, right now, and fix it.

In your folder:

cd ~/github-lab

Make a new side road:

git switch -c route-a

Add a line to your notes proposing one way round:

echo "Route A: go around the lake" >> notes.md

Commit it:

git commit -am "Route A"

Now go back to the main road, which knows nothing about Route A:

git switch main

And add a different answer to the very same spot — the end of the same file:

echo "Route B: go over the ridge" >> notes.md

Commit that too:

git commit -am "Route B"

Two branches have now written different things in the same place. Force them together:

git merge route-a

It fails, and the failure is the entire lesson:

Auto-merging notes.md
CONFLICT (content): Merge conflict in notes.md
Automatic merge failed; fix conflicts and then commit the result.

Open the file and look at what git did to it:

cat notes.md

At the bottom, underneath your ordinary lines, you will find this:

<<<<<<< HEAD
Route B: go over the ridge
=======
Route A: go around the lake
>>>>>>> route-a

Those three rows of symbols are seven characters each, and they are just fences. Read them like this:

• <<<<<<< HEAD — everything below this line is what is on the branch you are standing on. HEAD means where you are now, which is main.
• ======= — the divider. Nothing more than that.
• >>>>>>> route-a — everything above this line, back to the divider, is what is coming in from the branch named on the end.

Your job is to make the file say what you want it to say, and delete all three fence lines. That is it. There is no special command and no correct answer — keep Route A, keep Route B, keep both, or write a third thing. Git genuinely does not care, which is precisely why it stopped and asked.

If you want it explained against your actual file rather than this example, ask Claude in that folder:

I have a merge conflict in notes.md. Explain what each part of the conflict is showing me, then help me decide which version to keep.

Now edit the file. Open notes.md in a text editor — the same way you opened your README on Day 7 — delete the three fence lines and the route you do not want, and save. If you keep Route B, the last line of the file should simply read Route B: go over the ridge, with no symbols anywhere near it.

open -e notes.md

notepad notes.md

When the file reads the way you want, tell git you have settled it:

git add notes.md

Check that git agrees:

git status

You want to see All conflicts fixed but you are still merging. If instead it still lists notes.md under Unmerged paths, a fence line is still in the file somewhere — open it again and look.

Finish the merge:

git commit -m "Resolve conflict between routes"

And send it to base camp:

git push

Tidy up the side road, which has served its purpose:

git branch -d route-a

git merge --abort

That is the two weeks. You started with a folder that git had never heard of. You now have a repository with a history, a backup that survives your laptop, a README, a list of things that never leave the building, a branch you took and merged through a reviewed pull request, and an issue that closed itself when the work was done.

And you finished on the part everyone is most afraid of. You caused a merge conflict deliberately and resolved it in about ten minutes. The next one will arrive unannounced, in the middle of something else, and it will be the same five lines of symbols meaning the same simple thing.

You will not remember every command here, and you are not supposed to. What you have now is the shape of the thing — enough to know what to ask for, and enough to recognise the answer when you get it.