This content originally appeared on DEV Community and was authored by Abdulsalam Abdulrahman (Amtech Digital)
Difference between:
hint: git config pull.rebase false # merge
hint: git config pull.rebase true # rebase
hint: git config pull.ff only #
I'll explain the three git pull strategies and help you choose the best one for your situation:
Updated todo list
Three Git Pull Strategies Explained
- pull.rebase false (Merge Strategy) 🔀
git config pull.rebase false
What it does:
Creates a merge commit when pulling changes
Combines your local commits with remote commits
Preserves full history of both branches
Visual:
Before pull: Local: A — B — C Remote: A — X — YAfter pull: A — B — C — M (merge commit) \ / X — Y
Pros:
✅ Full history preserved
✅ Easy to see when integrations happened
✅ Safe for collaborative work
Cons:
❌ Messy commit graph with many merge commits
❌ Harder to read git log
- pull.rebase true (Rebase Strategy) 📚
git config pull.rebase true
What it does:
Replays your local commits on top of remote changes
Creates a linear history (no merge commits)
Rewrites commit history
Visual:
Before pull: Local: A — B — C Remote: A — X — YAfter pull: A — X — Y — B' — C'
Pros:
✅ Clean, linear history
✅ Easier to read and understand flow
✅ No merge commit clutter
Cons:
❌ Rewrites history (changes commit hashes)
❌ Can cause issues if commits are already pushed
⚠️ Slightly risky if you don't understand rebase
- pull.ff only (Fast-Forward Only) ⚡
git config pull.ff only
What it does:
Only allows fast-forward merges (linear history without new commits)
Rejects any pull that would require a merge or rebase
Forces you to manually resolve conflicts
Visual:
✅ ALLOWED (fast-forward):
Local: A — B — C
Remote: A — B — C — X — Y
Result: A — B — C — X — Y❌
REJECTED (non-fast-forward):
Local: A — B — C
Remote: A — X — Y → Pull fails! You must rebase or merge manually
Pros:
✅ Guarantees clean, linear history
✅ Forces intentional conflict resolution
✅ No accidental messy merges
Cons:
❌ Very strict; many pulls will fail
❌ Requires extra manual steps
❌ Not ideal for team collaboration
📊 Comparison Table
Feature merge rebase ff only
History shape Non-linear (branchy) Linear Linear
Merge commits
✅ Created
❌ None
❌ None
Rewrites commits
❌ No
✅ Yes Depends
Easy to read git log
❌ No
✅ Yes
✅ Yes
Safe for shared branches
✅ Yes
❌ No
✅ Yes
Risk of conflicts Low Medium High
Best for teams
✅ Yes
❌ Not really
✅ Sometimes
🎯 Recommendation for Your Situation
For resolving your current merge conflict in api-docs.json:
Use pull.rebase false (Merge) ← RECOMMENDED
git config pull.rebase false
Why?
✅ You're working in a team repo (hngprojects/HNG-Portal-BE)
✅ Your commits are likely already shared/pushed
✅ Safe - doesn't rewrite history
✅ Preserves the full narrative of changes
✅ Standard practice for collaborative projects
Your next steps:
1. Resolve the conflict manually in api-docs.json (You need to combine the auth endpoints + job-types endpoints)
2. Stage the resolved filegit add storage/api-docs/api-docs.json
3. Complete the mergegit commit -m "Merge: resolve conflicts in api-docs.json - combine auth and job-types endpoints"# 4. Push to remotegit push origin feature/add-job-types
Would you like me to:
✅ Help you resolve the conflicts in the file manually?
📝 Generate a merged version of api-docs.json with both sets of endpoints?
🔍 Review what content exists in each branch first?
Let me know which you prefer!
This content originally appeared on DEV Community and was authored by Abdulsalam Abdulrahman (Amtech Digital)
Abdulsalam Abdulrahman (Amtech Digital) | Sciencx (2025-11-19T14:02:47+00:00) Resolving GitHub conflict: merge, rebase and fast-forward only. Retrieved from https://www.scien.cx/2025/11/19/resolving-github-conflict-merge-rebase-and-fast-forward-only/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.