The problem: final_v3_REALLY-final.docx
You have probably done this already, even without writing code. You finish something, save it as report.docx, then make changes and save report_v2.docx, then report_final.docx, then report_final_REALLY.docx. A week later nobody — including you — knows which file is the real one, or what actually changed between them.
Git is the cure for this mess. It is a tool that quietly records the history of your project as you work, so you keep one set of files — not twelve copies — while still being able to travel back to any earlier moment. Think of it as an unlimited, automatic "undo" that remembers not just the last step, but every meaningful step you ever saved, with a note about why.
The mental model: repositories and snapshots
Everything in Git lives inside a repository — usually shortened to "repo." A repository is simply your project folder plus its entire history. The files look completely normal on your computer; the history is tucked away in a hidden folder Git manages for you. Turning a plain folder into a repository takes one command.
git init
The history is made of commits. A commit is a saved snapshot of all your files at one moment, with a short message you write explaining what changed and why — for example, "Add login button" or "Fix typo on homepage." Each commit links to the one before it, so the whole chain reads like a labelled timeline of your project. You can revisit any snapshot at any time.
The everyday loop: edit, stage, commit
Day to day, you will repeat one short loop. You edit your files as usual. Then you tell Git which changes you want to bundle together — this in-between step is called staging, and it lets you commit some changes now and others later. Finally you commit, attaching your message. That's the whole rhythm.
- Edit your files in your editor and save them as normal.
- Stage the changes you want to keep: git add . (the dot means "everything I changed").
- Commit them with a message: git commit -m "Add contact form".
The message matters more than beginners expect. Months later, the message is what you read to understand the change without reopening the code. A good message finishes the sentence "This commit will…" — "Fix crash when email is empty" beats "stuff" or "asdf" every single time. Short, specific, and present-tense is the goal.
Branching: a safe parallel line
Sometimes you want to try a new idea without risking the version that already works. A branch is exactly that: a parallel line of work that splits off from your main history. On the branch you can experiment freely — make commits, break things, change your mind — and your stable main version stays untouched the whole time.
git switch -c new-idea
When the idea works out, you bring it back with a merge. Merging tells Git to fold the commits from your branch into the main line, so the two histories become one again. If the idea flops, you simply delete the branch and it is as if the detour never happened. This is why branches make people brave: nothing you try can hurt what already works.
Working with others: Git vs GitHub
People often blur the two, but they are different things. Git is the tool that runs on your own computer and tracks history. GitHub is a website that stores a copy of your repository in the cloud so you and others can share it, see it, and work on it together. You can use Git completely alone; GitHub is what turns it into teamwork. (GitLab and Bitbucket are similar websites.)
To contribute to someone else's project, you usually fork it — that makes your own personal copy of their repository on GitHub. You change your copy, then open a pull request: a polite, reviewable proposal that says "here are my changes, please consider merging them into yours." The owner reads it, comments, maybe asks for tweaks, and clicks Merge when happy.
When it tangles: conflicts and rebase
Sooner or later you and a teammate will edit the same line of the same file in two different ways. Git cannot guess whose version is right, so it stops and shows you a merge conflict. This is not a failure or a punishment — it is simply Git being honest and asking you to choose. It marks the two competing versions in the file with clear dividers.
<<<<<<< HEAD Welcome to our site! ======= Welcome to our shop! >>>>>>> their-branch
You will also hear the word rebase. It is an advanced alternative to merging that replays your commits on top of the latest work, producing a cleaner, straight-line history with no extra "merge" entries. It is genuinely useful, but it rewrites history, so as a beginner it is fine to leave it alone for now and reach for plain merging — you can learn rebase once the basics feel comfortable.
Recap: your five everyday commands
That is the whole foundation. You will pick up more over time, but ninety percent of daily Git is just a handful of commands repeated in a comfortable rhythm. Keep this tiny cheat-sheet nearby until your fingers remember it.
git status # what's changed? git add . # stage everything git commit -m "..." # save a snapshot git push # send commits to GitHub git pull # get others' commits