There are few things in software engineering that induce panic quite like a massive git merge conflict.
You pull down the latest code, open your editor, and suddenly your screen is bleeding with <<<<<<< HEAD markers. Your logic is tangled with someone else’s, the CSS is conflicting, and you realise you just wasted hours building on top of outdated architecture.
It is easy to think this only happens to juniors, but it happens to us all. Case in point – this week it was the two of us butting… HEADs (get it?).
When you code in isolation, you get comfortable. You stop checking for open pull requests, you ignore issue trackers and you just start writing code. This is the trap I fell into.
And that is exactly how you break your application. It’s exactly how I broke our application!
If you want to avoid spending your weekend untangling a broken repository (ahem… like we did), you need to enforce these three non-negotiable git habits.
1. Stop Coding in a Vacuum and Use Issue Trackers
Don’t go rogue and start redesigning a codebase without talking to your team. It doesn’t matter if it’s a massive enterprise app or a two-person side project.
If two developers are working on the same views and templates without dedicated issue tickets, a collision is inevitable. You need to break generic ideas like “redesign the UI” into highly specific, granular issues (e.g., “fix this menu,” “change the nav bar colour”).
Communication is your first line of defence against code conflicts.
2. Check for Stale Pull Requests Before You Branch
Pulling the latest code from main is the baseline, but as I was painfully reminded, it isn’t enough.
Before you write a single line of code, you have to check for open pull requests. Your teammate might have a massive architectural change sitting in review that hasn’t hit production yet. If you branch off an old version of main while ignoring a pending PR, you are guaranteed to hit merge conflicts when you finally try to integrate your work.
Once your branch is merged, leave it alone. Don’t keep committing to a stale branch. Go ahead and create a brand new one for your next feature.
3. Master the Bailout Commands
Even with the best practices in place, mistakes happen. You might accidentally code a new feature directly on the main branch, or tangle your logic with a bug fix.
When things go wrong, you need to know how to safely extract your work. This is where advanced git commands become lifesavers. You need to know how to use git stash to temporarily park your changes, create a clean branch, and reapply them. You should also understand how to use git cherry-pick to pull specific historical commits out of a messy branch and into a clean one.
These tools give you the comfort to manipulate code without the fear of destroying the repository.
Bob and I got into a deep discussion about this exact issue after we, as I alluded to, broke every single one of these rules over the weekend.
We were working on our privacy-first book tracking app, Pybites Books. Because we hadn’t coded deeply together on the same codebase in a while, I was rusty and complacent. We didn’t use hyper-specific issues, I ignored an open pull request that was three weeks old, and we both changed the colour scheme independently.
It resulted in a massive merge conflict that required a lot of manual reconciliation, stashing, and cherry-picking to fix.
If you want to hear the full breakdown of our git mess, what went wrong, and how we saved the app, listen using the following links!
Listen to the Episode
– Julian
P.S. Check out the app that caused all of this drama! If you want a privacy-first way to track your reading without being farmed for data, head over to Pybites Books. We just shipped a massive new statistics dashboard (that survived the merge conflict!)