Lecture Notes: Version Control – II
Prerequisites: Basic
understanding of Git fundamentals, including repositories, commits, and the
commit-push workflow from Version Control – I. Learners should know how to
initialize a Git repository and make simple commits.
What you'll be able to do:
- Explain how branching supports parallel
development.
- Apply pull and merge requests in collaborative
workflows.
- Identify and resolve merge conflicts
effectively.
- Conduct and participate in code reviews using
Git-based platforms.
1. Introduction: What is Version
Control – II and Why Should You Care?
Core Definition
Version Control – II
extends your foundational understanding of Git by focusing on collaboration in teams. It moves beyond individual
commits to handling multiple developers, simultaneous updates, and integration
workflows. You’ll learn how branches, merges, pull requests, and code reviews
keep a team’s work organized, traceable, and conflict-free.
A Simple Analogy
Imagine a team
writing a shared novel. Each writer drafts a chapter separately (branching).
Once complete, they merge their chapter into the main book (pull request). If
two people edit the same page differently, they must reconcile changes
(conflict resolution). Finally, an editor reviews everything before publishing
(code review).
This analogy works
well to understand collaboration and merging, but it breaks down when
considering automation—Git manages merges using line-by-line logic, not
storytelling context.
Why This Matters to
You
Problem it solves: Without
structured collaboration, team projects quickly descend into chaos—files get
overwritten, versions mismatch, and progress stalls.
What you'll gain:
- Confidence in collaboration: You’ll handle
multi-developer projects smoothly.
- Error prevention: Understand how to
prevent overwriting others’ work.
- Professional workflow skills: Essential for any
developer working in teams or open-source projects.
Real-world context: Every software
company—from startups using GitHub to giants like Google—relies on these
workflows. Learning this prepares you for real-world engineering environments.
2. The Foundation: Core Concepts
Explained
Concept A:
Commit–Push Loop
Definition: The commit–push
loop is the basic workflow in Git that helps developers save their progress and
share updates with others. “Commit” means recording changes locally in your
computer’s Git repository, while “push” means sending those changes to a remote
repository like GitHub or GitLab so others can access them.
Key characteristics:
- Local first: Commits are always made locally
before being shared.
- Safe checkpoints: Each commit acts as a
snapshot of your project’s current state.
- Synchronization: The push step ensures your
local commits are available to teammates.
A concrete example:
git add .
git commit -m "Added login
feature"
This saves your work
locally with a clear message, then uploads it to the main branch on the remote
repository.
Common confusion: Beginners often
think that committing automatically updates the remote repository. In reality,
commits stay on your computer until you run git push.
Concept B: Branching
Definition: Branching
allows developers to create independent lines of development within a project.
Each branch can hold experimental or feature-specific code without affecting
the main production-ready branch (often called main or master).
Key characteristics:
- Isolation: Work independently
without disrupting others.
- Parallelism: Multiple features or
bug fixes happen simultaneously.
- Reintegration: Once a branch’s work
is ready, it’s merged back into the main line.
A concrete example:
git branch feature-login
git checkout feature-login
You now have a new
branch feature-login where you can
safely develop login functionality.
Common confusion: Beginners often
think creating a branch duplicates the entire project, but in reality, Git
branches share the same history and differ only where changes diverge.
Concept C: Pull/Merge
Requests
Definition: A Pull Request (PR) (or Merge Request, depending on the platform) is a way to
propose changes from one branch to another—often from a feature branch to the
main branch. It acts as a checkpoint for review and discussion before
integration.
How it relates to Branching: Branching lets
you develop independently; pull requests bring that work back together safely
and transparently.
Key characteristics:
- Visibility: Team members can
review and comment on proposed changes.
- Controlled merging: Prevents direct
updates to protected branches.
- Accountability: Each PR documents who
changed what and why.
A concrete example:
- You create a branch feature-search.
- You
push it to GitHub and open a Pull Request to merge into main.
- Your team reviews it, suggests edits, and
approves it for merge.
Remember: PRs are not
just technical—they’re communication tools. Always include meaningful
descriptions and context.
Concept D: Conflict
Fixes
Definition: Conflicts occur
when Git cannot automatically merge changes from different branches—typically
when two developers modify the same part of a file differently.
Key characteristics:
- Detection: Git identifies
conflicting lines during merge.
- Manual resolution: Developer decides
which version to keep or how to combine them.
- Commit after resolution: You must commit the
fixed merge to complete integration.
A concrete example:
git merge feature-login
# Git reports a conflict in login.py
You open the file,
find the conflict markers <<<<<<<, =======, >>>>>>>, edit to keep the
correct lines, and commit again.
Common confusion: Many assume
conflicts are errors—they’re not. They’re Git’s way of asking for human
judgment when changes overlap.
Concept E: Code
Reviews
Definition: A code review
is a systematic examination of code changes before merging, ensuring quality,
consistency, and maintainability.
Key characteristics:
- Quality check: Ensures code meets
project standards.
- Learning opportunity: Encourages knowledge
sharing.
- Error reduction: Catches issues early
before deployment.
A concrete example: In GitHub,
teammates leave comments directly on changed lines in a PR before approving it.
Remember: Good reviews
focus on clarity and improvement, not criticism.
How These Concepts
Work Together
Branching separates
work, pull requests integrate it, conflict fixes reconcile overlapping work,
and code reviews ensure quality. Think of it like a relay race: Each
runner (branch) runs their part independently, hands off the baton via PR, the
coach (reviewer) checks the transition, and the team crosses the finish line
together.
3. Seeing It in Action: Worked Examples
Example 1: The Basic
Case – Creating and Merging a Branch
Scenario: You’re adding a
“Contact Us” page to your website while others continue developing on the main
branch.
Our approach: Use a feature
branch to develop independently, then merge your work safely into main.
Step-by-step solution:
Step 1: Create a new branch
git checkout -b feature-contact
Step 2: Add files and commit
echo "Contact Us Page" >
contact.html
git add contact.html
git commit -m "Add Contact Us
page"
Step 3: Switch to main and merge
git checkout main
git merge feature-contact
Output:
Updating main..feature-contact
Fast-forward
contact.html | 1 +
What just happened: You created,
committed, and merged a feature branch. Git fast-forwarded the main branch
since there were no conflicts.
Check your understanding: Why was this a
“fast-forward” merge? (Hint: The main branch didn’t change while the feature
branch was developed.)
Example 2: Adding
Complexity – Handling Merge Conflicts
Scenario: You and your
teammate both edit app.py on different branches.
What's different: Git now
encounters overlapping changes—it can’t decide which to keep.
Solution:
git merge feature-new-logic
# Conflict message appears
# Open app.py and edit:
# <<<<<<< HEAD
print("Old logic")
=======
print("New logic")
>>>>>>>
feature-new-logic
# Keep the correct version and save
git add app.py
git commit
Output:
Merge made by the 'recursive' strategy.
app.py | 2 +-
Key lesson: Conflicts are
normal—resolving them thoughtfully maintains both correctness and team
collaboration.
Example 3: Real-World
Application – Team Collaboration on GitHub
Background: Your team of
three developers is working on a website with separate branches: feature-login, feature-signup, and feature-dashboard.
The challenge: Each feature
must integrate smoothly into main without overwriting others’ work.
The approach: Develop on
individual branches → Push → Create Pull Requests → Peer review → Merge.
Why this approach: It allows
asynchronous work and structured feedback cycles, ensuring stability.
The outcome: No overwrites,
all commits tracked, and code reviewed before production.
Caution: Avoid merging
unreviewed PRs—one faulty change can break the project for everyone.
4. Common Pitfalls: What Can Go Wrong
and How to Avoid It
The Mistake: Committing
directly to main.
Why It's a Problem: Skips review
and risks breaking production.
The Right Approach: Always branch
for new work.
Why This Works: Protects stable
code and documents change intent.
The Mistake: Ignoring conflicts
or using force merges.
Why It's a Problem: Overwrites
teammates’ work.
The Right Approach: Resolve
conflicts manually, communicate, and commit cleanly.
Why This Works: Maintains
shared ownership and accuracy.
The Mistake: Skipping code
reviews.
Why It's a Problem: Bugs or
inefficiencies enter unnoticed.
The Right Approach: Always open PRs
and request reviews.
Why This Works: Enforces
quality and spreads knowledge.
If you're stuck: Revisit the
“Conflict Fixes” section or rewatch GitHub tutorials showing interactive merge
conflict resolution.
5. Your Turn: Practice &
Self-Assessment
Practice Task (Estimated 15–20 minutes) The Challenge: Simulate a small team workflow.
Specifications:
- Create a new branch feature-newsletter.
- Make a change (e.g., add a new file).
- Create
a PR to merge into main.
- Introduce a conflict intentionally, then
resolve it.
- Request a mock review before merging.
Hint: To simulate a conflict, edit the
same line of a file on both branches before merging.
Extension (optional): Try adding a
reviewer comment on your PR using GitHub’s interface.
Check Your Understanding
- Explain why branching prevents integration
issues.
- In what cases should you rebase instead of
merging?
- What is a merge conflict, and how do you
resolve it?
- How do pull requests promote better teamwork?
- What are two key qualities of effective code
reviews?
Answers & Explanations
- Branching isolates work, so no two developers
overwrite the same code directly.
- Rebase is used to maintain a clean, linear
history before merging.
- Conflicts occur when overlapping edits exist;
you resolve them manually, then commit.
- Pull requests create visibility, discussion,
and accountability for all changes.
- Reviews should focus on correctness and
readability, not personal style.
Self-Assessment Checklist
✅ I can create, merge, and delete branches confidently. ✅ I understand how to create and review pull requests. ✅ I can identify and fix merge conflicts. ✅ I use branching
instead of direct commits to main. ✅ I collaborate
effectively through review and discussion.
If you checked fewer
than 4 boxes: Review the “Core Concepts” and “Worked Examples” sections again.
6. Consolidation: Key Takeaways &
Next Steps
The Essential Ideas
- Branching: Enables isolated,
parallel development.
- Pull/Merge Requests: Facilitate safe,
reviewed integrations.
- Conflict Resolution: Ensures smooth merging
and shared responsibility.
- Code Reviews: Maintain quality and
promote team learning.
Mental Model Check Think of
Version Control – II as team choreography—each
developer has moves to perform, but coordination keeps the routine synchronized.
What You Can Now Do You can
confidently collaborate on Git-based projects, contribute through branches,
handle merge conflicts, and conduct meaningful code reviews.
Next Steps To deepen this
knowledge:
- Explore rebasing and cherry-picking advanced Git commands.
- Contribute to open-source projects on GitHub
to experience real PR workflows.
Additional Resources
- GitHub Docs: “Collaborating with Pull
Requests”
- Atlassian Git Tutorials
- Pro Git Book by Scott Chacon & Ben Straub
Quick Reference Card (Optional)
|
Concept |
Command |
Purpose |
|
Create Branch |
git
branch branch_name |
Start new feature
work |
|
Switch Branch |
git
checkout branch_name |
Move between
branches |
|
Merge Branch |
git
merge branch_name |
Integrate work |
|
Resolve Conflict |
Edit file + git
add + git commit |
Finalize merge |
|
Create PR |
GitHub UI |
Request review
before merge |
