Разрешение конфликта для слияния в одном направлении не обязательно подходит для слияния в другом направлении. Во многих рабочих процессах вы в основном объединяетесь, чтобы сохранить две ветви как можно более похожими - например, перенести изменения из ветви разработки в рабочую ветку и, возможно, переместить критические исправления ошибок из производственной ветви обратно в ветку разработки. В такого рода рабочих процессах вы обычно не захотите расходиться при объединении двух ветвей (в конце концов, вам нужно это критическое исправление в обеих ветвях), поэтому неясно, почему вам придется разрешать конфликт слияния оба раза, но это определенно не единственный рабочий процесс при работе с ветками.
Раньше я работал над проектом Java, в котором были некоторые служебные библиотеки, которыми мы поделились с группой, работающей над другим проектом. В какой-то момент наши библиотеки по разным причинам должны были отличаться от своих, поэтому мы взяли ветвь их проекта, и обе группы внесли в библиотеку уникальные изменения. Иногда случалось, что мы исправляли ошибку, а иногда случалось, что они добавляли новую функцию, поэтому мы часто сливались друг с другом.
Здесь вы можете видеть, что результаты слияния нашей ветви с их не обязательно должны быть результатами слияния их ветви с нашей. Давайте предположим, что был файл, в который мы добавили несколько новых методов и, возможно, исправили несколько ошибок. И давайте предположим, что они добавили несколько разных методов. Когда они сливают наши изменения в свою ветку, у них возникает конфликт слияния, и давайте предположим, что они приняли исправления, но не взяли наши новые методы, так как они им не нужны. Теперь, когда мы выполняем слияние, чтобы внести их изменения в нашу ветку, мы все равно получаем конфликт слияния - это позволяет нам использовать их методы в нашем файле.
Если бы TFS сделало какое-то предположение о слиянии их филиала с нашим, основываясь на результатах нашего филиала, это было бы неточно.