How to Use GitHub: The Beginner's Guide (First Repository, First Push, and Your First Pull Request)

CodexFuse Team · 2026-10-28T08:39:32.596Z · 18 min read

Learning how to use GitHub takes about an hour: create an account, install Git, make your first repository, push your first code, and open your first pull request — all on a free account.

Learning how to use GitHub takes about an hour, and most of that hour is doing the steps once, slowly, instead of reading about them. GitHub is the website where developers store code, track every change to it, and work on it together. It is built on Git, the version-control tool that runs on your computer. This guide takes you from a blank account to your first repository, your first push, and your first pull request — the three moves that make up almost everything beginners do on GitHub. Everything here works on a free GitHub account, and the steps were checked against GitHub's own documentation on October 28, 2026. If you write code with an AI tool as well, our Claude Code beginner's guide covers the agent that edits your code — GitHub is where that code lives once it is written.

This guide is written for GitHub beginners: students, career changers, and new developers putting their first project online. You do not need to know the command line well, and you do not need to pay for anything. The guide shows both paths where they exist — the web interface in your browser, and the command line — so you can start with clicks and move to commands when you are ready.

How Do You Use GitHub?

You use GitHub by creating a free account, installing Git on your computer, creating a repository, and pushing your code to it with a short set of commands. A repository is a folder for one project that GitHub stores online. Once your code is in a repository, you change it locally, save each change as a commit, and push the commits to GitHub. Other people can then see your work, suggest changes, and contribute through pull requests. The whole first session looks like this:

1. Create a free account at github.com and pick a username you are happy to show to employers — it becomes part of your public profile address.
2. Install Git on your computer and tell it your name and email, so every commit you make is signed with your identity.
3. Create your first repository on github.com, with a README file, and choose public or private.
4. Clone it to your computer with git clone, or connect a project you already have with git remote add origin.
5. Make a change, then save it with git add and git commit -m, and upload it with git push.
6. Open a pull request when you want to propose a change to someone else's project, or to your own main branch from a side branch.

That is the entire loop. The rest of this guide slows each step down, explains the two ideas that confuse every beginner — Git versus GitHub, and branches versus pull requests — and shows the mistakes to avoid in your first week.

What Is GitHub, and How Is It Different From Git?

GitHub is a cloud platform that hosts Git repositories online, while Git is the free, open-source tool installed on your computer that tracks changes to your files. Git was created by Linus Torvalds — the same person who created Linux — in 2005, and it runs on every major operating system. GitHub, built on top of Git, gives your code a home on the internet where it is backed up, accessible from any device, shareable with collaborators, and visible as a portfolio. According to the DevRisePro beginner guide, GitHub has more than 100 million developers and hosts hundreds of millions of repositories, making it the largest open-source platform in the world.

The difference is the one thing beginners must get right, because the two names are used interchangeably and they are not the same thing. You can use Git without GitHub, keeping repositories only on your own computer. You cannot use GitHub without Git, because GitHub is built on top of it. In practice, almost every developer uses both together: Git does the tracking locally, and GitHub does the hosting, sharing, and collaboration online.

Think of Git as the engine and GitHub as the garage. The engine does the work of remembering every version of your project. The garage is where the car lives, where other people can see it, and where the tools for working on it together are kept. You need both to drive anywhere, but you only ever touch the engine directly when you run commands, and you only ever visit the garage when you open github.com.

How Do You Set Up Git on Your Computer?

You set up Git by installing it once, then telling it your name and email with two commands. Git attaches that name and email to every commit you make, so your work is always signed. The install path depends on your system, and GitHub's own setup documentation lists all three.

Verify the install, then configure your identity. These two commands are the first thing every Git tutorial asks you to run, and skipping them is the most common first error: Git refuses to commit until it knows who you are.

git --version
git config --global user.name "Your Name"
git config --global user.email "[email protected]"

Use the same email you signed up for GitHub with, so your commits link to your profile. Run git config --list afterwards to check the settings stuck. If you would rather avoid the command line entirely at this stage, GitHub's setup documentation points to GitHub Desktop, the free visual client that does the same jobs with buttons instead of commands. The command-line path is worth learning anyway, because every tutorial, employer, and AI coding tool assumes you can run these commands — and our Google Antigravity guide shows an agent IDE that runs the same Git commands for you once you know what they do.

How Do You Create Your First Repository?

You create your first repository on github.com in about two minutes, and GitHub's own quickstart says the whole first-commit flow takes about five minutes. A repository — a repo — is a folder for one project, plus the full history of every change ever made to it. Click the plus sign in the upper-right corner of any page, choose New repository, and fill in the form.

1. Name it. Type a short, memorable name in lowercase with hyphens, for example my-first-project. GitHub's own example is hello-world.
2. Add a description. One sentence about what the project is, for example "My first repository on GitHub." It shows up on the repo page and in search.
3. Choose the visibility. Public means anyone can see the code; private means only you and people you invite can. A public first repo is the usual choice for a portfolio, and a private one is the right choice for anything with secrets in it.
4. Turn on Add README. A README file is the front page of your project: it explains what the project does and how to use it, and GitHub displays it automatically on the repo page.
5. Click Create repository. Your repo now exists online, with its first file already in place.

There is also a command-line path, and it is the faster one once Git is installed. GitHub's CLI — the gh tool — creates a repo and clones it in one step, with no browser form at all.

gh repo create my-first-project --public --clone

That single command creates the repository on GitHub, marks it public, and downloads a local copy to your computer. Run it with --private instead of --public for a private repo, and drop the --clone flag if you only want the online repo. Either way, the result is the same: a repository with your name on it, ready for code.

How Do You Push Your First Code to GitHub?

You push code to GitHub with four commands: add, commit, push — after connecting your local folder to the online repo once. A commit is a snapshot of all the files in your project at one point in time, as GitHub's documentation puts it. The snapshot is the whole idea: every commit is a save point you can return to, and the history of commits is the story of the project.

Start from the repo you just created. Clone it to your computer, add a file, and push it back. The commands below use the repo name my-first-project and the username yourusername — replace both with yours.

git clone https://github.com/yourusername/my-first-project.git
cd my-first-project
echo "My first project" > README.md
git status
git add README.md
git commit -m "Add README"
git push --set-upstream origin HEAD

Each command has one job, and knowing the job is what makes the sequence stick instead of feeling like magic words.

If you already have a project folder on your computer instead of a fresh repo, the flow is the same with one extra step at the start: initialize the folder, then point it at GitHub. Run git init in the project folder, add and commit the files, then connect the remote and push.

git init
git add .
git commit -m "First commit"
git remote add origin https://github.com/yourusername/my-first-project.git
git push -u origin main

Write commit messages the way you would label a box: short, in the present tense, and describing the change. DevRisePro's guide recommends messages under 72 characters, written in the present tense, such as "Add navigation menu to header" or "Fix login button on mobile." A future you — and any collaborator — will read these messages to understand what happened and why, so "stuff" and "fix" are not messages. The daily workflow that grows out of this first push is the same six steps every time: pull, edit, status, add, commit, push. Most experienced developers do it dozens of times a day without thinking about it.

How Do You Make Your First Pull Request?

You make a pull request by creating a branch, changing code on that branch, and asking GitHub to merge it into the main branch. A pull request is a proposal: it shows exactly what changed, lets other people review it line by line, and records the discussion before the change lands. It is how open-source software gets built, and it is how teams review each other's work without overwriting it.

1. Create a branch. A branch is a copy of the project where you can work without touching the main code. From the main branch, run git checkout -b add-about-page — the -b flag creates the branch and switches to it in one step.
2. Make your change and commit it. Edit the files, then run the same add and commit commands as before. The commit lives on your branch, not on main.
3. Push the branch. Run git push -u origin add-about-page. GitHub will show a green button on the repo page offering to open a pull request.
4. Open the pull request. Click the button, write a title and a short description of what the change does and why, and submit it.
5. Wait for review, then merge. Reviewers comment on lines, ask for changes, or approve. When it is approved, click Merge pull request, and your branch's commits join main.

Two rules keep pull requests painless. First, never commit directly to main when a branch will do — GitHub's own quickstart advises creating a new branch for any commit when your current branch is the default one. Second, keep a pull request small: one change, one purpose, one clear title. A pull request that fixes a typo and rewrites the homepage is two pull requests pretending to be one, and reviewers will ask you to split it.

A fork is the same idea, one level further out. Forking copies someone else's repository into your own account, so you can change it without affecting the original. You fork, clone your fork, make a branch, push, and open a pull request back to the original repo. That is how a beginner's first open-source contribution works, and it is the same flow the pros use — the only difference is the size of the change.

How Do You Sign In to GitHub Without a Password?

You sign in to GitHub from Git with a personal access token or an SSH key, because GitHub no longer accepts account passwords for Git operations. When you push over HTTPS for the first time, Git will ask for credentials: the username is your GitHub username, and the password is a personal access token you generate in your GitHub settings, not your account password. A credential helper can remember the token so you are not pasting it every time.

The cleaner long-term option is SSH, and it is the one most developers settle on. You generate a key pair on your computer, add the public key to your GitHub account, and Git authenticates automatically from then on — no token pasting, ever. Our SSH key generator creates the key pair in your browser and explains where each half goes. GitHub's setup documentation notes that SSH keys must be generated on each computer you push from, so set it up once per machine and you are done.

Whichever method you pick, treat the credential like a house key. A token or private key in a public repository is a leaked key: anyone who finds it can push as you. DevRisePro's guide states the rule plainly — never commit passwords, API keys, or personal information, especially in public repositories — and a .gitignore file is how you enforce it, by telling Git which files to never track, such as .env files and node_modules folders.

GitHub Desktop vs the Command Line: Which Should You Pick?

GitHub Desktop and the command line do the same jobs, and the right choice depends on how you like to work. Desktop is a free app from GitHub with buttons for cloning, committing, branching, and pushing. The command line is the text interface every tutorial uses. Neither is the "real" way — professional developers use both, often in the same day.

Start with Desktop if the terminal feels intimidating, and switch to the command line when you find yourself clicking the same five buttons fifty times a day. The commands in this guide are the whole command line you need for the first month: clone, status, add, commit, push, pull, branch, and checkout. Everything else is a variation on those eight. If you build with AI tools, the command line is the better investment: our Google AI Studio beginner guide shows a workspace where the same Git commands connect your AI-built app to a repository, so the skill transfers directly.

How Much Does GitHub Cost?

GitHub costs nothing for everything in this guide. A free account covers unlimited public and private repositories, the web interface, GitHub Desktop, the command-line tools, pull requests, and the collaboration features a beginner needs. That is why the guides on page one of Google all start with "create a free account" — there is no paid step hidden halfway through the beginner flow.

GitHub also sells paid plans for teams that need advanced permissions, code review rules, and support, but none of that matters until you are working on a team project with real access rules. Start free, build the portfolio, and let the team's needs — not the pricing page — decide whether you ever pay. The free plan is the right default, and it stays the right default for a long time.

7 GitHub Mistakes Beginners Make

Most first weeks on GitHub go wrong in the same seven ways, and all seven are avoidable once you know them.

1. Committing secrets. Pushing a file with a password or API key in it publishes that secret to everyone who can see the repo. Use a .gitignore file and keep secrets in .env files that Git never tracks.
2. Running git add . without checking. The dot stages everything, including files you did not mean to include. Run git status first, every time, and look at the list before you stage it.
3. Committing straight to main. Main should always hold working code. Make a branch for the change, open a pull request, and merge when it is reviewed — even when you are working alone, the habit pays off.
4. Vague commit messages. "Update" and "fix stuff" tell nobody anything. Write what changed and why, in the present tense, under 72 characters.
5. Forgetting to pull. If you work on two computers, or with a team, pull before you start each day. DevRisePro's guide makes it a rule: always pull the latest changes before pushing your own, or you will hit the "rejected — non-fast-forward" error.
6. Pushing node_modules. That folder can hold tens of thousands of files and anyone can rebuild it from your package file. It belongs in .gitignore, not in the repo.
7. Force-pushing a shared branch. git push --force rewrites history, and on a branch other people use, it erases their work. Never force-push a branch someone else has pulled.

Sources

• GitHub — Plans and pricing (checked October 28, 2026; Free plan includes unlimited public and private repositories)
• GitHub Docs — Quickstart for repositories (create a repository in 5 minutes, README commit flow, gh repo create CLI path, commit as a snapshot, branch advice for pull requests)
• GitHub Docs — Set up Git (install Git, configure name and email, GitHub Desktop, GitHub CLI, HTTPS vs SSH authentication, credential helpers)
• DevRisePro — Git and GitHub for Beginners: Complete Guide to Version Control in 2026 (Git created by Linus Torvalds in 2005, free and open source, 100 million-plus developers, six-step daily workflow, commit-message rules, .gitignore, common errors and fixes)
• Vogella — Using GitHub Tutorial (global Git setup, first-repository command sequence, SSH vs HTTPS authentication, forking)
• The Linux Code — How to Use Git and GitHub: A Beginner's Guide (local Git identity setup, first repo and first push walkthrough)
• GeeksforGeeks — Using Git and GitHub (install and configure Git, clone, add, commit, history, pull requests)
• DEV Community — Getting started with GitHub (local setup, pushing code, pulling updates, authentication note)

Frequently Asked Questions

Is GitHub free?

Yes. A free GitHub account covers unlimited public and private repositories, pull requests, GitHub Desktop, and the command-line tools — everything in this guide. Paid plans exist for teams that need advanced permissions and support, but a beginner never needs to pay to learn GitHub.

What is the difference between Git and GitHub?

Git is the free, open-source tool installed on your computer that tracks changes to your files. GitHub is the website that hosts your Git repositories online, so they are backed up, shareable, and visible as a portfolio. You can use Git without GitHub, but you cannot use GitHub without Git — GitHub is built on top of it.

Do I need to know the command line to use GitHub?

No. GitHub's web interface handles creating repositories, editing files, and opening pull requests, and GitHub Desktop covers cloning, committing, and pushing with buttons. The command line is worth learning anyway, because every tutorial uses it and it is faster once the eight basic commands are familiar.

How do I push code to GitHub for the first time?

Create a repository on github.com, clone it with git clone, add your files, then run git add, git commit -m "First commit", and git push. If the project already exists on your computer, run git init in the folder, commit the files, connect the repo with git remote add origin, and push with git push -u origin main.

What is a pull request?

A pull request is a proposal to merge one branch into another, usually into the main branch. It shows exactly what changed, lets reviewers comment on individual lines, and records the discussion before the change is merged. It is how open-source contributions work: you fork a repo, change it on a branch, and open a pull request back to the original project.