Git & GitHub, explained like someone's actually next to you.
You don't need a tech background to read this. You need five minutes, a willingness to click things, and a tolerance for typing words into a black box. That's genuinely it.
Written byAnanya Raghu
ForAnyone who DM'd asking "how do I even start"
FormatClick-to-run, not watch-and-forget
↓ scroll — it's interactive the whole way down
00Before the commands — what this actually is
Forget the diagrams for a second. Here's the plain version.
GitHub is a shared table, not a filing cabinet.
"A common platform where people from one team come together to brainstorm — not verbally, not in a chat where you just write ideas down — but somewhere you actually execute them. Everyone can see what you're doing. Everyone can comment on it. And everyone can push their changes into one central place that's live — executable in real time."
That's the whole idea. Most explanations make Git and GitHub sound like accounting software for code. They're not. They're a way for a group of people to work on the same thing, at the same time, without standing over each other's shoulders — while still being able to see exactly what everyone did, and undo it if it was wrong.
👁️
Visibility, not secrecy
Nobody's work happens in a black box. Every change anyone makes is visible to the whole team — not described after the fact, but shown, exactly as it happened.
💬
Comments on real work
Feedback doesn't happen in a separate chat thread disconnected from the thing being discussed. You comment directly on the change itself, in context.
⚡
Live, not theoretical
This isn't a planning doc. When someone pushes a change, it becomes part of the real, running, executable project — immediately.
On version control — the idea underneath all of this
Here's the part that took the fear out of it for me: nothing is ever really gone. If you make a change and it turns out to be wrong, you're not stuck — you didn't overwrite the old version, you added a new one on top of it. Git keeps every version you've ever committed to, like a stack of saved checkpoints. You can flip back to any one of them. That single idea — that you can always go back in time — is what "version control" means. It's the reason you're allowed to experiment without being scared of breaking something permanently.
00.5The thing nobody explains first
Before any of this — where even are you?
This is the single most common beginner mistake, and it has nothing to do with Git. It's not knowing which folder you're standing in.
Every command you type happens somewhere — inside whatever folder your terminal is currently "in." Git doesn't ask "which project do you mean?" — it just acts on the folder you're already standing inside when you hit enter. If that folder is the wrong one, Git will quietly do exactly what you asked, just to the wrong place. That's not a Git bug. That's just what "run this here" means.
A path is just an address
A path is the full address of a file or folder on your computer — the same way a postal address says exactly which building, on which street, in which city. Two kinds:
Absolute path
The full address, from the very top
Starts from the root of your computer. Works no matter where your terminal currently is. /home/ananya/docking-project on Linux/Mac, or C:\Users\Ananya\docking-project on Windows.
Relative path
Directions from where you're standing
Depends on your current location. cd docking-project only works if you're already in the folder that contains it — same as "turn left" only makes sense from where you're standing.
The three commands you need before any Git command
Command
What it does
pwd
"Print working directory" — tells you exactly which folder you're currently standing in. Run this constantly. When in doubt, run pwd.
ls
Lists everything inside your current folder, so you can see what's actually here before acting on it. (Windows Command Prompt uses dir instead.)
cd <folder>
"Change directory" — moves you into a folder. cd .. moves you up one level, out of the current folder.
cd ~
Takes you straight to your home folder — the default starting point of most terminals, and not usually where your projects should live.
mkdir <name>
Creates a new, empty folder with that name, inside wherever you currently are.
Try it — find yourself, then move
This is the exact sequence to run before starting any new project, every single time.
ananya@laptop — bash
$
This four-step check — where am I, what's here, move in, confirm — takes ten seconds and prevents almost every "why did Git track my whole computer" mistake.
The mistake this prevents — and how to recover if it already happened
If you ever run git add . and see Git staging files you don't recognize — .bashrc, .cache, IDE config folders, anything that isn't your project — stop immediately. That means you ran git init in your home folder instead of your project folder, and Git is now trying to track your entire computer.
If you're mid-commit-message in the editor it opened (you'll know — it looks like a wall of text starting with # Please enter the commit message), don't save it. In nano, press Ctrl + X, then N to exit without saving — that aborts the commit safely. Then run rm -rf .git to delete the accidental repository (your actual files are untouched — this only removes Git's tracking of them). Then cd into the correct project folder and start over.
What "CLI" means — and why GitHub has one too
CLI stands for Command-Line Interface — it's just the proper name for "the terminal," the black box where you type text commands instead of clicking buttons. Everything we've done so far with git is a CLI tool. GitHub also has its own CLI tool, separate from Git itself, called gh — it lets you create repositories, open pull requests, check issues, and authenticate your account, all from the terminal, without opening a browser at all.
When the CLI genuinely beats the browser: creating a repo and pushing your first commit in one move, scripting repetitive tasks across many repos, working from a machine without easy browser access, or simply staying inside the terminal instead of breaking focus to alt-tab into Chrome twenty times a day.
When the browser still makes more sense: visually reviewing a pull request line-by-line, managing repository settings and collaborator permissions, or anything where seeing the layout matters more than speed. Most people end up using both — CLI for the fast repetitive stuff, browser for anything that needs a careful look.
01The engine
What Git actually is
Git is the tool. GitHub is the website. People mix them up constantly — let's fix that immediately.
Git is a program that lives on your computer. It doesn't need the internet. It doesn't need an account. Its entire job is to watch a folder on your machine and remember every version of every file in it, every time you tell it to. That's all version control is — a tool that takes snapshots of your work, on command, and lets you return to any snapshot later.
GitHub, which we'll get to in Act 2, is a website that stores copies of these Git snapshots online, so other people can see them and add their own. Git is the camera. GitHub is the photo album everyone can flip through together.
Works offlineFree, open sourceCommand-line toolCreated by Linus Torvalds, 2005
Installing it
This is a one-time, five-minute thing. Pick your operating system below.
Windows
Download Git for Windows from git-scm.com — it installs Git plus "Git Bash," a terminal you'll actually use.
git --version
Run this after installing to confirm it worked. You should see a version number, not an error.
macOS
Open Terminal and type the command below. If Git isn't installed, macOS will offer to install it for you.
git --version
Alternatively, install via Homebrew with brew install git.
Linux
Almost always pre-installed. If not, one line in your terminal does it.
sudo apt install git
(Debian/Ubuntu — other distros use their own package manager, same idea.)
Try it — your first conversation with Git
Below is a real, working terminal. Nothing here will affect your actual computer — it's a simulation so you can see exactly what Git says back to you, in order, with zero risk. Click each button in sequence.
ananya@laptop — bash
$
Click each step in order — Git's real responses are shown exactly as they'd appear on your machine.
What just happened — in order
01
Working directory
Your actual files, as you're editing them. Untracked, unsaved, just sitting on disk.
git init
→
02
Staging area
A holding zone. You choose exactly which changes you want to save next.
git add .
→
03
Repository (commit)
A permanent snapshot, saved with a message, that you can always return to.
git commit -m "..."
This three-step rhythm — edit → stage → commit — is something you'll do dozens of times a day once this clicks. It feels mechanical at first. It becomes muscle memory fast.
What a "repository" actually is
A repository (everyone says "repo") is just a folder that Git is watching. The moment you run git init inside a folder, Git quietly creates a hidden subfolder called .git there. That hidden folder is the entire history of your project — every commit, every version, every branch. Delete it, and Git forgets everything; the folder becomes a normal folder again.
Branches — working on ideas without touching the main version
A branch is a parallel copy of your project where you can try something — a new feature, a risky change, an experiment — without affecting the version everyone else is using. When it works, you merge it back in. When it doesn't, you delete the branch and nothing was ever at risk.
The core commands you'll actually use
Command
What it does
git init
Turns the current folder into a Git repository. Run once, per project.
git status
Shows what's changed, what's staged, what's not tracked yet. Your most-used command, by far.
git add <file>
Moves a specific file into the staging area. Use git add . to stage everything at once.
git commit -m "msg"
Saves a permanent snapshot of everything staged, with a message describing what changed.
git log
Shows the full history of commits — every snapshot ever saved, in order.
git branch <name>
Creates a new branch — a parallel version of the project to experiment in.
git checkout <branch>
Switches you into a different branch.
git merge <branch>
Pulls the changes from another branch into the one you're currently on.
git diff
Shows the exact lines that changed, before you commit them.
git revert
Undoes a specific commit by creating a new commit that reverses it — safe, doesn't erase history.
02The shared table
What GitHub adds on top
If Git is the camera, GitHub is where everyone's photo albums live side by side, in public, with comments open.
GitHub takes the local history Git already built on your machine and puts a copy of it online — at a URL anyone with access can visit. That's the entire mechanism that makes teamwork possible: instead of emailing zip files back and forth, everyone points their local Git at the same online repository.
Installing the GitHub CLI — push straight from the terminal
Before connecting a repo the manual way, it's worth setting up gh once — GitHub's own command-line tool. After this one-time setup, creating a repo on GitHub and pushing your code to it becomes a single line, no browser tab required.
terminal — installing & authenticating gh
$ sudo apt update && sudo apt install gh -y
Installing: gh
Setting up gh (2.46.0-3) ...
→ this installs the GitHub CLI tool itself, separate from git
$ gh auth login
? What account do you want to log into? GitHub.com
? What is your preferred protocol for Git operations on this host? HTTPS
? Authenticate Git with your GitHub credentials? Yes
? How would you like to authenticate GitHub CLI? Login with a web browser
! First copy your one-time code: 7909-4550
Press Enter to open github.com in your browser...
✓ Authentication complete.
✓ Logged in as your-username→ this is the ONLY time a browser opens — just to confirm it's really you, once
$ gh repo create annu --public --source=. --remote=origin --push
✓ Created repository your-username/annu on GitHub
https://github.com/your-username/annu
→ this single command does FOUR things at once: creates the repo on GitHub, sets it public, links your local folder to it, and pushes your code — all in one line
Reading the --source=. --remote=origin --push flags
--source=. means "use my current folder as the source." --remote=origin names the connection "origin," same convention as the manual method below. --push uploads your existing commits immediately, instead of just creating an empty repo. One real snag worth knowing: if you've already run git remote add origin manually before this, gh repo create will say unable to add remote "origin" — because that name is already taken. Fix it with git remote remove origin first, then re-run the gh repo create command.
Connecting your local repo to GitHub — the manual way
This is the moment your private project becomes a shared one. Worth knowing even with gh installed — it's what's happening underneath, and you'll hit situations (an existing repo someone else made, for instance) where you connect to it this way instead. Run through it below.
ananya@laptop — bash
$
This is the exact sequence that takes a project from "just on my laptop" to "the whole team can see and edit it."
The vocabulary, decoded
Push
Sending your commits up
Takes the commits saved on your machine and uploads them to GitHub, so everyone else can see them. git push
Pull
Bringing others' commits down
Downloads commits that teammates have pushed, and applies them to your local copy. git pull
Clone
Getting a full copy, once
Downloads an entire repository — every file and its whole history — onto your machine for the first time. git clone <url>
Fork
Your own copy of someone else's repo
Creates a personal copy of a repository under your own account — used when you don't have direct write access.
Pull Request (PR)
Asking to merge your changes in
A formal request: "here's what I changed, please review it before it joins the main project." This is where comments happen.
Issue
A tracked bug, task, or idea
A discussion thread tied to the project — for bugs to fix, features to build, or questions to answer.
A typical day, in sequence
This is the actual loop you'll repeat, over and over, once you're working with a team on GitHub.
01
Pull the latest changes
Before you touch anything, make sure you have what your teammates already pushed. git pull
02
Create a branch for your task
Keep your work isolated until it's ready. git checkout -b feature-name
03
Make your changes, commit as you go
Small, frequent commits with clear messages beat one giant commit at the end. git add . → git commit -m "..."
04
Push your branch to GitHub
Your branch is now visible online, even though it's not part of the main project yet. git push origin feature-name
05
Open a Pull Request
You're asking the team: "review this, comment if needed, merge it when it's ready."
06
Merge — and it's live
Once approved, your branch joins main. The change is now part of the real, executable project.
README.md — the front door of every repository
A README is the first thing anyone sees when they land on a repository. It's a plain text file written in Markdown (a lightweight formatting language — # text becomes a heading, **text** becomes bold) that GitHub automatically renders as a formatted page.
README.md
Viginyx
build: passinglicense: MITstatus: active
↑ badges — small status indicators, optional but common
A pharmacovigilance platform that simplifies adverse drug reaction reporting for pharmacists and patients.
Getting Started
git clone https://github.com/you/viginyx.git
cd viginyx
npm install
npm run dev
↑ the exact commands someone needs to run your project locally
Tech Stack
Next.js · Firebase · Groq (Llama 3.3) · OpenFDA API
A good README answers three questions in order: what is this, how do I run it, and what is it built with. That's the minimum. Everything else — contribution guidelines, screenshots, licensing — is added as the project grows.
Quick reference — GitHub-specific commands
Command
What it does
git clone <url>
Downloads a full copy of a GitHub repository to your machine.
git remote add origin <url>
Links your local repo to a GitHub repo, named "origin" by convention.
git push origin main
Uploads your committed changes to the "main" branch on GitHub.
git pull origin main
Downloads and merges the latest changes from GitHub into your local copy.
git fetch
Checks what's new on GitHub without merging it in yet — a safe "look before you pull."
git checkout -b <name>
Creates a new branch and switches to it, in one step.
.gitignore
A file listing what Git should never track — passwords, dependencies, local config.
Glossary
Repository / repo
A project folder, with its entire saved history attached.
Commit
A saved snapshot of your project at one point in time, with a message.
Branch
A parallel, independent line of work that won't affect others until merged.
Merge
Combining the changes from one branch into another.
Merge conflict
When two people changed the same line differently — Git asks you to pick.
Origin
The default name for the GitHub repo your local repo is linked to.
Main / master
The primary branch — the "official" current version of the project.
Fork
Your own copy of someone else's repository, under your account.
Clone
Downloading a full copy of a repository — files plus entire history — onto your machine.
Push
Uploading your local commits to GitHub, so others can see them.
Pull
Downloading and merging in commits that others have already pushed.
Pull Request (PR)
A formal request to merge your branch into the main project, opened for review and comments.
The two pairs people mix up most
Push vs. Pull
Direction of travel — that's the whole difference
Push = sending. You take commits sitting on your machine and upload them to GitHub. You push when you've made progress and want the team (and the cloud) to have it.
Pull = receiving. You take commits already sitting on GitHub and bring them down to your machine. You pull before you start working, so you're never editing an outdated version.
Fork vs. Clone
Whose copy is it — that's the whole difference
Clone = a copy on your machine, of a repo you already have write access to (your own project, or your team's). Changes you push go straight back to the same repo.
Fork = a copy under your own GitHub account, of someone else's repo you don't have write access to. You edit your fork freely, then open a Pull Request asking the original owner to accept your changes.
03The shortcut that's actually worth it
GitHub Copilot — for when you have a vision but not a CS degree
If you don't come from a tech background and you're trying to build something real anyway, this is the tool that closes that gap fastest.
GitHub Copilot is an AI coding assistant built directly into your code editor. You describe what you want in plain English — a comment, a function name, a half-written line — and it suggests the actual code to make it happen. It's not separate from Git or GitHub; it lives right inside the same workflow you've just learned, watching the files in your repo as you write.
Who this is actually for
If you're vibe-coding — building toward a product you can clearly picture, without formal training, and working within a limited budget of AI tokens or hours — Copilot is one of the highest-leverage tools available to you right now. You're not trying to become a software engineer overnight. You're trying to get from "I know what I want this to do" to "it does that," as directly as possible. Copilot is built for exactly that gap.
Why it's worth it
It writes the syntax, you keep the vision
You don't need to memorize every function or library — you describe the outcome, Copilot drafts the implementation, and you stay focused on whether it's actually solving your problem.
Why it's worth it
It works inside your real repo
Because it's tied into your editor, its suggestions are aware of the rest of your project — not generic code from nowhere, but something shaped around the files you already have.
Worth knowing
Token limits are a real constraint
Like any AI tool, heavier use costs more. Lean on it hardest for the parts you genuinely don't know — boilerplate, syntax, unfamiliar libraries — and write the parts you already understand yourself.
Worth knowing
It suggests — you still decide
Treat every suggestion as a draft from a fast, slightly overconfident collaborator. Read it before accepting it, especially anything touching data, money, or user information.
For someone in your exact position — non-CS background, real product vision, building solo or with a tiny team, watching the budget — Copilot isn't a crutch. It's the difference between an idea staying an idea and an idea becoming a working repo you can actually push to GitHub.
04How I actually learned this
Not from a module. From being willing to look clueless out loud.
"I didn't learn Git or GitHub the traditional way — sitting through modules, doing exactly what a course tells you to. I did real projects with a vision, and someone to guide me. The first thing I did was go talk to people and make myself look foolish in front of them."
That sentence is the whole method, honestly. If you don't show someone exactly where your understanding breaks down, they can't actually help you — they're just guessing at your level and explaining into the void. The discomfort of looking unsure in front of someone who knows more is the fastest path to actually closing the gap. It's not a fun feeling. It works anyway.
01
I had a real project, not a tutorial. Viginyx wasn't a "learn Git" exercise — it was a real product I needed version control for. The stakes made the learning stick.
02
I asked before I understood, not after. Going to someone and saying "I genuinely don't know what a commit is" felt humiliating in the moment. It's also the only way they could calibrate their explanation to where I actually was.
03
I had structured support running underneath. My mom funded a Scaler subscription that reinforced the fundamentals alongside the hands-on chaos — structured material plus real stakes, together.
04
I learned by doing the repo, not reading about repos. Every command in this guide is one I've actually typed into a terminal while something real was on the line — not copied from a cheat sheet.
If you take one thing from this whole page: don't wait until you understand Git to start using it. Start a real repo today, for something you actually care about, and let the confusion be the thing that drives you to ask the next question. That's a faster path than any course — including this guide.
↳Go deeper
Resources
This page is a starting point, not the whole map. These two playlists are where to go next.
Beyond this guide, the best place to actually learn this is GitHub's own official documentation — they built the tool, so naturally, they explain it best. Use this page to get oriented, then go straight to the source.