Git and GitHub Explained for Beginners (With Real Examples)

The problem Git solves

I started programming long before Git was everywhere, and I remember what folders looked like in those days. site_backup, site_backup_old, site_NEW, site_NEW_fixed, and one called site_dont_touch. Nobody knew which was current. When a client said “the version from last Tuesday was better,” the honest answer was often “I think I overwrote it.”

Now picture a team of five editing the same files. Two people change the same paragraph. Someone emails a zip file. Someone else works from an older copy. Merging all of that by hand is miserable, and mistakes are guaranteed.

Version control is the fix. Instead of copying folders, you tell a tool when you have reached a meaningful point, and it stores a snapshot. The most popular version control system in the world is Git, created in 2005 by Linus Torvalds for the Linux kernel. Today it is used by solo students, small studios and the largest software companies alike.

Git vs GitHub: the part everyone mixes up

Beginners often use the two names as if they were one thing. They are not, and the difference matters.

• Git is software that runs on your own computer. It works offline. It does the actual tracking of changes.
• GitHub is a company’s website (owned by Microsoft) that hosts Git repositories in the cloud and adds features around them: pull requests, issue tracking, code review and project pages.

The analogy I use in workshops: Git is a camera, and GitHub is the photo-sharing site. You can take photos without ever uploading them, but the website makes it easy to back them up and show them to others. Similar sites exist, including GitLab and Bitbucket. They all speak Git.

The vocabulary you need (and nothing more)

Git has a reputation for jargon. In reality, you need about eight words, and each has a plain-English meaning.

How a change travels through Git

This is the single most useful mental model in the whole subject, and almost every beginner tutorial skips it. A change passes through four places.

• Working folder: the files you see and edit on your computer.
• Staging area: a waiting room where you choose exactly which changes go into the next snapshot.
• Local repository: the saved history of commits, stored in a hidden .git folder.
• Remote (GitHub): the copy online that teammates can reach.

The staging area surprises people. Why not save everything at once? Because it lets you craft tidy commits. Imagine you fixed a typo and also started a risky new feature in the same afternoon. Staging lets you commit the typo fix by itself, with a clear message, and leave the unfinished feature for later.

Setting up: install and introduce yourself

Download Git from the official site (git-scm.com) or install it with your system’s package manager. Then check that it works.

git --version

Next, tell Git who you are. Every commit carries a name and email, so this is a one-time setup.

git config --global user.name "Your Name"
git config --global user.email "[email protected]"
git config --global init.defaultBranch main

The last line makes new repositories start with a branch called main, which matches what GitHub uses today. Older installs may still default to master, so setting it avoids confusion.

Your first repository, step by step

Let us track a small recipe collection. Open a terminal, make a folder and start Git inside it.

mkdir recipes
cd recipes
git init

Git replies with something like:

Initialized empty Git repository in /home/you/recipes/.git/

Now create a file called pasta.txt with three lines of text in any editor, then ask Git what it sees.

git status

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	pasta.txt

nothing added to commit but untracked files present (use "git add" to track)

“Untracked” means Git sees the file but is not recording it yet. git status is your best friend: run it constantly, especially when confused. Now stage the file and commit it.

git add pasta.txt
git commit -m "Add pasta recipe"

[main (root-commit) a1b2c3d] Add pasta recipe
 1 file changed, 3 insertions(+)
 create mode 100644 pasta.txt

Congratulations, you have made your first snapshot. The odd string a1b2c3d is the start of a commit’s unique ID. (Yours will look different; the examples here use made-up IDs.) Add a sauce recipe and a typo fix the same way, and your history looks like this.

git log --oneline

1f2e3d4 (HEAD -> main) Add dessert
7c8d9e0 Fix typo
e4f5a6b Add sauce
a1b2c3d Add pasta recipe

Every dot in that chain is a version you can return to. That is the whole magic: history becomes a thing you can read, search and travel through.

Writing commit messages people will thank you for

A commit message is a note to your future self, and to everybody else. Compare these two histories:

• “stuff”, “fix”, “fix 2”, “asdf”
• “Add login form validation”, “Fix crash when email is empty”, “Remove unused styles”

The second tells a story. A few habits help: write in the imperative (“Add”, not “Added”), keep the first line under about 50 characters, and describe what and why, not how. Six months later, when something breaks, you will be searching that history for answers, and clear messages turn a two-hour hunt into a two-minute one.

Telling Git what to ignore

Not every file belongs in version control. Passwords, API keys, temporary files and huge generated folders should stay out. Create a plain text file named .gitignore and list patterns.

.env
node_modules/
*.log
.DS_Store

This is more than tidiness. Never commit secrets such as API keys or passwords. Once something is pushed to a public repository, bots can find it within minutes. If it happens, rotate the key immediately. Deleting the file later does not erase it from history.

Branches: safe places to experiment

A branch is simply a movable label on a line of commits. Your main branch holds the version that works. When you want to try something, you create a new branch, work there, and leave main untouched.

git switch -c feature/bigger-portions
# edit files, then
git add pasta.txt
git commit -m "Increase pasta portion size"

Think of it as photocopying a document to scribble on, with the guarantee that the original stays clean. If the idea works, you merge it in. If it does not, you delete the branch and nothing is lost.

When you are ready, switch back to main and merge.

git switch main
git merge feature/bigger-portions

Merge conflicts are not scary

Sometimes two branches change the same line. Git cannot guess which you want, so it stops and asks you to decide. It marks the file like this.

<<<<<<< HEAD
Use 200g of spaghetti
=======
Use 250g of spaghetti
>>>>>>> feature/bigger-portions

The top part is your current branch, the bottom part is the incoming one. Edit the file to keep what you want (and delete the marker lines), then git add it and git commit. A conflict is just Git being polite and asking a question. In teams, conflicts become rare once people commit small changes often and pull regularly.

Bringing in GitHub

So far everything has lived on your computer. Now let us put it online. Create a free account at github.com, click the button to create a new repository, and name it recipes. GitHub will show you the web address of your empty repository. Connect your local project to it and upload.

git remote add origin https://github.com/YOU/recipes.git
git branch -M main
git push -u origin main

Here origin is just the nickname Git gives to your main remote. The -u flag remembers the connection so that later you can type only git push and git pull.

A practical note on logging in: GitHub no longer accepts your account password for Git operations over HTTPS. Use a personal access token, set up SSH keys, or install the GitHub CLI or Git Credential Manager, which handle sign-in for you. Their setup pages walk through it in a few minutes.

To get a project that already exists on GitHub onto your machine, you clone it.

git clone https://github.com/YOU/recipes.git

That downloads every file and the whole history, and sets up origin automatically.

Pull requests: how teams actually work

On a team, nobody pushes straight to main. Instead, the loop looks like this.

A pull request (often shortened to PR) is a page on GitHub that shows exactly what changed between your branch and main. Teammates can comment on specific lines, request changes and approve. When everyone is happy, someone clicks Merge. Automated checks, such as tests, can run on the PR too, so a broken change is caught before it reaches the shared code.

I have watched this process save projects. A new developer once pushed a change that would have deleted a customer table. Two people spotted it in review because the diff showed hundreds of red lines where there should have been five. Without a pull request, that change would have gone straight to production.

Five real situations, five workflows

Tap through the tabs. Each one shows a realistic scenario with the actual commands.

git init
git add pasta.txt
git commit -m "Add pasta recipe"
git log --oneline

# discard edits you have not committed
git restore pasta.txt

# take a file back out of the staging area
git restore --staged pasta.txt

# undo a commit by adding a new opposite commit
git revert 7c8d9e0

git switch -c feature/search
# ...edit files...
git add .
git commit -m "Add search box"
git push -u origin feature/search
# open a pull request on GitHub, get a review, merge
git switch main
git pull

# click Fork on GitHub, then:
git clone https://github.com/YOU/project.git
cd project
git switch -c fix-typo
# fix the typo, then
git commit -am "Fix typo in README"
git push -u origin fix-typo
# open a pull request to the original project

git add index.html
git commit -m "Launch portfolio"
git push origin main
# On GitHub: Settings, Pages, deploy from branch main

You will notice the same handful of commands appearing in every tab. That is the good news: the entire daily workflow of most developers is built from perhaps ten commands.

A beginner’s cheat sheet

A daily routine you can copy

• Morning: run git switch main and git pull so you start from the latest version.
• Before starting a task: create a branch with git switch -c and a descriptive name.
• While working: run git status and git diff often, and commit each small finished step.
• When done: push the branch and open a pull request.
• After the merge: switch back to main, pull, and delete the old branch.

It feels like a lot at first, and then one day you realise you have stopped thinking about it. That is when Git becomes a superpower instead of a chore.

Seven mistakes beginners make (tap to open)

Quick quiz: test yourself

Tap each question to reveal the answer and the reasoning.

Frequently asked questions