Git Basics: Version Control for Beginners

Why version control exists

Imagine writing an assignment and saving it as final.doc, then final-new.doc, then final-REALLY-final.doc. Version control ends that mess. It is a system that records every change you make to your files, so you can see what changed, when, and why — and go back to any earlier version whenever something breaks. Git is the most popular version control tool in the world, and GitHub is the website where Git projects (repositories) are shared.

Installing Git

Git is free. On Windows, download it from the official Git website and install it with the default options. On Mac it often arrives with the developer tools; on Linux, install it with your package manager. When it finishes, open a terminal and check:

git --version

Then tell Git who you are — this name is stamped on every change you save:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Creating your first repository

A repository (repo) is simply a project folder that Git is watching. Make a folder, move into it, and start Git:

mkdir my-first-project
cd my-first-project
git init

git init creates a hidden .git folder — that folder is Git’s memory. Delete it and the history is gone, so leave it alone.

The three areas — the one idea that explains Git

• Working folder — your files as you edit them
• Staging area — the changes you have chosen to save next (git add)
• Repository — the saved history (git commit)

Create a file called notes.txt, write one line in it, then save your first snapshot:

git status          # see what changed
git add notes.txt   # stage the file
git commit -m "Add my first notes file"

A commit is a saved snapshot with a message explaining it. Write messages that say why, like “Fix login button colour”, not “stuff” or “changes”.

Branches — safe parallel work

A branch is an independent line of work. The default branch is called main. Professionals never experiment directly on main — they branch off, try the idea, and bring it back only when it works:

git switch -c feature/about-page   # create + move to a new branch
# ...edit files, add, commit as usual...
git switch main                    # go back to main
git merge feature/about-page       # bring the work into main

Merging and conflicts

Merging combines one branch into another. If the two branches changed different lines, Git merges automatically. If both changed the same line, Git stops with a merge conflict — it marks both versions inside the file and asks you to choose. Edit the file to the correct final text, delete the marker lines, then git add and git commit to finish. A conflict is not an error; it is Git asking a human a question.

Fixing common mistakes

• Typo in the last commit message? git commit --amend -m "Correct message" (only before sharing it)
• Committed too early? git reset --soft HEAD~1 undoes the commit but keeps your changes staged
• One file is a mess? git restore filename throws away its unsaved edits and brings back the last committed version — careful, this cannot be undone
• Lost? Run git status and git log --oneline first. Git almost always tells you what is happening and what to do next

Practice task (45 minutes)

Create a repo called git-practice. Make three commits: a README, a notes file, and an edit to the notes. Then create a branch, add a new file on it, merge it back into main, and run git log --oneline. You should see your whole story in a clean list — that list is version control working. Then do it hands-on in Lab 23 below.

Common mistakes to avoid

• One giant commit at the end of the week instead of small, clear commits as you work
• Commit messages like “update” that explain nothing to your future self
• Committing passwords, keys or huge generated files — treat anything committed as hard to fully erase