Pull Requests, Code Review, and Conflict Resolution
What This Concept Is
Pull request style collaboration wraps Git branching in a human review process. The branch carries the proposed change. The pull request explains the intent, exposes the diff, and gives a place for review discussion. Merge conflicts happen when Git cannot combine changes automatically and needs you to produce the final correct result.
Why It Matters Here
Professional Git is not just "I can commit locally." It is "I can make my work easy to review, easy to integrate, and safe to resolve when there is overlap." That requires both technical and communication discipline.
Concrete Example
Healthy pull request flow:
git switch -c feature/readme-cleanup
# make small focused commits
git push -u origin feature/readme-cleanup
Then open a pull request with:
- a clear title
- a short summary of what changed
- any testing or verification notes
- the reason the change exists
If a merge conflict appears, Git will mark the file:
<<<<<<< HEAD
local version
=======
incoming version
>>>>>>> feature/readme-cleanup
Your job is not to pick a side blindly. Your job is to edit the file into the correct final content, remove the markers, stage the file, and complete the integration.
Common Confusion / Misconception
Misconception: A pull request is just a button to merge branches.
Correction: A pull request is a review and integration unit. The branch is technical; the pull request is technical plus communicative.
Misconception: Resolving a conflict means picking "ours" or "theirs" mechanically.
Correction: Conflict resolution means deciding what the final correct file should contain. Sometimes that is one side. Often it is a deliberate combination.
How To Use It
Make pull requests easy to review:
- keep branch scope small
- commit coherent units
- describe intent, not just files changed
- inspect the diff before asking others to inspect it
Conflict workflow:
- run
git status - open the conflicted file
- decide the correct final content
- remove markers
git add <file>- finish merge or rebase
Check Yourself
- What makes a pull request easier to review?
- Why is "just choose ours" a bad default conflict strategy?
- After editing a conflicted file, what tells Git the conflict is resolved?
Mini Drill or Application
Simulate two developers:
- create one branch that changes the same line in a file
- create a second branch that changes that same line differently
- merge them and trigger a conflict
- resolve the file manually
- write a two-sentence note explaining why your final resolution is correct