Git is one of the first tools every new developer hears about — and one of the most commonly misunderstood. This guide explains what Git actually does, why it matters even for solo projects, and the small set of commands that cover most everyday use.
If you’ve followed our guides on setting up a coding environment and using the terminal, you have the pieces in place to start using Git, which relies heavily on the same terminal skills covered previously in this series.
This guide covers what Git actually is, why it’s worth learning even before you’re collaborating with anyone else, and the handful of commands that make up a typical Git workflow.
What Git Actually Is
According to MDN’s introduction to version control, version control tools like Git are an essential part of modern coding workflows — used for backing up code, collaborating on projects, and rolling back to earlier versions when something breaks.
In plain terms, Git takes periodic “snapshots” of your project as you work, each one labeled with a short message describing what changed. If something goes wrong later, you can look back through that history, compare versions, or even restore an earlier snapshot entirely — something that’s genuinely difficult to do reliably without a tool built specifically for it.
Git vs. GitHub: An Important Distinction
One of the most common points of confusion for beginners is treating Git and GitHub as the same thing. According to W3Schools’ Git introduction, Git is the version control tool itself — it works on your own computer and tracks changes locally. GitHub, by contrast, is an online service that hosts Git repositories, adding features like collaboration tools, issue tracking, and a place to back up your code remotely.
You can use Git entirely on your own computer without ever touching GitHub. GitHub becomes relevant once you want to back your code up online, share it with others, or collaborate on the same project with multiple people.
Why Git Matters Even for Solo Projects
It’s easy to assume version control only matters for teams, but Git is genuinely useful even working entirely alone. It gives you a reliable undo button that goes far beyond your editor’s built-in history — you can jump back to exactly how your project looked at any previous commit, compare two versions side by side, or safely experiment with a risky change knowing you can always return to a known-good state.
It also builds a habit that pays off enormously once you do start collaborating: describing your changes clearly and in small, logical chunks, rather than one enormous, undocumented blob of edits that nobody, including future you, can easily make sense of later.
The Basic Git Workflow
According to freeCodeCamp’s introduction to Git and GitHub, a typical Git workflow moves through a small number of predictable steps every time you save progress:
- git init — turns a folder into a Git repository, done once per project.
- git add — stages your changed files, marking them ready to be saved.
- git commit -m “message” — saves a snapshot of the staged changes, with a short message describing what changed.
- git status — shows which files have changed, staged, or are untracked.
- git log — shows the history of previous commits.
In practice, most day-to-day Git usage boils down to a repeating loop: make changes, git add them, git commit with a clear message, and repeat as your project develops.
A Simple Practice Sequence
cd my-project
git init
echo "print('hello')" > main.py
git add main.py
git commit -m "Add initial hello world script"
git logThis initializes a repository, creates a small file, stages it, commits it with a descriptive message, then displays the commit history — a genuinely complete first Git session, even though it’s a short one.
Writing Good Commit Messages
A short, specific commit message makes your project’s history genuinely useful later. “Fixed bug” tells future-you almost nothing six months from now; “Fix incorrect tax calculation in checkout total” tells you exactly what changed and why, without needing to open the actual code to remember what happened or why the change was even necessary in the first place. This habit costs nothing extra in the moment but pays off significantly the first time you’re trying to track down when a specific bug was introduced.
A Brief Introduction to Branches
As you get more comfortable with the basic workflow, you’ll run into the concept of branches — separate, independent versions of your project that let you work on something new without affecting the main, working version. Think of a branch as a safe sandbox: you can experiment freely, and if the experiment doesn’t work out, you simply abandon that branch without any impact on your main code.
git branch new-feature
git checkout new-featureThis creates a new branch called “new-feature” and switches to it. Any commits you make while on this branch stay separate from your main branch until you explicitly merge them back together. As a beginner, it’s fine to work directly on your main branch for small solo projects — branches become genuinely important once you’re either experimenting with risky changes or collaborating with others.
Telling Git What to Ignore
Not every file in your project folder truly belongs in version control. Temporary files, downloaded dependencies, and files containing sensitive information like passwords generally shouldn’t be tracked. Git handles this through a special file named .gitignore, where you list file and folder patterns you want Git to skip entirely:
# .gitignore
node_modules/
.env
*.log
__pycache__/Setting this up early, even for small projects, prevents a common beginner mistake: accidentally committing a folder full of downloaded packages, or worse, a file containing an API key or password that shouldn’t be shared publicly.
Seeing Exactly What Changed
Before committing, it’s often useful to see precisely what you’ve changed since the last commit, rather than relying on memory. The git diff command shows exactly which lines were added or removed in each modified file:
git diffLines prefixed with a plus sign show additions, while lines prefixed with a minus sign show removals. Getting into the habit of reviewing this output carefully before committing helps catch accidental changes — like leftover debug print statements — before they become part of your project’s permanent history.
Common Questions Beginners Ask About Git
Do I need to use Git for every small project? Not strictly, but it’s a good habit to build early, since the commands stay the same whether your project is five lines or five thousand. Starting small means the workflow feels automatic by the time a project actually matters.
What if I make a commit with a mistake in it? Git has ways to fix this — amending the most recent commit, or creating a new commit that corrects the issue. As a beginner, don’t worry about doing this perfectly; Git’s history is genuinely forgiving to fix as you learn more.
Do I need to memorize every Git command? No. The handful covered here — init, add, commit, status, log — cover the overwhelming majority of everyday use. More advanced commands can be looked up as specific situations call for them, and you’ll build fluency with the ones you actually use regularly.
What happens if I forget to commit for a while? Nothing breaks — Git simply hasn’t recorded a snapshot yet. It’s a good habit to commit reasonably often, in small logical chunks, rather than one massive commit at the end of a long session, since smaller commits are easier to understand and revert individually if needed.
Is it too late to start using Git on a project I’ve already been working on? Not at all. You can run git init inside an existing project folder at any point, and Git will simply start tracking changes from that moment forward — your existing files become the starting point for the project’s history.
Quick-Reference Git Basics Guide
- Git — a version control tool that tracks changes to your project over time.
- GitHub — an online service that hosts Git repositories; not the same thing as Git itself.
- git init — starts tracking a folder with Git.
- git add — stages changes, marking them ready to commit.
- git commit -m “message” — saves a labeled snapshot of staged changes.
- Clear commit messages — make your project’s history genuinely useful later.
Conclusion
Git’s reputation for being confusing usually comes from trying to learn every single feature all at once. In reality, the core workflow — stage, commit, repeat, with a clear message each time — covers most of what a beginner actually needs, and it’s worth building as a habit well before you’re collaborating with anyone else on a real, shared project.
In the next guide in this series, we’ll cover creating a GitHub account and your first repository, connecting the local Git skills covered here to GitHub’s collaboration and backup features, and getting your code hosted somewhere accessible from any computer.
Explore More Tools & Setup Guides →
When not writing, Alex is probably debugging someone else’s code.