Git and GitHub for Absolute Beginners: From Your First Commit to Your First Pull Request
A plain-English, hands-on Git and GitHub guide for absolute beginners. Build the mental model first, then run the real commands from your first commit to your first pull request.
Three days of work, then one wrong Git command — and the certainty that all of it was gone. It was not gone; the work was safe the whole time. But nobody had ever shown what Git was actually doing underneath, so every command felt like a coin flip.
That fear is the real problem with git and github for beginners. Not the commands. The missing mental picture. So before you type anything, I want you to see what Git is doing underneath. Then the commands become obvious.
Quick answer: Git and GitHub for beginners, in one breath
Git is a free tool on your computer that saves snapshots of your project, so you can go back to any version. GitHub is a website that stores a copy of those snapshots online and lets other people see them. Git is the engine on your laptop. GitHub is the parking garage on the internet. You use Git to save your work, then push it to GitHub to back it up and share it. You can learn both in an afternoon.
Here is that whole loop as a real terminal session — every line below is actual Git output, not a summary of it. Follow along in an empty folder and yours will match.
$ git init
Initialized empty Git repository in ~/my-first-repo/.git/
$ git status
On branch main
No commits yet
nothing to commit (create/copy files and use "git add" to track)
$ git add notes.txt
$ git commit -m "add notes"
[main (root-commit) bd45bee] add notes
1 file changed, 1 insertion(+)
create mode 100644 notes.txt
$ echo "second line" >> notes.txt
$ git diff
diff --git a/notes.txt b/notes.txt
index 08fe272..06fcdd7 100644
--- a/notes.txt
+++ b/notes.txt
@@ -1 +1,2 @@
first line
+second line
$ git log --oneline
bd45bee add notesThree things worth noticing. git status told you exactly what to do next, which it almost always does. The commit line reports 1 file changed, 1 insertion(+) — Git counts lines, not files. And git diff shows the change you have not committed yet: a + in front of the new line. If git diff prints nothing, everything is already committed.
What is the difference between Git and GitHub?
Git is a tool you install on your laptop. GitHub is a website that hosts your Git projects online. They are not the same thing, and mixing them up causes half the confusion beginners feel.
Here is the comparison I use with my students. It is the same as Microsoft Word versus Google Drive. Word is the program on your machine. Drive is the place online where you store and share the file.
| Question | Git | GitHub |
|---|---|---|
| Where does it live? | On your computer | On the internet |
| What is it? | A version-control tool | A website that hosts Git projects |
| Do you need internet? | No | Yes |
| Plain analogy | Microsoft Word | Google Drive |
| Made by | Linus Torvalds, 2005 | A company (now owned by Microsoft) |
So when you read “the git vs github difference,” remember this. Git saves your work. GitHub stores and shares it. You can use Git with no internet at all. GitHub only matters when you want a backup online or want to work with other people.
The mental model: where does your code actually live?
Git moves your files through four places. Once you can picture these four places, every command makes sense. This is the part most tutorials skip, and it is the most important part.
- Working folder — the normal files you edit, right there on your computer.
- Staging area — a holding tray. You put the files here that you want to save in your next snapshot.
- Commit history — the saved snapshots. Each one is a checkpoint you can return to.
- Remote (GitHub) — the online copy of all your snapshots.
Think of packing a parcel. Your working folder is your messy desk with everything on it. The staging area is the box where you place only the items you want to send. The commit is sealing the box and writing a label on it. The push to the remote is handing the box to the courier so a copy reaches GitHub.
Why a separate staging box? So you control exactly what goes into each snapshot. You might change five files but only want to save two of them together. Staging gives you that control.
How do I install Git and set it up?
Download Git from the official site, install it, then tell Git your name and email once. That name and email get stamped on every snapshot you save.
Go to the official Git documentation and download the installer for your system. On the install screens, the default options are fine. After it finishes, open a terminal (Command Prompt on Windows, Terminal on Mac) and run these two lines once. Use the same email you will use on GitHub.
# Tell Git who you are (stamped on every commit)
git config --global user.name "Your Name"
git config --global user.email "you@example.com"The word --global means “use this for every project on this computer.” You only do this step once. GitHub has its own clear setup walkthrough too, in the official set-up Git guide, if you want screenshots.
The core loop: how do add, commit, and push work?
You will do the same three steps thousands of times. Add stages your changes, commit saves a snapshot, push sends it to GitHub. Learn this loop and you know most of what you will use in Git every day.
This is the git add commit push workflow, and it maps directly onto the four places from earlier.
| Command | What it does | Moves your code from |
|---|---|---|
git add | Stages the changes you choose | Working folder → staging |
git commit | Saves a snapshot with a message | Staging → commit history |
git push | Sends snapshots online | Commit history → GitHub |
One more command earns its keep: git status. It tells you which files changed and what is staged. When you feel lost, run git status first. It is your map.
How do I create my first repository and first commit?
Make a project folder, run git init inside it, then add and commit your files. A repository (or “repo”) is a folder that Git is watching for changes.
This is your first time, so go slowly. Create a folder, put one file in it (even an empty README.md), then run these commands inside that folder.
# Start tracking this folder with Git
git init
# See what Git notices (untracked files show in red)
git status
# Stage every changed file (the dot means "everything here")
git add .
# Save a snapshot with a short message
git commit -m "My first commit"That is your first commit. The message in quotes should say what you changed, in a few words. Future you will read these messages to find old work, so keep them honest.
Now push it to GitHub. First, create an empty repository on GitHub.com (click the green “New” button, give it a name, do not add any files). GitHub then shows you commands that look like this.
# Connect your local repo to the GitHub repo
git remote add origin https://github.com/yourname/your-repo.git
# Name your main branch "main"
git branch -M main
# Push your commits and remember this link for next time
git push -u origin mainRefresh the GitHub page. Your files are there. That whole flow is the heart of how to use git for the first time. If you got this far, the scary part is behind you. GitHub’s own Hello World tutorial covers the same ground with pictures.
Save this loop somewhere you can see it. Try it tonight on a throwaway folder before you use it on real work. Ten minutes of practice removes most of the fear.
What is a branch and why use one?
A branch is a separate copy of your project where you can try changes without touching the working version. If the change goes wrong, you throw the branch away and your main code is untouched.
Picture a video game save slot. main is your main save. A branch is a second slot where you can experiment. If you mess it up, your main save is safe. This is why teams use branches for every new feature.
# Create a new branch and switch to it in one step
git checkout -b my-feature
# ...edit your files, then stage and commit as usual...
git add .
git commit -m "Add my new feature"
# Push the branch up to GitHub
git push -u origin my-featureNow your branch lives on GitHub, next to main. The next step is asking to merge it back. That request has a name: a pull request.
How do I open my first pull request?
A pull request (PR) asks the project owner to pull your branch into the main code. After you push a branch, GitHub shows a “Compare & pull request” button. Click it, write what you changed, and submit.
There are two paths to how to make your first pull request on github, and beginners mix them up. Here is the difference in plain words.
| Path | When you use it | How it works |
|---|---|---|
| Same-repo branch | It is your own project, or you have access | Push a branch, open a PR from that branch into main |
| Fork | It is someone else’s project you cannot edit | Copy their repo to your account (fork), push there, open a PR back to theirs |
- Push your branch (see the commands above).
- Open the repo on GitHub. A yellow banner shows your branch.
- Click Compare & pull request.
- Write a clear title and a short description of what you changed.
- Click Create pull request.
That is it. The owner reviews it, asks for changes if needed, and merges it. GitHub’s beginner’s guide to creating a pull request walks through the fork path screen by screen, which is the path you will use to contribute to open-source projects.
How do I fix common Git mistakes and scary errors?
Almost every scary Git message is harmless and reversible. Your committed work is very hard to lose. Here are the errors that make beginners panic, and the calm fix for each.
“fatal: not a git repository”
You ran a Git command in a folder Git is not watching. Either you are in the wrong folder, or you forgot git init. Check where you are, then run git init if needed.
A merge conflict
Two people changed the same line, and Git cannot decide which to keep. It marks both versions in the file with <<<<<<< and >>>>>>> markers. You open the file, delete the version you do not want, remove the markers, then save, add, and commit. That is all a conflict is: Git asking you to choose.
“detached HEAD”
You are looking at an old snapshot instead of a branch. Nothing is broken. To get back to safety, run git switch main. You are home again.
“rejected” push
GitHub has commits you do not have locally. Run git pull first to bring them down, fix any conflict, then push again. The rejection is Git protecting work you might overwrite.
Your undo toolkit
Keep these four commands handy. They cover almost every “oh no” moment in your first months.
# Throw away unsaved changes to one file
git restore
# Undo the last commit but keep the changes (un-commit)
git reset --soft HEAD~1
# Jump back to your main branch from anywhere
git switch main
# See your last commits as one line each
git log --onelineWhen I started, I broke my repo so often I kept these in a sticky note on my monitor. After a month I never needed the note. You will reach that point faster than you think.
What is a .gitignore and what should I never commit?
A .gitignore file tells Git which files to ignore so they never get saved or pushed. You use it to keep secrets and junk files out of GitHub.
This is where beginners get burned. They push a .env file with a database password to a public repo, and now the whole internet can read it. A .gitignore stops that. Create a file named exactly .gitignore in your project root and list what to skip.
# Installed packages, you can reinstall these
node_modules/
# Secrets and passwords, never push these
.env
# Log files, just noise
*.logThe rule is simple. Never commit passwords, API keys, or huge generated folders. If a file contains a secret or can be regenerated, it belongs in .gitignore.
Where do you go from here?
You now have the mental model and the daily loop. The only thing left is reps. Do this tonight: make a folder, run git init, write a tiny README.md, then do the full add, commit, push to a new GitHub repo. Then make a branch and open one pull request into your own main. Thirty minutes, start to finish.
Git is one tool on the long road to your first job. If you are building that road, read my guide on how to learn to code in 2026 next, then look at what the junior developer job market in 2026 actually expects. And when you start using AI tools alongside Git, my comparison of Claude Code versus agent harnesses will help you pick one.
The next time a Git command scares you, come back to the mental picture at the top of this post rather than to the command list. Almost every Git error stops being frightening once you can say where your code currently lives.
Git questions beginners actually ask
What is the difference between Git and GitHub?
Git is a free tool on your computer that saves snapshots of your project. GitHub is a website that stores a copy of those snapshots online and lets others see them. Git is like Microsoft Word; GitHub is like Google Drive.
What does git add do?
The git add command moves your chosen changes from your working folder into the staging area. Staging is a holding tray. It decides exactly which files will go into your next commit, or snapshot.
How do I make my first pull request?
Push a branch to GitHub, open the repository, and click the “Compare & pull request” button. Write a clear title and short description of your change, then click “Create pull request”. The owner can then review and merge it.
How do I fix a merge conflict?
A merge conflict means two changes touched the same line. Open the marked file, delete the version you do not want, remove the conflict markers, then save the file and run git add and git commit. The conflict is just Git asking you to choose.
What should I put in .gitignore?
List any file that holds a secret or can be regenerated. Common entries are node_modules/, .env files with passwords, and .log files. This keeps your secrets and junk files out of GitHub.
Can I use Git without GitHub?
Yes. Git works fully offline on your computer. You only need GitHub when you want an online backup or want to share your code and work with other people.
