Prerequisites:
- Basic understanding of Git basics, commit-push
loop, and branching concepts.
What You'll Gain from This Pre-Read
After reading, you'll be able to:
- Understand how pull and merge requests
streamline collaboration.
- Identify and fix merge conflicts confidently.
- Recognize the importance of code reviews in
team workflows.
- Apply best practices for smooth teamwork using
Git and GitHub.
Think of this as:
- Learning teamwork in coding — how developers
safely share, merge, and review each other’s code without chaos.
What This Pre-Read Covers
This pre-read will:
- Explain the teamwork flow using pull requests
and code reviews.
- Show how to handle conflicts and keep projects
consistent.
- Demonstrate practical examples for merging and
collaboration.
- Build your understanding of version control
beyond just committing code.
Part 1: The Big Picture – Why Does This
Matter?
Opening hook:
- Imagine five developers editing the same file
at once — one adds a new feature, another fixes a bug, and someone else
updates documentation. Without coordination, their changes could overwrite
each other.
Expanded connection:
- Version control ensures this chaos doesn’t
happen. Tools like Git and GitHub provide features such as branches, pull
requests, and code reviews to manage teamwork safely. Understanding these
features helps you collaborate like professionals at companies such as
Google, Meta, or Netflix.
Where You'll Use This:
Job roles:
Software Developers: Work together
on shared repositories and merge code efficiently.
DevOps Engineers: Manage
versioned deployment scripts and infrastructure code.
QA Engineers: Review and test
specific branches before release.
Real products:
- GitHub – used for collaboration and code
reviews.
- GitLab – handles merge requests and continuous
integration.
- Bitbucket – used by many teams for private
repositories.
- VS Code + Git Integration – helps visualize
commits and merges easily.
What you can build:
- Collaborative projects (like websites or ML
models) where multiple contributors work on different features.
- Open-source projects where others can submit
changes through pull requests.
- Team-based automation or CI/CD systems that
rely on Git workflows.
Think of it like this:
- Imagine editing a shared Google Doc — each
person can comment, suggest, or edit. Pull requests and code reviews work
the same way for code: you “suggest” your version before it becomes part
of the main document.
Limitation:
- Unlike Google Docs, Git doesn’t auto-merge
real-time edits; developers must manually handle conflicts and approve
merges.
Part 2: Your Roadmap Through This Topic
Here’s what we’ll explore together:
- The Commit–Push Loop (Revisited)
- You’ll review how local commits become part of
the shared repository and understand why frequent, meaningful commits make
collaboration easier.
- Pull Requests (PRs)
- You’ll see how PRs allow developers to propose
changes, discuss them, and merge them only after review — the heart of
collaborative coding.
- You’ll learn what causes conflicts when
merging branches and how to resolve them safely without losing work.
- You’ll explore why reviewing each other’s code
improves quality, reduces bugs, and builds shared knowledge.
- You’ll discover guidelines for clean merges —
such as squashing commits, writing good messages, and avoiding unnecessary
branches.
The journey:
- We’ll start with how your code leaves your
computer, travel through pull requests and code reviews, and end with
merging strategies and conflict resolution.
Part 3: Key Terms to Listen For
Pull Request (PR)
- A request to merge your branch’s changes into
another branch (usually main or develop).
Example:
- You create a PR when you finish adding a new
feature and want others to review it.
- A situation where Git can’t automatically
combine changes from different branches.
Think of it as:
- Two people editing the same sentence in
different ways — Git needs your help deciding which version to keep.
- The process where teammates examine your code
for correctness, style, and clarity before merging.
In practice:
- A senior developer leaves feedback on your
pull request with suggestions for improvement.
- A special commit that records the combination
of two or more branches into one.
Example:
- When your feature branch is merged into main,
Git creates a merge commit to track that event.
- A Git command that reapplies commits from one
branch onto another, creating a cleaner history.
Think of it as:
- Moving your work to the top of the latest
code, as if you started from there.
Continuous Integration (CI)
- An automated process that tests and builds
code every time a PR is opened or merged.
Example:
- Tools like GitHub Actions automatically run
your test scripts after each push.
Key Insight:
- All these terms are connected — pull requests
create opportunities for code reviews, which may lead to conflicts that
must be merged carefully, supported by automated CI checks.
Part 4: Concepts in Action
Seeing Pull Requests and Merges in
Action
The scenario:
- You’re working on a team project where each
member is assigned a separate feature. You’ve completed your feature on a
branch named feature-login and want to merge it into main.
Our approach:
- We’ll use the commit–push–PR–merge flow to
safely bring your changes into the shared codebase.
The steps:
Step 1: Create and switch to a new
branch
git checkout -b feature-login
Step 2: Add changes
git add .
git commit -m "Add login feature
with validation"
Step 3: Push branch to remote
repository
git push origin feature-login
- Now your feature branch exists on
GitHub.
Step 4: Open a pull request on GitHub.
- Go to your repository.
- Click “Compare & pull request.”
- Add a title and description of your
changes.
- Request reviewers from your team.
Step 5: Review and merge.
- Your teammates check the code.
- They may comment or approve it.
- Once approved, click “Merge pull
request.”
Result:
- Your feature is now part of the main branch.
Git automatically creates a merge commit.
What’s happening here:
- Each branch represents isolated work. The pull
request brings visibility and accountability to your code before merging.
Everyone can review, test, and discuss before it becomes part of the main
product.
Key takeaway: PRs act like
quality gates — ensuring only reviewed and tested code joins the main branch.
Common Misconception:
- Many beginners think a pull request
automatically merges code — it doesn’t. It’s just a proposal until
reviewed and approved.
Handling Merge Conflicts
The scenario:
- You and your teammate edit the same file,
login.py, but in different ways. When you try to merge, Git reports a
conflict.
Our approach:
- We’ll fix the conflict manually and complete
the merge.
Step 1: Try to merge
git merge main
Step 2: Git reports conflict
# Output: CONFLICT (content): Merge
conflict in login.py
Step 3: Open the file and resolve
manually
Example conflict markers inside file:
<<<<<<< HEAD
print("Welcome user!")
=======
print("Welcome, please log
in!")
>>>>>>> main
Step 4: Choose or edit final version,
then:
git add login.py
git commit -m "Resolve merge
conflict in login.py"
What’s happening here:
- Git uses <<<<<<< and
>>>>>>> markers to show conflicting sections. You
decide the final version and commit again.
Key takeaway: Conflicts
aren’t errors — they’re Git’s way of asking for human judgment.
Common Misconception:
- Beginners often panic during conflicts.
Remember: conflicts are normal in teamwork; fixing them means you’re
collaborating!
Code Reviews in Practice
The scenario:
- Before merging your PR, your teammate reviews
your code for clarity, performance, and style.
Example review comments:
“Can you add error handling for invalid
input?”
“This function name could be clearer.”
“Great job on separating logic from
UI!”
Our approach:
- You respond, make changes, and push updates.
Git automatically updates your pull request.
After review changes
git add .
git commit -m "Add error handling
in login validation"
git push
Key takeaway:
- Code reviews are learning moments — they
improve not just your code, but your team communication and shared
understanding.
Best Practices for Smooth Collaboration
✅ Make small, frequent commits – easier to track and review. ✅ Write meaningful commit messages – explain “why,” not just “what.” ✅ Keep branches short-lived – merge often to avoid conflicts. ✅ Use pull requests for all merges – maintain transparency. ✅ Never merge without reviewing or testing.
Final Recap
- Concept What It Means Why It Matters
- Commit–Push Loop Sending local changes to
remote Keeps everyone updated
- Pull Request (PR) Proposing to merge code
Enables safe collaboration
- Merge Conflict When branches disagree Teaches
teamwork and attention
- Code Review Reviewing others’ code Ensures
quality and shared learning
- Merge Commit The record of combining branches
Keeps history consistent
Big Picture Insight:
- Version control isn’t just about saving code —
it’s about collaboration, communication, and control. PRs, reviews, and
conflict resolution make sure everyone contributes safely and effectively.
Next Steps:
- Practice creating pull requests with
teammates.
- Intentionally create and fix a merge conflict.
- Participate in a code review — both as a
reviewer and as an author.
- Once you master these, you’ll not only write
code — you’ll collaborate like a professional developer.
