Introduction
I avoided learning Git properly for way longer than I should have. I'd just zip my project folder and rename it project-final-v2-ACTUAL-FINAL whenever I wanted a backup. It worked, technically, until it very much didn't.
Git solves exactly this problem, and you genuinely only need about 10 commands to be productive with it. Here's everything you actually need, skipping the theory you won't use day-to-day.
Git vs GitHub — What's the Difference?
Git is the version control tool that runs on your computer. It tracks changes to your files over time.
GitHub is a website that hosts your Git projects online, so you can back them up, share them, and collaborate with others.
You can use Git without GitHub. You can't really use GitHub without understanding Git.
Setting Up (One-Time)
git config --global user.name "Your Name"
git config --global user.email "*Emails are not allowed*"
The Core Workflow
1. Initialize a repository
git init
Run this once, inside your project folder, to start tracking it with Git.
2. Check what's changed
git status
Shows you which files are modified, new, or staged. You'll run this constantly — it's your "what's going on right now" command.
3. Stage your changes
git add .
This stages all changed files, preparing them to be committed. Use git add filename.js to stage just one file.
4. Commit your changes
git commit -m "Add contact form component"
This saves a snapshot of your staged changes, with a message describing what you did. Write clear, specific messages — future you will thank present you.
Connecting to GitHub
5. Create a repository on GitHub
Go to github.com, click "New Repository," give it a name. Don't initialize it with a README if you already have a local project — you'll connect them next.
6. Link your local project to GitHub
git remote add origin https://github.com/yourusername/your-repo.git
7. Push your code
git push -u origin main
The -u flag remembers this connection, so future pushes just need git push.
Branches — Working Without Breaking Things
A branch lets you work on a new feature without touching your main, working code.
git checkout -b new-feature
Creates and switches to a new branch called new-feature.
git checkout main
Switches back to your main branch.
Once your feature works, merge it back:
git checkout main
git merge new-feature
Why this matters: if you're experimenting with something risky, do it on a branch. If it breaks, your main branch stays untouched and safe.
Pulling Changes
If you're working across multiple machines, or collaborating with others:
git pull
Downloads and merges the latest changes from GitHub into your local project.
Common Beginner Mistakes
- Committing giant, vague changes. "fixed stuff" tells you nothing six months later. Commit small, logical chunks with clear messages.
- Forgetting to pull before pushing when working with others — leads to avoidable merge conflicts.
- Committing sensitive files like .env with API keys. Always set up a .gitignore file before your first commit.
- Never using branches. Working directly on main for every experiment is how small mistakes become big headaches.
A Basic .gitignore for Frontend Projects
node_modules/
.env
dist/
.DS_Store
Save this as .gitignore in your project root before your first commit — it stops these files/folders from ever being tracked.
Final Thoughts
You don't need to memorize every Git command that exists. status, add, commit, push, pull, and basic branching cover probably 90% of real, everyday use. Learn these solidly, and the rest you can look up as you go.
Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: muhammad-farhan-dev.github.io/muhammadfarhan.dev