How to Use GitHub: Clone, Commit and Push Your First Change

by Souy Soeng /October 23, 2026

Diagram of code looping from a GitHub repository to a computer and back via git clone, git add, git commit and git push

Learning how to use GitHub comes down to three Git commands: clone copies a project from GitHub to your computer, commit saves a change you made, and push sends that change back to GitHub. Together they form a round trip, and each command handles one leg of the journey.

This guide walks through that round trip in order, from copying the repository URL to confirming your change online. Along the way you'll see why each step exists, what to check before moving on, and how to fix the errors beginners hit most often at the push step.

In short

Clone copies a repository down, commit saves a change, and push sends it back up.
Stage changes with git add before committing; only staged changes are saved.
A commit stays on your computer until you run git push.
If a push fails, read the error: use a token for login problems, run git pull if it's rejected.
You clone once, then edit, add, commit and push again and again.

Check you have what you need before you start

The goal is simple: copy a repository, save a change, and send it back to GitHub. Every command in this guide serves one part of that round trip, so if you ever feel lost, come back to that one sentence. It tells you where you are and what comes next.

Before typing anything, make sure three things are in place. You need a GitHub account so your work has somewhere to go. You need Git installed on your computer, which you can confirm by typing git --version in your terminal. And you need a repository you're allowed to push to.

For practice, a repository you created yourself is the safest choice. Nothing you push there can get in anyone else's way, so you can experiment, make mistakes and try again without worrying about other people's work.

You can sign in to your GitHub account
git --version prints a version number
You have a repository you can push to, ideally your own

Understand the loop your code travels

It helps to see the whole journey before zooming in. Your code travels in a loop, and every arrow in that loop is one Git command. It starts at the GitHub repository. git clone copies it into a folder on your computer. git add puts your chosen changes into the staging area. git commit saves them as local commits. git push sends them back up to GitHub.

The key idea is that a commit is saved locally. At first it lives only on your machine. That's useful, because you can keep working offline, but it also means nobody else can see it yet. Only git push updates GitHub.

Keep this in mind for later. If a change ever isn't showing up online, the first question to ask is always: did I actually push?

Clone: GitHub to your computer
Add: your changes into the staging area
Commit: a saved snapshot on your computer
Push: your commits back to GitHub

Copy the repository URL from GitHub

Git needs an address before it can copy anything, the same way you need a link before you can download a file. The URL tells Git exactly which repository to copy. Open your repository in the browser and find the green Code button, which sits just above the list of files. Click it and a small panel opens showing the URL with a copy icon beside it.

You'll see two kinds of address. The HTTPS one starts with https and uses a token when you push. The SSH one starts with git@github.com and uses an SSH key. Both work. If you haven't set up an SSH key yet, choose HTTPS for now. What matters is having the matching login details later, when you push.

Use the copy icon rather than typing the address by hand. A single wrong letter is enough to produce a repository not found error, and that's an easy mistake to avoid.

Click the green Code button above the file list
Pick HTTPS if you have no SSH key set up
Copy the URL with the icon instead of typing it

# HTTPS: sign in with a token
https://github.com/you/my-project.git
# SSH: sign in with an SSH key
git@github.com:you/my-project.git

Clone the repository and move into its folder

With the URL on your clipboard, open your terminal and go to wherever you keep your projects. Type git clone, a space, paste the URL and press Enter. Git will show messages as it counts and receives objects. A good way to think of clone is download plus history: you get the files and the project's full record of changes.

Clone creates a new folder named after the repository, inside whatever directory your terminal was in when you ran the command. Next, type cd followed by the folder name, for example my-project, to step inside your copy.

Don't skip the cd step. Git commands only work inside the repository folder. If you stay outside it, Git won't know which project you mean. Get this right once and every later command simply works.

Run git clone with the pasted URL
Check a new folder with the repository's name appeared
Run cd into that folder before anything else

# Copy the repo to your computer
git clone https://github.com/you/my-project.git
# Move into the new folder
cd my-project

Edit a file and stage it with git add

Now change something. Open any file, such as README.md, add a line and save it. Use whichever editor you like; Git doesn't care. It simply notices that the saved file is different from the last snapshot. But editing alone doesn't tell Git what you want to keep. That's the job of staging.

Run git status first. It lists README.md as modified, usually in red. Then type git add followed by the filename. Run git status again and the file turns green, which means it's staged and ready for your next commit.

Think of the staging area as a waiting room. Only what you add goes in. If you changed three files but staged one, only that one is saved in the next commit. This lets you choose exactly which changes belong together, and a quick git status check saves you from committing the wrong thing.

Save the file after editing
Red in git status means changed but not staged
Green in git status means staged and ready

# See what changed
git status
# Stage one file
git add README.md

Commit your change with a clear message

A commit is a snapshot of your project with a note explaining what changed. Type git commit -m followed by your message in quotes. Git replies with how many files changed. Then run git log --oneline, and your new commit appears at the top of the list.

Every commit becomes a point in history you can look back at, so the message matters. Clear messages say what changed, such as "Add setup steps to README" or "Fix typo on login page". Vague ones like "update" or "stuff" tell nobody anything. In a month, even you won't remember what they meant.

Here's the part beginners often miss: the commit is still only local. Your snapshot is safe on your computer, but your GitHub page hasn't changed at all. One more command fixes that.

Write a message that says what changed
Avoid one-word messages like "update"
Confirm the commit with git log --oneline

# Save a snapshot with a message
git commit -m "Add setup steps to README"
# See your commit in the history
git log --oneline

Push your commit and confirm it on GitHub

git push uploads your new commits to the repository online and closes the loop. Because you cloned the repository, Git already remembers where it came from, so you don't need to type the URL again. Type git push and press Enter. You'll see lines about writing objects. Then run git status, which should say your branch is up to date with origin/main.

Behind the scenes, a short exchange happens. Your laptop signs in with a token or key, GitHub confirms you're signed in, your new commit is sent, and GitHub replies that main has been updated.

The terminal output is encouraging, but seeing the change online is the real proof. Open the repository page and refresh it, since the browser may still show the old version. Your commit message should appear next to the file you edited, and the file should contain your new line. For extra certainty, open the commits view: your commit should be the newest entry. When the browser and git status agree, your round trip worked.

git status says up to date with origin/main
Refresh the repository page in the browser
Your commit message appears beside the edited file
Your commit is at the top of the commits view

# Send your commits to GitHub
git push
# Then check what Git thinks
git status

Fix the most common git push errors

If something didn't go to plan, you're in good company. Most failures happen at the push step, and each has a simple fix. Git's messages can look alarming, but they usually name the problem. Key words like authentication or rejected tell you which fix you need.

Authentication failed means GitHub doesn't accept your password here. Create a personal access token in your GitHub settings and paste it when the terminal asks for a password, or use an SSH key. This is the fix most beginners need.

Updates were rejected means GitHub has newer commits than your copy, perhaps from changes made elsewhere. Run git pull to bring them down, then push again. Not a git repository means your terminal is outside the project, so cd into the cloned folder and try again.

Authentication failed: use a token or SSH key
Updates were rejected: run git pull, then push
Not a git repository: cd into the cloned folder

Repeat the loop: clone once, push often

Put together, the whole round trip is five steps. Copy the URL from the green Code button. Clone, then cd into the folder. Edit a file and stage it with git add. Commit with a clear message. Push, and check GitHub to see your change there.

The reassuring part is that you only clone once. After that, the daily work is edit, add, commit and push, over and over, every time you change something. If a push is ever rejected, pull first. After a few rounds, the loop becomes muscle memory and you'll stop thinking about the individual commands.

Clone a repository only once
Then edit, add, commit and push for each change
Pull first if a push is rejected

Key takeaways

Clone copies a repository down, commit saves a change, push sends it up.
Always cd into the cloned folder before running Git commands.
Only staged changes go into a commit; check with git status.
Commits stay local until you run git push.
Use a personal access token, not your password, when pushing over HTTPS.
Confirm every push on the GitHub page, not just in the terminal.

Frequently asked questions

Why doesn't my commit show up on GitHub?

A commit is saved only on your computer until you push it. Run git push, then refresh the repository page in your browser. If the push fails, read the error message for the cause.

Should I use HTTPS or SSH to clone?

Both work. If you haven't set up an SSH key yet, HTTPS is the simpler choice. Just make sure you have the matching login details, a token for HTTPS or a key for SSH, when you push.

Why does git push say authentication failed?

GitHub doesn't accept your account password at that prompt. Create a personal access token in your GitHub settings and paste it when the terminal asks for a password, or set up an SSH key.

What does "updates were rejected" mean?

It means GitHub has newer commits than your local copy. Run git pull to bring those changes down, then run git push again.

What is the staging area in Git?

It's a waiting room for your next commit. Only the changes you add with git add go into it, so you choose exactly what gets saved. git status shows staged files in green and unstaged changes in red.

Do I need to clone the repository every time?

No. You clone once to get a local copy. After that, you edit, add, commit and push inside that same folder each time you make a change.

Watch the full video on YouTube →

Tag

Ad