Git and GitHub for Beginners: Your First Steps into Version Control
📅 Want a study plan for this topic?
Get a free 7-day learning plan in your calendar — one small lesson every day.
Introduction
Imagine you are working on a big school project. You save it as project_final.docx, then project_final_v2.docx, then project_final_FINAL.docx. A week later you have ten files and no idea which one is correct.
Every programmer faces this problem — except worse, because code breaks in invisible ways. That is why developers use version control, and the most popular version control tool in the world is Git, usually paired with GitHub. This guide shows you what they are, how they work, and how to push your very first project online today.
What Is Version Control (and Why Should You Care)?
Version control is a system that records every change you make to a file or a set of files, so you can look back at any earlier version later. Think of it as an unlimited “undo” button combined with a diary that remembers exactly what you changed and when.
Here is what it gives you:
- Safety. Accidentally deleted something? Roll back to yesterday’s version in one command.
- Fearless experiments. Try a risky new idea in a separate “branch” while your working code stays untouched.
- Teamwork. Five people can edit the same project at once without overwriting each other.
- Proof of skill. Employers routinely check a candidate’s GitHub profile the way they check a résumé.
You do not need any of this to be complicated. For beginners, five or six commands cover almost everything.
Git vs. GitHub: What’s the Difference?
This confuses every beginner, so let’s clear it up once:
- Git is free, open-source software that runs on your computer. It does the actual version tracking. No account needed, no internet needed.
- GitHub is a website (owned by Microsoft) that hosts Git projects online. Think of Git as the save system and GitHub as the cloud folder where you keep a backup — plus a social network where developers share code.
You can use Git without GitHub, but GitHub is where the magic of sharing, collaboration, and building your public portfolio happens.
Installing Git and Setting It Up
Download Git from git-scm.com and install it for your system (Windows, macOS, or Linux). Then open a terminal and tell Git who you are — it stamps your name on every change you save:
git config --global user.name "Your Name"
git config --global user.email "you@example.com"You only do this once per computer. That’s it — Git is ready.
The 5 Commands That Cover 90% of Git
Let’s walk through a tiny example. Create a folder, open a terminal inside it, and type:
1. git init
Turns the folder into a Git project (“repository”). Git starts watching for changes.
2. git add .
Stages your files — meaning “I want these changes saved.” The dot means “everything in this folder.”
3. git commit -m "My first commit"
Saves a snapshot of your staged files with a short message describing what you did. Good messages read like “Add login page” or “Fix crash on empty input” — never “stuff” or “update”.
4. git log
Shows your history of commits. This is your project’s diary.
5. git status
Shows what’s changed since your last commit. When in doubt, run this — it’s your compass.
The basic rhythm of Git is always the same: make changes → git add → git commit. Do it often. Small, frequent commits are much easier to understand than one giant commit at the end of the week.
Your First GitHub Repository: Step by Step
Ready to put your code on the internet? It takes about five minutes:
- Create a free account at github.com.
- Click the “+” menu in the top-right corner and choose “New repository”.
- Give it a name (for example,
my-first-project), keep it public or private — your choice — and click “Create repository”. - GitHub will show you a few commands. In your project folder’s terminal, run these two lines (replace the URL with yours):
git remote add origin https://github.com/YOUR-USERNAME/my-first-project.git
git push -u origin main- Refresh your GitHub page — your files are now online. Congratulations, you’re officially a GitHub user.
Your GitHub profile is now a public portfolio. Every project you push shows future employers, teachers, and collaborators what you can build.
Practical Takeaways
- Commit messages matter. Future-you (and anyone else reading) will thank present-you for clear messages.
- Commit early, commit often. One commit per logical change, not one per month.
- Always pull before you push when working with others, so you don’t overwrite their work.
- Start with a README. A short
README.mdexplaining what your project does makes any repository look professional instantly. - Learn branching next. Branches let you experiment safely — the natural next step once these basics feel familiar.
Let’s Run a Real Git Session: Three Commits, Exact Output
The guide above lists the Git commands, but it never shows you what the terminal actually says back. That is the part that makes beginners nervous — the blank screen after you press Enter. So I ran a real session, start to finish, in a fresh folder, and here is the exact output. First, the setup: create a folder, turn it into a repository, and save the first version of a file.
$ git init -b main
$ echo "My first website" > index.html
$ git add index.html
$ git commit -m "Add homepage"Then I added one line to the file — a heading — and saved again. Then one more line, and saved a third time. Here is what git log --oneline showed afterwards. These are my real commit codes; yours will look different, and that is completely normal — Git generates a fresh code for every commit on every computer.
eaf4553 Add second line
8882c57 Add heading to homepage
32b541e Add homepageRead it bottom to top: the first thing I saved is at the bottom, the newest save is at the top. Each line is one snapshot, and the short message is the label I gave it. Three commits, and git rev-list --count HEAD confirms it: 3.
Now the two status checks that tell you where you stand. After editing the file but before staging it, Git said:
$ git status --short
M index.htmlThat space-then-M means "modified, but not staged yet" — Git sees the change, but you have not told it to include the change in the next snapshot. After git add index.html, the same command said:
$ git status --short
M index.htmlNow the M has moved to the front: "modified and staged." One letter, two positions, two different meanings — and once you have seen both, you will never mix them up again. And here is exactly what the second commit saved, shown by git show:
diff --git a/index.html b/index.html
--- a/index.html
+++ b/index.html
@@ -1 +1,2 @@
My first website
+<h1>Hello</h1>The plus sign marks the one line I added; everything else stayed the same. That is the whole idea of a commit: not a copy of the file, but a record of exactly what changed. In my opinion, this is the moment Git clicks for most people — when you realise the history is not a pile of files called final_v2 and final_FINAL, but a clean list of small, labelled changes you can read, count, and undo one at a time.
Try it yourself: add a second file, for example style.css, stage it, commit it with the message "Add stylesheet", and run git log --oneline again. If you see four commits and the count says 4, your repository is working exactly as it should — and you have done the full Git flow on real work, not a tutorial example.
Conclusion
Git and GitHub turn messy file chaos into a clean, time-traveling record of everything you build. You now know the core ideas — repositories, staging, commits — plus the five commands that handle almost all daily work, and how to publish your first project on GitHub.
Your next step: take a project you already have — even a single HTML file from our HTML & CSS guide — and run the full flow: git init, git add, git commit, then push it to GitHub. The best way to learn Git is to use it on real work, one commit at a time.
Happy coding — and remember: Learn • Practice • Build.
Keep learning
📅 Want a study plan for this topic?
Get a free 7-day learning plan in your calendar — one small lesson every day.
Leave a Reply