Git and GitHub Explained: How to Track, Undo and Share Your Work

by Souy Soeng /October 13, 2026

Messy files named report_final and report_final2 beside a clean Git history synced to GitHub

Git and GitHub are two tools that work as a pair. Git records snapshots of your project on your own computer, and GitHub hosts those projects online so other people can see them, copy them and contribute. Together they let you track every change, undo mistakes and work with a team, without a folder full of files named final, final2 and final-really-this-time.

This guide walks through the ideas in the same order they build on each other: why manual copies fail, what each tool does, how a snapshot gets saved, how branches let you experiment, and how push and pull move work between teammates. It finishes with the beginner mistakes that cause the most confusion and the simple habits that prevent them.

In short

Git is version control on your computer; GitHub is a website that hosts Git projects online.
Saving work is two moves: git add to stage a change, then git commit to save a snapshot with a message.
Branches give you a safe sandbox to try ideas, then you merge them back into main.
git push uploads your commits to GitHub; git pull downloads what teammates have pushed.
Write clear commit messages, keep secrets out of Git, pull before you push, and commit small and often.

Why saving files as final2 doesn't work

Most people start by saving copies by hand. You finish a report, save it as report_final, make a few edits, save report_final2, and later add report_final_REALLY. It feels manageable at first. Then you find yourself staring at the folder asking which file is the real one, and none of the names tell you what actually changed between them.

The trouble grows in three ways. First, changes get lost: you overwrite a good version and can't get it back, or a teammate emails you an older copy that quietly replaces your newer edits. Second, there is no clear history. Even when every copy survives, you can't easily see who changed what, or why, so finding the change that broke something becomes guesswork.

Third, teamwork becomes painful. When three people edit the same files, someone has to combine all of those edits by hand, which is slow and easy to get wrong. The core problem is that manual copies don't scale. That gap is exactly what Git was built to fill.

Lost changes: overwrite one copy and earlier work is gone.
No clear history: you can't see who changed what, or why.
Painful teamwork: merging everyone's edits by hand is slow and risky.

What is the difference between Git and GitHub?

The names are similar, but the jobs are different. Git is a version control system. It runs on your computer and records snapshots of your project over time. A helpful way to picture it is save points in a video game: each snapshot is a moment you can always return to, no matter what happens afterwards.

GitHub is a website that hosts Git projects online. Think of it as a shared space built specifically for Git. Once your project lives there, other people can see it, copy it and contribute to it. Git does the tracking; GitHub gives that tracked project a home everyone can reach.

Git exists for three reasons: to track a project's history safely, to make undoing mistakes easy, and to let many people work on one project at the same time. A short way to remember the relationship is that Git is the engine and GitHub is the meeting place.

Git: version control that records snapshots of your project on your computer.
GitHub: a website that hosts Git projects so others can see, copy and contribute.
Purpose: safe history, easy undo, many people on one project.

How do you save a snapshot in Git?

Everything in Git happens inside a repository. A repository is simply your project folder with Git switched on. You create one with git init, which turns on tracking for a folder you already have, or with git clone, which copies an existing project so you can start working on it.

From there, every save happens in two small moves. Say you edit a file called index.html. First you stage the change with git add index.html. Then you commit it with git commit -m followed by a short message describing what you did. The result is one new commit: a saved snapshot of your project at that moment.

The staging area is the step that confuses people most, so here is the reason it exists. It works like packing a box before you ship it. You choose exactly which changes go into the next snapshot, so each commit holds one clear, related idea instead of a jumble of unrelated edits.

A commit is a permanent save point with a message explaining it. Because every commit is a spot you can return to, a mistake later on stops being a disaster. You can look back through the history, see what changed, and go back to a version that worked.

Create a repo: git init, or git clone to copy an existing project.
Stage a change: git add index.html.
Commit: git commit -m with a message.
Result: one new commit you can return to.

What are Git branches and why use them?

Once you can save snapshots, a new question appears: how do you try something risky without breaking what already works? Branches are the answer. A branch is a separate line of work. You can change anything on it while the main version of your project stays safe and untouched.

Here is a typical flow. Main is your working version. You want to try a new idea, so you create a branch called new-menu and build it there. Whatever you do on new-menu stays on new-menu. If the idea flops, you delete the branch, and main is exactly as it was, as if nothing happened.

If the idea works, you merge the branch back into main, and Git combines the branch's commits for you. Sometimes two branches have changed the same lines. Git can't guess which version you want, so it asks you to choose. That situation is called a merge conflict, and it is a normal part of working with branches.

Branches also make parallel work possible. Each person or feature gets its own branch, so a whole team can experiment at once without stepping on each other's toes, then bring finished work into main when it is ready.

Safe sandbox: changes on a branch don't touch main.
Merge when ready: Git combines the branch's commits into main.
Merge conflict: when two branches changed the same lines, you choose.
Parallel work: each person or feature gets its own branch.

How do git push and git pull work with a team?

So far, everything has happened on one computer. Push and pull are how your work travels up to GitHub and back down to your team. Consider two teammates fixing a bug on the same website. Maya makes a commit on her laptop that fixes a broken login button.

Maya runs git push, which sends her new commit to the project's repository on GitHub. Then Sam, on his own laptop, runs git pull, and the fix lands on his machine. Sam now has Maya's work and can build on top of it, without anyone emailing files or combining edits by hand.

There is a useful side effect of pushing. Until you push, your commits only live on your own computer. Once they are on GitHub, you have a copy somewhere else too, so pushing also works as a simple backup. The bigger benefit is that GitHub becomes the team's one shared source of truth.

git push: upload your new commits to GitHub.
git pull: download commits others have pushed and add them to your copy.
Until you push, your work exists only on your computer.

Common Git mistakes beginners make

Git only helps if you use it well. The mistakes beginners make most often are not hard to avoid; they just take a little attention while the habits are forming. The first is writing vague commit messages. A message like fix or stuff tells future you nothing. Instead, write what changed and why, such as fix login button on mobile.

The second is committing passwords or secret keys. Once those are pushed to GitHub, other people may be able to see them, and they stay in the project's history. The fix is to keep secrets in files listed in .gitignore, which tells Git to skip those files entirely.

The third is forgetting to pull before pushing. If teammates have pushed new commits, your copy is out of date and GitHub rejects your push. Make it a routine: pull first, then push. Tying all of this together is the habit of small, frequent commits. Each one is easy to read and easy to undo.

Vague messages: describe what changed and why.
Committing secrets: list secret files in .gitignore.
Forgetting to pull: pull first, then push.
Better habit: small, frequent commits.

The Git and GitHub workflow in six steps

With the pieces in place, the whole journey from a plain folder to a shared project fits into six points. Each step builds on the one before it, which is why it helps to learn them in this order rather than memorising commands on their own.

If you are just starting, focus on the habit rather than the commands. Commit small, commit often, and share your work. Git tracks your history, GitHub shares it, and the routine becomes second nature after a few projects.

Git records snapshots of your project.
GitHub hosts and shares it online.
Start with git init or git clone.
Run git add, then git commit.
Branch to experiment, then merge back; pull first, then push.

Key takeaways

Git tracks your project's history on your computer; GitHub shares it online.
A repository is a project folder with Git switched on.
Staging lets each commit hold one clear, related change.
Branches let you experiment safely and merge only what works.
Push sends your commits to GitHub; pull brings teammates' commits to you.
Clear messages, no secrets, and pulling before pushing prevent most beginner problems.

Frequently asked questions

Is Git the same as GitHub?

No. Git is a version control system that runs on your computer and records snapshots of your project. GitHub is a website that hosts Git projects online so others can see, copy and contribute to them.

Why do I need to run git add before git commit?

git add puts changes into the staging area, where you choose exactly what goes into the next snapshot. This keeps each commit focused on one clear, related idea instead of mixing unrelated edits.

What happens if an idea on a branch doesn't work out?

You can simply delete the branch. Changes made on a branch don't touch main, so your working version stays exactly as it was.

What is a merge conflict?

A merge conflict happens when two branches changed the same lines and Git can't tell which version to keep. Git stops and asks you to choose before finishing the merge.

Why was my git push rejected?

A common reason is that teammates have pushed new commits and your copy is out of date. Run git pull first to bring in their work, then push again.

How do I keep passwords out of my GitHub repository?

Store secrets in files listed in .gitignore so Git skips them. This matters because anything pushed to GitHub may be visible to others and stays in the project's history.

Watch the full video on YouTube →

Tag

Ad