Git VS GitHub: The Beginning of Version Control

Have you felt that familiar anxiety after staring at a terminal full of Git commands, or scrolling through a GitHub repository jammed with branches, pull requests, and merge conflicts? It’s a common hurdle.

Many of us have been there, unsure whether our last commit was a step forward or if we had just created a bigger mess.

But here’s the thing, once you understand the basics & the difference between Git and GitHub, everything starts to make sense.

Git and GitHub are terms you will often hear linked, but they actually serve different purposes.

Why You Need Git in the First Place

Working solo on a project? You might survive with basic file saving (for now). But the moment you add even one more developer into the mix, everything starts to get messy.

If you and your teammate are working on the same file and you complete your changes and send the file to your project head. Meanwhile, your teammate downloads the same file, makes different changes (maybe even deletes your additions by mistake), and sends that version instead. Now:

• Your changes are gone.
• You don’t know who deleted what.
• There’s no timestamp.
• There’s no log. No backup. No way to reverse the damage.

This is exactly what Git fixes.

• Track every change made to every file.
• Know exactly who made the change and when.
• Roll back if something breaks.
• Work in parallel with other developers without stepping on each other’s toes.

Git

Git is a Distributed Version Control System (DVCS) created by Linus Torvalds (yes, the Linux guy) back in 2005. It’s like having a rewind button and a collaborative notebook for your entire codebase.

What Makes Git So Powerful?

• Local Control: You don’t need internet or a central server. Everything happens locally. You can make commits, create branches, and review history on your machine.
• Branching & Merging: Want to try a new feature? Create a branch. If it works, merge it back. If it fails, delete it — no harm done.
• Commit History: Every change is saved as a “commit” — a snapshot of the code, along with who did it, when, and why.
• Commit History: Every change is saved as a “commit” — a snapshot of the code, along with who did it, when, and why.
• Distributed Design: Every developer has the full repository on their computer. So even if the main server crashes, your code is safe.

With Git, you’re not just writing code, you’re writing a history of decisions. You can see what worked, what failed, who made changes, and how the project evolved. It’s not just about saving code, it’s about saving context.

What Are Git States?

When you’re using Git, your project files aren’t just sitting there; they move through a few key stages.

Working Directory    →    Staging Area    →    Repository
     (Modified)            (Staged)           (Committed)
         |                     |                   |
    [git add] ────────────────→|                   |
                           [git commit] ──────────→|        

• Modified: This is your initial working state. You’ve made changes to a file, maybe added some code, fixed a typo, or removed a line. Git knows something’s different, but you haven’t yet told Git to prepare these specific changes for saving. It’s like writing notes on a draft document; they’re there, but not yet finalized for the official version. These changes won’t be part of your next save (snapshot) until you move them along.
• Staged: Now, you’ve decided which of your modified changes you want to include in your next save. When you “stage” a file, you’re essentially telling Git, “Hey, these particular changes are ready to be packaged up.” It’s like putting specific items into a box, preparing them for shipment. These are the changes that will be part of your next official snapshot. You do this using the git add command.
• Committed: This is the final step in the recording process. When you “commit” your staged changes, Git takes a permanent snapshot of your project at that exact moment, including all the changes you staged. It’s like sealing the box and sending it off. The changes are now officially saved in your project’s history. Each commit gets a unique ID and a message describing what was changed, creating a clear timeline. You use the git commit command to do this.

Git Basics

Git helps you track your project like a timeline. These key commands are your daily tools for saving, switching, sharing, and organizing code. Let’s break them down in a no-jargon, quick-read format.

git commit – Save Your Work

• Think of it as a “save point” in your project.
• It records all changes you’ve added using git add.
• Once committed, the changes are locked in your project history.
• Used when: You finish a task or fix it and want to save it permanently.

git checkout – Switch or Restore

• Let you move between branches or go back to a specific version.
• You can also use it to restore files to a previous state.
• You want to switch to a feature branch or undo changes.

git clone – Copy a Repository

• Downloads a full copy of a Git project from a remote source (like GitHub).
• You now have your local version to work on.
• You want to start working on someone else’s project.

git pull – Get Latest Changes

• Updates your local project with the latest changes from the remote repo.
• Combines fetch (get changes) + merge (apply them).
• You want to sync with the latest team updates.

git tag – Mark a Version

• Tags are fixed markers for specific commits , like labeling a release version.
• Unlike branches, tags don’t move.
• You release a version (e.g., v1.0) and want to mark it.

GitHub

Now let’s bring in GitHub. While Git lives on your local machine, GitHub lives in the cloud. It’s a platform built on top of Git that makes sharing, collaborating, and managing code easier, especially when working in teams.

What GitHub Brings?

• Remote Repositories: You can push your local code to GitHub so others can access it, contribute to it, or just admire it.
• Pull Requests (PRs): Want to contribute to a project? Fork it, make your changes, and submit a PR. It lets the team review and discuss your code before it’s merged.
• Issues & Project Boards: Need to report a bug? Open an issue. Planning features? Use GitHub’s project boards (like Trello, but made for devs).
• Community Features: You can star repos you like, fork projects to build on them, or join discussions to learn and contribute.
• Integration with Tools: GitHub works smoothly with tools like Jenkins, Slack, VS Code, GitHub Actions (CI/CD), SonarQube, and many more.

What Is a Git Repository?

A Git repository (or just “repo”) is where your entire project lives — all your files, folders, branches, commits, and history.

• It can be local, on your machine, when you run git init.
• Or it can be remote, hosted on platforms like:
• GitHub
• GitLab
• Bitbucket

Checklist for Hands-On:

In upcoming blogs, we will learn more commands and do some hands-on for better understanding. Before starting, ensure you have:

• Git installed (git --version)
• GitHub account created
• Basic terminal/command prompt knowledge
• Code editor ready (VS Code, Atom, etc.)

So… Git or GitHub?

The answer is: Both.

• Use Git to manage your code history, experiment safely, and undo mistakes.
• Use GitHub to collaborate, share, and build projects with your team or the world.