Совместное разрешение конфликтов слияния в TFS 2010 - PullRequest
2 голосов
/ 01 июля 2011

Я отвечаю за существенную прямую интеграцию в ветке, с которой я не слишком знаком.Я чувствую себя комфортно при слиянии большинства конфликтов, но есть некоторые области, которые я действительно хотел бы сделать, чтобы снизить риск ошибок слияния.Мы работаем на Tfs 2010: какие у меня варианты?

Наш обычный рабочий процесс для обмена изменениями между разработчиками - использование наборов полок, но Tfs запрещает откладывание файлов до разрешения конфликтов слияния ...это сами конфликты слияния, которые я хочу обойти.Я знаю, что в Tfs 2010 появилась идея общего рабочего пространства - может ли эта функция использоваться несколькими людьми для разрешения конфликтов слияния?

У нас есть географически распределенная команда, поэтому, к сожалению, мы не можем просто обойтина столы друг друга.Если общие рабочие пространства не помогут мне достичь этой цели, каковы мои варианты?

1 Ответ

2 голосов
/ 01 июля 2011

Наша команда обычно выделяет этот раздел для слияния с разработчиком, который в основном работал над ним, предполагая, что он самодостаточен (слияние IE здесь не нарушит код внутри sln).Затем, когда завершится, произойдет остаток слияния.Конечно, это два шага;тем не менее, он гарантирует, что слияние выполнено правильно.

В тех случаях, когда это невозможно, обычно ответственное за слияние лицо принимает к сведению файл или файлы, в которых он не уверен на 100%о, а затем, после слияния и, конечно же, убедившись, что проект создается, он отправляет команде IM / электронной почты список файлов и просит людей, которые в основном работали над этим кодом, пересмотреть изменения.Конечно, этот процесс не является полным доказательством, но, по крайней мере, именно так мы с ним справились.

Другое решение, к которому вы не обращали внимания, - это создание общего рабочего пространства TFS, которое находится на сервере, которыйвся ваша команда может удаленно изучать код.Вот хорошая статья , описывающая, как это настроить.Если все используют одно и то же общее рабочее пространство / сопоставления и т. Д., Объединенное объединение проще выполнить.

И, наконец, последний вариант, который приходит на ум, - сохранить локальную версию (не объединять файл), предполагая, что она не нарушит сборку, а затем передать ее другому разработчику.Этот разработчик, используя TF Merge / force, может принудительно выполнить слияние, которое уловит тот факт, что вы решили сохранить локальную версию, в то время как дополнительный разработчик может разрешить эти конфликты слияния.обзоры, поэтому нет поддержки для разрешения конфликтов.Или, как заявляет MS:

В отличие от операции Get, которая автоматически объединяет согласованные различия между двумя версиями файла и помогает вручную объединять конфликты, операция без поддержки не поддерживает объединения.Удаляя отложенные отложенные изменения из вашей рабочей области в начале проверки кода, вы можете быть уверены, что любые изменения, внесенные вашим обозревателем в набор полок, такие как добавление комментариев в файл, не вызовут конфликтов слияния во время небрежного процесса.

Я понимаю, почему они это делают, но я согласен с вами, что было бы неплохо иметь полку "типа" типа Merge или что-то подобное.Это наверняка поможет при работе с большими проектами со сложными объединениями.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...