Introduction to Git: Version Control Explained from Scratch

Git is the version control system underlying virtually every software project. It solves three problems: tracking who changed what and when, enabling parallel development through branches, and providing a mechanism to recover from mistakes.

The common misconception is that Git is just a backup system. It is not. Git is a content-addressable DAG (directed acyclic graph) of snapshots. Understanding this mental model separates engineers who blindly run commands from those who can recover from any state, resolve complex conflicts, and design efficient branching strategies.

This guide covers the fundamentals, then layers on production-grade insights: when rebases go wrong, how to recover from force-push disasters, and why your branching strategy directly impacts deployment velocity.

What Is a Repository and Why Does Git Need One?

Before you run a single Git command, you need to understand the word 'repository' — because it comes up constantly. A repository (usually shortened to 'repo') is just a folder on your computer that Git is actively watching and tracking. That's it. The moment you tell Git to watch a folder, that folder becomes a repository.

Inside every Git repository, Git creates a hidden folder called .git. This is Git's private notebook where it stores the entire history of your project — every version of every file, every message you attached to your saves, and every branch you've ever created. You'll almost never need to touch that .git folder directly, but knowing it exists explains the magic: as long as that folder is there, your full history is safe.

Think of the repository as a library and the .git folder as the librarian's filing cabinet in the back room. Your actual files are the books on the shelves that you read and edit. The filing cabinet tracks every edition of every book ever checked in, who edited it, and what changed between editions. You work with the books; Git manages the filing cabinet automatically.

Creating a repository is the very first step in any Git workflow. You'll either initialise a fresh one from scratch, or clone (download) an existing one from a platform like GitHub. Let's start from scratch.

# Step 1: Create a new project folder and navigate into it
mkdir my-first-project
cd my-first-project

# Step 2: Tell Git to start tracking this folder
# This creates the hidden .git folder inside my-first-project
git init

# Step 3: Confirm that Git is now watching this folder
# The .git folder only appears when you pass the -a flag (show hidden files)
ls -a

# Step 4: Check the current state of the repository
# At this point there are no files yet, so Git will say it's a fresh repo
git status

Your First Commit: How Git Actually Saves Your Work

In Git, saving your work isn't called 'saving' — it's called 'committing'. A commit is a permanent snapshot of your project at a specific moment in time. Think of it like taking a photograph of your entire project folder. You can take as many photographs as you want, and you can always look back at any photo from any point in the past.

Here's the part that trips up every beginner: Git uses a two-step process to save work, and for good reason. First you 'stage' your changes (step 1), then you 'commit' them (step 2). Staging is like putting items into a box before you seal and label it. It lets you choose exactly which changes go into a commit — maybe you changed three files but only want to snapshot two of them right now. That's completely valid.

The command for staging is git add. The command for committing is git commit. Every commit requires a message — a short human-readable note explaining what changed and why. These messages are invaluable six months later when you're trying to remember why a certain change was made. Write them like you're leaving a note for your future self, because you are.

The analogy: staging is packing the box, committing is sealing it, labelling it, and putting it on the archive shelf permanently.

# We're inside my-first-project (from the previous step)

# Step 1: Create a real file with some content
echo "# My First Project" > README.md
echo "This project is tracked by Git." >> README.md

# Step 2: Check what Git sees — it notices the new file but isn't tracking it yet
# Git calls untracked files 'untracked' — they exist in the folder but not in Git's history
git status

# Step 3: Stage the file — tell Git 'yes, include this file in the next snapshot'
# The dot (.) means 'stage everything in the current folder'
git add README.md

# Step 4: Check status again — README.md is now in the 'staging area'
git status

# Step 5: Commit the staged file with a descriptive message
# -m lets you write the message inline — always use present tense, e.g. 'Add' not 'Added'
git commit -m "Add README with project description"

# Step 6: View the commit history — you'll see your commit with its unique ID
git log --oneline

Branches: How to Experiment Without Breaking Anything

Here's where Git goes from 'useful' to 'genuinely magical'. A branch is an independent line of development that runs parallel to your main code. You can create a branch, make all kinds of experimental changes in it, and your main code is completely untouched. If the experiment works, you merge the branch back in. If it doesn't, you delete the branch and it's as if it never happened.

Every Git repository starts with one default branch, usually called main (older projects may call it master). This is your stable, production-ready code. Nobody should push broken code directly to main. Instead, every new feature or bug fix gets its own branch.

Picture a river. The main river is your main branch — it keeps flowing steadily. When you want to try something new, you dig a side canal (a new branch). You do all your experimental digging in the canal. If the canal works great, you reconnect it to the main river (merge). If it floods and turns into a swamp, you just fill it back in (delete the branch) — the main river never knew anything happened.

This is the exact workflow used at every professional software company on earth. Features developed on branches, reviewed, then merged. Understanding this is what separates someone who 'knows some Git commands' from someone who actually understands Git.

# We're continuing inside my-first-project with our first commit already made

# Step 1: See all existing branches — the asterisk (*) shows your current branch
git branch

# Step 2: Create a new branch called 'add-contact-page'
# Naming convention: use lowercase, hyphens, descriptive names — never spaces
git branch add-contact-page

# Step 3: Switch to the new branch so our changes happen there, not on main
git switch add-contact-page

# (Older Git versions use 'git checkout add-contact-page' — both work)

# Step 4: Create a new file on this branch
echo "# Contact Page" > contact.md
echo "Email us at: hello@myproject.com" >> contact.md

# Step 5: Stage and commit the new file — this commit lives ONLY on add-contact-page
git add contact.md
git commit -m "Add contact page with email address"

# Step 6: Switch back to main and notice contact.md is GONE from your folder
# It's not deleted — it simply doesn't exist on the main branch yet
git switch main
ls

# Step 7: Merge the work from add-contact-page into main
# Now contact.md will appear in main and the commit history merges too
git merge add-contact-page
ls

# Step 8: Delete the branch — the work is merged, we don't need it anymore
git branch -d add-contact-page

Configuring Git and Connecting to GitHub — The Full Picture

Git runs entirely on your local machine — everything we've done so far lives only on your computer. That's great for personal version control, but most real projects need a remote home so your team can access the code, or so you don't lose everything if your laptop dies. That's where platforms like GitHub, GitLab, and Bitbucket come in.

Think of your local repository as your personal notebook and GitHub as the shared whiteboard in the office. You do your thinking and drafting in your notebook, then when you're ready, you share your updates to the whiteboard. Your colleagues can pull your updates from the whiteboard into their own notebooks.

Before any of this works, Git needs to know who you are. Every commit is stamped with a name and email address so your team knows who made each change. This is a one-time setup on your machine. After that, you point Git at your remote repository with git remote add, push your work up with git push, and pull your teammates' work down with git pull.

You don't need a GitHub account to learn Git locally, but you'll want one before you share any project or apply for jobs — your GitHub profile is your public portfolio.

# ── PART 1: One-time global configuration ──────────────────────────────────

# Tell Git your name — this appears on every commit you ever make
git config --global user.name "Alex Johnson"

# Tell Git your email — use the same email as your GitHub account
git config --global user.email "alex.johnson@example.com"

# Set VS Code as your default editor (optional but recommended for beginners)
git config --global core.editor "code --wait"

# Confirm your settings look correct
git config --list

# ── PART 2: Connect your local repo to GitHub ───────────────────────────────
# Assumes you've created an empty repo on github.com called 'my-first-project'

# Add the remote — 'origin' is the conventional name for your primary remote
# Replace YOUR_USERNAME with your actual GitHub username
git remote add origin https://github.com/YOUR_USERNAME/my-first-project.git

# Verify the remote was added correctly
git remote -v

# ── PART 3: Push your local commits to GitHub ───────────────────────────────
# -u sets 'origin main' as the default so future pushes just need 'git push'
git push -u origin main

# ── PART 4: Pull the latest changes from GitHub (use this daily) ────────────
# This fetches + merges any changes your teammates pushed since your last pull
git pull origin main

Frequently Asked Questions