# Conflict Resolution and Code Reviews

DevFeed: [Conflict Resolution and Code Reviews](<https://devfeed.tech/articles/conflict-resolution-and-code-reviews-21873.md>)

Original publisher: [Read original article](<https://ponyfoo.com/articles/conflict-resolution-and-code-reviews>)

Author: nico@ponyfoo.com (Nicolás Bevacqua)

Published: 2019-04-10T10:00:46Z

Content type: tutorial

Language: en

Sources: [Pony Foo](<https://devfeed.tech/sources/pony-foo.md>)

Topics: [Code review](<https://devfeed.tech/topics/code-review.md>), [Pull Request](<https://devfeed.tech/topics/pull-request.md>), [Git](<https://devfeed.tech/topics/git.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [checkout](<https://devfeed.tech/tags/checkout.md>), [code-review](<https://devfeed.tech/tags/code-review.md>), [code-reviews](<https://devfeed.tech/tags/code-reviews.md>), [git](<https://devfeed.tech/tags/git.md>), [git-commit](<https://devfeed.tech/tags/git-commit.md>), [github](<https://devfeed.tech/tags/github.md>), [tips](<https://devfeed.tech/tags/tips.md>)

## AI overview

A tutorial on reviewing conflict resolution in large Git pull requests. It shows how to recreate the merge with conflict markers locally so reviewers can isolate and inspect the changes made to resolve conflicts, while ignoring unrelated branch changes.

## Source excerpt

Have you ever tried to do a code review on a PR that merges a large release branch or feature branch back into mainline, fixing merge conflicts? It's not pretty. The diffs are often and easily very big, -- 50k+ LOC big -- have hundreds of commits, and the actual changes made by the engineer resolving the merge conflicts are virtually impossible to spot. This article covers one nifty trick I've been using lately in these cases that lets you review exactly the conflict resolution, while ignoring the mountains of changes that don't represent any conflicts (and can thus be safely ignored). Check out the PR locally If you haven't done this before, you can just add the author's remote (provided they're using a fork, otherwise you can skip this step) like so: $ git remote add nico https://github.com/nico/repo.git Then we can fetch the PR branch, let's assume it's called fix-merge-conflicts and it was merging branch-with-conflicts into master, fixing the conflicts along the way: $ git fetch nico fix-merge-conflicts $ git checkout fix-merge-conflicts Assess the situation The git log should indicate they've merged a couple branches. The commit hashes are the key bits here. $ git log -1 HEAD commit a9c9ed7gcc0a76670d86df4b732f1f219ccb48de (HEAD -> fix-merge-conflicts) Merge: aecf730802 ba9918dad5 Author: Bloodninja <bloodninja@usenet.org> Date: Mon Apr 8 12:32:38 2019 +0000 Merge remote-tracking branch 'branch-with-conflicts' And now we can verify that these indeed belong to each of the branches we care about: $ git branch --contains=aecf730802 master * fix-merge-conflicts $ git branch --contains=ba9918dad5 branch-with-conflicts * fix-merge-conflicts Now for the magic git checkout -b what-were-they-thinking git reset --hard aecf730802 git merge --no-ff ba9918dad5 # this will conflict git add . git commit -m WIP At this point, what-were-they-thinking is the version of the conflict resolution where you just committed things exactly as git merge left them, conflict markers and all.