What Is Version Control
Imagine a Infinite Ctrl+Z for your entire project. Not just for the last character you typed, but for any point in its history: yesterday morning, last week, before that change that broke everything. That's version control. Git keeps a timeline of your project, and every time you save (a "commit"), you create a point you can always go back to.
π§ Analogy: An Infinite Ctrl+Z
In a text editor, Ctrl+Z undoes the last thing you typed. But if you close the program, the history disappears. Git is like a Ctrl+Z that never disappears and works for the whole project.
- β’Each time you save, it becomes a photo of the project at that moment
- β’You can look at any old photo and see what changed
- β’If something breaks, you can return to the snapshot from when everything was working
- β’Nothing gets lost: the entire history is saved
π‘ Why Git exists
Before Git, people saved folders called projeto-final, projeto-final-2, projeto-final-AGORA-VAI. A mess. Git solves this: it keeps all the versions organized, shows exactly what changed between them, and lets several people work on the same project without getting in each other's way.
Installing and Configuring Git
Before using Git, you need to install it is to specify who you are (name and email). You only do this once per computer. Each operating system has its own way, but the result is the same: the command git starts working in the terminal.
Windows
Download the official installer and follow the βNext, Next, Nextβ steps
# Visit the official website in your browser
https://git-scm.com/download/win
# Run the installer. Accept the default options.
# It also includes "Git Bash," a terminal just for Git.
macOS
Via Homebrew or developer tools
# Option 1: with Homebrew (recommended)
$ brew install git
# Option 2: Apple tools
$ xcode-select --install
Linux
Through your distribution's package manager
# Ubuntu / Debian
$ sudo apt install git
# Fedora
$ sudo dnf install git
Check the installation and configure who you are
# Confirm that Git is installed
$ git --version
git version 2.43.0
# Tell Git your name (appears in each commit)
$ git config --global user.name "Your Name"
# Tell Git your email
$ git config --global user.email "you@email.com"
# Check what was configured
$ git config --list
user.name=Your Name
user.email=you@email.com
O --global applies to all projects on your computer. You only do this once.
β οΈ Common Error
Problem: You type git --version and you see "git: command not found" (or "not recognized as a command").
Solution: Git wasn't installed, or the old terminal didn't "see" the installation. Close the terminal and open it again. If it still doesn't work, repeat the installation steps for your operating system above.
The Basic Cycle: init, add, commit
Thereβs a three-step cycle youβll repeat a thousand times in life: start version control in a folder, prepare the files that changed, and commit (save the snapshot). Think of each commit as taking a project photo: you choose what goes into the photo, then take the picture with a caption.
git init - Start version control
Inside the project folder, this command creates a Git repository (a hidden folder .git) that will store the entire history.
$ git init
Initialized empty Git repository in /home/usuario/meu-site/.git/
git status - Check the situation
Shows which files have changed and haven't been saved yet. Always use it when you're unsure.
$ git status
On branch main
No commits yet
Untracked files:
index.html
style.css
(use "git add" to include it in the next commit)
Red = file modified but still outside the snapshot.
git add - Choose what goes in the snapshot
# Add a specific file
$ git add index.html
# Add ALL modified files
$ git add .
# Check: now they appear in green
$ git status
Changes to be committed:
new file: index.html
new file: style.css
The point . means βeverything in this folder.β Green = ready to go into the photo.
π· git commit - Take the photo
# -m is the photo caption (commit message)
$ git commit -m "First version of the site"
[main (root-commit) a1b2c3d] First version of the site
2 files changed, 12 insertion(+)
create mode 100644 index.html
create mode 100644 style.css
Done! The photo was saved to the history. The a1b2c3d is the unique "code" for this commit.
β Good commit messages
- β
"Adiciona menu de navegacao" - β
"Corrige cor do botao de envio" - βShort, clear, say WHAT changed
β Bad messages
- β
"alteracoes"(what changes?) - β
"asdasd"or"." - βHuge commits with 50 mixed files
Understanding What Changed: status, log, diff
Git isn't just for saving. It also tells you the project history: what changed just now, what changed over time, and exactly which lines were modified. Three commands answer these questions: status, log e diff.
git status - What changed just now
After editing a file thatβs already been committed, the status shows that it was modified:
$ git status
On branch main
Changes not staged for commit:
modified: index.html
(use "git add" to include it in the next commit)
git log - The full story
Lists all commits, from newest to oldest, with author, date, and message:
$ git log
commit 7a8b9c2d (HEAD -> main)
Author: Your Name <voce@email.com>
Date: Mon Jun 16 10:20 2026
Fix the menu colors
commit a1b2c3d4
Author: Your Name <voce@email.com>
First version of the site
# Short version, one line per commit
$ git log --oneline
7a8b9c2 Fixes the menu colors
a1b2c3d First version of the site
To exit the log when it fills the screen, press the q.
git diff - Exactly which lines changed
Shows line by line what was removed (in red, with -) and what's been added (green, with +):
$ git diff
diff --git a/index.html b/index.html
@@ -3,3 +3,3 @@
- <h1>Hello world</h1>
+ <h1>Welcome to my site</h1>
Line with - was the old version; with + and the new one.
π How to read the output in practice
- β’status before committing: "What am I saving?"
- β’diff before adding: "Are the changes correct?"
- β’log later: "how did the project evolve?"
Branches: Parallel Realities of the Project
A branch (branch) is a parallel copy of the project where you can test an idea without changing the main version. Itβs like having a draft: if the idea works, you merge it back; if it doesn't, you throw it away and nothing was affected.
π§ Analogy: Parallel Realities
Imagine you could create a parallel universe for your project, test a wild renovation there, and only bring it into the βrealβ universe if it turns out well. The branch main and the main reality (the one that goes live); each new branch is a testing universe.
Branch commands
# See which branch you're on and which ones exist
$ git branch
* main
# Create and switch to a new branch at once
$ git switch -c nova-cor
Switched to a new branch 'nova-cor'
# ... here you edit, add, and commit as you like ...
# Return to the main branch
$ git switch main
Switched to branch 'main'
# Bring the changes from nova-cor into main
$ git merge nova-cor
Updating a1b2c3d..7a8b9c2
Fast-forward
β When to use a branch
- βTest a new feature without breaking main
- βTry a different design
- βWork as a team, each on your own branch
β What to avoid
- βMake all changes directly on main in serious projects
- βLet old branches pile up without merging
- βSwitch branches with uncommitted changes
.gitignore: What Never to Version
Not everything in your project should go into Git. Passwords, automatically generated files, and huge dependency folders just get in the way (and can be dangerous). The file .gitignore is a list of what Git should ignore completely: it acts as if these files don't even exist.
β οΈ Common Error (and dangerous)
Problem: You commit a file .env with the database password and pushes it to GitHub. Now the password is public for the whole world to see.
Solution: Create the .gitignore before from the first commit and add .env in it. Git will never track this file, and the password stays only on your computer.
node_modules
Dependencies (huge)
.env
Passwords and keys
dist / build
Generated files
.DS_Store
System Junk
Example file .gitignore
Create the file in the project root (touch .gitignore) and put them inside, one rule per line:
# Installed dependencies
node_modules/
# Environment variables and passwords
.env
.env.local
# Files generated by the build
dist/
build/
# Operating system junk
.DS_Store
Thumbs.db
# Logs
*.log
The bar / at the end indicates a folder. The * in *.log means βany file ending in .log.β
π‘ Tip: no need to memorize
There are .gitignore ready-made options for each type of project on the site gitignore.io. You type "node," "python," etc., and it generates the complete file. At first, copy it from there and learn what each line does as you go.
π Module Summary
Next Module:
1.3 - GitHub and Pages (upload your code to the cloud and publish your site for free)