Git is arguably the single most important tool in modern software development — and also the one new developers spend the most time fighting when they don't understand the core concepts. The good news: despite feeling intimidating, there are really only about a dozen commands developers use on a regular basis. Here's the practical foundation, without the overwhelm.
What Git Actually Is
Git is a version control system that tracks every change you make to your files over time. Think of it as a time machine for your code — you can always go back to an earlier state, see exactly what changed and when, and experiment freely without fear of permanently breaking something.
Git and GitHub are not the same thing. Git is the version control tool itself, running locally on your machine. GitHub is a website that hosts your Git repositories online, making it possible to back up your code and collaborate with others.
Step 1: Initialize a Repository
Navigate to your project folder in the terminal and run:
git initThis tells Git to start watching this folder for changes. You'll now have a hidden .git folder tracking everything going forward.
Step 2: The Core Daily Workflow — Add, Commit, Push
This three-step cycle is what you'll do dozens of times a day once you're comfortable with Git:
git add .
git commit -m "Describe what you changed here"
git pushgit add .stages all your changed files, telling Git "include these in the next snapshot"git commit -m "..."saves that snapshot permanently in your project's history, with a message describing what changedgit pushsends your committed changes up to GitHub (or wherever your remote repository lives)
Step 3: Connect to GitHub
Create a new repository on GitHub, then connect your local project to it:
git remote add origin https://github.com/yourusername/your-repo-name.git
git branch -M main
git push -u origin mainA note on authentication: GitHub no longer accepts your account password for command-line pushes. You'll need a Personal Access Token instead — generate one under GitHub Settings → Developer Settings → Personal Access Tokens, and use it in place of your password when prompted.
Step 4: Branching — Working Without Breaking Things
A branch lets you work on a new feature or fix in isolation, without touching your main, working codebase until you're ready to merge it in.
git switch -c new-featureThis creates and switches to a new branch called new-feature in one step. Modern Git practice favors git switch over the older git checkout command for this specific purpose, since checkout historically did too many different things at once and caused confusion. Once your work is ready, merge it back:
git switch main
git merge new-featureStep 5: Cloning an Existing Project
To pull down a project that already exists on GitHub (someone else's, or your own from another machine):
git clone https://github.com/username/repo-name.gitThis downloads the full project along with its entire commit history to your machine.
Step 6: Pulling Updates
If you're working with others (or across multiple machines yourself), pull down the latest changes before starting new work:
git pullMaking this a habit before you start working each day prevents a large share of merge conflicts before they happen.
The GitHub-Specific Workflow: Pull Requests
On a team, you typically don't push directly to the main branch. Instead: push your feature branch to GitHub, then open a Pull Request (PR) — a formal request asking teammates to review your changes before they're merged into main. This is the standard collaboration pattern almost every professional codebase uses.
What to Do When You Mess Up (You Will, and That's Fine)
New Git users worry constantly about breaking something permanently — you genuinely can't, easily. A few lifesavers:
git status— shows exactly what's changed and staged right now, your most-used diagnostic commandgit log— shows your commit history, so you can see what happened and whengit reflog— can recover commits or branches you thought were lost; this has saved countless developers from what felt like a catastrophic mistake
Frequently Asked Questions
Do I need to memorize every Git command?
No. Most developers use around a dozen commands regularly and look up the rest when needed. Fluency with add, commit, push, pull, branch, and merge covers the overwhelming majority of daily work.
Is it safe to experiment and make mistakes while learning?
Yes — on your own local repository, it's genuinely difficult to break anything unrecoverably. Commands like git reflog exist specifically to recover from what feels like a disaster.
Should I use the command line or a GUI tool like GitHub Desktop?
Either works, but learning the command line first builds a foundational understanding that transfers to any tool or platform (GitLab, Bitbucket) later — GUI tools are convenient once you already understand what's happening underneath.
