How to Discuss Merge Conflicts in English

Merge conflicts are a routine part of collaborative development, but resolving them well often requires a short conversation with a teammate — and that conversation goes faster with precise vocabulary for what’s actually conflicting and why. This guide covers the English for discussing merge conflicts clearly instead of just saying “there’s a conflict, can you look?”

Key Vocabulary

Conflicting hunk — the specific block of changed lines where Git can’t automatically determine which version to keep, distinct from the rest of the file, which merges cleanly. “The conflicting hunk is just the function signature — the rest of the file merged automatically without any issue.”

Semantic conflict — a situation where two changes merge cleanly at the text level but still break when combined, because they make incompatible assumptions about the code’s behavior. “Git didn’t flag this as a conflict, but it’s a semantic conflict — your change assumes the function still returns a string, but my change made it return an object.”

Ours vs. theirs — Git’s terms for the two versions being merged: “ours” is the branch you’re merging into, “theirs” is the branch being merged in, a distinction that’s easy to get backwards. “In this rebase, ‘theirs’ actually refers to my original commits, not the other person’s — the ours/theirs labeling flips during a rebase compared to a merge.”

Rebase vs. merge conflict — a distinction in how the conflict arose, since resolving a conflict during a rebase can require repeating the resolution across multiple commits, unlike a single merge conflict. “This is a rebase conflict, not a merge conflict, so if the same lines conflict in multiple commits, we may need to resolve it more than once as the rebase continues.”

Conflict resolution — the act of manually editing a conflicting hunk to produce the final, correct combined version, followed by staging the file to mark it resolved. “Once you’ve finished the conflict resolution, don’t forget to run git add on the file before continuing the rebase.”

Common Phrases

• “There’s a conflicting hunk in the config file — looks like we both touched the same three lines.”
• “This isn’t a Git conflict, but I think it’s a semantic conflict — did your change assume the old return type?”
• “Which version should we actually keep here — yours, mine, or a combination of both?”
• “Are we resolving this as part of a merge or a rebase? That changes how we handle it if it recurs.”
• “Can you double-check my resolution here? I want to make sure I didn’t accidentally drop your change.”

Example Sentences

Flagging a conflict to a teammate: “We’ve got a conflicting hunk in auth.ts — it looks like we both modified the token refresh logic around the same time. Do you have a few minutes to walk through it together so we don’t lose either change?”

Describing a semantic conflict that Git missed: “Git merged this cleanly, but I think there’s a semantic conflict — your PR changed the API to return null instead of throwing, but my code still has a try/catch expecting the old behavior. We should update mine to match.”

Confirming a resolution before pushing: “I resolved the conflict by keeping your validation logic and my error message change — can you take a quick look before I push, just to confirm I combined them correctly?”

Professional Tips

• Say “conflicting hunk” to point precisely at the affected lines rather than saying “there’s a conflict in the file,” which could mean anything from one line to the whole file.
• Watch for and name semantic conflicts explicitly — these are more dangerous than Git-flagged conflicts because nothing warns you automatically, and they require an actual conversation to catch.
• Double-check the ours/theirs meaning before describing a resolution, especially during a rebase, since the labels don’t mean what most people assume.
• Always offer a double-check on a non-trivial conflict resolution — a resolved conflict that silently drops a teammate’s change is a common and hard-to-notice bug.

Practice Exercise

1. Write a two-sentence message flagging a conflicting hunk to a teammate and proposing a quick call.
2. Write one sentence describing a semantic conflict that Git didn’t catch automatically.
3. Write a sentence asking a teammate to double-check a conflict resolution before you push.

Navigating Nuance: Specific Vocabulary for Conflict Resolution

Discussing merge conflicts effectively isn’t just about stating that there’s a problem; it’s about conveying how you see the solution and demonstrating a collaborative approach. For non-native English speakers, mastering specific terminology can dramatically improve your ability to participate confidently in these discussions. Let’s look at some phrases beyond simply saying “There’s a conflict.”

One key area is describing the nature of the disagreement. Instead of a vague “This doesn’t work,” try phrasing it more precisely. For example, if you’ve introduced a new variable that clashes with an existing one, you could say: “I’ve added a user_id field to the Customer model. This introduces a potential conflict because the previous version used a customerId field. It seems like we need to decide which naming convention is preferred for this data.” Notice how this uses technical terms – user_id, customerId, Customer model – but frames it as a question of preference, fostering dialogue rather than confrontation. Another useful phrase is “overlapping functionality,” referring to when two different branches have implemented the same feature in slightly different ways. This avoids accusatory language and highlights the technical issue at hand.

Furthermore, learn how to propose resolutions clearly. Don’t just say “Resolve this.” Instead, offer a specific suggestion: “I suggest we keep the customerId field for backward compatibility, while I update my code to use user_id going forward. We could then create a migration script to handle the transition.” This demonstrates you’ve considered the implications and are proactively offering a path forward. Similarly, when responding to a teammate’s suggestion, acknowledge their perspective: “That’s a good point about maintaining backward compatibility. Let’s explore that option further.” Using phrases like “Let’s investigate,” “Could we consider,” or “What if we…” shows you’re open to collaboration and willing to adapt your approach based on the discussion.

Finally, be mindful of tone in written communication – particularly Slack messages or PR descriptions. Avoid language that might sound demanding or dismissive. Phrases like “Please fix this” can come across as critical. Instead, opt for “Could you take a look at this conflict and suggest a solution?” This is polite, professional, and invites collaboration. Remember, the goal isn’t to win an argument but to find the best way forward as part of a team.