What is the difference between git and GitHub?

`git` records history on your own machine; GitHub is a service that hosts and shares that history. Git works perfectly well without it.

How is add different from commit?

`add` chooses what goes into the next record, `commit` turns that selection into one. The staging area in between is what lets you record part of your work rather than all of it.

I got the commit message wrong.

If you have not shared it yet, `git commit --amend -m "new message"` rewrites it. Amending something already pushed rewrites history other people have, so be careful there.

How do I throw away my changes?

`git restore ` puts the file back to the last commit. Those changes are gone for good, so look at `git diff` first if you are unsure.

git push complains about an upstream.

The branch has no destination yet. Run the `git push --set-upstream origin ` line it prints, and afterwards plain `git push` is enough.

← Linux command list

git command: record your changes as history

__ __ _ _____

\ \ / /__| |_|_ _|__ _ __ _ __ ___

\ \ /\ / / _ \ '_ \| |/ _ \ '__| '_ ` _ \

\ V V / __/ |_) | | __/ | | | | | |

\_/\_/ \___|_.__/|_|\___|_| |_| |_| |_

A sandbox for trying git. Nothing here can touch your real files.

user@webterm:~/project$

git records changes to your code. Learn how to read `git status`, what separates `add` from `commit`, and how to read the history with `git log`, by running the commands in a real terminal in your browser.

Updated: 2026-09-06

Syntax

git <subcommand> [options]

git is not one command but a family of them. The five below cover almost every day.

Try it first

Everything starts with git status.

$ git status
On branch main

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   README.md

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

no changes added to commit (use "git add" and/or "git commit -a")

Three things are being reported.

Heading	Meaning
`On branch main`	You are working on `main`
`Changes not staged for commit`	Edited, but not chosen for the next record
`Untracked files`	Files git has never seen

-s gives the short version.

$ git status -s
 M README.md
?? notes.txt

M is modified and ?? is untracked.

Seeing what changed

git diff shows the actual edit.

$ git diff
diff --git a/README.md b/README.md
index 4f908a3..3b65e7d 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,4 @@
 # project
 
 A small example project.
+Run npm start to begin.

Lines marked + are the ones you added. Read this before recording anything. It is the only place where a stray edit you did not mean to make will show itself.

Recording

Recording takes two steps. First choose what goes in.

$ git add README.md
$ git status
On branch main

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   README.md

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

README.md has moved to Changes to be committed, the staging area. Then turn that selection into one record.

$ git commit -m "Explain how to start the app"
[main 212b4a4] Explain how to start the app
 1 file changed, 1 insertion(+)

212b4a4 is the name this commit was given, and it differs every time. notes.txt was never selected, so it is not part of the record.

$ git status -s
?? notes.txt

Choosing, then confirming, is the heart of git. Even when one sitting touched several unrelated things, you can select only the related files and record them as separate, meaningful commits.

Reading the history

$ git log --oneline
212b4a4 (HEAD -> main) Explain how to start the app
6606c5f add a description
77860e9 first commit

Newest at the top. Without --oneline you get the long form, with the author and the date.

The subcommands you use daily

Subcommand	What it does
`git status`	See where things stand
`git diff`	See what you changed
`git add <file>`	Choose what to record
`git commit -m "..."`	Record what you chose
`git log --oneline`	Read the history
`git switch -c <name>`	Create a branch and move to it
`git restore <file>`	Throw away your edits to a file

When you actually reach for it

git is what you use to make sure you can get back before you go forward.

Situation	What to type
Check the state before starting	`git status`
Remember what you changed	`git diff`
Record at a sensible stopping point	`git add <file>` then `git commit -m "..."`
Reword the last commit	`git commit --amend -m "..."`
Discard your changes	`git restore <file>`

Things that trip people up

Nothing is recorded until you git add. Saving a file does not put it in history. Check git status right before committing and make sure what you expect is under Changes to be committed.

Run git status before git add . The . means everything below where you stand. Private keys and build output get swept in that way, so look at what is about to be added first.

Messages are written for whoever reads them later. fix or update tells nobody anything six months on. A single line about why, rather than what, pays for itself.

git is a big tool. This page covers the entrance you use every day. Working across branches, and choosing between the different ways to undo, are what the tutorial and the course below take up next.

Practise it hands-on

webterm.appthis site

Git Basics
Learn basic Git operations
Try the tutorial
Git Fundamentals
Learn branching and history operations
Try the tutorial

learn.webterm.appa separate site

>_WEBTERM LEARN

WebTerm Learn: from one command to actually using it

Commands stick when they show up in a real sequence of work, not one at a time. There is a course that builds them up in order.

See the course

Related commands

vim / ls / diff / less

Frequently asked questions

What is the difference between git and GitHub?: `git` records history on your own machine; GitHub is a service that hosts and shares that history. Git works perfectly well without it.
How is add different from commit?: `add` chooses what goes into the next record, `commit` turns that selection into one. The staging area in between is what lets you record part of your work rather than all of it.
I got the commit message wrong.: If you have not shared it yet, `git commit --amend -m "new message"` rewrites it. Amending something already pushed rewrites history other people have, so be careful there.
How do I throw away my changes?: `git restore <file>` puts the file back to the last commit. Those changes are gone for good, so look at `git diff` first if you are unsure.
git push complains about an upstream.: The branch has no destination yet. Run the `git push --set-upstream origin <branch>` line it prints, and afterwards plain `git push` is enough.