Sitemap
Dipali

Dipali

Stop Losing Your Code.
Start Using Git.

A clear, visual guide to Version Control Systems — from the basics to the Git workflow every developer needs to know.

6 min readMar 26, 2026

--

In this guide

  1. Why Every Developer Needs Version Control
  2. The Three Types of VCS, Explained Simply
  3. What Exactly Is Git?
  4. The Four Stages of Git
  5. Git vs GitHub — Not the Same Thing
  6. Branching: Work Without Breaking Things
  7. Quick Reference & Final Takeaways

Section 01

Why Every Developer Needs Version Control

Picture this: your team is three weeks into a customer project. Three developers, three laptops, three separate modules — each person working hard on their piece of the puzzle. Then one morning, a hard drive fails. A month of work, gone.

This isn’t a hypothetical. It happens all the time, and it’s entirely preventable. The solution is a Version Control System (VCS) — software that tracks every change to your code, lets multiple people collaborate without stepping on each other’s toes, and ensures your work is always backed up.

When code lives only on local machines, one crash means total data loss for that module.
When code lives only on local machines, one crash means total data loss for that module.
Backup & Restore | Collaboration | Branching & Merging | Tracking Changes

The one-line definition: A VCS tracks and manages changes to software code or other files, enabling multiple users to collaborate efficiently on the same project.

Section 02

The Three Types of VCS, Explained Simply

Not all version control systems work the same way. Over the decades, three distinct approaches have emerged — each solving a problem the previous one created.

1. Local Version Control System (LVCS)

The simplest approach: keep a version database right on your own machine. Every time you save, a new version is recorded locally. The fatal flaw? If your computer dies, so does every version of your code.

Examples: SCCS, RCS

LVCS: Versions are stored in a local database on the same machine you work on.
The problem: Everything — your working files AND all your saved versions — lives on one machine. One hardware failure = total loss.

2. Centralized Version Control System (CVCS)

CVCS moved the version database to a shared server. Now the whole team can commit their work to one central place and pull down updates. Collaboration: solved. But a new single point of failure emerged — the central server itself.

Examples: CVS, Perforce, Subversion (SVN)

CVCS: All developers share one central server. Great for collaboration, but one server crash = all code gone.
The problem: The central server is still a single point of failure. You also need a network connection just to commit or update your code.

3. Distributed Version Control System (DVCS)

Examples: Git, Bazaar

Why DVCS wins: Remote crashes? You still have your local copy. No internet? You can still commit. This is why Git became the industry standard.

Side-by-Side Comparison

Section 03

What Exactly Is Git?

Git stands for Global Information Tracker. It’s a free, open-source, distributed version control system that has become the backbone of modern software development.

“Git was created by Linus Torvalds in 2005 — the same person who created the Linux kernel — because no existing tool was powerful enough for the job.”

Written in C and built for speed, Git can handle everything from a solo side project to a codebase with thousands of contributors (like the Linux kernel itself). It’s platform-independent, completely free, and the third generation of version control systems.

A Brief History of Version Control

Git’s Three Main Purposes

Section 04

The Four Stages of Git

Understanding how Git thinks about your code is the key to using it effectively. Git organizes your work into four distinct stages — think of them as checkpoints your code passes through on its journey from idea to published.

Press enter or click to view image in full size
  1. Working Directory: This is your project folder — where you write, edit, and delete files. Run git init here to tell Git to start watching this folder. Think of this as your drafting table.
  2. Staging Area: Not everything you change should be committed. The staging area is where you carefully choose which changes go into your next snapshot. Use git add filename or git add . to stage files.
  3. Local Repository: When you run git commit -m "your message", Git takes a permanent snapshot of your staged changes and stores it in the hidden .git folder. Your full history lives here, offline.
  4. Remote Repository (e.g., GitHub): Run git push to upload your commits to a remote server like GitHub. Now your work is backed up, shareable, and visible to your team. Pull others' work down with git pull.

GitHub Alternatives: You don’t have to use GitHub. Other popular remote hosting platforms include GitLab, BitBucket, SourceForge, and AWS CodeCommit.

Section 05

Git vs GitHub — Not the Same Thing

This is one of the most common points of confusion for beginners. Here’s the clearest way to think about it:

When companies manage their own Git server in-house, they take on real responsibilities: what happens if that server crashes? Who manages security? Who ensures performance? GitHub handles all of this for you, at scale.

Alternatives to GitHub

GitLab : Open-source friendly, built-in CI/CD pipelines, self-host or cloud.

Get Dipali’s stories in your inbox

Join Medium for free to get updates from this writer.

BitBucket : Integrates tightly with Jira and the Atlassian suite.

SourceForge : One of the oldest platforms, still popular for open-source.

AWS CodeCommit : Deep integration with Amazon Web Services infrastructure.

Section 06

Branching: Work Without Breaking Things

Imagine you’re working on a stable, live product. You need to build a new feature, but you don’t want to risk breaking what’s already working. This is exactly what branches solve.

A branch is an independent line of development. You can create one, experiment freely, and when you’re confident the work is solid, merge it back into your main codebase — without ever touching it in the meantime.

Essential Branch Commands

git branchList all branches in your repo

git branch branchnameCreate a new branch

git checkout branchnameSwitch to an existing branch

git checkout -b branchnameCreate a new branch and switch to it immediately

git merge branchnameMerge another branch into your current one

git rebase branchnameReapply your commits on top of another branch for a cleaner history

git branch -D branchnameDelete a branch (after it's been merged)

git branch -m old newRename a branch

git cherry-pick commitidGrab a specific commit from another branch and apply it here

git stashTemporarily save uncommitted work so you can switch branches

git stash applyRestore the stashed work

Section 07

Quick Reference & Final Takeaways

Here’s a snapshot of the most important commands, organized by what you’re trying to do — bookmark this section.

Getting Started

git initStart a new repository in your current folder

git clone urlDownload an existing remote repository

git statusSee what's changed and what's staged

git log --onelineView a compact commit history

Saving Your Work

git add .Stage all changes in the current directory

git commit -m "msg"Save a snapshot with a descriptive message

git pushUpload your commits to the remote repository

git pullDownload and merge the latest changes from remote

Undoing Mistakes

git restore filenameDiscard changes in the working directory

git restore --staged filenameUnstage a file without losing your changes

git reset --soft HEAD^Undo the last commit but keep changes staged

git reset --hard HEAD^Completely wipe the last commit — use carefully

git reflogYour safety net — see all recent HEAD movements for recovery

Key Takeaways

  • Version control is not optional — it’s a professional standard. Start using it even on personal projects.
  • Git is distributed, meaning you always have a full local copy of your history — even offline.
  • The four stages (Working Dir → Staging → Local Repo → Remote) are the mental model everything else builds on.
  • Git and GitHub are different things: Git is the tool, GitHub is where you store your repos online.
  • Branches let your team build fearlessly. Merge when ready, and nothing onmaingets disrupted.
  • When in doubt,git statusandgit log --onelineare your best friends.

👉 Explore the full Git resource list here. https://medium.com/@dipaligunjal1145/list/git-19562044676f

--

--