Git Basics and Essential Commands for Beginners
Get started with Git repositories, staging, commits and the essential commands used in a basic version-control workflow.
On this page 13
No More “Final_Final_v2.js”: A Beginner's Guide to Git
If you’ve ever found yourself with a folder full of files named project.code, project_final.code, and project_final_REAL.code, you already know why you need Git. We’ve all been there. But there is a better way.
What is Git? (In Simple Terms)
Technically, Git is a Distributed Version Control System (VCS). That sounds intimidating, so let's break it down:
Think of Git as a Time Machine for your code. It keeps a perfect record of every change you make. If you mess something up, you can simply "rewind" to a point when everything was working perfectly.
Why do we use it?
- Collaboration: Multiple people can work on the same project without overwriting each other's work.
- Snapshots: Unlike "Saving" (which overwrites the old version), Git saves "Snapshots" of your project over time.
- Experimentation: You can try new ideas without risking your main, working code.
Core Concepts: The Vocabulary
Before we type any commands, we need to learn the lingo:
- Repository (Repo): This is just the folder where your project lives. It’s where Git tracks your files.
- Commit: This is a "save point." When you commit, you are taking a snapshot of your project at that exact moment.
- Branch: Imagine an alternate reality. You can create a "branch" to test a crazy new feature. If it works, you merge it back. If it fails, you delete it, and the main project remains untouched.
- HEAD: This is a pointer that says, "You are here." It points to the specific version (commit) you are currently looking at.
The Three States: How Git "Saves"
To master Git, you must understand the journey a file takes. Imagine you are packing a box to ship:
| State | Definition | Analogy |
|---|---|---|
| Working Directory | Files you are currently editing. | The items scattered on your desk. |
| Staging Area | A "waiting room" for your changes. | Placing items inside the shipping box. |
| Repository | The permanent database of snapshots. | Sealing the box and mailing it. |
A Basic Developer Workflow (Hands-On)
Let's walk through a real-life scenario. You are starting a new web project. Open your terminal, and let's go.
1. Start the Engine
git initWhat happened? You turned a regular folder into a Git Repository. A hidden .git folder was created to track your history.
2. Check the Situation
Bash
git statusWhat happened? This tells you what Git sees. If you have new files, Git will show them in red (Untracked). It sees them, but it isn't "watching" them yet.
3. Stage Your Files
Bash
git add index.html
# Or to add everything at once:
git add .What happened? You moved your files into the Staging Area. They are now in the "box" and ready to be saved.
4. Save the Snapshot
Bash
git commit -m "Created the homepage layout"What happened? You created a permanent save point. The files are now safely in the Repository. Always leave a message (-m) so you know what you did!
5. Look at History
Bash
git logWhat happened? You’ll see a list of every commit with its unique ID, the author, the date, and your message.
Guided Logic: Test Your Knowledge
Imagine you just finished a brilliant new feature. You run git commit -m "Added cool feature", but Git gives you an error saying "nothing to commit, working tree clean."
The Problem: You skipped a step. The Question: Based on the "Three States" table above, which command did you forget to run to move your code from the Working Directory to the Staging Area?
Summary Checklist
Here is the daily rhythm of a developer:
- Work on your code.
git statusto see what changed.git add .to prepare the changes (Stage).git commit -m "message"to save the snapshot (Commit).
Happy coding!
Comments 00
Got something to say? Leave a comment.
Join the discussion ↗