Learning how to use GitHub comes down to one workflow: push your code, branch off safely, and merge through a pull request. One bad commit can wipe out days of work. GitHub makes every change reversible, but only if you use it right.
This guide walks through each stage in order. You'll create a repository, confirm your merge landed on main, and fix the errors that trip up almost everyone. Repo, branch, pull request, merge: it's the same flow professional teams use to ship code every day.
- Set up Git, a GitHub account and an SSH key or token, then test with ssh -T git@github.com.
- Create a repo with a README, clone it with the SSH URL, then commit small and push often.
- Do all new work on a branch with git switch -c so main stays safe.
- Open a pull request, and merge only when checks are green and a reviewer approves.
- Verify the merge with git pull and git log, and use git pull --rebase when a push is rejected.
- 0:00Intro
- 0:23Get your toolkit ready
- 0:57Create a new repository
- 1:33Clone it to your machine
- 2:09Commit and push your changes
- 2:49Branch off main safely
- 3:23Open a pull request
- 4:01Merge once checks pass
- 4:38Verify the merge landed
- 5:11Fix the most common errors
- 5:51Ship like the pros
- 6:22Your GitHub workflow in six moves
- 6:44Small commits. Short branches. Every PR.
Get Git, a GitHub account and an SSH key ready
Every step that follows depends on three things. You need Git installed on your machine and a GitHub account. You also need either an SSH key or a personal access token. The key or token matters most, because GitHub has to know it's really you before it accepts a single change. If you skip it, your first push fails.
Keep the finish line in view: one clean change, reviewed and merged into main through a pull request. Test your authentication before you touch a repository. Run ssh -T git@github.com in your terminal. If GitHub greets you by your username, you're authenticated. If it doesn't, fix it now, because every later step depends on it.
- Git is installed on your machine
- You can sign in to your GitHub account
- An SSH key or personal access token is set up
- ssh -T git@github.com greets you by username
ssh -T git@github.comCreate a new repository on GitHub
A repository is your project's home. It holds every file and every change you'll ever make. Creating one takes a single form and a single button. Open github.com/new. Under Create a new repository, type a name such as hello-github. Choose Public, tick Add a README file, and click Create repository.
Two choices on that form pay off later. Ticking the README gives main a first commit, so you clone a real project instead of an empty shell. The name becomes part of your URL, so short, lowercase and hyphenated beats clever. Click the button, and your project lives on GitHub.
- The repository name is short, lowercase and hyphenated
- Add a README file is ticked
- The new repo page loads with a first commit on main
Clone the repository to your laptop
The repo exists in the cloud. Now pull a copy down so you can work on it. Cloning copies everything: every file plus its full history. Click the green Code button, copy the SSH URL, then type git clone and paste it. You'll see 'Cloning into hello-github', then 'Receiving objects ... done'. Finally, cd into the folder.
You now have two copies of one project. The GitHub repo stays the source of truth in the cloud. Your laptop holds a full working copy, linked back to it under the name origin. Use the SSH URL if you set up a key. It matches your key, so you won't get prompts. You're now connected in both directions.
- You copied the SSH URL from the green Code button
- The clone finished with 'Receiving objects ... done'
- Your terminal is inside the hello-github folder
git clone git@github.com:you/hello-github.git
cd hello-githubCommit and push your first change
A commit saves a snapshot on your laptop. A push sends that snapshot up to GitHub. Edit, stage, commit, push: you'll run this loop all day. Edit the README, run git add to stage it, then commit with a message. Git prints a short hash for the commit. Run git push origin main, and main on GitHub jumps to your new commit.
Size matters. With one idea per commit, a bad change is one easy revert instead of days of lost work. Messages matter too. 'Add project intro' tells your future self exactly what happened, so the history reads like a log. Remember that until you push, the commit exists only on your laptop.
- Each commit holds one idea
- The message says what changed
- git push origin main finished without errors
- GitHub shows your new commit on main
git add README.md
git commit -m "Add project intro"
git push origin mainBranch off main before you experiment
Main works, so keep it that way. From now on, every experiment lives on its own branch, a parallel line of work that leaves main untouched. Run git switch -c feat/docs and Git replies 'Switched to a new branch'. The -c flag creates the branch and moves you onto it at once, with no separate step.
Commit your work on the branch, then push it with git push -u origin feat/docs. A new branch appears on GitHub. The payoff is safety. You can break everything on feat/docs and main won't notice, so working code keeps working while you try things. That safety net is the whole point of branching.
- git switch -c created the branch and switched you onto it
- Your commits are on feat/docs, not main
- The branch shows up on GitHub after git push -u
git switch -c feat/docs
git commit -am "Document setup steps"
git push -u origin feat/docsOpen a pull request to propose your change
Your branch is pushed. Now ask to bring it home. A pull request proposes merging your branch into main, with a review first. It shows the diff, runs checks and collects reviews in one place. After you push the branch, GitHub shows a Compare and pull request banner. Click it to start.
Under Open a pull request, check that base is main and compare is feat/docs. Add a title such as Document setup steps, request a reviewer, and click Create pull request. Use the description to explain why you made the change. Reviewers approve faster when they know the goal.
The review is your real safeguard. A second pair of eyes catches the typo, the bug or the leaked secret before main ever sees it. Whether you work alone or on a team, nothing reaches main unchecked.
- Base is main and compare is your branch
- The title describes the change
- A reviewer is requested
- The description explains why you made the change
Merge the pull request once checks pass
Wait before you merge. You need two signals: green checks and an approval. On the pull request page, look for 'All checks have passed' and 'Changes approved'. Then click Merge pull request, followed by Confirm merge. GitHub shows 'Pull request successfully merged', and your change is now in main.
Red means stop. If a check fails, fix the problem on the branch and push again. The pull request updates itself and reruns the checks, so you don't need to open a new one. After merging, delete the branch with the button GitHub offers. Short-lived branches mean fewer conflicts and a cleaner repo.
- The page shows 'All checks have passed'
- The page shows 'Changes approved'
- Any failing check is fixed on the branch first
- The branch is deleted after the merge
Verify the merge actually landed on main
Merged doesn't mean verified. Three quick checks take about thirty seconds and prove your change really landed. Locally, run git switch main, then git pull. Run git log --oneline -3. At the top you should see 'Merge pull request #1', then 'Document setup steps', then 'Add project intro'.
Next, refresh GitHub. The repo page on main should show your updated files, with the merge as the latest commit. Finally, scan the history under Commits. Every change is there, in order, with its author. That record isn't paperwork. It's exactly what makes every change reversible.
- git log shows the merge commit at the top
- Main on GitHub shows your updated files
- The Commits history lists every change in order
git switch main
git pull
git log --oneline -3Fix the most common GitHub push errors
Didn't go smoothly? That's completely normal. A few errors trip up almost everyone, and each one has a one-line fix. Read the error, match it to one of the cases below, and run the fix.
Push rejected means the remote has commits you don't, usually because someone pushed first. Run git pull --rebase, then push again. Auth failed means you typed your account password. Passwords don't work for Git, so use a personal access token. Key denied means GitHub doesn't know your SSH key, so add it in your GitHub settings.
Here's the classic case. git push origin main gets rejected with 'fetch first'. Run git pull --rebase, and Git replays your commit on top of the remote changes. When it reports 'Successfully rebased', push again.
- Push rejected: run git pull --rebase, then push
- Auth failed: use a token, not your password
- Key denied: add your SSH key in GitHub settings
git push origin main
git pull --rebase
git push origin mainThe bottom line
- Six moves: create a repo, clone it, commit and push, branch off, open a pull request, merge once checks pass.
- Commit small, so a bad change is one easy revert.
- Keep branches short. Merge in days, not weeks, so main doesn't drift away from your work.
- Open a pull request every time, even on solo projects, for checks, a record and an undo button.
- Run the pro loop on every change: branch off, small commits, open a PR, checks pass, merge, repeat.
Quick-fire questions
What's the difference between a commit and a push?
A commit saves a snapshot of your changes on your own machine. A push sends that commit up to GitHub. Until you push, the commit exists only on your laptop.
Why does GitHub reject my password when I push?
Passwords don't work for Git operations on GitHub. Use a personal access token instead, or set up an SSH key and clone with the SSH URL so you don't get prompts.
Do I need pull requests if I work alone?
They're still worth it. A pull request runs your checks, leaves a record of what changed and why, and gives you an easy way to undo a change.
How do I fix 'rejected (fetch first)' when pushing?
The remote has commits you don't have locally. Run git pull --rebase so Git replays your commit on top, then run git push again.
Should I delete a branch after merging it?
Yes. GitHub offers a button to delete the branch after the merge. Short-lived branches keep the repo clean and lead to fewer conflicts.
Why should I tick Add a README file when creating a repo?
The README gives main a first commit. That means you clone a real project rather than an empty one.
