Resolve simple merge conflicts on GitHub

On my team I've found that it's incredibly useful to commit the merge conflicts and conflict markers, then immediately resolve the conflicts in the next commit. This gives you one commit that shows exactly how the two branches merged together, followed by a commit that shows exactly how the conflicts were resolved. The resolution commit can then be code reviewed independently for a nice clean view of the conflicts introduced in the merge. It also allows you to easily reset to the merge commit and resolve the conflicts differently.

The standard git workflow (and this github feature) seems to promote resolving the conflicts alongside all of the other changes in the merge working copy. This make me nervous, as there's no way to differentiate the new lines that were introduced to resolve merge conflicts from the thousands of lines of (previously reviewed) code from the feature branch.

If you're not careful, completely unrelated working-copy code and behavior can be introduced in a "merge commit" and neither you or any of your reviewers will notice. "Looks good to me."

Re: Resolve simple merge conflicts on GitHub

#5

Post by orivej » Mon, Dec 12, 2016, 10:06 PM UTC

diff3 conflict style display would be considerably more useful.

Re: Resolve simple merge conflicts on GitHub

#6

Post by fogleman » Mon, Dec 12, 2016, 10:09 PM UTC

pkamb wrote: post #4

On my team I've found that it's incredibly useful to commit the merge conflicts and conflict markers, then immediately resolve the conflicts in the next commit. This gives you one commit that shows exactly how the two branches merged together, followed by a commit that shows exactly how the conflicts were resolved. The resolution commit can then be code reviewed independently for a nice clean view of the conflicts in…

That's a really good idea! I'm going to start doing that.

Re: Resolve simple merge conflicts on GitHub

#7

Post by acchow » Mon, Dec 12, 2016, 10:10 PM UTC

pkamb wrote: post #4

On my team I've found that it's incredibly useful to commit the merge conflicts and conflict markers, then immediately resolve the conflicts in the next commit. This gives you one commit that shows exactly how the two branches merged together, followed by a commit that shows exactly how the conflicts were resolved. The resolution commit can then be code reviewed independently for a nice clean view of the conflicts in…

Sounds like this would be a nightmare to rebase onto.

Re: Resolve simple merge conflicts on GitHub

#8

Post by nothrabannosir » Mon, Dec 12, 2016, 10:11 PM UTC

pkamb wrote: post #4

On my team I've found that it's incredibly useful to commit the merge conflicts and conflict markers, then immediately resolve the conflicts in the next commit. This gives you one commit that shows exactly how the two branches merged together, followed by a commit that shows exactly how the conflicts were resolved. The resolution commit can then be code reviewed independently for a nice clean view of the conflicts in…

Great idea! Although this does break cherry-pick, doesn't it?

Re: Resolve simple merge conflicts on GitHub

#9

Post by kovrik » Mon, Dec 12, 2016, 10:12 PM UTC

pkamb wrote: post #4

On my team I've found that it's incredibly useful to commit the merge conflicts and conflict markers, then immediately resolve the conflicts in the next commit. This gives you one commit that shows exactly how the two branches merged together, followed by a commit that shows exactly how the conflicts were resolved. The resolution commit can then be code reviewed independently for a nice clean view of the conflicts in…

Yes, that is a problem.

On the other hand, with your approach you are going to have revisions that won't even build/compile.

If you have automatic builds or/and unit/integration tests, then you'll have failed builds every time you have a merge conflict.

Also, you are kind of 'polluting a well': what if meanwhile someone merges that revision into his/her branch? Or what if you have automatic merges configured?

Re: Resolve simple merge conflicts on GitHub

#10

Post by aargh_aargh » Mon, Dec 12, 2016, 10:13 PM UTC

nothrabannosir wrote: post #8

pkamb wrote: post #4

On my team I've found that it's incredibly useful to commit the merge conflicts and conflict markers, then immediately resolve the conflicts in the next commit. This gives you one commit that shows exactly how the two branches merged together, followed by a commit that shows exactly how the conflicts were resolved. The resolution commit can then be code reviewed independently for a nice clean view of the conflicts in…

Great idea! Although this does break cherry-pick, doesn't it?

Why would it? You can get a conflict on a cherry-pick as well.