What Is GitHub? Git & GitHub Explained Simply for Non-Techies and Vibe Coders

If you only want the simplest possible explanation:

Git is a system that keeps track of changes to a project.

GitHub is an online platform where Git projects can be stored and where people can collaborate on them.

Or even simpler:

Git tracks the history. GitHub gives the project and that history an online home.

GitHub explains the distinction in its What is GitHub? and About Git documentation.

But that definition becomes much more useful once you see what problem Git is actually solving.

Suppose you want a personal website.

Let’s call it:

yourname.com

You open an AI coding tool and type:

Build me a modern personal portfolio website.

A few moments later, the AI creates something.

Behind the nice-looking page are files.

Your project might look something like:

personal-website/

src/
public/
images/
package.json
README.md

You do not need to understand what any of those files do yet.

For now, all you need to know is:

Those files together make up your project.

You then ask the AI:

Make the homepage look more premium.

It changes some files.

Looks good.

Then:

Add dark mode.

Done.

Then:

Change the navigation.

Done.

Then:

Redesign the About section.

Done.

Then you ask for one more change.

And suddenly...

the website breaks.

The navigation disappears.

Dark mode stops working.

The design you liked 20 minutes ago is gone.

And you think:

Can I just go back to the version I had before?

This is where Git starts to make sense.

Think about Google Docs.

You write something.

You change it.

You change it again.

But Google Docs keeps a version history.

If today’s version is terrible, you can look back at an earlier version.

Git gives software projects a powerful form of version history.

Without Git, you might try to manage versions like this:

website
website-new
website-final
website-final-v2
website-final-v2-new
website-final-FINAL
website-final-FINAL-actually-final

That might survive for a tiny personal project.

Now imagine a product with thousands of files, dozens of developers and hundreds of changes every week.

The “final-final-2” strategy stops working very quickly.

Git solves that problem.

Instead of creating endless duplicate folders, Git keeps an organised history of how the project changed.

For example:

Created homepage
      ↓
Added About page
      ↓
Added dark mode
      ↓
Changed navigation
      ↓
Fixed mobile menu

Git can tell you what changed between those points.

So the simplest definition is:

Git is the system that tracks the history of your project.

No.

This is the single most important distinction in this entire guide:

Git is the version-control system. GitHub is a platform built around Git.

You can use Git without GitHub.

Git can work entirely on your computer.

GitHub is a website and cloud platform built around Git.

Imagine your website exists only on your laptop.

What if your laptop dies?

What if you buy another computer?

What if a developer wants to help you?

What if five people need to work on the project?

What if somebody wants to review a change before it becomes part of the project?

GitHub gives the repository a shared online home and adds tools for collaboration.

YOUR COMPUTER                       GITHUB

Your project                        Shared project
Git history          ←→             Git history
Local work                           Collaboration

A useful sentence to remember is:

Git works underneath. GitHub is the place people collaborate around it.

This is the part many beginner explanations skip.

When you’re vibe coding, several things can look like “the website”, but they are actually different.

1. YOUR EDITOR / AI TOOL
        ↓
2. YOUR PROJECT FILES
        ↓
3. GIT
        ↓
4. GITHUB
        ↓
5. YOUR HOSTING / DEPLOYMENT PLATFORM
        ↓
6. YOUR LIVE WEBSITE

These are not automatically the same thing.

Your editor or AI coding tool

This is where you make changes.

It could be Cursor, VS Code, an online AI builder or another development environment.

Your project files

These are the actual files that make up the website or application.

Git

Git tracks how those files change.

GitHub

GitHub can store a remote version of your Git repository online.

Your hosting or deployment platform

This is what actually serves the website or application to users.

Your live website

This is what people see when they visit something like:

yourname.com

That distinction answers one of the most common beginner questions:

If I push something to GitHub, does my website automatically change?

Not necessarily.

We’ll come back to that.

Now we reach a word you will see everywhere:

repository

Usually shortened to:

repo

A beginner-friendly way to think about it is:

A repository is your project together with the Git information and history used to track it.

GitHub’s Hello World guide starts with an even simpler analogy: a repository is like a folder that contains related items.

Your personal website might therefore have a repository called:

personal-website

Inside it could be:

personal-website/

src/
images/
public/
README.md
package.json

And Git keeps track of how those files change.

On GitHub, you might see something like:

saurav / personal-website

That basically means:

ACCOUNT / REPOSITORY

A repository can usually be public or private.

So when somebody says:

“Send me the repo.”

they usually mean:

“Send me the GitHub repository containing the project.”

Your repository can exist on your own machine.

That’s the:

local repository

And the shared copy can exist on GitHub.

That’s the:

remote repository

YOUR COMPUTER                         GITHUB

Local repository       ←──────→       Remote repository

This is why Git needs concepts such as push and pull.

You need a way to move changes between these places.

There are two common starting situations.

Situation 1: The project already exists on GitHub

Maybe you joined a company.

The company’s application is already in GitHub.

You need the project on your computer.

You clone it.

Situation 2: You created the project first

Maybe you vibe coded your personal website locally.

The files already exist on your computer, but GitHub knows nothing about them.

In that case, you can turn the project into a Git repository and publish or connect it to a GitHub repository.

So beginners should not memorise:

“Every Git project begins by cloning.”

It doesn’t.

Clone is for getting an existing remote repository onto your machine.

A new project can start locally and later be published to GitHub.

Suppose your website already exists on GitHub.

You buy a new laptop.

Or a new developer joins your team.

They need that project locally.

They can clone the repository.

GITHUB

personal-website
       │
       │ CLONE
       ▼

YOUR COMPUTER

personal-website

Clone essentially means:

“Create a local copy of this existing repository so I can work on it.”

Usually you clone a repository once when setting it up on a machine.

You do not normally clone the whole project every morning.

After that, you keep your existing copy updated.

If you click Download ZIP on GitHub, you get the project files.

If you clone the repository with Git, you get a working Git repository connected to its history and remote source.

For a one-off look at the files, ZIP may be enough.

If you want to keep working with the project using Git, cloning is usually the right mental model.

Repositories can have different lines of development called branches.

One branch is normally selected as the default branch.

On many modern GitHub repositories, that branch is called:

main

Think of main as:

The central line of the project that the team considers its primary version of the code.

Important:

main does not automatically mean “the live website”.

It is a Git branch.

Whether code from main gets deployed to a live website depends on how that project’s deployment system is configured.

Let’s return to your personal website.

Your current homepage looks good.

But you want to completely redesign it.

You could immediately modify your main line of work.

But what if the new design turns out to be terrible?

Instead, you create a branch.

────────────── main ──────────────
                \
                 \
                  homepage-redesign

That second line is a branch.

You can work there without immediately changing main.

So:

Branch = a separate line of work inside the repository.

Your branch could be called:

homepage-redesign

or:

feature/google-login

or:

fix/mobile-menu

Different teams follow different naming conventions.

The name matters less than the idea:

Work separately first. Combine it later when it is ready.

Imagine another developer changed the navigation yesterday and merged that change into main.

Your laptop might still contain the older version.

You don’t want to start your new feature from outdated code.

So a developer will often make sure their local main is current before creating a new branch.

Go to main
      ↓
Get the latest version
      ↓
Create a new branch
      ↓
Start working

Let’s say you’re working on:

homepage-redesign

You change the hero section, navigation, fonts and About section.

Those files have changed.

But changing a file and recording that change in Git’s history are not the same thing.

A commit is:

A recorded checkpoint in your project’s history.

You might create commits such as:

• Redesign homepage hero
• Improve mobile navigation
• Add new About section

A commit is not the same as pressing Save.

You may save your file 30 times while working.

A commit means:

“This set of changes is meaningful enough that I want Git to record it as part of the project’s history.”

Imagine you changed four things:

• Homepage
• Navigation
• Footer
• Contact form

But you only want the next commit to contain:

• Homepage
• Navigation

Git lets you choose which changes should be included.

That selection process is called:

staging

A common command for doing it is:

git add

Conceptually:

Everything I changed
        ↓
Select what belongs together
        ↓
GIT STAGING AREA
        ↓
COMMIT

You do not need to memorise the command yet.

Understand the idea first.

This causes unnecessary confusion because the same word is used twice.

Git staging area

This is where you select changes before creating a commit.

Changed files
     ↓
Git staging area
     ↓
Commit

Staging environment

This is a version of an application used for testing before it reaches real users.

Code
 ↓
Staging environment
 ↓
Production

Same word.

Completely different concepts.

You have now created a branch, changed files, staged the relevant changes and created commits.

But those commits may still exist only on your computer.

GitHub may not have them yet.

So you:

push

Push means:

Send your local commits to the remote repository.

MY COMPUTER → GITHUB

So when a developer asks:

“Did you push your changes?”

they usually mean:

“Are those commits available in the shared remote repository yet, or are they still only on your machine?”

Easy memory trick:

Push = away from me, towards GitHub.

Not necessarily.

This is extremely important for vibe coders.

A push simply means Git commits were sent to the remote repository.

That does not automatically mean:

• customers can see the change;
• the change has been approved;
• it is part of main;
• it has been deployed;
• your live website has changed.

GitHub and your live website are related, but they are not the same thing.

Now your homepage redesign is finished.

You want it to become part of main.

In a collaborative workflow, you create a:

Pull Request

Usually shortened to:

PR

A Pull Request basically says:

“Here are the changes I made. Please review them, discuss them if necessary, and then we can decide whether to combine them with the target branch.”

GitHub describes pull requests as a way to propose, discuss, review and merge changes.

A Pull Request lets reviewers see which files changed, what was added or removed, which commits are included and any discussion around the work.

The names make this unnecessarily confusing.

git pull

Means:

Bring newer remote changes to my local copy.

Pull Request

Means:

Review these proposed changes and potentially merge them into another branch.

Completely different things.

PULL
GitHub → my computer
PULL REQUEST
My branch → review → potentially merge

A Pull Request creates a place where another person can examine the proposed changes.

That’s:

code review

A reviewer might ask:

• Does the feature actually work?
• Could it break something else?
• Is there a security problem?
• Is this unnecessarily complicated?
• Does it follow the team’s standards?
• Do the automated tests pass?

If you’re building a tiny website alone, you might not have another person review every change.

Inside professional teams, review before merging is a common safeguard.

Your new homepage still lives on:

homepage-redesign

The central branch is:

main

The Pull Request has been reviewed and approved.

Now the changes can be:

merged

Merge means:

Combine changes from one line of development into another.

homepage-redesign
       │
       │ MERGE
       ▼
      main

Once merged, your redesign is now part of main.

Again:

that does not automatically mean it is already visible to customers.

Deployment is a separate concept.

Now imagine someone else is working on the website.

Your homepage redesign has been merged.

GitHub’s main contains the new version.

But their laptop still has the old version.

They need to update their local copy.

They:

pull

GITHUB → YOUR COMPUTER

The easiest memory trick is:

PUSH
My computer → GitHub
PULL
GitHub → My computer

You have a personal website.

The repository is already on GitHub.

You want to redesign the homepage.

Step 1: Get the project

GitHub
   ↓
Clone
   ↓
Your computer

Step 2: Get the latest version

Remote main
    ↓
Pull
    ↓
Local main

Step 3: Create a branch

main
  \
   homepage-redesign

Step 4: Make your changes

You use Cursor, VS Code, Claude, ChatGPT or another tool to edit the project.

Step 5: Check what changed

Git can show you which files have been modified.

Step 6: Stage the changes you want to record

Changes
   ↓
git add
   ↓
Git staging area

Step 7: Commit

Create a meaningful checkpoint:

Redesign homepage hero

Step 8: Push

Your computer
     ↓
   PUSH
     ↓
GitHub

Step 9: Open a Pull Request

Ask for the changes to be reviewed and eventually merged.

Step 10: Review

You, another developer and/or automated systems check the changes.

Step 11: Merge

Approved changes become part of:

main

That’s the fundamental workflow.

Imagine a travel startup.

Its website lets customers search for and book flights.

The product team wants to add:

Save Traveller Details

A product manager creates a task.

A developer picks it up.

The developer already has the repository cloned.

They first make sure their local main contains the latest work.

Then they create a new branch:

feature/save-traveller

They build the feature locally.

They test it.

They stage relevant changes.

They make commits.

They push the branch to GitHub.

They create a Pull Request.

Then additional safeguards may kick in:

• automated tests;
• build checks;
• security checks;
• code-quality checks;
• code review.

The developer makes any requested fixes, pushes again, and the Pull Request updates.

Once the required checks pass and the work is approved, it is merged into main.

GitHub supports status checks so teams can require builds, tests and other validations before important branches are merged.

The professional workflow isn’t fundamentally different from your personal website.

It simply has:

more people, more automation and more safeguards.

Now we leave Git itself and enter another part of software development:

deployment

Your customers do not visit your GitHub repository when they want to use your product.

The software needs to run somewhere.

That’s where environments such as:

development

staging

and:

production

come in.

Development is where software is being built and tested.

A developer’s own computer can be part of their development setup.

A company might also have shared development environments.

The important idea is:

Developers need somewhere they can build and break things without breaking the product for real customers.

Suppose the Save Traveller feature passed code review.

Would you immediately expose it to every customer?

Probably not.

The company may first deploy it to a:

staging environment

Think of staging as:

The dress rehearsal before the real performance.

Teams might check:

• Does the feature work end to end?
• Does it work on mobile?
• Does it work with other systems?
• Did anything else break?
• Does QA approve it?
• Are there unexpected errors?

GitHub’s documentation uses development, staging and production as examples of deployment environments.

Production is the live version.

Real customers use it.

If the company’s actual website is:

travelcompany.com

and customers are booking flights there:

that’s the production environment.

DEVELOPMENT
     ↓
Build and experiment

STAGING
     ↓
Test something close to the real product

PRODUCTION
     ↓
Real users

This is especially important for people who are vibe coding.

GitHub normally stores and manages your code.

Your website still needs somewhere to run.

A deployment or hosting service can be connected to your repository.

YOUR CODE
    ↓
  GIT
    ↓
 GITHUB
    ↓
HOSTING / DEPLOYMENT
    ↓
LIVE WEBSITE

A project can be configured so that certain GitHub events trigger a deployment.

For example:

Merge into main
      ↓
Automated build starts
      ↓
Tests run
      ↓
Website gets deployed

GitHub Actions can run deployment workflows, and many hosting platforms can also watch a GitHub repository and deploy when selected branches change.

So:

GitHub stores and coordinates the code. A deployment system turns that code into something users can access.

No.

main is a Git branch.

Production is an environment.

A company might configure:

main
 ↓
automatic deployment
 ↓
production

But another company might do:

main
 ↓
staging
 ↓
approval
 ↓
production

Do not turn:

main = production

into a universal rule.

It isn’t.

No.

There is no single universal Git workflow used by every company.

One team might use:

feature branch
      ↓
main
      ↓
staging environment
      ↓
production environment

Another might have branches such as:

feature
   ↓
develop
   ↓
release
   ↓
main

Another might use short-lived branches and merge frequently into main, while deployment systems separately manage preview, staging and production environments.

This is why it’s important to understand the concepts rather than memorise one diagram.

Branches

Examples:

• main
• feature/login
• fix/payment-error
• develop
• release

They belong to Git.

Environments

Examples:

• development
• staging
• production

They describe where software is running.

A company can create a branch called staging, but a staging branch and a staging environment are conceptually different things.

There is no single mandatory standard.

But a very common modern mental model looks like this:

TASK / TICKET
      ↓
GET LATEST MAIN
      ↓
CREATE SHORT-LIVED BRANCH
      ↓
MAKE CHANGES LOCALLY
      ↓
TEST
      ↓
STAGE CHANGES
      ↓
COMMIT
      ↓
PUSH
      ↓
PULL REQUEST
      ↓
AUTOMATED CHECKS
      ↓
CODE REVIEW
      ↓
APPROVAL
      ↓
MERGE
      ↓
BUILD / DEPLOYMENT PIPELINE
      ↓
STAGING / PREVIEW
      ↓
QA / APPROVAL
      ↓
PRODUCTION

Not every company uses every step.

But understanding this model will allow you to follow a huge number of engineering conversations.

Imagine 30 developers editing the central version of a banking app at the same time.

One changes login.

One changes payments.

One is redesigning onboarding.

One is fixing notifications.

Another is experimenting with an AI feature.

Without safeguards, this can become chaotic.

Professional teams therefore often use:

• separate branches;
• Pull Requests;
• code review;
• automated checks;
• protected branches;
• staging or preview environments.

These steps aren’t there simply to make software development complicated.

They’re there because:

changing software safely becomes harder as the project and team grow.

Eventually you’ll hear developers say:

CI/CD

You do not need to understand all the engineering behind it.

Just understand what problem it solves.

CI: Continuous Integration

When developers submit changes, automated systems can check whether those changes integrate safely.

New code
   ↓
Build project
   ↓
Run tests
   ↓
Run checks
   ↓
Pass or fail

CD: Continuous Delivery or Continuous Deployment

For a beginner, the important concept is:

Automate as much of the path from finished code to released software as possible.

Commit / Merge
      ↓
Build
      ↓
Test
      ↓
Deploy

There are several ways to interact with Git.

Terminal

You type Git commands directly:

git status
git add .
git commit -m "Update homepage"
git pull
git push

GitHub Desktop

GitHub Desktop gives you a graphical interface for many common Git operations.

VS Code, Cursor and other editors

Modern editors often include Git controls directly inside the interface.

You may see buttons for Source Control, Commit, Sync, Push, Pull and Branches.

The interface changes.

The underlying concepts don’t.

That’s why understanding the mental model first is more valuable than memorising where a button happens to be.

Not necessarily.

GitHub itself is primarily an online platform.

You can use many GitHub features directly in your browser.

If you want to work with repositories locally, you may use:

• Git;
• GitHub Desktop;
• GitHub CLI;
• VS Code, Cursor or another editor with Git support.

So when someone searches:

“download GitHub”

they often actually mean:

“How do I install Git?”

or:

“How do I install GitHub Desktop?”

Those are different things.

You don’t need to memorise 100 commands.

Do not try to memorise all of them today.

Once the workflow makes sense, the commands become labels for actions you already understand.

You are vibe coding:

yourname.com

Your project exists on GitHub.

You want to add a blog.

First, your computer needs the project.

So you clone the repository.

You make sure your local main is up to date.

You pull the latest changes.

You create:

feature/blog

That’s your branch.

You ask your AI coding tool:

Add a blog section to my website.

It modifies several files.

You test the result.

You select the changes you actually want to record.

That’s Git staging.

You create:

Add blog section

That’s a commit.

You send those commits to GitHub.

That’s push.

You create a Pull Request.

You review the changes.

Maybe automated checks run.

Maybe another developer checks them.

Everything looks good.

You merge the branch into main.

Your hosting system notices that the relevant branch changed.

It builds your website.

Maybe it first creates a preview or staging deployment.

Everything looks correct.

The new version gets deployed to production.

Someone visits:

yourname.com

They can now see your blog.

IDEA
 │
 ▼
LOCAL PROJECT
 │
 ▼
BRANCH
 │
 ▼
CHANGE FILES
 │
 ▼
STAGE CHANGES
 │
 ▼
COMMIT
 │
 ▼
PUSH
 │
 ▼
GITHUB
 │
 ▼
PULL REQUEST
 │
 ▼
REVIEW
 │
 ▼
MERGE
 │
 ▼
MAIN
 │
 ▼
DEPLOY
 │
 ▼
STAGING / PREVIEW
 │
 ▼
PRODUCTION
 │
 ▼
YOUR LIVE WEBSITE

That is the whole story.

Everything else is detail.

What is GitHub in very simple language?

GitHub is an online platform where people store Git repositories and collaborate on software projects.

Git keeps track of changes.

GitHub makes those projects easier to share, review and work on together.

What is the difference between Git and GitHub?

Git is the version-control system.

GitHub is an online platform built around Git.

You can use Git without GitHub.

What does “source control” or “version control” mean?

Both terms refer to systems that help track changes to files over time.

Git is a version-control system.

When Cursor or VS Code shows a Source Control section, it is usually showing Git-related information such as changed files, commits and branches.

Why do vibe coders need Git and GitHub?

Because AI can generate code very quickly, but you still need a safe way to track what changed, restore earlier versions, experiment safely, collaborate and connect code to deployment systems.

Is GitHub only for programmers?

No.

Developers are major users, but GitHub is also used by people working in product, data, security, documentation and many other functions around software.

Can I understand GitHub without knowing how to code?

Yes.

You may not understand every file inside a repository, but you can absolutely understand repository, branch, commit, push, pull, PR, merge, staging and production.

Those are workflow concepts.

What is a repository on GitHub?

A repository is essentially a project managed with Git.

It contains the project’s files plus the Git data and history used to track changes.

What is the difference between a repository and a normal project folder?

A normal folder contains files.

A Git repository is a project folder that Git is tracking, together with Git’s history and metadata.

What is the difference between commit and push?

A commit records a checkpoint in Git.

A push sends your local commits to a remote repository such as GitHub.

What is the difference between push and pull?

PUSH
My computer → GitHub

PULL
GitHub → My computer

What is the difference between Git pull and a Pull Request?

Git pull brings newer remote changes onto your computer.

A Pull Request proposes changes for discussion, review and possible merging.

What is the difference between clone and pull?

Use clone when you need to create a local copy of an existing remote repository.

Use pull when you already have the repository locally and want newer changes.

What is the difference between clone and Download ZIP on GitHub?

Download ZIP gives you the current files.

Clone gives you a Git working copy with repository history and a connection to the remote repository.

What is the difference between a branch and a repository?

A repository is the overall project.

A branch is one line of development inside that repository.

What does main mean on GitHub?

main is a common default branch name.

Many teams treat it as the central line of the project.

It does not automatically mean “production”.

Why do I sometimes see master instead of main?

Older repositories and some Git configurations may use master as the default branch name.

Many newer repositories use main.

The underlying idea is the same: it is a branch name.

What is a merge conflict?

Imagine you change:

Button colour = blue

while someone else changes the same part to:

Button colour = green

Git may not be able to decide which version should win.

That’s a merge conflict.

A person needs to resolve the conflicting changes.

What is a fork on GitHub?

A fork creates a separate repository based on another repository.

This is particularly useful when you want to modify or contribute to a project where you don’t have permission to work directly inside the original repository.

A branch is a separate line of development inside a repository.

A fork is a separate repository.

What does origin mean in Git?

You may eventually see:

origin/main

origin is commonly the default nickname Git gives to the remote repository you cloned from.

So origin/main roughly means:

the main branch on that remote repository.

Is GitHub basically Google Drive for code?

That’s an understandable beginner analogy, but it is incomplete.

Google Drive primarily stores and synchronises files.

GitHub is built around Git’s version history and software-development workflows.

It understands concepts such as commits, branches, Pull Requests, code review, issues, automated tests and deployments.

Do I need to download GitHub?

Not necessarily.

GitHub.com works in your browser.

If you want to work with Git locally, you may use Git itself, GitHub Desktop, or an editor such as VS Code or Cursor.

Do I need to know Git commands?

No — not to understand Git.

Learn the mental model first.

Once this makes sense:

Repository
    ↓
Branch
    ↓
Change
    ↓
Commit
    ↓
Push
    ↓
Pull Request
    ↓
Review
    ↓
Merge

commands become much easier because you understand what you’re asking the computer to do.

Is Git staging the same as a staging environment?

No.

Git staging means selecting changes for your next commit.

A staging environment is a place where an application can be tested before reaching production.

They share a word.

They solve completely different problems.

If I push code to GitHub, will my website automatically update?

Sometimes — but only if your project has been configured that way.

For example, a hosting system may watch main and automatically deploy whenever it changes.

Another project may require a manual deployment or additional approvals.

So:

push ≠ deploy

unless the project’s automation connects those two actions.

How does GitHub connect to my website?

A hosting or deployment platform can connect to your GitHub repository.

When selected code changes, the platform can:

• download the latest code;
• build the website;
• run checks;
• deploy it;
• make the new version available online.

The exact process depends on the project’s setup.

Should I commit directly to main?

For a tiny solo experiment, you technically can.

In professional collaborative projects, teams commonly prefer changes to be made on separate branches and reviewed through Pull Requests before they reach protected important branches.

GitHub can look intimidating when you first open it.

There are branches.

Commits.

Files.

Pull Requests.

Actions.

Issues.

Strange developer usernames.

And if you’re non-technical, it is easy to assume you need to understand all of it before GitHub will make sense.

You don’t.

Start with the story.

You have a project.

Git keeps track of how that project changes.

That tracked project is your repository.

GitHub gives the repository an online home.

You create a branch when you want a separate line of work.

You make changes.

You create a commit when you want to record a meaningful checkpoint.

You push your local commits to GitHub.

You create a Pull Request when you want the changes reviewed.

The work gets merged when it is accepted.

Other people pull newer changes when their local copy becomes outdated.

The software can then be deployed to a testing environment such as staging and eventually to production, where real users see it.

That’s it.

Once you understand that journey:

Git → GitHub → repo → clone → branch → commit → push → Pull Request → review → merge → pull → staging → production

stop feeling like unrelated technical words.

They’re simply different steps in the life of a software project.

1. GitHub Docs — What is GitHub?
2. GitHub Docs — About Git
3. GitHub Docs — Hello World
4. GitHub Docs — Pull requests
5. GitHub Docs — Status checks
6. GitHub Docs — Deployment environments
7. GitHub Docs — GitHub Desktop

I’m Saurav Mishra. I work across growth, product, marketing and analytics, and I also build and experiment with digital products using modern AI and development tools.

I wrote this guide for the version of me who could use GitHub before I could confidently explain what every part of the workflow meant.

Explore my case studies →