/ Root Node
Search
Programming // Version Control Systems

Git and GitHub Explained: A Practical Guide for Beginners

Git is not a magical cloud backup utility—it is a localized, content-addressable object store based on cryptographically hashed Directed Acyclic Graphs (DAGs). Here is how version control actually works.

By Julian Vance • Senior Systems Architect
• 16 min read
Software engineering team collaborating over source code repositories
Figure 1: Collaborative source tree integration across remote engineering teams.

1. The Mental Model: Snapshots, Not Deltas

Traditional version control systems (like SVN or CVS) tracked software history as a base file followed by a list of sequential differences (deltas). If you had 10 versions of a file, the system calculated the math by replaying diff 1, diff 2, through diff 10.

Git, created by Linus Torvalds in 2005 to manage the Linux kernel codebase, completely abandoned this approach. Git thinks of its data more like a series of complete cryptographic snapshots of a miniature filesystem. Every time you commit, Git takes a picture of what all your files look like at that exact moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again—just a link to the previous identical file it already has stored.

Terminal command prompt displaying git status and branches
Figure 2: Inspecting localized commit hashes and tree states via the terminal interface.

2. Git vs. GitHub: Clarifying the Separation

Beginner developers frequently confuse Git and GitHub as interchangeable synonyms. They are fundamentally separate entities:

  • Git: An open-source, local command-line distributed version control tool installed on your personal machine. It requires zero internet access to create repositories, make commits, switch branches, or view history.
  • GitHub: A commercial cloud hosting platform and web interface for Git repositories. GitHub provides remote storage, issue tracking, continuous integration (GitHub Actions), and code review workflows (Pull Requests). Competitors include GitLab, Sourcehut, and self-hosted Gitea.

3. The Immutable Object Database (.git)

When you type git init, Git creates a hidden directory named .git. Inside sits a key-value object store located in .git/objects/. Git has four fundamental object types, all keyed by their SHA-1/SHA-256 cryptographic checksums:

  • Blobs: Store raw file content (data only, no filenames or permissions).
  • Trees: Represent directory structures, mapping filenames to blob hashes and sub-tree hashes.
  • Commits: Contain a pointer to a top-level Tree object, parent commit hashes, author metadata, timestamp, and the commit message.
  • Annotated Tags: Permanent references to specific commits.
$ git cat-file -p HEAD
tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
parent a7f10b83b3d11b5e5b3f1c84138a0b0219c99182
author Julian Vance <julian@rootnode.internal> 1760100000 -0400
committer Julian Vance <julian@rootnode.internal> 1760100000 -0400

Refactor TCP socket buffer allocation
Silicon printed circuit board representing data trees and graphs
Figure 3: Directed Acyclic Graphs (DAGs): how Git links commit parent pointers into history.

4. The Three States of Git

Git manages your code across three distinct areas on your local machine:

  1. Working Directory: The actual physical files you edit in your code editor.
  2. Staging Area (Index): A binary cache file (.git/index) that holds the exact snapshot prepared for your next commit.
  3. Repository (HEAD): The permanent history of committed objects in the .git database.

5. Branching and Merge Strategies

In Git, a branch is not an expensive duplication of folders. A branch is simply a 41-byte text file containing a 40-character commit hash. Creating a branch with git branch feature is instantaneous because it just writes a pointer to the current commit.

Library archives representing version history and commit trees
Figure 4: Archival branches: navigating divergent lineages and merging history safely.

6. Remotes, Pull Requests & Reviews

When collaborating, you configure a remote repository (conventionally named origin). Running git push origin main uploads your local object database blobs and updates the remote branch pointer.

A Pull Request (PR) is a GitHub construct requesting that repository maintainers merge your branch into the canonical trunk. High-quality PRs feature atomic commits, descriptive summaries, and automated test suite passes.

7. Mastering Merge Conflicts

Merge conflicts occur when two branches alter the exact same lines of code within a file since their common ancestor. Git refuses to guess which change is correct, generating conflict markers: 

<<<<<<< HEAD
const port = 8080;
=======
const port = 3000;
>>>>>>> feature-branch

Resolving conflicts simply requires opening the file, choosing the correct code, removing the conflict markers, staging with git add, and completing the merge commit.

8. The Essential Command Suite

  • git status — Inspects working directory and index delta states.
  • git log --oneline --graph — Visualizes the commit graph DAG.
  • git diff — Compares unstaged working directory changes against the index.
  • git stash — Shelves uncommitted modifications to allow branch switching.

9. Frequently Asked Questions

What is the difference between `git merge` and `git rebase`?

merge creates a non-destructive merge commit tying two branches together, preserving exact history. rebase replays your feature commits on top of the target branch tip, creating a clean linear history by generating brand new commit hashes.

What does `git reset --hard` do?

It resets the current branch pointer, the index, and overwrites all uncommitted working directory changes to match the specified commit. Use with caution, as uncommitted changes cannot be recovered.