Imagine you're writing an essay. You save it as "essay.doc," then make some changes and save a new version as "essay-v2.doc." Then you delete a whole paragraph and panic — but you can't get it back. That's what life is like without version control.

Now imagine this: every time you save, your computer automatically creates a snapshot of your entire project. You can go back to any snapshot at any time. You can experiment with a new feature, and if it doesn't work, you throw away the experiment in one command. Multiple people can work on the same project simultaneously, and their changes are automatically merged unless they conflict. This is what Git does.

And GitHub is where you store your Git repositories online so the world can see them, collaborate on them, and — critically — where hiring managers will look at your work before they even read your resume.

If you're learning to code — whether it's web development (HTML/CSS, JavaScript), data science, or Python (see our Python guide) — Git and GitHub are not optional skills. Every professional developer uses them every single day. Let's demystify them in this complete beginner guide.

Git vs GitHub: What's the Difference?

Let's get this straight once and for all. Most beginners (and even some experienced devs) use these terms interchangeably, but they're two completely different things:

Think of it this way: Git is like a file organizer app on your phone that keeps snapshots. GitHub is like iCloud — it stores those snapshots online and lets you share them with others. You can use Git without GitHub (many developers do, hosting repositories on their own servers), but GitHub is by far the most popular place to host Git repositories.

Other GitHub alternatives exist: GitLab, Bitbucket, and SourceForge. But GitHub is where 90% of open source projects live, and it's where employers will look for you. Start with GitHub — you can switch later if you want.

Installing Git (5 Minutes)

Let's get Git on your computer. The official installer is free and takes about 2 minutes:

  1. Go to git-scm.com/downloads.
  2. It will auto-detect your operating system (Windows, Mac, Linux) and start the download.
  3. Run the installer. On every screen, click "Next" with the default settings — they're all fine for beginners. On Windows, this will also install Git Bash, a Linux-style terminal you'll use for Git commands.
  4. After installation, open a terminal (Git Bash on Windows, Terminal on Mac/Linux) and run:
git --version

If it outputs something like git version 2.43.0, you're ready.

Your First GitHub Account

  1. Go to github.com/signup.
  2. Pick a username — this will be your developer identity forever. Choose something professional and memorable. "johndoe" is fine; "xXxGamerBoyxXx" is not. You can't change it easily later.
  3. Use a professional email and a strong password.
  4. Verify your email address.
  5. Fill out your profile: real name, location, a short bio ("Learning Python and web development | Building things that matter"), and a profile picture. This is your first impression to potential employers.

Core Git Commands You Need to Know (And Only Those)

Git has over 150 commands, but you'll use about 8 of them 95% of the time. Let's learn those — and skip the rest until you actually need them.

1. git init — Start a New Repository

Run this inside a folder to tell Git: "Hey, track everything in this folder from now on."

mkdir my-project    # Create a new folder (Linux/Mac)
cd my-project       # Go inside it
git init            # Initialize Git tracking here

Git creates a hidden .git folder inside my-project. That folder contains the entire version history of your project — don't delete it!

2. git clone — Copy an Existing Repository

Want to work on someone else's project? Or pull down your own project from GitHub to a new computer? Clone it.

git clone https://github.com/username/repository-name.git

3. git add — Stage Your Changes

When you create, edit, or delete files, Git notices. But it doesn't automatically save them. git add puts files into the "staging area" — a temporary holding zone — before you commit.

git add index.html          # Stage one specific file
git add .                   # Stage ALL changed files in the current folder

Think of the staging area like this: You're packing for a trip. You put clothes in a suitcase (staging area). You don't actually leave for the airport (commit) until you've packed everything you need. git add = pack. git commit = go to airport.

4. git commit — Save a Snapshot

This is the moment Git creates a permanent snapshot of your staged changes. The -m flag lets you write a commit message — describe what you changed and why.

git commit -m "Add dark mode toggle to settings page"

Good commit messages are specific. Bad commit messages say "update," "fix stuff," or "oops." Future-you (and potential collaborators) will thank you.

5. git push — Upload to GitHub

Commits live on your computer until you push them to GitHub. This connects your local repository to a remote one on GitHub and uploads your snapshots.

git push origin main

(More on why it's main and not master below.)

6. git pull — Download from GitHub

If someone else (or you on another computer) pushed changes to GitHub, pull them down to get the latest version.

git pull origin main

7. git branch — Work in Isolation

Branches let you work on new features without messing up your stable code. Your main (or master) branch always has the production-ready version. Feature branches are for experiments and new work.

git branch feature-log-in        # Create a new branch called "feature-log-in"
git checkout feature-log-in       # Switch to that branch
# (make changes, commit, etc.)
git checkout main                 # Switch back to main

8. git merge — Combine Branches

When your feature is done and tested, merge it back into main.

git checkout main
git merge feature-log-in

If you and someone else both changed the same lines, Git will show a merge conflict. This sounds scary but it's normal — Git marks the conflicting sections, you open the file, decide which version to keep (or write a combination), and commit. No data is lost.

Why "main" Instead of "master"?

GitHub renamed the default branch from "master" to "main" in 2020. Git itself still supports both, but all new GitHub repositories default to "main." Use "main" for all new projects — it's the modern standard.

Your First Real Workflow: Push a Project to GitHub

Let's walk through the complete flow. You have a project on your computer (let's say a Python script or an HTML page). You want to put it on GitHub so you can access it from anywhere and show it to others.

Step 1: Create a Repository on GitHub

  1. Log into github.com.
  2. Click the "+" icon in the top-right, then "New repository."
  3. Give it a good name (kebab-case is standard: weather-app, personal-site).
  4. Add a short description.
  5. Do NOT check "Add a README file" or "Add .gitignore" — we'll do this from the command line.
  6. Click "Create repository."

Step 2: Connect Your Local Project to GitHub

GitHub will show you a page with some terminal commands. Copy and run them in order, or use this template:

# Go to your project folder
cd /path/to/your/project

# Initialize Git (if not already)
git init

# Add all your files
git add .

# Commit
git commit -m "Initial commit"

# Add GitHub as the remote
git remote add origin https://github.com/YOUR_USERNAME/REPO_NAME.git

# Rename the default branch to main
git branch -M main

# Push!
git push -u origin main

The -u flag sets up "upstream tracking," so after the first push you can just type git push and git pull without specifying "origin main."

Step 3: Refresh the GitHub Page

Your files should now be visible on GitHub. That's it — you've successfully used Git and GitHub!

Making a Pull Request (Your First Open Source Contribution)

Pull requests (PRs) are how developers propose changes to projects. Here's the real-world scenario: you find a bug in someone else's project, you fix it in your own copy, you submit a PR suggesting they accept your fix. This is how every open source project on GitHub grows and improves.

Let's do this with octocat/Hello-World, a tiny demo repository GitHub created specifically for practicing pull requests:

  1. Fork the repository. On the Hello-World page, click the "Fork" button in the top-right. This creates your own copy (fork) of the repo under your account.
  2. Clone your fork. On your fork's page, click the green "Code" button and copy the URL. Then in your terminal: git clone https://github.com/YOUR_USERNAME/Hello-World.git
  3. Create a branch. git checkout -b fix-typo
  4. Make a change. Open a file in your code editor, fix something (a typo, add a comment), save it.
  5. Commit your change. git add . && git commit -m "Fix typo in README"
  6. Push your branch. git push origin fix-typo
  7. Open the pull request. Go to GitHub, open your fork's page. You'll see a yellow banner saying "Compare & pull request." Click it. Write a clear description of what you changed and why. Click "Create pull request."

Congratulations! You just made your first pull request. For real projects, a maintainer will review your code and either merge it, ask for changes, or close it. Either way, you've participated in how software is built collaboratively.

Building Your GitHub Portfolio (That Impresses Hiring Managers)

Your GitHub profile is your online developer resume. A potential employer will open it before they read your CV. Here's how to make it count:

Profile Tips

What Makes a Good Portfolio Project?

GitHub Pages: Free Web Hosting for Your Projects

Here's a huge bonus: GitHub will host your static websites for free on yourname.github.io. This is how you deploy your HTML/CSS site from Article 16, your JS projects from Article 17, or your personal portfolio.

How to Deploy with GitHub Pages:

  1. Create a GitHub repository called YOUR_USERNAME.github.io (yes, that exact name). Put your HTML files in it.
  2. Alternatively, if you want to host a project site, go to your project repo's Settings → Pages → Source, and select "main" branch. GitHub will publish it at yourname.github.io/repo-name/.
  3. Wait 1–2 minutes. Your site is live.

This is perfect for showing off your work to recruiters — instead of saying "I built a portfolio site," you can say "Here's the link."

Common GitHub Mistakes Beginners Make

A One-Week Git Challenge (5 Commands a Day)

The fastest way to learn Git is to use it daily. Here's a simple challenge: every time you work on a coding project this week, run these commands at the end of each session:

git status           # See what changed today
git add .            # Stage everything
git commit -m "Today's work: [description]"
git push origin main # Upload to GitHub

That's it. 4 commands, 30 seconds. After 7 days, you'll have 7 commits in your history and Git will feel like second nature.

Your GitHub Roadmap from Here

Git and GitHub are skills you'll deepen over time, but the basics you've learned here cover 90% of what you need for solo projects and small teams. As you progress, you might explore:

Final Thought

Git was created in 2005 to help Linux kernel developers collaborate on a massive, distributed project. Today, it's used by every software team on the planet — from one-person startups to Google. When you learn Git and GitHub, you're not just learning a tool — you're joining a global community that builds software together, sharing knowledge, and improving each other's work.

Your next step: open your terminal, create a test repository, and run git init. Welcome to the world of version control. 🔧