GitHub, explained the way a patient friend would.
For people who have never pushed, pulled or committed anything. Seven short stops, about 30 minutes, from "what is Git?" to running your own organisation and letting Claude do the typing.
Where are you starting from?
Skip whatever you already know. Every stop stands on its own.
The line
Filled stations are the ones you've visited on this device.
Git and GitHub are two different things
Most confusion starts here, so let's settle it first. One is a tool on your computer. The other is a website.
Already clear on this? Skip to stop 2 →
In shortGit keeps the history on your computer. GitHub keeps it online and lets people work on it together.
Git
A free program that watches a project folder and keeps every version you decide to save. It works offline, and nobody else sees it unless you share.
One common mix-up: Git is . It's a tool, the way Excel is a tool.
GitHub
A website that hosts Git projects. It gives your folder a home online so it's backed up, shareable, and other people (and tools) can work on it with you.
It's a company, owned by Microsoft since 2018. do the same job.
Laptops never talk to each other directly. They each sync with GitHub. That's why "is it on GitHub?" is the question that matters.
Do I have to use the black screen with typing?
No. There are three ways in, and they all do the same thing underneath.
| Way in | What it's like | Good for |
|---|---|---|
| github.com | Click "Add file", upload, edit a file in the browser | Quick fixes, reading, reviewing |
| GitHub Desktop | A free app with buttons for commit, push and pull | People who prefer clicking |
| Command line | Typing commands like git push | Speed, and what Claude uses for you |
If you use Claude Code, you mostly skip all three. You describe what you want in plain words and it runs the Git commands. This guide teaches you the words, so you know what it's doing and what to ask for.
A repository is one project, with its memory
Everyone shortens it to "repo". It's a folder, plus the complete history of every saved change to that folder.
Know what a repo is? Skip to stop 3 →
In shortA repo is a project folder that remembers every saved version of itself.
- the front page
- index.htmlthe website
- style.csshow it looks
- app.jshow it behaves
- things to never save
- LICENSEwho may reuse it
Left: what's in the folder right now. Right: its history, newest at the top. The repo is both.
Every repo has an address in this shape. Tap a part to see what it means.
Public or private?
Public means anyone on the internet can see the code (they still can't change it). Private means only people you invite can see it. Private repos are free and unlimited, so start private unless you mean to share.
One project, two copies
The same repo lives in two places: a copy on your computer, called local, and a copy on GitHub, called the remote (usually nicknamed ). They don't stay in sync on their own, unlike Dropbox. You move changes between them on purpose. That's stop 4.
A good rule of thumb
One repo per app or website. Your tracker app, your company website and this guide would be three repos. Keeping them apart means you can share one without sharing the others.
A commit is a save point with a note
Not every Ctrl+S. A commit is a deliberate of the project, with a short message saying what changed and why.
Comfortable with commits? Skip to stop 4 →
In shortStage what belongs together, commit it with a clear message, and you can always come back to it.
Packing the box
Imagine you're posting a parcel. You edited three files today, but only two belong to the bug you fixed. So you put those two in the box (stage them), write a label (the message), and seal it (commit). The third file waits for its own parcel. The box is called the .
Changed files · not saved yet
The box · staged, git add
History · commits, git commit
Put the two files that fix the date bug in the box, then commit.
You can always go back
Each commit stores the whole project as it was at that moment. So you can open any old version, compare two versions, or undo a change without losing anything. The comparison view is called a diff: green lines were added, red lines were removed.
That code under each message, like e05b7c1, is the commit's : its unique ID.
Writing a good message
Your future self, and anyone helping you, reads these. Start with a verb, say what changed, keep it under about 60 characters.
| Vague | Clear |
|---|---|
| fix | Fix renewal date showing a day late |
| changes | Add yearly price to the pricing page |
| final final v2 | Remove the old logo files |
Push, pull and clone move commits around
Your laptop and GitHub each hold a copy of the repo. These words are how commits travel between the two.
Push and pull feel natural? Skip to stop 5 →
In shortClone once, then pull to get changes and push to share yours.
| Clone | Download a repo from GitHub for the first time, with its whole history. You do this once per computer. |
| Push | Send your new commits up to GitHub. |
| Pull | Bring other people's new commits down, and fold them into your copy. |
| Fetch | Check what's new on GitHub without changing your files yet. A peek before a pull. |
Your laptop local
GitHub remote·origin
Why did my push get rejected?
Try it above: let a teammate push, then commit and push yourself. GitHub refuses, because it has commits you haven't seen. It won't let you overwrite them blindly. The fix is always the same: pull first, then push.
The habit that prevents most trouble: pull when you sit down to work, push when you get up. Small, frequent pushes are much easier to combine than one huge one.
Is it like Dropbox?
Close, with one big difference: nothing syncs by itself. That's deliberate. Half-finished work stays on your laptop until you decide it's ready to share.
Branches let you try things without breaking anything
A branch is a side line off the main timeline. You work there freely, and only join it back once it's right.
Already open pull requests? Skip to stop 6 →
In shortWork on a branch, open a pull request, get it reviewed, merge into main.
Every repo has a main timeline, called . It should always be in working shape, because it's what people download and what your website runs on. So new work goes on a branch: a copy of the timeline with its own name, like dark-mode. When it's ready, you merge it back into main.
What a pull request actually is
A pull request (PR) is a page on GitHub that says: "here's my branch, please pull it into main." It shows exactly what changed, line by line, and gives everyone a place to comment, ask for fixes and approve. The name is ; think of it as a merge request.
Add dark mode #12
Openwants to merge 2 commits into main from dark-mode
A pretend pull request. Tap the tabs: these three are what you'll look at on every real one.
When two changes collide
If you and someone else change the same line in different ways, Git can't guess which one wins. That's a merge conflict. It looks scary, but it's just Git asking a human to choose. The file gets markers like these:
To fix it: keep the line you want, delete the other line and all three marker lines, save, and commit. Or ask Claude: "resolve the merge conflict, keep the ₹99 price."
And a fork?
A is your own copy of someone else's repo, under your account. You use one when you can't push to the original: you change your fork, then open a pull request asking the owner to take your changes.
Accounts, organisations and who sees what
The part people get stuck on when they start a company or a side project. Here's how the pieces fit, using an example studio called Mundhra Labs.
Running an organisation already? Skip to stop 7 →
In shortOne account per person, one organisation for the company, one repo per app, and access given repo by repo.
Your questions, answered
Should I make a second GitHub account for my work email?
No. GitHub expects one personal account per person. Keep the account you have, and add your work address to it under Settings → Emails. You can even make the work address the primary one later. All your work, personal or company, lives under one login.
What exactly is an organisation?
A shared account that owns repos on behalf of a group, like a company or a studio. Nobody logs in "as" the organisation. People log in with their own accounts and are given a role inside it.
It has its own @name and page (github.com/mundhralabs), so your projects read as the studio's work, not your personal side projects. If someone leaves, you remove their access and the repos stay put. The Free plan includes unlimited public and private repos and unlimited collaborators.
Can I add a new email ID to a repo?
Sort of: you add a person, not an email. In the repo's Settings → Collaborators (or your organisation's People page) you can type someone's GitHub username or their email. If that email has no GitHub account yet, they get an invite and create one, free.
The access then belongs to their account. If they later change their email, they keep access. If they leave, you remove the account.
Can one of my apps have its own @name, like @tracker?
Not inside an organisation. @names belong only to people and organisations. An app is a repo, and its address is github.com/mundhralabs/tracker. In conversation people write it as mundhralabs/tracker.
The things that do get an @ inside an organisation are teams, written @mundhralabs/tracker-team, so you can give one group access to one app.
If an app ever becomes its own company, create a separate organisation (@tracker, if free) and transfer the repo there. GitHub keeps redirects from the old address.
How do I give someone only part of an app?
Access works per repo, not per folder. Anyone who can see a repo can see every file in it. So you have three choices:
- Give them the repo with a limited role. Fine when it's all right for them to see everything. Use Read if they only need to look, Write if they'll push changes.
- Split that part into its own repo. For example, keep the website separate from the app, or a design kit separate from the code. Then invite them to only that repo.
- Have them work through pull requests. They push to a branch, you review every change before it reaches main. You can make GitHub enforce this with a .
Whatever you choose, never keep passwords or secret keys in a repo. Then "seeing everything" is far less risky.
What's the difference between a member and an outside collaborator?
A member is part of the organisation and can be added to teams. An outside collaborator is invited to specific repos only, and isn't part of the organisation. Freelancers and agencies are usually outside collaborators.
The five repo roles
From least to most power. Pick the lowest one that lets the person do their job.
| Role | Can do | Typical person |
|---|---|---|
| Read | See and download the code, comment | An advisor, an auditor |
| Triage | Also sort issues and pull requests | A support or project person |
| Write | Also push branches and merge | A developer, a freelancer |
| Maintain | Also manage the repo's settings, minus the risky ones | A lead developer |
| Admin | Everything, including deleting the repo | You |
Setting up your own, in order
- Keep your personal account and turn on .
- Add your work email in Settings → Emails and verify it.
- Click + (top right) → New organization → Free. Pick the name carefully: it becomes the address.
- Create repos inside the organisation, private by default.
- Invite people per repo, or create a team per app and add people to teams.
In shortYou know enough to work with GitHub and to direct Claude on it. Keep the glossary and the stuck page handy.
Working with Claude: it types, you decide
Claude Code can run every Git command in this guide for you. Your job moves from typing commands to giving clear instructions and checking the result.
The amber stretch happens on a branch, so nothing reaches your live site until you merge.
What Claude can do in a repo
- Read the whole project and explain how it's put together.
- Create a branch, make changes, and commit them with sensible messages.
- Push to GitHub and open a pull request that summarises what changed, using GitHub's own command-line tool, .
- Read an error message and tell you what went wrong in plain words.
- With the Claude GitHub app installed on a repo, you can also mention
@claudein a pull request or issue comment and ask it to make a change there.
What stays your job
- Look at the Files changed tab before merging. You don't need to read code fluently, just check nothing unexpected is in there.
- Open the preview link, if your host gives one, and click around.
- Press merge yourself. Keep main as the version you've approved.
- Never paste passwords, secret keys or one-time codes into the chat or the code.
Things to say to Claude tap to copy
Push to go live
Hosting services such as Cloudflare Pages, Netlify and Vercel can watch a GitHub repo. Once connected, every change merged into main goes live by itself in about a minute. Every other branch gets its own , so you can see a change working before anyone else does. This is why main should always be in working shape.
Keep secrets out
A repo's history is forever. A password committed once stays in every copy, even if you delete the file later. Keep secrets in a file listed in .gitignore (often called .env), or in your host's settings.
If a secret ever lands in a commit, treat it as leaked. Change or revoke that key first, then clean up the repo. Some keys are designed to be public, like a website's ; check before panicking.
Glossary
Every word you'll bump into, explained like you'd explain it to a friend.
I'm stuck
The messages and moments that trip everyone up. Find yours, read the fix. Each one also has a sentence you can hand to Claude.
Cheat sheet
The commands you'll actually use, each with what it means in plain words. Words in CAPITALS are placeholders you replace.