Git and GitHub for Absolute Beginners: A Practical Walkthrough

Git and GitHub are two different things that get talked about as one. Git is version control software that runs on your computer and tracks changes to your files over time. GitHub is a website that hosts copies of Git projects online, so you can back them up, share them, and collaborate with others. You can use Git without GitHub, but most people learn them together, so that's how we'll walk through it here.

The core idea: commits

Instead of saving one file that keeps overwriting itself, Git lets you save labeled snapshots of your project called commits. Each commit records exactly what changed, when, and (if you write a good message) why. This means you can always go back to any previous snapshot, compare two points in time, or understand exactly what changed and when something broke.

Setting up

Install Git from git-scm.com if it isn't already on your machine, then set your identity once — this gets attached to every commit you make:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

The everyday workflow

Almost everything you'll do as a beginner boils down to five commands, used in roughly this order:

1. git init — turns a regular folder into a Git-tracked project. You only run this once per project.
2. git status — shows what's changed since your last commit. Run this often; it's the command you'll use most.
3. git add <file> (or git add . for everything) — stages changes, telling Git "include this in the next commit."
4. git commit -m "message" — saves a snapshot of everything staged, with a short description of what changed.
5. git log — shows the history of commits, so you can see what's happened over time.

Where GitHub comes in

Once you have a Git project on your computer, GitHub gives you a place to store a copy online. This does two things: it backs up your work somewhere other than your laptop, and it lets other people view, download, or contribute to it. The core commands for this:

• git remote add origin <url> — connects your local project to a GitHub repository you've created on the website.
• git push — uploads your local commits to GitHub.
• git pull — downloads any new commits from GitHub that aren't on your local machine yet (useful when working across multiple computers or with collaborators).
• git clone <url> — downloads a full copy of someone else's (or your own) GitHub repository to start working on it locally.

Branches: working without breaking the main project

A branch is an independent line of development — a way to try something new (a feature, a fix, an experiment) without touching your project's main, working version until you're confident it's ready.

git branch new-feature       # create a branch
git checkout new-feature     # switch to it
# ...make changes and commit as usual...
git checkout main            # switch back to the main branch
git merge new-feature        # bring those changes into main

This pattern — branch, work, merge — is the backbone of how most real-world software teams collaborate without stepping on each other's changes.

What a "pull request" actually is

On GitHub specifically, a pull request (PR) is a request to merge one branch into another, along with a space for discussion, comments, and automated checks before it happens. It's less a Git concept and more a GitHub feature built around Git's branching — the mechanism teams use to review code before it becomes part of the main project.

Common beginner mistakes worth avoiding

• Committing sensitive files. Passwords, API keys, and personal data committed to Git history are difficult to fully remove later, even after deleting the file — treat "don't commit it" as the real rule, not "delete it afterward."
• Writing vague commit messages. "Fixed stuff" tells future-you nothing. A specific one-line summary takes ten extra seconds and saves real time later.
• Never running git status. It's the single best habit for avoiding surprises — always know what Git thinks has changed before you commit.
• Panicking at merge conflicts. They're a normal part of collaborative work, not a sign something's broken — Git marks exactly which lines conflict, and you simply choose (or combine) the correct version.

This is an introductory guide; it intentionally leaves out advanced topics like rebasing and submodules to keep the core workflow clear for first-time users.