In response to the various references to using DISTINCT, keep in mind that DISTINCT will only save you if the values are duplicates. Once the values diverge, DISTINCT won't keep your MERGE from erroring and it won't keep your UPDATE from picking one at random. Much better to use partitioning to deterministically select one of the values (and to have a defensible criteria for selecting which value).
Personally, I think DISTINCT (outside of ETL scenarios) is a potential code-smell. I avoid using it in the final SELECT clause of a query and strive only to use it in well-scoped sub-queries where I understand exactly why I am using it. Even then I think DISTINCT is really a shortcut and should probably be thought about as a shortcut for a more verbose form that expresses the actual intent.
For instance, let's assume I have a M:M join table and I want to identify all the records on one side that have joins in the join table, so I do something like:
SELECT DISTINCT Col2 From JoinTable;
An alternative way of looking at that would be to do something like this:
SELECT Col2 FROM Table2 WHERE EXISTS (
SELECT * FROM JoinTable WHERE Table2.Col2 = JoinTable.Col2
The point it, what I'm really asking for is a list of all of the Col2 values (which should be the primary key of a table somewhere) that have one or more matching records in the JoinTable. In general, looking for DISTINCT values that aren't foreign keys is a hint that there may be a missing table in your schema. The fact that you are looking for DISTINCT values indicates that the values reference distinct objects, and if you haven't surfaced those objects in your schema, you're missing something.
I'll still use DISTINCT (it's a lot shorter than the alternative syntax), but I try to limit myself to scenarios where I could replace it with the alternate syntax.
While I'm on this kick, keep in mind that GROUP BY can be just another way of saying DISTINCT! That means that using GROUP BY at the top level of a multi-join query is a major code-smell (and can result in inefficient queries). Ditto for UNION without ALL, etc.