Git and GitHub — A Beginner's Guide

What Are Git and GitHub?

Git

Git is a version control system. It tracks changes in your files so you can:

See exactly what changed and when
Go back to any previous version of your project
Experiment safely without fear of breaking anything permanently

GitHub

GitHub is a website that hosts Git repositories online. It lets you:

Store your code safely in the cloud
Share projects publicly or keep them private
Collaborate with others on the same codebase

The relationship in plain terms:

Git    = the tool that runs on your computer
GitHub = the website that stores your Git projects online

Git can exist without GitHub. GitHub without Git would be nothing.

Installing Git

Download Git from git-scm.com and follow the installer for your OS.

After installing, verify it worked:

git --version

You should see something like:

git version 2.44.0

First Time Setup

Tell Git who you are. This information gets attached to every commit you make:

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

The --global flag means this applies to every repo on your machine. You only need to do this once per machine.

Verify your settings:

git config --list

Creating a Project

Create a new folder and navigate into it:

mkdir my-project
cd my-project

Initialize Git — this tells Git to start tracking this folder:

git init

You'll see a message like "Initialized empty Git repository." A hidden .git folder is created inside your project — that's Git's database. Never delete it manually.

Adding and Staging Files

Create a file:

touch hello.txt

Check what Git sees:

git status

Git will show hello.txt as untracked — it exists but Git isn't watching it yet.

Stage the file — tell Git to include it in the next commit:

git add hello.txt

Or stage everything at once:

git add .

Run git status again and you'll see the file is now listed under "Changes to be committed" — it's in the staging area.

NOTE

The staging area is a deliberate step that lets you choose exactly which changes go into each commit. You don't have to commit everything at once — you can stage and commit related changes separately, keeping your history clean and meaningful.

Committing Changes

A commit is a permanent saved snapshot of everything in the staging area:

git commit -m "Add hello.txt"

The -m flag lets you write the commit message inline. Write commit messages in the present tense describing what the commit does — "add hello.txt" not "added hello.txt" or "stuff".

TIP

Commit often. Small, frequent commits with clear messages are far more useful than large infrequent ones. If something breaks, small commits make it easy to pinpoint exactly where things went wrong.

Viewing History

See all previous commits:

git log

Output looks like:

commit 6b2g...
Author: Your Name <you@email.com>
Date:   Mon Sep 7 2026

    Add hello.txt

Each commit has a unique ID, author, date, and message.

Creating a GitHub Repository

Go to github.com and sign in
Click the + icon → New repository
Give it a name
Choose Public or Private
Click Create repository

You'll get a repository URL like:

https://github.com/username/my-project.git

Connecting Your Project to GitHub

Add GitHub as a remote — a named connection to the online repo:

git remote add origin https://github.com/username/my-project.git

origin is the conventional name for your primary remote. Verify it:

git remote -v

Pushing to GitHub

Upload your local commits to GitHub:

git push -u origin main

The -u flag sets upstream tracking so future pushes only need git push — no need to specify the remote and branch every time.

Your project now appears on GitHub. Every subsequent push is just:

git push

The Everyday Workflow

Most of the time, Git comes down to four commands repeated in a loop:

git status                      # 1. check what changed
git add .                       # 2. stage changes
git commit -m "describe change" # 3. commit
git push                        # 4. push to GitHub

TIP

Run git status constantly — before staging, after staging, before committing. It's your ground truth for what Git currently sees. Getting comfortable reading its output is one of the most valuable Git habits you can build.

Cloning a Repository

To download an existing project from GitHub to your machine:

git clone https://github.com/username/project.git
cd project

This copies the entire repo including its full commit history.

Pulling Updates

If someone else pushed changes to GitHub, or you pushed from another machine, pull the latest updates:

git pull

This fetches the remote changes and merges them into your local copy.

WARN

Always git pull before you start working — especially if you use multiple machines. Pushing without pulling first when the remote has new commits will result in a conflict you'll need to resolve.

SSH Keys — Connecting Your Machine to GitHub Securely

By default GitHub uses HTTPS for authentication, which requires entering your username and password (or a personal access token) every time you push. SSH authentication is the better alternative — once set up, you never have to authenticate manually again.

How it works

An SSH key is a matched pair of files:

Private key — stays on your machine, never shared with anyone
Public key — you give this to GitHub

When you push to GitHub, your machine and GitHub perform a cryptographic handshake. Your machine proves it holds the private key that matches the public key GitHub has on file — without ever sending the private key itself.

Generate an SSH key

ssh-keygen -t ed25519 -C "your@email.com"

-t ed25519 — the encryption algorithm. Ed25519 is modern, fast, and what GitHub recommends
-C "your@email.com" — a label so you remember what the key is for

When prompted for a save location hit Enter to accept the default (~/.ssh/id_ed25519). Hit Enter twice to skip the passphrase on a personal machine.

Add the key to the SSH agent

The SSH agent is a background process that holds your key in memory:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Copy your public key

cat ~/.ssh/id_ed25519.pub

Copy the entire output — it starts with ssh-ed25519 and ends with your email. One missing character breaks the connection.

Add the public key to GitHub

Go to GitHub → profile picture → Settings → SSH and GPG keys
Click New SSH key
Give it a descriptive title like Personal Laptop or Desktop WSL2
Paste your public key
Click Add SSH key

Test the connection

ssh -T git@github.com

Type yes when asked to confirm trust. A successful connection returns:

Hi username! You've successfully authenticated, but GitHub does not
provide shell access.

The "no shell access" part is expected — you can use Git commands but you can't SSH into GitHub like a server.

Use SSH URLs instead of HTTPS

When cloning a repo, use the SSH URL instead of HTTPS:

# HTTPS (requires authentication every time)
git clone https://github.com/username/repo.git

# SSH (authenticates automatically)
git clone git@github.com:username/repo.git

If you already have a repo cloned via HTTPS, switch it to SSH:

git remote set-url origin git@github.com:username/repo.git

TIP

Each machine needs its own SSH key added to GitHub. A key lives on one machine — you can't copy it to another machine and expect it to work. Generate a fresh key on each machine and add it to GitHub separately.

Working Across Multiple Machines

GitHub makes it straightforward to work on the same project from different machines — a desktop at home, a laptop on the go, a work machine. Here's the correct workflow.

Setting up a new machine

Every new machine needs:

Git installed and configured
A fresh SSH key generated and added to GitHub
The repo cloned locally

# 1. Configure Git identity
git config --global user.name "Your Name"
git config --global user.email "your@email.com"

# 2. Generate SSH key and add to GitHub (see SSH section above)

# 3. Clone the repo
git clone git@github.com:username/repo.git
cd repo

# 4. Install dependencies if needed (for example, a Node.js project)
npm install

The golden rule — always pull before you start

Before doing any work on any machine, always pull the latest changes from GitHub first:

git pull

This ensures you're working on the most up-to-date version. Skipping this step and pushing without pulling first leads to conflicts that need to be resolved manually.

The multi-machine daily workflow

# Start of session — get latest changes
git pull

# Do your work...

# End of session — push your changes
git add .
git commit -m "describe what you did"
git push

Treat GitHub as the single source of truth. Every machine syncs to and from GitHub — never directly to each other.

WARN

Never copy project files between machines using USB drives, email, or cloud storage like Dropbox. Always use git push and git pull to keep machines in sync. Mixing Git with other file transfer methods leads to conflicts and lost work.

What to do if you forgot to pull and get a conflict

If you pushed from machine A and then try to push from machine B without pulling first, Git will reject the push:

error: failed to push some refs to 'github.com:username/repo.git'
hint: Updates were rejected because the remote contains work that
you do not have locally.

The fix:

git pull        # fetch and merge the remote changes first
git push        # now push your changes

In most cases Git merges automatically. If the same file was changed in conflicting ways on both machines, Git will flag it and ask you to resolve the conflict manually — but this is rare if you follow the pull-first habit.

NOTE

If you're the only person working on a project across your own machines, conflicts are rare. They become more common when multiple people are editing the same files simultaneously — that's when branching strategies become important.

Useful Commands Reference

Command	What it does
`git init`	Initialize a new Git repo in current folder
`git status`	Show staged, unstaged, and untracked changes
`git add .`	Stage all changes
`git commit -m "msg"`	Save a snapshot with a message
`git push`	Upload commits to GitHub
`git pull`	Download and merge remote changes
`git log`	View full commit history
`git clone <url>`	Download an existing repo
`git diff`	See unstaged changes
`git branch`	List branches

Tips for Beginners

Commit often — small commits are easier to understand and debug
Write clear commit messages — your future self will thank you
Run git status constantly — it always tells you what to do next
Don't panic — Git history protects your work. Almost nothing is truly lost

The difference between a good and bad commit message:

✅ "Fix login bug on mobile"
✅ "Add SSH key setup guide"

❌ "changed stuff"
❌ "fix"
❌ "asdfgh"

Looking for a quick reference to keep open while working? Check out the Git Cheat Sheet.

What Are Git and GitHub?

Git

GitHub

Installing Git

First Time Setup

Creating a Project

Adding and Staging Files

Committing Changes

Viewing History

Creating a GitHub Repository

Connecting Your Project to GitHub

Pushing to GitHub

The Everyday Workflow

Cloning a Repository

Pulling Updates

SSH Keys — Connecting Your Machine to GitHub Securely

How it works

Generate an SSH key

Add the key to the SSH agent

Copy your public key

Add the public key to GitHub

Test the connection

Use SSH URLs instead of HTTPS

Working Across Multiple Machines

Setting up a new machine

The golden rule — always pull before you start

The multi-machine daily workflow

What to do if you forgot to pull and get a conflict

Useful Commands Reference

Tips for Beginners

Related