Lesson 1 of 4 18 min read
Git and version control
Track changes to your code with Git commits, inspect history, and work safely with branches and merges.
In this lesson you will
- Explain what version control is and why teams depend on it
- Use the core Git workflow of init, status, add, commit and log
- Create, switch and merge branches
Why version control?
Without version control, projects end up with folders like project-final, project-final-v2 and project-really-final. Version control records every change to your files, who made it and why, so you can:
- go back to any earlier version,
- see exactly what changed and when,
- work on new features without breaking working code,
- combine work from many people safely.
Git is the most widely used version control system. It is distributed: every developer has the full history on their own computer.
Setting up
Install Git from git-scm.com, then tell it who you are (this appears on your commits):
git config --global user.name "Asha Menon"
git config --global user.email "asha@example.com"The three areas
- Working directory
- git add
- Staging area
- git commit
- Repository history
- The working directory holds your files as you edit them.
- The staging area collects the changes you want in your next snapshot.
- The repository stores the history of committed snapshots.
The core workflow
mkdir portfolio && cd portfolio
git init -b main # create a repository with a branch named main
echo "# My portfolio" > README.md
git status # README.md is listed as untracked
git add README.md # stage the file
git commit -m "Add README" # record a snapshot with a message
git log --oneline # list commits, newest firstA repeating cycle: Edit files, then git status, then git add (stage), then git commit (snapshot), then back to Edit files
Each commit gets a unique identifier (a hash such as 3f2a9c1). Write commit messages that explain what changed in the imperative mood, such as "Add contact form" or "Fix broken nav link".
Useful commands while you work:
| Command | What it does |
|---|---|
git status | Shows changed, staged and untracked files |
git diff | Shows unstaged changes line by line |
git add . | Stages all changes in the current folder |
git restore file.txt | Discards unstaged changes to a file |
git log --oneline | Shows a compact history |
Branches
A branch is an independent line of development. The default branch is usually main. Create a branch for each feature or fix:
git switch -c add-projects-section # create and switch to a new branch
# ...edit files...
git add .
git commit -m "Add projects section"
git switch main # go back to main
git merge add-projects-section # bring the feature into main
git branch -d add-projects-section # delete the merged branchMerge conflicts
If two branches change the same lines differently, Git can't decide which version to keep and reports a merge conflict. It marks the file like this:
<<<<<<< HEAD
<h1>Welcome to my portfolio</h1>
=======
<h1>Hi, I'm Asha</h1>
>>>>>>> add-projects-sectionEdit the file to keep the correct version, delete the markers, then git add the file and git commit to finish the merge. Conflicts are normal and become routine with practice.
Hands-on exercise
Create a new folder, initialise a Git repository and commit a README.md. Create a branch named feature-about, add an about.md file, commit it and merge it into main. Then create a deliberate conflict: on two different branches, change the same line of README.md in different ways, merge both into main and resolve the conflict. Finish by running git log --oneline --graph to see the history.
Knowledge check
3 questions • 70% to pass • Practice only, no certificate
Key concepts
- Version control records every change so you can review, undo and combine work safely.
- The core loop is: edit files, git add to stage, git commit to record a snapshot.
- Branches isolate work; git switch -c creates one and git merge combines it back.
- Resolve merge conflicts by editing the marked lines, then add and commit; never commit secrets.