GitHub Basics

What GitHub actually is

5 min read

GitHub is a website and platform where people store projects, track every change made to them, and work on them together. Think of it as Google Docs version history, a shared project folder, and a to-do board, rolled into one and built for files like code, web pages and documentation.

It is not only for programmers. Students, designers, researchers, writers and project managers use it to keep a safe history of their work, collaborate, and publish websites. GitHub describes itself as a platform that supports the whole software process, from planning work through deploying it.

Git vs. GitHub

6 min read + 31 min video (optional, watch later)

Git is free, open-source software that runs on your computer. It tracks changes to files and lets you merge your work with other people's work safely. GitHub is a website that hosts Git projects in the cloud and adds collaboration tools on top.

An easy comparison: Git is the engine, GitHub is the garage, parking lot and car-sharing club. You can use Git without GitHub, but GitHub is built on Git.

Video 1: GitHub Basics Tutorial by Tiffany Thompson, freeCodeCamp.org (31 min). Covers creating a repo, branches and pull requests using the website. Recorded in 2018, so buttons may look slightly different today. Open on YouTube

Repositories and commits

7 min read + practice

A repository (or "repo") is a project folder that GitHub tracks. It holds your files plus the complete history of changes. A commit is a saved snapshot of your project at one moment, with a short message describing what changed. Commits are the beats of your project's history.

There are two copies of most repos: the local copy on your computer and the remote copy on GitHub. You push commits up to GitHub and pull other people's commits down. Clone means downloading a full copy of a repo for the first time.

Video 2: Git and GitHub Crash Course by Gwen Faraday, freeCodeCamp.org. Covers common terms, installing Git, cloning, adding files, pull requests and branching. Open on YouTube

Branches

6 min read + practice

A branch is a parallel version of your project where you can experiment without touching the main, working version. Most repos have a default branch called main. When you want to try a redesign or fix, you create a new branch, work there, and only bring changes back to main when they are ready.

Pull requests and merging

7 min read + 1 hour video (optional)

A pull request (PR) is a proposal: "I made changes on this branch. Please review them and add them to main." On a PR, people can see exactly what changed, leave comments, request fixes and approve. When everyone is happy, you click Merge pull request.

GitHub's own Hello World exercise walks you through this: create a repo called hello-world, make a branch, edit the README, open a pull request, and merge it. It takes about ten minutes and is the best hands-on practice for this lesson.

Video 3: Git and GitHub Crash Course for Beginners by Sumit Saha, freeCodeCamp.org (about 1 hour, published Dec 2025). Covers staging, commits, branches, merge conflicts, pull requests and more. Open on YouTube

GitHub for site and app builders

4 min read

You do not have to type Git commands to benefit from GitHub. Many website and app tools connect to it for you:

• AI app builders (such as Lovable or Replit) can sync a project to a GitHub repo, giving you a backup, a change history, and a way to hand code to another developer. Check each tool's current docs for how to connect.
• WordPress themes and custom plugins are often kept in a repo, so you can roll back a bad update and track client-specific changes.
• Shopify theme code can be connected to a GitHub repo so changes are versioned and reviewable.
• Automation and prompts: scripts, prompt libraries and config files are easy to store and version in one place.
• Hosting: GitHub can publish simple websites and run automated deployments when you merge.

Best practices

4 min read

• Commit small and often, with clear messages
• Never work directly on main for risky changes; use a branch
• Write a README that says what the project is and how to run it
• Use a .gitignore file to keep junk and private files out of the repo
• Pull before you start working so you have the latest version
• Describe pull requests so reviewers know what and why
• Use issues to track tasks and bugs
• Add a license if you share a project publicly

git clone <url>        # download a repo
git status             # what changed?
git add .              # stage changes
git commit -m "msg"    # save a snapshot
git push               # send to GitHub

Common pitfalls and safety

4 min read

• Committing .env files or keys
• Making a private project public by accident (check visibility when you create a repo)
• Huge commits with a vague message like "changes"
• Editing the same file on two branches without syncing, which causes a merge conflict
• Confusing Git with GitHub, or "clone" with "fork"

Knowledge check

4 min · 10 questions

Glossary

Sources and next steps

• GitHub Docs: What is GitHub?
• GitHub Docs: Hello World
• GitHub Docs: GitHub flow
• GitHub Docs: Git cheatsheet
• GitHub Docs: Ignoring files
• GitHub Docs: Storing your secrets safely
• GitHub Docs: GitHub glossary
• GitHub Skills (free hands-on courses)
• freeCodeCamp: GitHub Basics Tutorial (Tiffany Thompson)
• freeCodeCamp: Git and GitHub Crash Course (Gwen Faraday)
• freeCodeCamp: Git and GitHub Crash Course for Beginners (Sumit Saha)