You now know what Git is and have it installed. Time to learn the workflow that will become second nature: the three step dance of adding, committing, and repeating.
Every time you want to save your progress in Git, you follow the same pattern. Think of it as taking a snapshot of your work. First you choose what goes in the photo, then you take the picture, then you write a note about what the picture shows.
The Three Steps
Step 1: Add your changes
When you modify files, Git notices but doesn't automatically track those changes. You have to tell it which changes to include in your next snapshot using git add.
To add a specific file:
git add filename.txt
To add all changed files at once:
git add .
The dot means "everything in this folder." Most of the time, you'll use the dot version.
Step 2: Commit your changes
After adding, you commit. This creates the actual snapshot and stores it permanently in your project history:
git commit -m "Your message here"
The -m flag lets you write your commit message directly in the command. Without it, Git opens a text editor, which confuses new users.
Step 3: Repeat
Make more changes, add them, commit them. This cycle becomes automatic once you get the hang of it.
Why Two Steps Instead of One?
The add then commit pattern seems redundant at first. Why not just save everything automatically? Because you don't always want to commit every change you've made.
Say you're working on two different features. You finish the first one but the second is half done and broken. With Git's approach, you can add and commit only the completed work, leaving the broken code for later.
The space between git add and git commit is called the staging area. Think of it as a loading dock where you gather everything before shipping it out.
Writing Commit Messages That Don't Suck
Your commit message explains what you changed and why. Future you (and anyone else reading your code) will thank you for clear messages.
Good messages are short and direct:
- "Fix login button alignment"
- "Add user registration form"
- "Remove unused CSS classes"
Bad messages tell you nothing:
- "Updates"
- "Fixed stuff"
- "asdf"
Start with a verb in the present tense. Write like you're giving Git a command: "Fix this bug" or "Add this feature." The convention is to keep the first line under 50 characters.
Checking Your Status
Before you add or commit, check what Git sees:
git status
This command shows you which files have changed, which are staged for commit, and which are completely new. When you're starting out, run this constantly. It's like checking your mirrors while driving.
You'll see output like:
Changes not staged for commit:
modified: index.html
modified: styles.css
Untracked files:
new-feature.js
This tells you that two files have changes but aren't staged yet, and one file is completely new to Git.
A Complete Example
Let's say you're working on a website. You edit your homepage and add a new stylesheet. Here's the complete workflow:
First, check what changed:
git status
Add your changes:
git add .
Commit with a clear message:
git commit -m "Update homepage layout and add mobile styles"
That's it. Your changes are now saved in Git's history forever.
The Safety Net
This workflow creates a safety net. Every commit is a point you can return to if something goes wrong later. Mess up your code? Go back to the last working commit. Accidentally delete something important? It's still there in your Git history.
The key is committing often. Don't wait until you've written 500 lines of code. Commit every time you complete a small piece of work. Fix a bug? Commit. Add a feature? Commit. Clean up some messy code? Commit.
Small, frequent commits make your project history readable and give you more recovery points if things go sideways.