Lesson 5: Git on your own

By the end of today your tool will have a history. Every change you made, when you made it, and a way to go back to any of it.

Keys of the day

Something is running in your terminal and you want the prompt back for a minute. You do not have to stop it.

Keys	Does
Ctrl + z	pause what is running and give you the prompt back
jobs	list what you have paused
fg	bring the last one back, exactly as it was
bg	let it keep running, quietly, in the background

Open vim and press Ctrl + z. You are back at the prompt, and vim is paused. Run whatever you needed to run. Type fg and you are back in the file, cursor in the same place.

One more thing. Ctrl + c is not copy. In a terminal it means stop, which is why it kills whatever is running. Copy is Ctrl + Shift + c and paste is Ctrl + Shift + v.

Windows Terminal is kind about this and will copy with Ctrl + c if you have text selected. Select nothing, and it stops your program instead. On most other machines it always stops your program, so the Shift version is a good habit to have.

Warm up

Did pw learn any words?

The button

Most developers use git by clicking buttons in their editor. Pick the files, type a message, click commit. It works, and a lot of people never do anything else.

We will not use those buttons today.

They are not bad. They just do four simple commands for you, and hide them. When something unusual happens there is no button for it, and then you need the commands.

What git actually is

Git saves the state of a directory over time, and lets you go back to any of it.

The surprising part is that git is distributed. Every copy of a project holds the whole history. Not a link to it, all of it. Put a project on your laptop, get on a plane with no internet, and you still have every change anyone ever made to it.

So GitHub is not git. GitHub is a company that keeps a copy for you and puts a website in front of it. GitLab and Bitbucket do the same job. You can also keep a copy on your own server, or on a memory stick. They are all useful. None of them is git.

We get to GitHub next time, because that is where everybody else is.

Fact

Linus Torvalds wrote git in ten days in 2005, after the tool Linux used until then stopped being free. He named it after British slang for an unpleasant person, and said he names all his projects after himself.

Three places

This is the whole idea. A file can be in three places, and most confusion with git comes from not being sure which one you are looking at.

1. On disk. What you just edited
2. Staged. What you picked to go in the next commit
3. In the history. What you already committed

A change moves through them in that order. You edit, you stage, you commit.

If you are ever not sure where something is, git status will tell you. It also usually suggests the command that moves it on.

Starting

git init
git status
git add pw
git commit -m "first version"

git init turns the directory into a repository. It makes a hidden .git folder and changes nothing else, so it is safe to run on anything you own.

Command	Does
git init	start tracking this directory
git status	where is everything right now
git add <file>	stage a change
git commit -m "..."	put what is staged into the history

Challenge, two minutes. Run git status after each of those commands and read what it says. It says something different every time, and it is trying to help you.

Looking back

git log
git show
git diff

git log lists your commits. git show prints the last one, message and changes together. git diff shows what you have changed but not staged yet.

You have seen that last output before. It is the same -u format from last week. A - line was removed, a + line was added, and the lines around them show you where you are.

Curiosity. Try git log --oneline. Same history, one line per commit. After ten commits you will not want anything else.

Undoing

Three commands, and they cover almost everything.

Command	Does
git restore <file>	throw away your changes to that file
git restore --staged <file>	unstage it, keep the change
git reset --soft HEAD~1	undo the last commit, keep the work

git restore arrived in 2019, which makes it much newer than the rest of git. Before it, those first two jobs belonged to git checkout and git reset, and each of those did several other unrelated things as well. That is a big part of why git felt confusing for so long.

The old commands still work, and always will. So almost every answer you find online uses them. git checkout -- somefile is the old way of writing git restore somefile.

Oh Shit, Git!?! is one short page of fixes for the moments when something has gone wrong and you do not know what to search for. Worth a bookmark. It uses the old commands, which makes it good practice at reading them.

Fact

A commit’s id is not a number that counts up. It is a hash of what is in the commit, and that includes the id of the commit before it. Change one character anywhere in the past, and every id after it changes too. So nobody can edit history quietly. How that works is a lesson of its own, later.

Task: practise in the browser

webterm.app has three git modes. Work through all three:

• What is Git?
• Git Basics
• Git Fundamentals

Nothing you do there can break anything, so try things.

Task: put pw under git

Your tool exists, you wrote it, and it has no history yet. Today it gets one.

1. git init in its directory
2. Add a .gitignore, and have a think about what belongs in it
3. Commit what you have
4. Make one real improvement to pw, and commit that too
5. Then run git log, git show, and git diff HEAD~1

That last command compares now with one commit ago. HEAD means where you are, and ~1 means one step back.

Two commits is enough. You are not building a history today. You are checking that you have one, and that you can look at it.

Bonus

Run git commit with no -m and no message. Something will open. Work out what it is, what it wants from you, and how to get out of it.

You already know everything you need for this one.