Best Practices for Merging Code in Teams

Developers often complain about the risks of merge conflicts with long-lived branches, but the “solutions” they propose usually miss the real point. The most common one is to keep merging main (or, even worse, develop) into the branch. That’s often accompanied by the vaguest advice of all: “Keep communicating with others to know what they’re working on.” The first is a non-solution. Merging the main trunk of development into branches regularly doesn’t help when changes stay isolated on those branches for long periods. Other developers’ work won’t land in main quickly enough to reveal integration issues in time. The second is also a non-solution, and frankly a ridiculous one. First, it’s impossible to know at any given moment what everyone else is doing and to work around it. That approach simply doesn’t scale. Second, if we need to invest that much energy into constant communication, it’s better to do it synchronously by working socially. The real solution to this conundrum is called Continuous Integration. Unfortunately, only a small fraction of developers know how to implement it well. The prerequisite for CI is trunk-based development. My recipe: - Adopt Trunk-based Development: code is integrated into the main line continuously (ideally every few minutes). - Adopt Team-focused Development: social programming techniques like pair or mob, so code review happens continuously. - Adopt Test-driven Development: the short feedback cycles make it possible to push code every few minutes with confidence. - Embrace a Continuous Delivery model. Yes, I think the solution is T*D. Teams should ditch long-lived feature branches, post-development reviews and, above all, anti-CI models like GitFlow. #continuousintegration #trunkbaseddevelopment #tbd #teamfocuseddevelopment #socialprogramming #pairprogramming #mobprogramming #ensembleprogramming #softwareteaming #continuousdelivery #testdrivendevelopment #tbd #agile #agilesoftwaredevelopment #softwaredevelopment #softwareengineering

When you’re coding a new feature, how often do you merge your changes? Do you wait until everything is done, then create a PR? Or maybe you break the work into smaller chunks, and merge a few days, or few hours, of work together, when it feels “ready”? Neither of these is optimal. Both lead to your code being out of sync with the rest of the team. In the worst case, you’ll end up with some nightmare merge conflicts, with some fancy merge-weaving to get everything working again. In the least-worst case, you’ll at least occasionally need to do some rebasing or merging, and minor conflict resolutions. In either case, it’s waste. Resolving conflicts is one of the silliest things a developer could spend their time doing. It’s a form of rework that adds no value at all, when you consider it could easily be avoided. How so? Don’t wait until your feature is “ready” to merge. Rather, merge as soon as it’s safe. Do you need to add a new parameter to a function, then do something with it? What’s the smallest, safe change you can make? Maybe add the parameter and do nothing with it? Sure. Do that. Then merge. Then do the thing. Or maybe just add the validation. Then merge. After that, maybe do the full thing. Get over the idea that you need to merge complete features. This leads to conflicts. Conflicts lead to anger. Anger leads to hate. Hate leads to suffering. Or something like that. #softwaredevelopment #programming #git #mergeconflicts #cicd #continuousintegration

→ What if your project could reveal its risks BEFORE they become disasters? 𝐂𝐨𝐧𝐭𝐢𝐧𝐮𝐨𝐮𝐬 𝐈𝐧𝐭𝐞𝐠𝐫𝐚𝐭𝐢𝐨𝐧 (𝐂𝐈) is not just developer jargon - it’s a PROJECT MANAGER’S secret weapon. Here’s why it demands your attention: • 𝐖𝐡𝐚𝐭 𝐢𝐬 𝐂𝐈? Developers merge code changes multiple times daily into a shared repository. Each merge triggers automated builds and tests. • 𝐖𝐡𝐲 𝐬𝐡𝐨𝐮𝐥𝐝 𝐩𝐫𝐨𝐣𝐞𝐜𝐭 𝐦𝐚𝐧𝐚𝐠𝐞𝐫𝐬 𝐜𝐚𝐫𝐞? 𝐁𝐞𝐜𝐚𝐮𝐬𝐞 𝐂𝐈: • Detects bugs early, saving time and headache. • Ensures higher code quality consistently. • Provides immediate feedback for swift fixes. • Reduces risky code merges and integration hell. • Fosters team collaboration around a single source of truth. → 𝐇𝐨𝐰 𝐝𝐨𝐞𝐬 𝐂𝐈 𝐟𝐢𝐭 𝐢𝐧𝐭𝐨 𝐲𝐨𝐮𝐫 𝐩𝐫𝐨𝐣𝐞𝐜𝐭 𝐦𝐚𝐧𝐚𝐠𝐞𝐦𝐞𝐧𝐭 𝐫𝐡𝐲𝐭𝐡𝐦? • Plan for integration and testing cycles - blocking buffer time is key. • Allocate resources: automated testing tools, build servers, and infrastructure. • Monitor build health and pipeline bottlenecks continuously. • Use CI outcomes as transparent status updates to stakeholders. → 𝐓𝐡𝐞 𝐠𝐨𝐥𝐝𝐞𝐧 𝐩𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞𝐬 𝐲𝐨𝐮 𝐜𝐚𝐧’𝐭 𝐢𝐠𝐧𝐨𝐫𝐞: • Frequent small code merges to avoid conflicts. • Automated builds & tests catching bugs before they escalate. • Team collaboration sharpened through shared code bases. • Faster, safer delivery by catching issues early. • Dramatically reduced risk - fewer surprises. CI transforms uncertainty into insight.  It shifts your role from firefighting to foresight. Follow Carlos Shoji for more insights on project management

You are having a perfect day at work; you created a PR to merge with the main branch, and bamm you run into a merge conflict.  Here's what to do: 1. Take a deep breath and stay calm, you got this! 2. Pull latest changes - make sure local main is up-to-date. > git checkout main > git pull origin main 3. Return to your branch > git checkout your-feature-branch 4. Merge latest changes from main. > git merge main 5. Resolve conflicts - git will inform you which files have conflict. Open the files and  <<<<<<< HEAD ... changes from your current branch ... ======= ... changes from the branch you're merging ... >>>>>>> branch-name The <<<<<<< HEAD marker indicates the start of the conflicting section and the changes from your current branch (the branch you’re on when you start the merge) are shown after it. The ======= marker separates your changes from the changes in the other branch (the branch you’re trying to merge). The >>>>>>> branch-name marker indicates the end of the conflicting section. Manually edit in a code editor. Then git add, commit and push the changes. All git conflicts should have been resolved! Here are some git best practices to avoid merge conflicts: 1. Pull and merge from the target branch frequently. 2. Be a minimalist: 1 task = 1 branch = 1 PR 3. When completing PR, use squash. Conflicts typically arise when changes in different commits affect the same lines of code. Squashing small commits into 1 big commit reduces the chances of conflict. Happy coding!✨