TFS Code Reviews - Показать обновленные файлы в ответ на комментарии

Мы начинаем использовать функцию обзора кода, встроенную в предварительный просмотр VS 2012 и VS 2013. Запрос обзора и добавление комментариев выглядят довольно просто. Если кто-то добавляет комментарии, требующие изменения кода, то как этот запрос может внести эти изменения и показать их?

Итак, процесс будет протекать следующим образом:

  • Лицо 1 запрашивает обзор кода.
  • Лицо 2 добавляет комментарии и выбирает "Требует работу".
  • Лицо 1 вносит необходимые изменения.

Как Person 1 теперь показывает эти изменения Person 2? Вы можете добавлять комментарии и отправлять их, но файлы не меняются. Я предполагаю, что файлы находятся из набора изменений, созданного при запросе оригинала. Должен ли человек 1 закрыть этот обзор и запросить второй отзыв?

Создание второго обзора не представляется оптимальным, потому что вы теряете историю своего разговора о том, почему вы вносили изменения.

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

ОТВЕТЫ

Ответ 1

Итак, процесс будет протекать следующим образом:

  • Лицо 1 запрашивает проверку кода.
  • Лицо 2 добавляет комментарии и выбирает "Требует работу".
  • Лицо 1 вносит необходимые изменения.
  • Лицо 1 Обновляет полку, связанную с просмотром кода.
  • Лицо 1 добавляет комментарии для продолжения обсуждения
  • Повторите шаги 2 - 5 до тех пор, пока не будут приняты

Ниже приведены шаги, необходимые для обновления полки, связанные с обзором.

  • На панели "Обзор кода" выберите ссылку "просмотр полки"
  • Из панели "Детали полки" выделите и скопируйте имя полки
  • Перейдите в панель "Ожидающие изменения", нажмите "Shelve" и вставьте имя полки
  • Нажмите кнопку "Да" на полке для замены диалогового окна подтверждения.
  • Теперь рецензент может видеть обновленные файлы, и обсуждение обсуждений может продолжаться.

Я включил некоторые снимки экрана, поскольку я нахожу, что это помогает прояснить ситуацию.

1) На панели "Обзор кода" выберите ссылку "просмотр полки", как показано ниже:

enter image description here

2) Из панели "Детали полки" выделите и скопируйте имя полки, как показано ниже:

enter image description here

3) Перейдите к панели "Ожидающие изменения", нажмите "Shelve" и вставьте имя полки, например:

enter image description here

4) Нажмите кнопку "Да" на полке для замены диалогового окна подтверждения:

enter image description here

Ответ 2

Я считаю, что правильной процедурой является fore Person 1, чтобы внести изменения и запросить другой обзор. Когда ваш код нуждается в работе, это означает, что вы измените его, чтобы вы хотели, чтобы старая версия оглядывалась назад для сравнения. У вас все еще есть старый обзор в истории после его закрытия, если вы хотите просмотреть комментарии. В настоящее время мы работаем над оптимизацией процесса проверки кода на моем рабочем месте.

Ответ 3

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

Недавно команда TFS приступила к этапам планирования для решения очень старого запроса на публикацию, чтобы включить обновление обзора кода, которое должно быть элегантно решить эту проблему, сделав повторную проверку кода.

Ответ 4

Вам нужно сделать это с помощью двух разных обзоров. Но есть также способ сохранить историю во втором обзоре. Все, что вам нужно, это задачи.

Этот рабочий процесс описан для обзоров, основанных на изменениях, но он также работает для обзоров на основе полных версий.

  • Создать задачу1
  • Перед проверкой в ​​changeet1 добавьте task1 как связанный рабочий элемент
  • Проверить изменения с помощью одного связанного рабочего элемента и запроса на этот набор изменений.
  • Создать задачу2
  • Перед проверкой в ​​changeet2 добавьте обе задачи в качестве соответствующего рабочего элемента.
  • Проверьте изменения с двумя связанными рабочими элементами и просмотрите запрос на этот набор изменений.

Теперь во втором запросе на проверку рецензент может искать связанные задачи, и если рецензент ищет задачу1, он видит changeet1 и запрос на просмотр с его комментариями. Таким образом, вы не потеряете историю разговоров.