Merge conflicts UX

Problem to solve

One participant in the SAST to Complete CMS was tasked with enabling SAST, but was blocked by merge conflicts. She's a new developer and new to git, and did not understand how to proceed. Her struggle can be boiled down to two problems to solve:

• She didn't understand the meaning of use theirs vs use ours
• She didn't understand that she had to choose one of the above options in order to proceed, possibly because they don't look like buttons used elsewhere in the GitLab UI

Screenshot:

Other info

I brought this up in Slack. Here's the transcript:

Becka (me): @pedroms I'm not sure if your team "owns" this part of the MR experience, but I noticed that when there are merge conflicts, we have "use theirs" and "use ours". This came up in a SAST CMS interview when the participant (a developer) was trying to enable SAST and she wasn't sure how to proceed. Starting at 13:59 of this video (going until about 15:50), I ask her, "Is that clear to you what that means - use theirs vs use ours?" Her response was, "Yes" at first, but then thought about it more and changed her answer to "No" (it's not clear). She then adds, "I assume that GitLab is theirs ...". I didn't dig into this too much because I had to be mindful of time and make sure I completed all of my scenarios for the CMS, but I thought this terminology was interesting (theirs I assume is the other person trying to merge conflicting code to the same branch and ours are the owner(s) of the MR in which we were in (?) and the buttons don't quite look like buttons here either.

@jboyson: FWIW ours/theirs is git specific verbiage. Context: https://stackoverflow.com/a/25576672/2892106. Not saying we can’t make it better, but it is (for better or worse) industry standard.

Becka (me): @jboyson Interesting, thanks! Curious how many developers are familiar with this. The developer I spoke with was less experienced (I believe she completed a bootcamp and this is her first job) so for users like that I think it could be helpful to include a tooltip or some kind of explanation on what this means, but curious to hear if any of the designers or researchers have heard specific feedback on this or not.

@jeldergl: And there are situations where ours and theirs can flip if I remember right. Like during a rebase. Does that sound right @jboyson?

@jboyson: Sadly, yes. I think you are correct. I have several seasoned developers that basically don’t know anything beyond git checkout/pull

Intended users

Anyone who is trying to merge an MR (possibly all personas), and especially Sasha (Software Developer)

User experience goal

• Developers new to Git understand how to resolve merge conflicts
• Developers new to Git can quickly and easily figure out the difference between use theirs and use ours
• Developers new to Git understand they need to choose one of these options in order to resolve conflicts and thereby unblock the MR

Proposal

Possibly both problem validation (if none has been done in this area) and if problem is validated, do solution validation on 1 or more design explorations

Documentation

The MR docs page doesn't appear to go into the difference between theirs vs ours, and the screenshot there appears to be outdated.

cc @aqualls

Available Tier

All tiers

What does success look like, and how can we measure that?

Is this a cross-stage feature?

Yes, many stages involve CI/CD but this primarily falls under the Code Review group