Lecture Notes: Version Control in Teams
Prerequisites:
- None — no prior experience with Git or version
control is fair. A basic understanding of what “saving files” means is
enough.
- What You’ll Be Able to Do After This Lecture
- Understand what version control is and why
it’s important for teamwork.
- Use Git commands like init, add, commit, push,
and pull confidently.
- Work with branches to manage parallel
development safely.
- Resolve simple conflicts that happen when
multiple people edit the same code.
- Collaborate on GitHub or similar platforms
using common team workflows.
Introduction: What Is Version Control
and Why Should You Care?
Core Definition
- Version control is a system that tracks every
change made to your code (or any file), allowing you to go back in time,
compare versions, and collaborate with others without overwriting each
other’s work.
A Simple Analogy
- Think of version control like Google Docs for
code. When you edit a document in Google Docs, it keeps track of every
change, lets you see who made what change, and allows multiple people to
work at once — all without losing progress.
Git does the same for programmers:
- It tracks all versions of files.
- It records who made which change.
- It allows multiple people to safely work
together on the same project.
Real-World Example
- Imagine you and your teammate are writing a
Python project together. You’re working on a login system while your
teammate adds a dashboard. Without version control, if you both save and
send files back and forth, it’s easy to lose track or accidentally
overwrite each other’s work.
- With Git, both of you can:
- Work on your own copy (branch).
- Save progress with clear messages (commit).
- Merge your updates later.
- If something breaks, you can roll back to an
older version. That’s the safety net version control provides.
Limitation
- Version control won’t fix your code errors
automatically — it only keeps a record of changes and helps you
collaborate safely. The logic and correctness are still up to you!
Why Version Control Matters
Problem It Solves:
- Without version control, teams often face:
- Lost files (“final_final_version2.py”)
- Overwritten changes
- Confusion over who changed what
- No way to undo a mistake
What You’ll Gain:
Safety: Easily undo
mistakes.
Clarity: Track every
change with author and date.
Collaboration: Multiple
developers can work together efficiently.
Consistency: Everyone stays
synced to the same project version.
In the Real World:
- Every professional software team — from Google
to small startups — relies on version control tools like Git and platforms
like GitHub, GitLab, or Bitbucket.
The Foundation: Core Concepts Explained
Concept A: What Is Git?
Definition:
- Git is a version control system — a tool that
records changes to your files over time. It runs locally on your computer,
so even without the internet, it tracks versions.
Key Characteristics:
- Stores snapshots of your project.
- Allows branching and merging (parallel
development).
- Keeps full history of changes (commits).
- Works offline or online.
A Concrete Example:
git init
- This creates a new Git repository in your
project folder. From now on, Git tracks every change.
Common Confusion:
- Beginners think Git and GitHub are the same.
- Git = the tool.
- GitHub = the website to store and share Git
repositories online.
Concept B: The Commit–Push Loop
Definition:
- This is the core workflow for saving and
sharing changes. It consists of three main steps:
Add – Tell Git which files you want
to save.
Commit – Save those
changes with a message.
Push – Upload the commits to a shared
remote repository (like GitHub).
Step-by-step Example:
git add app.py
git commit -m "Added login
feature"
git push
What Happens Here:
git add: Tells Git to
include the file for tracking.
git commit: Saves a
snapshot locally.
git push: Sends your
local changes to the remote repository so others can see them.
Common Confusion:
- Many beginners forget to commit before
pushing, leading to errors. Remember: you
can’t push something you haven’t committed.
Concept C: Branching
Definition:
- A branch is a separate line of development. It
lets you experiment or work on new features without disturbing the main
code (often called main or master).
Why It Matters:
- You can develop safely.
- You can test new ideas without breaking
existing code.
- Once satisfied, you can merge your branch back
into the main one.
A Concrete Example:
git branch feature-login
git checkout feature-login
- Now you’re on a new branch called
feature-login.
Common Confusion:
- Beginners think branching duplicates the
entire project. Actually, Git stores only the differences — it’s
lightweight.
Concept D: Merging
Definition:
- Merging combines changes from one branch into
another. Usually, you merge your feature branch into the main branch after
testing.
A Concrete Example:
git checkout main
git merge feature-login
-Now, your new
feature (login) is part of the main project.
What If Conflicts Occur?
- Sometimes two people change the same line of
code — Git marks a merge conflict.
- You must manually choose which version to
keep, then commit again.
Common Confusion:
- Beginners panic when they see “merge
conflict.”
Remember:
- Git won’t lose your code — it pauses for you
to resolve it safely.
Concept E: Remote Repositories
Definition:
- A remote repository is a version of your
project stored online (GitHub, GitLab, etc.) for collaboration and backup.
Key Characteristics:
- Accessible to team members anywhere.
- Used for pushing (uploading) and pulling
(downloading) changes.
- Ensures synchronization across devices.
Example:
git remote add origin
https://github.com/username/project.git
git push -u origin main
- This links your local repository to GitHub.
Seeing It in Action:
- Worked Examples
Example 1:
- Setting Up a Project
Scenario:
- You’re starting a new Python project for a
small tool.
Steps:
mkdir team-tool
cd team-tool
git init
echo "print('Hello Team!')"
> app.py
git add app.py
git commit -m "Initial
commit"
Key Lesson:
- A repository is just a folder Git is watching
— that’s it!
Example 2:
- Collaborating with a Team
Scenario:
- You and your teammate are working on the same
GitHub repository.
Steps:
Clone the repository:
git clone
https://github.com/teampath/project.git
- Make changes and commit locally.
- Push your changes.
- Pull updates before pushing next time:
git pull
git push
Key Lesson:
- Always pull before you push to stay in sync
with teammates.
Example 3:
- Using Branches for Features
Scenario:
- You’re adding a “dark mode” feature.
Steps:
git checkout -b feature-darkmode
# make your changes
git add .
git commit -m "Added dark mode
styles"
git checkout main
git merge feature-darkmode
Key Lesson:
- Branches allow parallel work without fear of
breaking others’ code.
Example 4:
- Handling Merge Conflicts
Scenario:
- You and your teammate edited the same line.
Git shows:
<<<<<<< HEAD
print("Welcome to App")
=======
print("Welcome, dear user")
>>>>>>> feature-ui
Solution:
- Manually edit the line to choose or combine
both versions, then:
git add app.py
git commit -m "Resolved merge
conflict"
Key Lesson:
- Conflicts aren’t errors — they’re Git asking
for your decision.
Example 5:
- Sharing Work on GitHub
Scenario:
- You finished your feature and want to show it
to your team.
Steps:
Push your branch to GitHub:
git push origin feature-darkmode
- On GitHub, create a Pull Request (PR).
- Teammates review your code and comment.
- Once approved, merge via GitHub.
Key Lesson:
- Pull requests are a professional way to review
and integrate changes.
Common Pitfalls: What Can Go Wrong
Mistake:
- Forgetting to commit before pushing
Why It Happens
- Rushing workflow
Fix
- Always check git status
Mistake:
- Working directly on main branch
Why It Happens
- Fear of branching
Fix Always create a new branch for
features
Mistake:
- Ignoring pull updates
Why It Happens
- Causes conflicts
Fix Run git pull daily
Mistake:
-Not writing clear
commit messages
Why It Happens
-Laziness
Fix -Use short, clear summaries
(“Fixed login bug”)
Mistake:
- Force pushing (--force) without need
Why It Happens
- Misunderstanding
Fix
- Avoid unless necessary
Your Turn: Practice &
Self-Assessment
Practice Task
- Create a Git repository, add a file, make
multiple commits, create a branch, and merge it back.
Steps:
- Create a folder and initialize Git.
- Add a file named notes.txt and
commit.
- Create a branch update-notes.
- Edit notes.txt and commit again.
- Merge back into main.
Bonus: Push to GitHub
and create a pull request.
Check Your Understanding
- What is the difference between Git and GitHub?
- Why should you use branches in a team project?
- What is a commit message and why is it
important?
- How do you resolve a merge conflict?
- Why is “pull before push” a good practice?
Consolidation: Key Takeaways & Next
Steps
Essential Ideas
- Git keeps a complete history of your code
changes.
- Commits are safe checkpoints in your work.
- Branches allow multiple people to develop
features independently.
- Merges bring everything back together.
- Remotes like GitHub let you collaborate
online.
Mental Model Check
- Think of Git as a time machine for code.
- It records every change, lets you travel back
in time, and allows multiple people to write the same story without
stepping on each other’s sentences.
- What You Can Now Do
- Initialize and use a Git repository
confidently.
- Save and push code safely.
- Create and merge branches for teamwork.
- Resolve small conflicts and communicate via
commits.
- Collaborate on GitHub using pull requests.
Next Steps
- Learn about advanced Git commands like rebase,
stash, and cherry-pick.
- Explore GitHub Actions to automate testing and
deployment.
- Practice real-world workflows by contributing
to open-source projects.
- Pair up with a friend and simulate a mini team
project — merge, push, and resolve conflicts together.
