Git and GitHub for Absolute Beginners

Git and GitHub are two of the most important tools in a programmer’s life, and beginners often confuse them because the names sound alike. In plain terms: Git tracks changes in your code on your own computer, and GitHub is a website where you can store and share those tracked projects online. In this guide, you will learn what each one does, install Git, and push your first project to GitHub step by step.

Git vs. GitHub: What Is the Difference?

This is the number one point of confusion, so let us settle it clearly:

Git is a free program you install on your computer. It is a version control system — it records snapshots of your files every time you tell it to, so you can review old versions, undo mistakes, and experiment safely. Git works fully offline on your own machine.
GitHub is a website (owned by Microsoft) that hosts Git projects online. It adds collaboration features: sharing code, suggesting changes, tracking bugs, and showcasing your work to employers. You need a free GitHub account to use it.

An analogy helps: Git is like the “track changes” feature in a document editor, while GitHub is like Google Drive — a place to store the document online and collaborate on it. You can use Git without ever touching GitHub, but GitHub is useless without Git underneath.

There are alternatives to GitHub (GitLab and Bitbucket are the best known), but GitHub is the most popular, so it is the best one to learn first.

Why Version Control Matters

Git solves this cleanly with complete history, safe experimentation on branches, sane teamwork, and off-laptop backup:

Complete history: Every change is recorded with who made it, when, and a message explaining why. You can time-travel to any past state of your project.
Fearless experimenting: You can try a risky idea on a separate branch (a parallel copy of your work). If it fails, delete the branch — your main code is untouched.
Teamwork without chaos: Multiple people can work on the same project simultaneously, and Git helps combine their changes sensibly.
Backup and portfolio: Pushing your code to GitHub backs it up off your laptop and builds a public portfolio that employers actually look at.

Even if you code alone, Git is worth it for the undo power alone. Every professional developer uses it daily.

Installing Git and Setting It Up

Installation takes a few minutes:

Windows: Download the installer from git-scm.com and run it. The default options are fine for beginners.
macOS: Open Terminal and type git --version. If Git is missing, macOS will offer to install the developer tools — accept. Alternatively, install it with Homebrew: brew install git.
Linux: Use your package manager, for example sudo apt install git on Ubuntu/Debian.

Verify the installation with:

git --version

You should see something like git version 2.43.0. Next, introduce yourself to Git — every snapshot you save will be labeled with this identity:

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

Use the same email address you plan to use for your GitHub account. The --global flag means this setting applies to all your projects, so you only do it once.

Your First Repository: The Core Workflow

A repository (or “repo”) is simply a project folder that Git is watching. Let us create one and learn the three commands that make up 90% of Git usage.

Step 1: Initialize a repository

mkdir my-first-repo
cd my-first-repo
git init

git init creates a hidden .git folder that will store all the history. Your folder is now a repository. (Never delete or edit the .git folder directly.)

Step 2: Create a file and check status

Create a file called notes.txt with a line of text in it, then run:

git status

Git tells you that notes.txt is untracked — it sees the file but is not watching it yet. git status is your best friend: run it whenever you are unsure what is going on.

Step 3: Stage and commit

Saving in Git is a two-step process. First you stage the files you want to include, then you commit them as one snapshot:

git add notes.txt
git commit -m "Add notes.txt with first line"

Think of staging as putting items into a box, and committing as sealing the box and labeling it. The -m message is the label — write messages that explain why you made the change, not just what changed. Future you will be grateful.

You can stage everything at once with git add . (the dot means “this folder”). To see your history of snapshots:

git log --oneline

Each line shows a commit’s ID (a short code like a3f9c1d) and its message. That ID lets you return to any snapshot later.

Undoing Mistakes: Git’s Safety Net

Mistakes are normal, and Git gives you several levels of undo. Learn these in order of safety:

See what changed: git diff shows unstaged changes line by line, with - for removed lines and + for added ones.
Unstage a file: git restore --staged notes.txt takes a file back out of the staging box without touching its content.
Discard file changes: git restore notes.txt throws away unstaged changes and returns the file to its last committed state. Use carefully — discarded edits cannot be recovered.

Notice the pattern: nothing is truly lost until you explicitly discard it. Committed work is remarkably safe, which is why committing often — in small, logical chunks — is the single best Git habit you can build.

Branches: Safe Experimentation

A branch is an independent line of development. Your main line is usually called main (older projects may use master). When you want to try something risky — a new feature, a redesign — you create a branch, work there, and merge it back only if it works out.

git branch experiment
git switch experiment

You are now on the experiment branch. Make some changes, stage, and commit them — your main branch is completely unaffected. Check which branch you are on anytime with git branch (the current one has a star) or git status.

To bring the experiment back into main:

git switch main
git merge experiment

Git combines the two lines of work. If both branches edited the same lines, Git asks you to resolve a merge conflict — it marks the disputed section in the file, you edit it to keep what you want, then commit. The golden rule: keep main always working, and do experiments on branches.

Pushing to GitHub: Sharing Your Work Online

Now let us put your repository on GitHub. First, create a free account at github.com if you do not have one.

Create a new repository on GitHub: Click the “+” menu, then “New repository.” Name it my-first-repo, leave it public, and — important — do not check “Add a README file” (since your local repo already has content, starting empty avoids conflicts). Click “Create repository.”
Connect your local repo: GitHub shows you commands. In your project folder, run the ones under “push an existing repository”:
```
git remote add origin https://github.com/YOUR-USERNAME/my-first-repo.git
git branch -M main
git push -u origin main
```
Replace YOUR-USERNAME with your actual GitHub username. A remote named origin is just Git’s nickname for “the copy on GitHub.”
Authenticate: GitHub will ask you to sign in — this usually opens a browser window. Password authentication at the command line was retired, so follow the prompt; it is a one-time setup per computer.

After that, pushing future changes is one command:

git push

The -u flag you used the first time told Git that main tracks origin/main, so later pushes know where to go. To download changes (yours from another computer, or a teammate’s), use git pull. And to copy someone else’s repository to your machine, use git clone https://github.com/USER/REPO.git — cloning is how most open-source contributing starts.

One essential file to add early: a .gitignore file listing things Git should never track — passwords, API keys, and bulky generated files. A single line like *.log ignores all log files. Create it before your first commit on real projects.

Common Beginner Mistakes

Committing secrets: Never commit passwords or API keys. Once pushed to GitHub, assume they are public forever — even if you delete them later, the history remembers. Use .gitignore and environment variables instead.
Giant vague commits: A commit named “stuff” containing 40 changed files is useless history. Commit small, related changes with clear messages like “Fix login button alignment on mobile.”
Forgetting to pull before pushing: If a teammate pushed changes first, your push will be rejected. Run git pull, resolve any conflicts, then push.
Ignoring git status: When confused, run git status. It almost always tells you exactly what to do next.

Final Thoughts

You now understand the Git/GitHub split, you can initialize a repository, stage and commit changes, undo mistakes, work with branches, and push your code to GitHub for the world to see. That covers the daily workflow of millions of developers.

Your suggested next steps: first, create a GitHub account if you have not already, and push the practice repository from this guide — your profile’s first green square is a real milestone. Second, add a README.md describing your project; it becomes the front page people see on GitHub. Third, find a beginner-friendly open-source project and read its issues tab — fixing a tiny documented bug is the classic first step into collaborative coding.