Git for Beginners: init, add, commit, push, pull Explained with Real Examples

You have a project that changes every day. HTML, CSS, PHP, maybe a database. Every edit is a risk: one fix breaks another, you try to go back by memory, files pile up in folders like site_final_v3_true_final.zip. We see this all the time from people who come to us with a half-built WordPress e-commerce and no change history.

We, at Meteora Web, have been using Git since our foundation in 2017. Not because it's trendy, but because it saves us hours every week. And when you manage clients all over Italy, every hour counts. In this guide we take the five fundamental commands — init, add, commit, push, pull — and explain them with examples you can copy and paste. No corporate slides, no Linux history. Just stuff you'll use right now.

Why Git is not optional — the problem it solves

Imagine you're working on a website. You edit the footer. Then the client says: "The old footer was better." With Git you type git checkout . and you're back. Without Git? You dig through the trash or manual backups, or rewrite everything. For Italian SMEs, time spent recovering old versions is money lost. We see this when sites arrive with plugins updated randomly and no change log. Git isn't just for startup developers: it's for anyone who touches code, even if you only do WordPress templates.

First step: initialize a repository with git init

A repository (repo) is the folder where Git keeps track of everything. git init creates a hidden .git subfolder inside your directory. From that moment, every file you change can be tracked.

How to do it

cd /var/www/my-site
git init

# Output: Initialized empty Git repository in /var/www/my-site/.git/

Done. Now you can start saving versions. Practical tip: do it at the beginning of the project, not three weeks later — otherwise you lose the history of initial changes.

Add files to the staging area with git add

Git does not automatically track every file. You have to explicitly tell it which ones to watch. git add moves files to the staging area, which is the "list of things to save in the next snapshot."

Basic usage

# Add one specific file
git add index.html

# Add all files in the current folder
git add .

# Add everything, including deleted files
git add -A

Difference between . and -A? git add . adds new and modified files in the current directory and subdirectories. git add -A also includes file deletions you made. For beginners, always use git add -A — you avoid leaving orphan files.

Common mistake: forgetting to add files before commit. Always check with git status.

git status
# On branch master
# Changes not staged for commit:
#   modified:   style.css
# Untracked files:
#   new-script.js

Take a snapshot with git commit

A commit is the photograph of your project at an instant. Each commit has a message describing what you did. It's not just a note for yourself — it's the project history that anyone (future you, colleagues, clients) can read.

How to make a good commit

# After git add, run
git commit -m "Added contact form with client-side validation"

Golden rule: one commit = one logical change. Don't mix a bug fix with a new feature. Write clear messages in English (or your language, but be consistent). Examples:

• "Fixed 404 error on product page"
• "Updated CSS footer for mobile"
• "Removed dead code in functions.php"

To see history: git log --oneline (compact) or git log (detailed).

Save to a remote server with git push

So far everything is local. To collaborate or have a backup off your computer, you need a remote repository (GitHub, GitLab, Bitbucket, or your own server). We recommend GitHub because it's the most popular and has generous free plans. Even a VPS with a bare Git repo works.

Connect a remote

# Add a remote repository called origin
git remote add origin https://github.com/your-username/my-site.git

# Verify
git remote -v

# Now send local commits to remote
git push -u origin master

The -u flag sets the current branch (master) to track the remote. After that, just git push is enough.

Note: if you use the branch named main (increasingly common), replace master with main. GitHub defaults to main.

Download changes from remote with git pull

When you work in a team (or from two different computers), you need to update your local copy with others' changes. git pull does two things: downloads new commits (git fetch) and merges them into your current branch (git merge).

# Make sure you're on the right branch
git checkout master

# Fetch and merge
git pull origin master

If there are conflicts (you and a colleague edited the same line), Git shows the conflicting files. You'll need to edit them manually and then make a new commit. It's normal, don't panic. We handle it every day.

The complete workflow in 5 commands

Here's the sequence we use daily:

1. git pull — update local with remote changes.
2. Edit files.
3. git add -A — stage everything.
4. git commit -m "message" — take the snapshot.
5. git push — share with the team.

With these five steps you never lose a change. And you no longer need final_v2 folders.

Concrete example: a static HTML site

Let's practice. Create a mini site, version it, and upload it to GitHub.

mkdir my-first-site
cd my-first-site
git init
echo "<h1>Hello World</h1>" > index.html
git add index.html
git commit -m "First commit: initial page"

# Now on GitHub create a new repository (no README)
git remote add origin https://github.com/your-user/my-first-site.git
git push -u origin master

# Edit index.html
echo "<h1>Welcome to Meteora Web</h1>" > index.html
git add -A
git commit -m "Updated title with brand"
git push

Done. Now you have the site on GitHub with full history. You can clone it on another computer with git clone https://github.com/your-user/my-first-site.git.

Common mistakes and how to avoid them

• Commits too large: if you change everything at once, the message becomes vague and tracking is hard. Split into atomic commits.
• Forgetting .gitignore: files like wp-config.php or node_modules/ should not be in the repo. Create a .gitignore file right after git init.
• Pushing to the wrong branch: before pushing, check which branch you're on with git branch.
• Not pulling before push: if someone else pushed changes, you'll get an error. Always git pull before git push.

Useful tools for beginners

The command line is powerful, but can be intimidating at first. Use a graphical client like GitHub Desktop (very simple) or VS Code with built-in Git integration. We use the shell for full control, but for a starting client we recommend GitHub Desktop. The important thing is understanding the concepts.

Quick reference table

Command	What it does
git init	Creates a new local repository
git add file	Adds file to staging area
git commit -m "msg"	Saves a snapshot with message
git push	Uploads commits to remote
git pull	Downloads and merges remote changes
git status	Shows working directory status
git log	Shows commit history

In summary — what to do now

1. Create a new project (or take an existing folder) and run git init.
2. Add a file with git add -A and then make your first commit.
3. Create a GitHub account (if you don't have one) and a new empty repository. Then connect the remote with git remote add origin ....
4. Push your commits to GitHub.
5. Modify something and repeat: add, commit, push.

You don't need to know everything at once. Start with these five commands and the rest will follow. If you work with WordPress and want to see how to integrate Git into a real development workflow, here's an SQL guide that shows how we track data changes. Same philosophy: control and traceability.