The VikiD Truth

Knowledge base / Computing

Read This! | Picolisp | Picolisp Machine | Pil Sources | Linux | BASH | C-Programmming | Javascipt | Python | Scheme | Operating Systems | AssemblyLanguage | Computer Security | Firewalls | Exploitation | Social Engineering | Metasploit | Emacs | vim | Pharo Smalltalk | Databases | Networking | Machine Learning | Git

Git

Here is the truth about Git that finally made it click for me: it is not a backup tool and not a file-sync tool – it is a content-addressed database of snapshots, with pointers. Once you see the graph of commits, every confusing command becomes a way of moving those pointers around.

What it is, in plain words

Git is a distributed version-control system created by Linus Torvalds in 2005 to manage the Linux kernel. “Distributed” means every clone has the full history; there is no required central server. GitHub, Codeberg, GitLab and the like are just convenient places to put a clone and talk about it.

The three places your work lives:

  1. Working tree – the files you edit.
  2. Index (staging area) – the next snapshot you’re building, file by file.
  3. Repository (.git/) – the database of commits, tags and branches.

A commit is a snapshot of the index, with a pointer to its parent commit(s), an author, a message, and a hash. A branch is a movable pointer to a commit. HEAD is a pointer to the branch (or commit) you’re on.

flowchart LR
  W[Working tree] -- git add --> I[Index]
  I -- git commit --> R["Repository (commits)"]
  R -- git checkout / switch --> W
  R -- git push --> Rem[Remote]
  Rem -- git fetch / pull --> R

Why it matters

Almost every piece of software you’ll touch is in Git. Knowing it means you can explore history, undo mistakes safely, collaborate without overwriting each other, and understand how a codebase grew. It also teaches a useful habit: make small, honest commits that each say one thing.

An everyday analogy: a sketchbook with sticky notes

Each commit is a photograph of your sketchbook. Branches are sticky notes saying “this is where the dragon drawing is” or “this is the colour-test page”. Merging is photocopying two pages onto a new one. The remote is a spare sketchbook in a friend’s studio that you occasionally sync with.

A hands-on example: the everyday loop

git clone git@github.com:vukini/thevikidtruth.com.git
cd thevikidtruth.com
git status                          # what's different?
git switch -c topic/fix-page     # new branch (modern; was git checkout -b)

# edit files…
git add content/computing/git.md
git commit -m "Computing: write Git page"
git pull --rebase origin main       # update first – important on shared main
git push -u origin HEAD

Useful daily commands:

git log --oneline --graph --decorate -20
git diff                            # unstaged
git diff --staged                   # staged
git show HEAD                       # last commit
git blame content/computing/git.md  # who last touched each line
git stash push -m "wip"             # set work aside
git stash pop

Undo, carefully:

git restore file.md                 # throw away unstaged edits
git restore --staged file.md        # unstage, keep edits
git revert HEAD                     # new commit that undoes the last one (safe for shared history)
git reset --soft HEAD~1             # undo last commit, keep changes staged
# git reset --hard and git push --force: only on branches nobody else has pulled

Remotes, rebase and merge

git pull is git fetch + either merge or rebase. Rebase replays your commits on top of the updated branch – a cleaner history, which is why this site’s workflow uses git pull --rebase before every push. Never rebase commits that other people already have; use merge (or revert) for those.

git remote -v
git fetch origin
git switch main && git pull --rebase
git switch topic/fix-page && git rebase main

Submodules and subtrees, briefly

Sometimes you need one repository inside another. Submodules pin an external repo at a specific commit:

git submodule add https://github.com/example/lib.git vendor/lib
git submodule update --init --recursive   # after clone

They work, but have sharp edges (a clone doesn’t fetch them unless you ask). For many cases, copying the code in with git subtree or just using a package manager is happier. Reach for submodules when you truly need to track an upstream at a pinned revision.

Common misconceptions

Connections

To update your local repository with remote repository you can use:

git pull

git pull origin <branch_name>

Last edited · 6 revisions

Tags: #Computing