We’ve all been there. You are working on a university project. You have a team of five. You are the designated "Tech Lead", handling the backend and CI/CD. The rest of the team are enthusiastic beginners handling the frontend.
The energy is high, the Figma designs look great, but then... the Git conflicts start.
In this post, I want to share a specific workflow I use to save my team from broken code and the lessons I learnt about using AI for code reviews in a beginner environment.
The Scenario: "I Can't Wait"
It’s 11:45 PM. The sprint review is tomorrow morning. The Frontend Rookie finally sends the pull request titled 'Final Login Fix REAL v3'.
I open the PR, hoping for a miracle.
I look at the code. There’s a missing semicolon on line 42, they accidentally hardcoded their database password as ILovePizza123 instead of using the config file, and for some reason, they left echo "I AM HERE 1"; and echo "WHY IS THIS NOT WORKING"; scattered across the entire script.
I could request changes and wait for them to wake up, figure it out, and push again. But they are probably sleeping the sleep of the innocent.
I sigh, crack my knuckles, and decide to launch a Git Rescue Mission.
The Workflow: Fixing a Teammate's Branch (The Right Way)
Many beginners think you have to clone the repo into a separate folder to fix a friend's code. Please don't do that.
I use the GitHub Pull Requests and Issues extension in VS Code. It turns "fixing their code" into a 3-step process:
Checkout: I right-click their PR in the VS Code sidebar and select Checkout Pull Request.
The Localhost Test: Now, my local environment (Laragon/Docker) is running their code. I can see the "I AM HERE 1" message on my browser immediately.
The Fix & Push: I delete the debug echoes, fix the password, commit it, and hit "Sync".
Magic: This pushes the code directly to their branch on GitHub and updates the PR automatically.
I merge it. The site is saved. Everyone is happy. Until...
The Trap: The "Gemini" Conflict
This is where things get messy. As a lead, I use AI tools (like Gemini) to review code. I see a block of spaghetti HTML, I ask Gemini to refactor it, and I paste the clean version into the branch and push it.
Meanwhile, The Rookie is still working on their laptop.
They didn't know I fixed their code. They realize they forgot to capitalize a button, change one letter on their (now old) version, and push. Git explodes.
We now have a merge conflict. My "Clean AI Code" vs. their "Old Code with a Typo Fix".
The Solution: The "Base & Borrow" Technique
So, how do you solve this "logic vs. design" conflict?
If you click "Accept Current Change" (Your Code), you delete their CSS tweaks. If you click "Accept Incoming Change" (Their Code), you bring back the bugs.
I learnt the hard way that you cannot just click a button. You have to use the Base & Borrow technique in VS Code:
The Base (Your Logic): I start by accepting my clean code as the base. This ensures the backend logic and syntax are correct.
The Borrow (Their Design): Before I hit save, I look at their code in the "Incoming Change" window. Did they change a class to btn-danger? Did they fix a typo in the header?
The Patch: I manually copy only those design tweaks and paste them into my clean block.
It takes 30 seconds longer, but it ensures we get the best of both worlds: My Working Logic + Their Polished Design.
3 Rules to Survive the Chaos
After fighting these fires for weeks, I realized that technology wasn't the problem—communication was. Here are the rules we established to stop the bleeding:
1. The "Traffic Light" System
Green Light: Before you write a single line of code, run git pull.
Yellow Light: If you are working on a file, say it in the chat ("I'm on login.php").
Red Light: If I type "FREEZE", stop typing. It means I'm fixing the server.
2. The "Stop Typing" Command
Before I enter a teammate's branch to perform a rescue fix, I send a message to the group chat:
"I am entering the [Login-Feature] branch to fix a bug. STOP working on it. Hands off the keyboard. Do not push until I say 'GO'."
3. The "Pull First" Mantra
If I do push a fix to a teammate's branch, I make them swear by this rule: Before you write a single line of code today, run git pull.
If they don't pull my fixes down to their laptop first, everything they write next is guaranteed to cause a conflict.
Conclusion: Just Because You Can, Doesn't Mean You Should
Even though I mastered the "Base & Borrow" technique, my biggest lesson was actually about restraint.
It is tempting to fix every bug yourself because it's faster. But if you fix every PR manually, your team never learns.
Sometimes, the best move isn't to checkout the branch and fix it. The best move is to leave a comment: "Line 45 is broken. You forgot the semicolon. You fix it."
It takes longer, but it prevents the conflicts—and it turns your teammates into better developers.
Top comments (0)