Chapter 3.5 — Prevention Strategies☕ 14 min read

Prevention Strategies

Small PRs banao, daily sync karo, Prettier use karo, team se baat karo. Conflicts honge kam, productivity zyada!

01Small PRs: The #1 Prevention Strategy

Smaller Pull Requests = fewer lines changed = fewer potential conflicts. This is the single most effective strategy for preventing merge conflicts.

Aim for PRs under 400 lines of changes. Beyond that, split your work into multiple focused PRs. Small PRs are easier to review, easier to test, and easier to merge.

Giant PRs (1000+ lines) are almost guaranteed to conflict and rarely get proper review. Reviewers skim large PRs — bugs slip through.

Break features into independent, mergeable pieces. Each PR should do ONE thing.

"If you can't explain the PR in one sentence, it's too big."

# BAD: One massive PR with everything
git checkout -b feature/everything
# ... 50 files changed, 3000 lines added ...
# 47 conflicts during merge!

# GOOD: Multiple focused PRs
git checkout -b feature/auth-login    # 8 files, 200 lines
git checkout -b feature/auth-signup   # 6 files, 180 lines
git checkout -b feature/auth-profile  # 5 files, 150 lines
# Each merges cleanly or with at most 1-2 minor conflicts

# Rule of thumb:
# < 200 lines: Easy to review, low conflict risk
# 200-400 lines: Manageable, some conflict risk
# 400-800 lines: Hard to review, high conflict risk
# > 800 lines: Split it!

A PR with 50 files and 3000 lines changed will almost certainly have conflicts, and reviewers won't properly review it. Small PRs mean small blast radius. If something goes wrong, you revert one small PR instead of debugging a massive one. This is not just a Git best practice — it's a software engineering fundamental.

02Sync Frequently: Keep Your Branch Updated

The longer your branch diverges from main, the more conflicts you will have when you finally merge. This is not a theory — it is mathematical certainty.

Sync daily: git fetch origin followed by git rebase origin/main or git merge origin/main.

Rebase is preferred for keeping your branch up-to-date — it replays your commits on top of the latest main, giving a cleaner history. Merge is easier if you are not comfortable with rebase yet.

Frequent syncing catches conflicts early when they are small and easy to fix. A conflict that takes 2 minutes today takes 2 hours next week.

"Merge daily = tiny conflicts. Merge weekly = big conflicts. Merge monthly = merge hell."

# Daily sync routine (recommended)
git checkout feature
git fetch origin
git rebase origin/main
# Resolve any small conflicts (1-2 files, easy)
git push --force-with-lease origin feature

# Alternative: Merge main into your feature
git checkout feature
git fetch origin
git merge origin/main
# Resolve conflicts, then continue

# Pro tip: Set up your prompt to show if you are behind origin/main
# Oh My Zsh, Starship, or custom PS1 can show branch status

💡 Pro Tip: git push --force-with-lease is safer than git push --force. It only forces the push if nobody else has pushed to the same branch since your last pull. This prevents accidentally overwriting a teammate's work when you rebase.

03Communication: Talk to Your Team

Many conflicts are caused by two people editing the same file without knowing the other is working on it. Communication prevents 80% of merge conflicts.

Before starting work, announce: "I am working on the auth module this week." Use Slack channels, Jira comments, or PR drafts to signal your work.

Code ownership: if one person "owns" a module, coordinate with them before editing their files. GitHub's CODEOWNERS file enforces this automatically.

Pair programming on shared files eliminates conflicts entirely — two people, one keyboard, zero conflicts.

Draft PRs are an excellent communication tool. Open a draft early to show what you are changing — even before the code is ready.

# Communication strategies:
# 1. Slack/Teams: "I am refactoring the payment module this sprint"
# 2. Jira: Comment on the ticket that you are working on it
# 3. Draft PRs: Open early to show what you are changing
gh pr create --draft --title "WIP: Payment refactor"

# 4. CODEOWNERS file (GitHub)
# .github/CODEOWNERS
# /src/payment/    @payment-team
# /src/auth/       @auth-team
# Now GitHub requires their review before merging!

# 5. Coordinate on shared files
# "Hey, I need to update config.js. Anyone else working on it?"

Communication is not just soft skills — it is engineering strategy. Teams that communicate about file ownership have 80% fewer merge conflicts. A 30-second Slack message can save 3 hours of conflict resolution. CODEOWNERS makes this automatic: specific teams must review changes to their modules.

04Auto-Formatting: Kill Whitespace Conflicts

A huge source of conflicts: different developers' editors format code differently. Tabs vs spaces, trailing whitespace, line endings (LF vs CRLF) — these create meaningless conflicts that waste time.

Solution: Prettier + ESLint + .editorconfig — automated, consistent formatting for everyone on the team.

If everyone uses the same formatter with the same config, style-related conflicts disappear entirely. No more "you use tabs, I use spaces" debates.

Run formatter before every commit: npx prettier --write .

Husky + lint-staged can auto-format on commit — covered in Stage 8. For now, manual formatting is enough.

# Install Prettier
npm install --save-dev prettier

# Format before committing
npx prettier --write .

# Set up .editorconfig for consistent editor settings
# .editorconfig:
# root = true
# [*]
# indent_style = space
# indent_size = 2
# end_of_line = lf
# trim_trailing_whitespace = true
# insert_final_newline = true

# NEVER reformat an entire file in a feature branch
# BAD: reformatted all 500 lines of app.js - massive conflict
# GOOD: format only the lines you changed, or format on main separately

💡 Pro Tip: Never reformat an entire file as part of a feature branch. That 500-line reformat will conflict with everyone else's changes. Instead, do code formatting in a separate PR on main, merged first. Then start your feature work on the freshly formatted codebase.

05Modular Code: Separate Concerns

If files have single responsibilities, fewer people need to edit the same file simultaneously. This is architectural conflict prevention.

Modular architecture: separate components, services, utilities into focused files. When multiple features touch the same file, it is a sign of poor separation of concerns.

A single utils.js with 5000 lines that everyone edits is a conflict factory. Split it into format.js, api.js, auth.js, payment.js — each with its own responsibility.

Refactor shared files to have clear, single responsibilities. The best conflict resolution is a conflict that never happens.

Feature flags can replace long-lived feature branches, reducing the time window for conflicts.

# BAD: One giant utils.js with everything
# utils.js (5000 lines)
# - formatting functions
# - API helpers
# - auth helpers
# - payment helpers
# Everyone edits this file - constant conflicts!

# GOOD: Separate modules
# utils/format.js   (50 lines) - only formatting
# utils/api.js      (100 lines) - only API
# utils/auth.js     (80 lines) - only auth
# utils/payment.js  (60 lines) - only payment
# Each person edits their own module - almost no conflicts!

# Feature flags instead of long-lived branches
if (FLAGS.newDashboard) {
  renderNewDashboard();
} else {
  renderOldDashboard();
}

Modular code prevents conflicts by design. When each file has one clear purpose, different developers work on different files. It is the same principle as separation of concerns in software design — loose coupling, high cohesion. If your team constantly conflicts on the same files, the architecture needs refactoring, not better Git skills.

Lo kar liya — Key Points:

✅ Small PRs (< 400 lines) are the #1 way to prevent conflicts — they're easier to review and merge
✅ Sync your branch with main daily using git rebase origin/main or git merge origin/main
✅ Communicate with your team about which files you're editing to avoid overlapping work
✅ Use Prettier + .editorconfig to eliminate whitespace and formatting conflicts
✅ Modular code with single responsibilities reduces the number of people editing the same file
✅ Feature flags can replace long-lived feature branches, reducing conflict duration

Previous3.4 — Abort & Start Over 📋 All Chapters Next Chapter3.6 — Binary File Conflicts →