# Finding Joy in Git Conflict Resolution

DevFeed: [Finding Joy in Git Conflict Resolution](<https://devfeed.tech/articles/finding-joy-in-git-conflict-resolution-20028.md>)

Original publisher: [Read original article](<https://technology.doximity.com/articles/finding-joy-in-git-conflict-resolution>)

Author: Doximity

Published: 2023-01-31T16:50:00Z

Content type: tutorial

Language: en

Sources: [Doximity](<https://devfeed.tech/sources/doximity.md>)

Topics: [Git](<https://devfeed.tech/topics/git.md>), [Command-line interface](<https://devfeed.tech/topics/cli.md>), [Refactoring](<https://devfeed.tech/topics/refactoring.md>), [feature flags](<https://devfeed.tech/topics/feature-flags.md>)

Tags: [command-line](<https://devfeed.tech/tags/command-line.md>), [feature-flags](<https://devfeed.tech/tags/feature-flags.md>), [git](<https://devfeed.tech/tags/git.md>), [parallel](<https://devfeed.tech/tags/parallel.md>), [refactoring](<https://devfeed.tech/tags/refactoring.md>)

## AI overview

This article explains Git's diff3 conflict resolution strategy, which adds context about the common ancestor to conflict markers and helps developers understand the intent behind conflicting changes. It also notes that trunk-based development, feature flags, smaller incremental changes, and refactoring high-churn areas can reduce conflicts.

## Source excerpt

Your big feature is tested and ready to go! Time to merge, and then... Nooooo! 😭 Memories arise of hours of uncertainty spent trying to resolve past conflicts. Sure, there are lots of UIs that make picking one side or the other easier than using the command line, but is picking sides really the right answer? I'll share a hidden gem that, for me, has turned conflict resolution from frustration into something of a joy. Git has a built-in feature that you can enable called the diff3 conflict resolution strategy. Turning this setting on enables a predictable approach to understanding and resolving the conflicts you encounter. I'll note that git conflicts can be minimized through practices such as Trunk Based Development with Feature Flags, breaking features into smaller chunks that you can deliver incrementally, and refactoring hotspots with high churn. Fewer conflicts is always a win. Even still, we'll need to deal with conflicts occasionally whenever there are parallel development branches. Before going further, let's take a closer look at what's missing from the default conflict markers that Git has always provided (for backward compatibility with other tools). Example When Git is told to merge two branches of work that modify the same lines, Git won't try to determine how to apply both changes to the same line. Instead, it inserts a set of conflict markers and relies on your beautiful human brain to work it out. These conflict markers delineate the end result of the lines with conflicting changes in both the currently checked-out branch (HEAD) and the branch you've attempted to merge. (During a rebase, it checks out the commit you're rebasing onto, which gets labeled HEAD in the first section, and the commits you're rebasing show up in the second section as the change being "merged".) Take a look at this conflict. How would you resolve it? <<<<<<< HEAD GreenMessage.send(include_signature: true) ======= BlueMessage.send(include_signature: false) >>>>>>> merged-branch S