I finally wrapped my head around what Git and GitHub are, the three areas (working → staging → commit), and the basic commands to actually use them.

This post is me journaling what I learned about branches, what HEAD really is, how to switch between them, and why actual companies live and breathe this stuff. I'll keep it simple, no fluff, just the parts that finally made sense to me.

Branches Are Just Pointers (Not Copies!)

A branch in Git is not a full copy of your code. It's super lightweight.

Think of your commit history as:

• Commit A → Commit B → Commit C

Each branch is basically a movable label (a pointer) that points to one of those commits, usually the latest one in that line of work.

When you create a new branch, Git doesn't duplicate all your files. It just makes a new pointer starting at the same commit your current branch is on.

Example:

• You have main pointing to Commit C.

• You run git branch feature-login

• Now feature-login also points to Commit C.

• Both branches share the same history up to C, zero extra space used.

Then you start working on feature-login, make Commit D → now feature-login moves forward to D, but main stays at C.

That's it. Branches are cheap and fast because they're just 40-character pointers (the commit hash) stored in a tiny file.

What is HEAD?

HEAD is Git's way of saying: "This is where you are right now."

More precisely:

• HEAD is a special pointer that always points to the current commit you're working on.

• Usually, HEAD points to a branch name (like main or feature-login).

• When HEAD points to a branch, we say you're "on" that branch. Any new commit you make will move that branch forward.

You can check where HEAD is with:

git branch          # shows branches, * marks current one (where HEAD is)

There's also something called "detached HEAD", when HEAD points directly to a commit hash instead of a branch. That happens if you checkout an old commit by hash. In detached mode, new commits don't move any branch, they're kind of floating until you create a branch there. For beginners, just avoid detached HEAD for now (stick to branch names).

Switching Branches (The Commands I Actually Use)

Super straightforward once you get it.

1. See what branches exist:

    git branch
   

2. Create and switch to a new branch in one command (most common):

    git checkout -b feature/add-dark-mode
    # shorthand for:
    # git branch feature/add-dark-mode
    # git checkout feature/add-dark-mode
   

3. Switch to an existing branch:

    git checkout main
    # or newer :
    git switch main
   

When you switch, Git updates your working directory to match the latest commit on that branch. Any uncommitted changes might come along (or Git will stop you if there's conflict).

Quick Bonus Topics That Helped Me

• Naming branches — Use descriptive names: feature/user-auth, bugfix/payment-error-500, experiment/new-ui. Prefixes help a lot.

• Delete branches after merge — git branch -d feature-done (local), and GitHub usually offers to delete remote after PR merge.

• git log --graph --oneline --decorate — Run this. It shows branches visually, super helpful to see where things diverged.

• Pull often — Before creating a new branch or switching back to main: git pull to stay up-to-date.

Thanks for reading, Keep committing.

This is my very first blog post.

I'm starting this space to document my learning journey as honestly and clearly as I can. I'm not pretending to be an expert, I'm just someone figuring things out, making mistakes, reading docs, watching tutorials, and slowly getting better at building stuff.

What is Git? What is GitHub?

Git

Git is a version control system — basically a time machine for your code.

It lets you:

• Save exact snapshots of your project at any moment (called commits)

• See exactly what changed between any two points in time

• Go back to any previous version if something breaks

• Experiment with new ideas safely (using branches) without touching your working code

• Work completely offline — everything happens on your computer first

Git was created by Linus Torvalds in 2005 to manage the Linux kernel. Today it's the standard tool used by almost every developer and team in the world. When you install Git, you get a command-line tool that lives on your machine. The moment you run git init in a folder, that folder becomes a "repository" and Git starts quietly keeping track of everything inside it.

GitHub

GitHub is not Git.

GitHub is an online platform (owned by Microsoft) that takes your Git repositories and puts them in the cloud so you can:

• Back up your work automatically

• Share your code with other people

• Collaborate with teammates (multiple people editing the same project)

• Show off your projects to the world (great for portfolios)

• Use powerful features like pull requests, code reviews, issue tracking, GitHub Actions (automation), and even free website hosting

You write and commit code using Git on your computer → you push those commits to GitHub → others can pull your code, make changes, and suggest improvements back to you.

What Exactly is a Repository?

A repository (repo) is a project folder + its complete version history.

Technically, when you run git init, Git creates a .git directory that contains:

• all committed snapshots (in compressed form inside objects/)

• references to branches and tags (refs/)

• configuration and index files

Every commit is a full snapshot of the project at that moment (though Git stores only the differences efficiently using delta compression and pack files).

• Local repo — on your computer

• Remote repo — usually on GitHub

The Three Core Areas of Git

Git manages your project in three distinct states:

1. Working Directory
   Your actual files — what you see and edit.
   Git compares them against the last commit (HEAD) to detect modifications.

2. Staging Area (also called the index)
   A middle layer stored in .git/index.
   When you run git add, Git copies the current version of those files into the index.
   This lets you commit exactly what you staged — even if other files are still changed or untracked.

3. Repository (committed history)
   Permanent snapshots created by git commit.
   Each commit is identified by a 40-character SHA-1 hash (e.g., a1b2c3d...).
   Commits point to a tree object (directory structure), parent commit(s), author, date, and message.

Visual summary of the flow:

Basic Git Commands — The Ones You’ll Use Every Day

1. git init

What it does: Turns a normal folder into a Git repository (repo). It creates a hidden .git folder that stores all the version history, branches, configuration, etc.

When to use it: The very first time you want Git to start tracking a project.

After this, Git is "watching" the folder. Nothing is tracked yet, you still need to add and commit files.

Tip: You only run git init once per project (unless you're starting fresh).

2. git status

What it does: Shows you the current state of your repo. It tells you:

• Which files are modified but not staged

• Which files are staged (ready to commit)

• Which files are new (untracked)

• Which branch you're on

When to use it: Literally all the time, before and after almost every command. It's your safety check.

Tip: Run git status first whenever you're unsure what's going on.

3. git add

What it does: Moves changes from your working directory to the staging area (also called the index). Staging lets you choose exactly what you want to include in the next commit.

When to use it: After you've made changes and you're ready to prepare them for committing.

Common ways to use it:

git add file.txt              # stage one specific file
git add css/style.css         # stage another
git add .                     # stage ALL changes (new + modified + deleted)
git add docs/                 # stage everything in the docs folder

Important: git add doesn't save anything permanently — it just prepares the snapshot.

4. git diff

What it does: Shows the actual line-by-line differences (deltas) between versions of your files.

Common uses:

• git diff → unstaged changes (working directory vs staging area)

• git diff --staged (or git diff --cached) → staged changes (staging area vs last commit)

• git diff HEAD → all changes since last commit (staged + unstaged)

Output might look like:

- Old line that was removed
+ New improved line added here

Tip: Use git diff before git add to double-check what you're about to stage.

5. git commit

What it does: Takes everything in the staging area and saves it as a permanent snapshot (a commit) in your repo's history. Each commit gets:

• A unique ID (SHA hash)

• Your message

• Author info

• Timestamp

• Pointer to parent commit(s)

When to use it: After staging — this is when you actually "save" your progress.

Basic usage:

git commit -m "Add user login form and validation"

(The -m lets you write a short message inline.)

Good commit message tip: First line = short summary (50 chars or less), then blank line, then details if needed.

6. git log

What it does: Shows the commit history — who changed what, when, and why.

Useful variations:

git log                       # full detailed history
git log --oneline             # compact: one commit per line (most useful!)
git log --oneline --graph     # shows branch merges visually
git log -p                    # shows the diff (changes) for each commit
git log --author="Tushar"     # filter by author
git log -3                    # show only last 3 commits

Thanks for reading my very first post. Here's to many more commits, many more lessons, and way fewer "final_v99" files.