Обзор кода Рабочий процесс + Ветвление функций в TFS

Question

Мы начинаем работать с ветвями функций, и мы хотим настроить политику регистрации, которая позволяет выполнять check-ins только для базовой линии, когда у них есть связанный анализ кода.

Новый рабочий процесс проверки кода в 2012 году является довольно приятным, так как вы можете легко взаимодействовать с разработчиком и другими рецензентами и напрямую писать строки кода. Тем не менее, похоже, MS не думаю, что случай использования полностью, потому что мы легко запустить в следующей задаче:

1. Разработчик работает на проверку в функцию отраслевого/стеллажа и вперед-интеграции на регулярной основе.

2. Когда она хочет интегрировать эту функцию, она снова объединяется в базовую линию и запрашивает обзор этих ожидающих изменений.

3. Рецензент делает несколько замечаний, и теперь ей приходится менять код. Где она это делает?

Вариант 1: Вернитесь к ветви, редактирования кода и регистрации в изменениях в отрасли. Отмените ожидающие изменения первого слияния. Слейте и повторите запрос. Повторяйте, пока комментариев больше нет. Завершите слияние. Это не так приятно, потому что все комментарии к обзору находятся в ожидающих изменениях слияния, и она должна работать в филиале, где она не видит комментарии напрямую.

Вариант 2: Внесите изменения непосредственно в ожидающие изменения слияния. Запросить повторную проверку. Повторяйте, пока комментариев больше нет. Завершите слияние. Если она хочет продолжить работу над филиалом, ей нужно будет провести интеграцию, потому что изменений в обзоре нет.

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

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

Новое:. Использование VS и TFS2013, до сих пор никаких улучшений :(

Answer 1

Ты ничего не пропуская Это не досадная проблема, связанная с тем, как были реализованы Кодовые Отзывы, они могут быть связаны только с одним changeet, а не в диапазоне изменений.

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

Есть трюк, это не идеально, но это может помочь. Вы можете проверить (на своей ветке свойств) все файлы, которые были изменены с момента последней проверки. Затем запросите обзор. Он будет создавать полки с вашими изменениями и связывать их с обзором. Таким образом, вы не должны выполнять слияние перед запросом обзора. Просто убедитесь, что вы объединили последнюю версию из main в свою ветку функций, прежде чем потянуть этот трюк.Есть два основных недостатка:

1. Хотя все измененные файлы будут связаны с обзором, изменения, произошедшие после последнего обзора, не будут подсвечиваться автоматически. Рецензент должен будет вручную выполнить «Сравнить с версией» и выбрать цель сравнения.
2. Существует ограничение в 4000 (с верхней части головы) файлов, которые могут быть связаны с обзором, так что это может создать ограничение на то, какие файлы вы можете просмотреть в группе (надеюсь, вы не меняете 4000 + файлы между интеграциями в основной).