Learn Git &
GitHub Properly.
A clear, hands-on learning path that takes you from your very first commit to branching, merging, and real collaboration.
You haven't started yet
Click any card below to begin — your progress saves automatically on this device.
Your Git & GitHub Roadmap
Tap any card to open the lesson. Work through them in order or jump to what you need.
What is Git & Why It Matters
Git is a distributed version control system that tracks changes to files over time, letting you and your team work on the same codebase without overwriting each other's work.
Installing & Configuring Git
Before making your first commit, Git needs to know who you are. This identity gets attached to every change you save.
Creating Your First Repository
A repository (or 'repo') is a folder that Git is watching. Once initialized, Git can track every change made inside it.
Staging & Committing Changes
This three-step rhythm — edit, stage, commit — is the heartbeat of working with Git. You'll repeat it constantly.
Branching: Working in Parallel
A branch is an independent line of development. Branching lets you experiment or build a feature without affecting the stable, working version of your project.
Merging & Resolving Conflicts
Once work on a branch is finished and tested, merging brings those changes back into another branch — usually main.
GitHub: Remote Repositories
A remote is a version of your repository hosted somewhere else — almost always GitHub. Connecting one lets you back up your work and share it with others.
Push, Pull & Fetch
Once your local repo is linked to GitHub, push and pull are how changes flow between your machine and the remote.
Pull Requests & Code Review
A pull request (PR) is a formal proposal to merge changes from one branch into another, reviewed by your team before anything is merged.
Forking & Open Source Contribution
Forking creates your own personal copy of someone else's repository on GitHub, which you can freely change without affecting the original project.
Undoing Changes Safely
Mistakes happen constantly. Git gives you several tools to undo them safely, depending on exactly what needs fixing.
Stashing & Tagging
Two handy tools for everyday Git work: stash for temporarily setting aside changes, and tags for marking specific points in history.
Issues, Actions & GitHub Pages
GitHub is more than file storage — it includes built-in tools for tracking work, automating tasks, and even hosting websites.
Quick Knowledge Checks
One short quiz per stage — pick a stage and see how much stuck
Loading question...
Git & GitHub Glossary
Plain-English definitions for the terms you'll keep running into
Repository (repo)
A folder tracked by Git that stores your project files plus the complete history of every change ever made to them.
Commit
A saved snapshot of your staged changes, stored permanently in the repository history with a unique hash, author, timestamp, and message.
Branch
A lightweight, movable pointer to a commit. Branches let you develop features or fixes in isolation without affecting the main codebase.
HEAD
A pointer that marks your current position in the repository — usually the tip of the branch you have checked out.
Merge
The process of integrating changes from one branch into another, creating a merge commit when the histories have diverged.
Merge conflict
Occurs when two branches have made different changes to the same lines of a file. Git cannot auto-decide which to keep and marks the conflict for you to resolve.
Remote
A version of your repository hosted elsewhere (e.g. on GitHub). 'origin' is the conventional name for the default remote.
Clone
Creates a full local copy of a remote repository — including all commits, branches, and history — on your machine.
Fork
A personal GitHub copy of another user's repository, stored under your account. Lets you freely experiment and propose changes via pull requests.
Pull request (PR)
A GitHub proposal to merge changes from one branch into another, enabling code review, discussion, and approval before the merge happens.
Staging area (index)
A middle step between editing files and committing. 'git add' moves changes here; only staged changes are included in the next commit.
Working directory
The local folders on your machine where you edit files. Changes here are 'unstaged' until you run 'git add'.
git add
Moves changes from the working directory into the staging area so they will be included in the next commit.
git push
Uploads your local commits to the remote repository, making them available to your team or backing them up online.
git pull
Downloads commits from the remote and immediately merges them into your current branch. Equivalent to 'git fetch' + 'git merge'.
git fetch
Downloads new commits and branches from the remote without merging anything. Lets you inspect changes before integrating them.
git rebase
Reapplies commits from one branch on top of another, producing a cleaner linear history instead of a merge commit.
git stash
Temporarily shelve uncommitted changes so you can switch tasks. Bring them back later with 'git stash pop'.
git revert
Creates a new commit that undoes the changes of a previous commit, without deleting history. Safe for shared branches.
git reset
Moves HEAD (and optionally the working tree) back to an earlier commit. Can rewrite history — use with caution on shared branches.
Commit hash (SHA)
A unique 40-character hexadecimal ID generated for every commit. Git also accepts the first 7 characters as a short form.
Tag
A permanent, human-readable label attached to a specific commit. Commonly used to mark release versions like 'v1.0.0'.
.gitignore
A text file listing patterns for files and folders Git should never track — e.g. 'node_modules/', '.env', '*.log'.
Fast-forward merge
A merge where Git simply moves the branch pointer forward because no diverging work exists. No extra merge commit is created.
Detached HEAD
A state where HEAD points directly to a commit instead of a branch. Commits made here won't belong to any branch unless you create one.
Upstream
The original repository a fork was created from, or the remote branch a local branch is tracking.
Cherry-pick
Applies the changes from a specific commit onto your current branch without merging the entire source branch.
git log
Shows the commit history of the current branch. Add '--oneline' for a compact view or '--graph' for a visual branch diagram.
git diff
Shows the line-by-line differences between files — e.g. between your working directory and the last commit, or between two branches.
Origin
The conventional shorthand name given to the primary remote repository — the one you cloned from or added first.
Issue
A GitHub feature for tracking bugs, feature requests, and tasks. Issues can be referenced in commits and pull requests.
GitHub Actions
GitHub's built-in CI/CD system. Workflows defined in YAML files run automatically on events like push or pull request.
Git & GitHub FAQ
Quick answers to the questions beginners ask most often
What's the difference between Git and GitHub?
Git is the version control software that runs on your computer and tracks changes to your files. GitHub is a website that hosts Git repositories online, adding features like pull requests, issues, and team collaboration on top of plain Git. You can use Git without GitHub, but GitHub needs Git to function.
Do I need an account to use Git?
No. Git itself works entirely offline on your own machine and never requires an account. You only need a GitHub account once you want to back up your work online or collaborate with other people through a shared repository.
What is a commit, exactly?
A commit is a saved snapshot of your project at a specific point in time, along with a message describing what changed. Commits build up your project's history, and you can return to any previous commit whenever you need to.
When should I create a new branch?
Create a branch whenever you start a new feature, bug fix, or experiment. Keeping work on its own branch means your main branch stays stable and deployable while you build and test elsewhere.
What causes a merge conflict, and is it a problem?
A merge conflict happens when two branches change the same lines of a file in different ways, and Git can't automatically decide which version to keep. It isn't a problem or a mistake — it's expected from time to time, and resolving it just means manually choosing which changes to keep.
What's the difference between git pull and git fetch?
Fetch downloads new commits from the remote repository but doesn't change your current branch, letting you inspect the updates first. Pull does both steps at once — it fetches and then immediately merges those changes into your current branch.
What is a pull request used for?
A pull request proposes merging changes from one branch into another, usually so teammates can review the code before it becomes part of the main project. It's GitHub's structured way of discussing, reviewing, and approving changes.
Can I undo a commit after I've already pushed it?
Yes. The safest approach on a shared branch is git revert, which creates a new commit that undoes the previous one without rewriting history. Rewriting already-pushed history with reset is possible but can cause problems for anyone else who already pulled that history.
What should go in a .gitignore file?
Anything Git shouldn't track: dependency folders, build output, environment files with secrets, log files, and editor-specific configuration. Keeping these out of version control keeps your repository clean and avoids leaking sensitive information.
What's the difference between forking and cloning?
Cloning downloads a copy of a repository to your local machine, but it stays connected to the same remote on GitHub. Forking creates an entirely separate copy of the repository under your own GitHub account, which you can then clone and modify independently of the original.
Is it okay to commit directly to the main branch?
For solo, low-stakes projects it's common and fine. For team projects, it's best practice to make changes on a separate branch and merge through a reviewed pull request, keeping main always in a stable, working state.
How often should I commit my work?
Commit whenever you reach a small, complete, logical change — not just at the end of the day. Frequent, focused commits make your history easier to read, easier to undo selectively, and easier for teammates to follow.