Git: save points for your work

Ever named files like essay-final-v2-REALLY-final.txt? Git fixes that for good. It keeps a history of every version of a folder, so you can see what changed, when and why, and jump back whenever you break something. Every software team in the world uses it, and so do sysadmins, for scripts and config files.

The big idea

Think of a video game with save points. A repository (repo) is a folder whose history git is tracking. A commit is one save point: a snapshot of the files, plus a message saying what changed and who changed it. You decide when to save, and you can always go back.

The staging area lets you save only some of your changes, for example the finished fix and not the half-done experiment.

Install and introduce yourself

sudo dnf install git
git --version          # git version 2.47.1

git --version          # git version 2.43.0
sudo apt install git   # only if it's missing

Every commit records who made it, so tell git your name and email once. They're saved in ~/.gitconfig:

git config --global user.name "Ana Student"
git config --global user.email "ana@example.com"
git config --global init.defaultBranch main     # name the first branch "main"

Skip this, and your first commit fails with “Author identity unknown”. Everyone meets that message once. The last line stops git from showing a long hint about “master” every time you create a repository. Most projects now call their main branch main.

The everyday loop

mkdir notes && cd notes
git init                          # start tracking this folder (creates .git/)
echo "Linux notes" > notes.txt
git status                        # what's changed? (use this ALL the time)
git add notes.txt                 # stage it  (git add . = everything here)
git commit -m "Start my notes"    # save point, with a message

[main (root-commit) c36fd51] Start my notes
 1 file changed, 1 insertion(+)
 create mode 100644 notes.txt

That c36fd51 is the commit's ID, the first 7 characters of a long unique code called a hash. Then you keep working in a loop: edit, git status, git add, git commit. For files git already tracks, git commit -am "message" stages and commits in one step.

Looking back

git log                 # every commit: who, when, what
git log --oneline       # one line each
git diff                # what changed since the last add (not staged yet)
git diff --staged       # what's staged, about to be committed
git show c36fd51        # one commit and its changes

@@ -1 +1,2 @@
 Linux notes
+- ls lists files        ← + means added, - means removed

Undo! (the reason git exists)

git restore notes.txt            # throw away my edits: back to the last commit
git restore --staged notes.txt   # un-stage it (the file itself isn't changed)
git log --oneline                # find an older save point…
git restore --source=c36fd51 notes.txt   # …and bring back that version of a file

Keep secrets out: .gitignore

A file called .gitignore lists things git should never track: passwords, API keys, logs, huge downloads. It's especially important once you share a repository, because anything pushed to GitHub can be copied by the whole world in seconds, and bots scan for leaked keys all day.

secrets.txt       # one file
*.log             # every file ending in .log
build/            # a whole folder
.env              # where apps often keep passwords

Once listed, git status stops mentioning those files. Commit the .gitignore file itself so everyone on the project gets it.

What's in .git?

The whole history lives in the hidden .git folder (ls -a). It's all normal files, so you can look: cat .git/HEAD shows which branch you're on. Delete .git and the history is gone, but your current files stay. That's why git lets you move a project folder around, or back it up (Linux Sysadmin, lesson 8), in one piece.

Try it: your first repository 💾

Quick check