Why every project needs version control
The folder full of "final" files
Picture a project folder like this:
app_controller.rb
app_controller_v2.rb
app_controller_v2_FINAL.rb
app_controller_v2_FINAL_fixed.rb
app_controller_v2_FINAL_fixed_ACTUALLY_FINAL.rb
That is what software development looks like without version control: no record of why something changed, no way to see what the code looked like last Tuesday, and disaster the moment two people edit the same file. Git replaces that entire folder with a single history that never lies to you.
What Git tracks
Git takes a snapshot of your whole project every time you tell it to (that action is called a commit). Each snapshot points back to the one before it, forming a timeline:
commit A ──▶ commit B ──▶ commit C ──▶ commit D (current state)
"init" "add users" "fix typo" "add tests"
Nothing is ever silently overwritten. You can jump to any point on that timeline, compare any two points, or figure out which commit introduced a bug: abilities that are unavailable in a folder of hand-renamed files.
Why Git, specifically
Version control systems existed before Git, but Git won for concrete reasons that matter to your daily work:
- Distributed: every clone of a repository carries the entire history, every snapshot ever made. Your laptop has a full, independent backup the moment you clone.
- Fast: almost every operation (commit, branch, diff) runs on your local disk: no network round trip.
- The industry standard: GitHub, GitLab, and Bitbucket are built on Git. Pull requests, code review, CI/CD pipelines, and deploy hooks all key off Git history.
Every professional Rails team you will ever join uses Git. Everything else in the software lifecycle sits on top of it.
Five words you will use every day
| Term | Meaning |
|---|---|
| Repository (repo) | A project's full history, tracked by Git |
| Commit | One saved snapshot of the project, with a message explaining why |
| Working tree | The actual files on disk, as you are editing them right now |
| Staging area | A holding area where you pick which changes go into the next commit |
| Branch | An independent line of commits, so you can work on something without touching the main history |
This course covers the first three; branches get a full course of their own later on the roadmap.
Check what you have
Git ships with the build tools you installed in your environment course. Confirm it is there:
git --version
git version 2.43.0
Any version 2.3x or newer works fine for everything in this series.
How this course is organized
git init: turn a folder into a repository, and see what that createsgit config: tell Git who you are, so every commit carries a real author.gitignore: tell Git what to never look at- Inspecting a repository:
status,log, anddiff - Multiple identities: separate config for work and personal projects
- Bootstrapping a real Rails project's Git history from scratch
By the end, every new project you start will have a properly initialized, properly identified Git history from its very first file.
Let's create your first repository.
Keep going with lesson 2
git init: anatomy of a repository
What git init creates in the .git folder, the three file states, and setting the default branch.
A free account also gives you the quizzes, your progress and notes, and the discussion.