How to Upload a Website to GitHub Step-by-Step

Uploading your website to GitHub is a great way to store your code online, share it with others, and even host it for free using GitHub Pages. This complete step-by-step guide will walk you through the entire process — even if you are completely new to Git and GitHub. By the end, your website will be live on the internet and you will understand the core workflow that professional developers use every single day.

’x” What's GitHub and Why Use It?

GitHub is one of the most widely used platforms in software development. At its core, it is an online service that stores code using a version control system called Git. Think of it like Google Drive, but designed specifically for code — with powerful tools for tracking every change, collaborating with others, and managing multiple versions of a project at the same time.

For beginners, GitHub is particularly valuable because it provides completely free website hosting through a feature called GitHub Pages. You can put your portfolio, personal project, or school assignment live on the internet without paying anything for a server. Developers at every skill level — students, freelancers, and engineers at major tech companies — use GitHub as the central hub for their work.

Beyond code storage, a GitHub profile is increasingly important for anyone pursuing a career in tech. When you apply for jobs, internships, or freelance contracts, employers and clients regularly check your GitHub profile as evidence of your real skills. Every project you push and every commit you make builds your developer identity online. Starting to use GitHub now — even on small beginner projects — is one of the best habits you can build.

’x— Understanding Git vs GitHub

Many beginners confuse Git and GitHub. They are closely related but they are not the same thing. Understanding the difference will make this entire guide make much more sense.

The simplest way to remember it: Git is the tool, GitHub is the storage. You use Git commands on your computer to manage your code locally, then "push" (upload) that code to GitHub where it lives online. Every command you will type in this guide is a Git command — GitHub is simply the destination where the result ends up.

“& Prerequisites

Before you start, make sure you have the following in place:

• A GitHub account — sign up free at github.com. Choose your username carefully: it will appear in your live website URL and on your public developer profile.
• Git installed on your computer (the tip box below explains how to check)
• Your website files ready in a folder — at minimum an index.html file
• A terminal or command prompt — this is built into every operating system
• Basic comfort with navigating folders on your computer

git --version

When creating your GitHub account, take a moment to also add a profile photo and a short bio once you are signed in. Your GitHub profile is your developer identity — a clean, professional profile creates a strong first impression on employers, collaborators, and anyone who finds your work through search.

’x— Step 1: Create a GitHub Repository

A repository (often shortened to "repo") is GitHub's version of a project folder. Every project you upload needs its own repository. Before you can push any code, you must create an empty repository on GitHub to serve as the destination.

’x— Step 2: Open Terminal in Your Project Folder

All Git commands are entered into a terminal (also called the command line or command prompt). Before running any Git commands, you must navigate your terminal into your website's folder — otherwise Git has no way of knowing which project you are referring to.

cd C:\Users\YourName\Desktop\my-website

cd ~/Desktop/my-website

# Mac/Linux: list files
ls

# Windows: list files
dir

’xa— Step 3: Initialize Git Repository

Now that your terminal is inside your project folder, you need to tell Git to start tracking it. This is called "initializing" a repository. You only do this once per project — never again for the same project.

git init

This command creates a hidden folder called .git inside your project directory. That folder is where Git stores your entire project history — every commit, every change, every branch. You should never manually edit or delete this .git folder; doing so would permanently destroy your version history.

After running the command you will see a message like: "Initialized empty Git repository in /your/folder/.git/". Your folder is now a Git repository. Git is aware of it — but it has not tracked any files yet. That's what the next step is for.

—~" Step 4: Add Your Files

Initializing Git does not automatically track your files. You must explicitly tell Git which files to include in the next save point. This process is called staging. Staged files are placed in a holding area and will be included in your next commit.

Add Everything at Once

The most common approach — stage all files in the current folder and all subfolders:

git add .

The dot (.) is shorthand for "everything here." This is what most beginners and even many experienced developers use for the majority of commits.

Add Specific Files Only

To stage only certain files and leave others unstaged:

git add index.html style.css script.js

Check What Has Been Staged

Before committing, always check the current state of your working directory:

git status

The output shows everything in color: green files are staged and ready to commit, red files are modified or new but not yet staged. Running git status frequently — before staging, before committing, before pushing — is one of the best habits a beginner can build. It keeps you fully aware of exactly what Git is tracking.

’x— Step 5: Commit Your Files

A commit is a permanent save point — a complete snapshot of all your staged files at this exact moment in time. Every commit is stored forever in your project history. If something breaks in the future, you can always roll back to any previous commit. This is the core power of version control.

git commit -m "First commit - initial website upload"

The -m flag lets you write a short message describing what this commit contains. The commit message is for humans — it should clearly describe what changed and why.

Writing Good Commit Messages

The quality of your commit messages directly reflects your professionalism as a developer. Here is the difference in practice:

When you look back at a project after several months, a well-written commit history reads like a clear changelog — you can see exactly when every feature was added and every bug was fixed. Use present tense: "Add" not "Added." Be specific enough that a stranger reading the message would understand the change without needing to look at the code.

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

’xR— Step 6: Rename Branch to Main

In Git, a "branch" is a separate timeline of your project. Older versions of Git automatically named the default branch master, but the modern standard — and what GitHub now uses — is main. Renaming ensures that your local branch name matches what GitHub expects, preventing errors when you push.

git branch -M main

The -M flag forces the rename even if another branch with that name already exists. After this command, your branch is called main and everything aligns with GitHub's default setup.

To make main the automatic default for all future projects on your machine, run this one-time configuration command:

git config --global init.defaultBranch main

’x Step 7: Connect to GitHub

Your Git repository currently exists only on your local computer. You need to link it to the repository you created in Step 1 on GitHub. This link is called a remote — essentially a bookmark that tells Git where to send your code when you push.

git remote add origin https://github.com/YOUR_USERNAME/YOUR_REPO_NAME.git

Replace YOUR_USERNAME with your actual GitHub username and YOUR_REPO_NAME with your repository name. For example:

git remote add origin https://github.com/johndoe/my-website.git

The word origin is simply a conventional nickname for the remote URL. It's not a special keyword — it is just the name that virtually every developer in the world uses for their primary remote. Following this convention makes your workflow compatible with standard tutorials, team projects, and open-source contributions.

Verify that the remote was added correctly by running:

git remote -v

You'll see your GitHub URL listed twice — once for "fetch" (downloading) and once for "push" (uploading). If both URLs match your repository, you are ready for the final push.

’x— Step 8: Upload to GitHub

This is the final step. "Pushing" sends all your committed code from your local machine up to GitHub, where it is stored and publicly accessible.

git push -u origin main

The -u flag sets origin main as the default upstream. After this first push, you can simply type git push in the future without specifying the remote name and branch every time.

You'll be prompted to enter your GitHub username and a password. Important: GitHub no longer accepts your account login password for command-line push operations. You must use a Personal Access Token (PAT).

If the push succeeds, you will see output ending with something like "Branch 'main' set up to track remote branch 'main' from 'origin'." Open your browser and navigate to https://github.com/YOUR_USERNAME/YOUR_REPO_NAME — you will see all your files listed there. Your code is now on GitHub!

’x Updating Your Website

After the initial upload, keeping your GitHub repository in sync with your latest changes is fast and simple. Every time you edit your website — fixing a typo, adding a new section, redesigning the layout, or updating any content — you follow the same three-step update cycle:

git add .

git commit -m "Fix mobile navigation and update footer text"

git push

If you have GitHub Pages enabled, your live website will automatically rebuild and show the new changes within one to three minutes of pushing. Simply refresh your browser on the live URL and the update will appear.

Over time, building the habit of committing and pushing regularly — after each meaningful change rather than waiting until a project is entirely finished — makes your workflow far more organized, safer from accidental data loss, and easier to manage as complexity grows.

’xR— Host Your Website Free with GitHub Pages

GitHub Pages is a free static website hosting service built directly into GitHub. It publishes your HTML, CSS, and JavaScript files from your repository as a fully live, publicly accessible website — no server setup, no monthly fees, and no infrastructure to maintain. For beginners, students, and anyone hosting personal projects, it is one of the most useful tools available on the entire internet.

Your site will be live at: https://YOUR_USERNAME.github.io/YOUR_REPO_NAME. This is a real URL you can share with anyone — a future employer, a client, a professor, or anyone else you want to show your work to.

Custom Domain with GitHub Pages

If you own a custom domain name — like www.yourname.com — you can connect it to your GitHub Pages site for free. In the Pages settings page, there is a "Custom domain" input field. Enter your domain name and save. Then log into your domain registrar (GoDaddy, Namecheap, Cloudflare, Google Domains, etc.) and update your DNS records to point to GitHub's IP addresses. GitHub provides step-by-step instructions for this in their documentation. Once configured, GitHub also automatically provisions a free HTTPS/SSL certificate through Let's Encrypt within minutes, so your site will be fully secure without any extra setup.

What GitHub Pages Can and Can't Host

GitHub Pages is purpose-built for static websites — sites built with HTML, CSS, and JavaScript that run entirely in the browser without needing a server to process requests. It's ideal for portfolios, landing pages, documentation sites, project showcases, and blogs (especially using a static site generator like Jekyll, which GitHub Pages natively supports).

It does not support server-side languages like PHP, Python, Ruby, or Node.js, nor does it support databases. If your project requires a backend API or a database, you will need separate hosting for those components — services like Render, Railway, Fly.io, or Vercel work well alongside GitHub Pages for full-stack projects.

’xa— Using .gitignore to Exclude Files

Not every file in your project folder should be uploaded to GitHub. Operating system files, editor configuration files, compiled build output, package dependency folders, and especially any files containing private credentials should never be committed. The .gitignore file is how you tell Git to permanently ignore certain files and folders — they will never appear in git status and will never be staged, committed, or pushed.

Create a file named exactly .gitignore (with the leading dot, and no file extension) in the root directory of your project. Inside it, list patterns for everything you want Git to skip:

# Mac OS system files
.DS_Store

# Windows system files
Thumbs.db
desktop.ini

# Node.js — never commit the dependencies folder (it can be hundreds of MB)
node_modules/

# Environment variable files — these often contain API keys and secrets
.env
.env.local
.env.development
.env.production

# Build output directories
dist/
build/
out/

# Code editor configuration folders
.vscode/
.idea/

# Log files
*.log
npm-debug.log*
yarn-debug.log*

Lines beginning with # are comments and are ignored by Git. A trailing slash (/) means a folder and everything inside it. An asterisk (*) is a wildcard matching any characters. Patterns are matched from the root of the repository.

’xR— Understanding Branches

Branches are one of Git's most powerful and distinctive features. A branch is an independent, parallel timeline of your project. You can create a new branch, make any changes you want inside it, and your main branch remains completely untouched. This lets you experiment, build new features, or try a redesign — all without any risk to the working version of your project.

The most common beginner use case is a feature branch: create a branch when starting something new, build it there, and merge it back into main when it works correctly and you are satisfied with it.

Creating, Using, and Merging a Branch

# Create a new branch and switch to it immediately
git checkout -b new-feature

# Now work on your changes... then stage and commit as usual
git add .
git commit -m "Add new portfolio section with project cards"

# When ready, switch back to main
git checkout main

# Merge the feature branch into main
git merge new-feature

# Push the updated main to GitHub
git push

# Optionally delete the branch now that it has been merged
git branch -d new-feature

Viewing Your Branches

# List all local branches (the current branch has a * beside it)
git branch

# List all branches, including remote ones on GitHub
git branch -a

As a solo developer on a simple project, you may not feel the need for branches right away — and that is completely fine. However, as projects grow, and especially when collaborating with other developers, branches become absolutely key. They form the backbone of professional workflows like GitHub Flow (create a branch —  commit —  open a Pull Request —  review —  merge) that are used at software companies of every size around the world.

’x SSH Keys — Push Without a Password

Entering your GitHub username and Personal Access Token every single time you push is tedious. SSH (Secure Shell) key authentication solves this permanently. Once configured, git push authenticates you automatically in the background — no prompts, no tokens, no typing. This is how most professional developers interact with GitHub on a daily basis.

SSH uses a matched key pair: a private key that lives only on your computer (never share this) and a public key that you upload to GitHub. When you push, GitHub verifies that the keys match and grants access instantly.

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

# Mac or Linux
cat ~/.ssh/id_ed25519.pub

# Windows (Git Bash)
cat ~/.ssh/id_ed25519.pub

git remote set-url origin git@github.com:YOUR_USERNAME/YOUR_REPO_NAME.git

⭐ Git Best Practices for Beginners

Knowing how to use Git commands is only one part of the picture. Using Git well — with good habits and discipline — is what separates developers who are comfortable in professional environments from those who are not. These six habits are worth building from your very first project.

git pull origin main

’x:—️ Common Problems and Solutions

Here are the most frequent errors beginners run into when working with Git and GitHub, along with clear explanations and exact fixes for each:

git remote remove origin
git remote add origin https://github.com/YOUR_USERNAME/YOUR_REPO_NAME.git

git pull origin main --rebase
git push

git add .
git commit -m "Resolve merge conflict in style.css"

’x9 Quick Reference: Complete Command List

Every Git command covered in this guide, organized in a single reference table:

Full Initial Setup — Copy and Paste Ready

# 1. Navigate to your project folder
cd your-project-folder

# 2. Initialize Git
git init

# 3. Stage all files
git add .

# 4. Create your first commit
git commit -m "Initial website upload"

# 5. Rename branch to main
git branch -M main

# 6. Link to your GitHub repository (replace with your actual URL)
git remote add origin https://github.com/YOUR_USERNAME/YOUR_REPO_NAME.git

# 7. Push to GitHub for the first time
git push -u origin main

The Three-Command Update Cycle

After the initial setup, this is everything you need every time you update your site:

git add .
git commit -m "Describe what you changed"
git push

’x}0 Conclusion