TFS: Слияние лучших практик

Question

У нас есть стандартная отраслевая архитектура, в которой у нас есть ветвь развития для каждой команды, общая ветвь интеграции (откуда все ветви развития разветвлены) и производственная ветвь, разветвленная от Интеграции.

На этапе разработки я делаю много коммитов в ветку разработки. В конце фазы я объединю свои изменения в интеграции, а затем и в производство.

Имеет ли смысл объединить каждую фиксацию отдельно, скопировав исходное описание фиксации и связавшись с исходной задачей? Другим вариантом является, разумеется, объединить все коммиты сразу с одной операцией слияния. Причина моего вопроса в том, что первый путь занимает много времени. Я не вижу каких-либо инструментов автоматизации в TFS, которые связывают слияние с другой веткой с исходным фиксацией.

Я хотел бы услышать ваше мнение о лучших практиках.

Answer 1

1. Слияние с Dev * -> Интеграция и интеграция -> Продукция всегда должна быть «копировать». Это самый безопасный способ сохранить стабильность ваших нисходящих ветвей.
   1. Сначала слейте в другом направлении (например, Integration -> Dev2), чтобы получить последние изменения от целевой ветви.
   2. Если есть конфликты, обрабатывайте разницы по каждому случаю. AcceptMerge (автоматический или ручной), как правило, является желаемым результатом, но иногда вы хотите, чтобы одна или другая копия не изменилась.
   3. Используйте ветку источника (Dev # 2 в нашем случае), чтобы полностью включить, отреагировать и стабилизировать эти изменения.
   4. Объединить в нужном направлении (например, Dev2 -> Интеграция). Разрешайте все конфликты как AcceptTheirs [aka «копия из источника»].
   5. Убедитесь, что в целевой ветке нет изменений в шаге 1-4. Если ветвь Dev принимает слияние рано & часто, как и должно быть, тогда не должно быть обременительно блокировать целевую ветвь во время этого многообещающего короткого процесса. Если вы ожидаете «большого взрыва» слияния смерти по любой причине, есть приличная блокировка блокировки, чтобы другие команды выполняли то же самое параллельно, так что вам, возможно, придется повторять шаги 1-4 1-4, пока вы не будете готовы ,
2. «Догоняй» сливается, когда это возможно. То есть, объединить вещи в том же порядке, в котором они были проверены. Если изменения 10, 20 и 30 являются кандидатами для слияния с A -> B, то любой из этих диапазонов слияния является «догоняющим»: 10 ~ 10, 10 ~ 20, 10 ~ 30. Любой диапазон изменений, который пропускает # 10, известен как «выбор вишни»."Как только вы начинаете вишню собирание вы столкнетесь с несколькими опасностей:.
   1. Вы не можете использовать merge down, copy up модель, описанную выше Для этого в одиночку, Лора Wingerd бы сказал, что вы перепрыгивать через бордюр
   2. Если какой-либо. из файлов, затронутых вашим диапазоном, также были затронуты ранее, вам нужно будет объединить трехстороннее слияние контента, чтобы распространять только вишневые различия. Инструмент diff не идеален, вы добавляете ненулевой риск приведения более чем задуманный код, чем предполагалось, случайно переписывая изменения, внесенные в цель, вводя логические ошибки, когда две ветви расходятся и т. д.
   3. Набор изменений, которые вы продвигаете в предположительно более устойчивую ветвь, представляет собой конфигурацию tha t имеет никогда не было. Вы можете догадаться о конечном состоянии целевой ветви. «Я объединяю все изменения, влияющие на модуль Foo, и я тестировал новую версию Foo в Dev, так вот как Foo будет вести себя в интеграции, верно?» Конечно ... может быть ... если вы можете отслеживать каждую зависимость в своей голове (включая все, что могло измениться в Integration, когда вы тестировали Dev). Но эти догадки никоим образом не известны или не подтверждены вашей цепочкой инструментов SCM.
   4. В TFS конкретно, выбор вишни, где происходят изменения пространства имен, - это просто просить о сожжении. Если ваш диапазон версии и/или область пути исключает источник переименования, он будет заменен как ветка. Если вы исключите цель, она отложит удаление. Если ваша область пути не включает корень восстановления, вы получите загадочные ошибки. Если ваш диапазон охватывает промежуток времени между удалением &, повторное удаление, вы получите «фантомные» файлы, отображаемые в целевом объекте, даже если вы не включите его самостоятельно. Если вы слияете Moves со всем своим пути &, то варианты верны, но сделать это не по порядку, возможно получить другое имя цели, чем имя источника, даже после того, как все версии изменений кандидатов будут исчерпаны. Я уверен, что есть больше способов, чтобы эта комбинация пошла не так, как сейчас не приходит в голову ... просто поверьте мне.
3. Всегда делайте переход на целевую ветвь перед слиянием. Расширенная версия для максимальной безопасности: синхронизируйте рабочую область, в которой вы будете сливаться с определенным номером набора изменений, который находится рядом с подсказкой или рядом с ним, а затем [догоняющее] слияние с тем же набором изменений. Это позволяет избежать несколько потенциальных проблем:
   1. Объединения в несвежий код, дающий запутанное 3-ходовое, которые появляются посмотреть различие в удалить изменений от того, что вы видите на наконечнике. [вы, в конце концов, вернете их на Checkin + Resolve, но нет причин идти через два рискованных различий, когда вы можете избежать обоих]
   2. Необходимо пройти через процесс разрешения конфликта дважды: один раз на Merge, один раз на Checkin. Нельзя избежать этого в общем случае, но большую часть времени одновременных изменений, сделанных вами при объединении + разрешении, крошечный по сравнению с # изменениями, которые вы встретили в рабочей области, которая может быть дней или недель из Дата.
4. Не сливайте этикетку (или рабочую область), если вы действительно не знаете, что делаете. Давайте рассмотрим функции, предлагаемые метками TFS, а затем проанализируем, почему каждый из них не подходит для безопасного согласования с &.
   1. Этикетки могут представлять собой несколько точек во времени. Если метка представляет собой согласованный снимок VCS - и всегда была предназначена как таковая, то она не имеет технических достоинств над датой или набором изменений #. К сожалению, довольно сложно определить, действительно ли ярлык со временем.Если нет, то сливаясь этикетки может привести к:
      1. непреднамеренного снятия сливок, если диапазон начинается с ярлыком, который указывает на элемент @ некоторое время впереди своего первого кандидата
      2. Небрежность исключения, если начинается диапазон с ярлыком, который указывает на элемент @ некоторое время впереди в конце диапазона
      3. Небрежность исключение, если диапазон заканчивается с ярлыком, который указывает на элемент @ на время до начала диапазона
   2. Этикетки версий спецификаций представляют собой определенный набор элементов. Они могут использоваться для преднамеренного исключения файлов и папок, которые в противном случае видел бы рекурсивный запрос. Эта функция также является плохим совпадением для операций слияния. (И опять же, если вы не нужна эта способность, вы навлечь на следующий риск, не получив ничего по датам & ревизий.)
      1. Предметов, которые не присутствуют в метке будет просто игнорироваться, а не слиты как ожидающие удаления. В отличие от некоторых рассмотренных до сих пор краевых дел, это большое дело, которое, скорее всего, произойдет в основных сценариях, но большинство людей не хватает. [В результате TFS 2010 добавляет поддержку удаленных элементов внутри меток.]
      2. Небрежный выбор вишни, если вы добавили элемент на метку, которая присутствовала некоторое время, но была исключена из предыдущих объединений из-за одной из вышеупомянутых сторон последствия.
      3. Преднамеренный сбор вишни. Все преимущество этой функции приносит Merge - значит нарушить одно из наших рекомендаций, поэтому, очевидно, это не очень хорошая причина. Кроме того, он вызывает сбор вишни на уровне , что еще более опасно, чем «обычная» сборка вишни по набору изменений.
   3. Этикетки имеют дружественные настраиваемые имена, владельцы и комментарии. Таким образом, мы имеем чистую разницу в использовании по сравнению с датами/наборами изменений; техническое преимущество не предоставляется. Но даже здесь это не так привлекательно, как кажется. TFS не делает много, чтобы на самом деле нарисовать метки в пользовательском интерфейсе, тогда как вы можете видеть комментарии к изменениям по всему месту. Запрос владельца выполняется быстро (на стороне сервера), но большинство других запросов выполняется медленно (на стороне клиента), если вы не знаете точное имя метки. Средства управления практически отсутствуют. Нет изменений или аудита, только временная метка. В целом, это едва ли причины отказаться от поручительства, предоставляемого наборами изменений.
5. Всегда объединяйте всю ветку сразу. Слияние файлов или поддеревья иногда заманчиво, но в конечном итоге сводится к простому набору вишни под новым видом.
6. План вперед. К сожалению, переобучение филиалов в TFS является болезненной темой. Иногда это тяжело, иногда это всего лишь несколько шагов, но это никогда не очевидно; нет встроенной команды (до 2010 года). Вытягивание его в 2005/2008 году требует довольно глубокого знания вашей текущей структуры отрасли, желаемой структуры и способов злоупотребления побочными эффектами различных команд TF.
7. Не создавайте ветви внутри ветвей. Например, иногда рекомендуется объединение ветвей & в качестве способа поддержания общих модулей или двоичных файлов между слабо связанными проектами. Я не думаю, что это очень хороший совет для начала - гораздо лучше, чтобы ваша система сборки выполняла свою основную работу должным образом, чем обучать вашу систему управления версиями тем, что она не предназначена для этого. Во всяком случае, эта тактика «совместного использования» ужасно конфликтует с самими проектами, живущими внутри более широкой иерархии филиалов для целей SCM. Если вы не слишком осторожны, TFS с радостью разрешит вам создавать произвольные отношения «во много раз» между элементами управления версиями. Удачи, сортируя это (я когда-то должен был сделать это для клиента, а не красиво.)
8. Не создавайте файлы с одинаковым относительным путем в двух ветвях независимо друг от друга; используйте Merge, чтобы разветвить их, или вы будете часами преследовать конфликты пространства имен. (n/a в 2010 году)
9. Не добавляйте файлы поверх пути, где другие предметы существовали. Были ли старые элементы переименованы/перемещены или просто удалены, вы столкнетесь с интересными задачами в момент слияния; как минимум, для полноты размножения потребуется две проверки. (n/a в 2010 году, хотя опыт все еще несколько ухудшился, требуется только 1 проверка, содержимое элемента сохраняется, но история имен находится в этой ветке & всех дочерних ветвей)
10. Не используйте флаг/force если вы не знаете, что делаете. Все/принудительные слияния - это, как правило, черемухи, что приводит к очень похожим рискам (код теряется во время процесса Resolve и т. Д. И т. Д.).
11. Не используйте флаг/необозначенный флажок, если вы действительно не знаете, что делаете. Вы пропустите удаление - похоже на ярлыки, за исключением того, что переименовывает всегда получает morphed в ветвях, а не только в неудачных случаях кромки. Вы не получаете никакой дебетовой/кредитной защиты вообще. И самое страшное из всех, вы будете создавать новые отношения ветви. Иногда. (пользователю не сообщается о том, являются ли все целевые элементы новыми, старыми с новым отношением или старыми с существующим отношением)
12. Избегайте/отказывайте (и, что то же самое, разрешения AcceptYours), когда это возможно. Отбрасывание некоторых наборов изменений только для принятия последующих - это еще одно название для выбора вишни :)
13. Будьте осторожны с вашими разрешениями в целом. Каждый из них обладает уникальными эффектами нисходящего потока, кроме его влияния на слияние.
    1. AcceptTheirs - это быстрый способ получения «копии», как это предусмотрено в первом руководстве. Если вы используете его и в других сценариях, помните, что вы не, просто говоря TFS, чтобы содержимое файла было одинаковым. Вы говорите, что два файла: полностью синхронизированы с версией POV. Для этого любые предварительные изменения целевого файла, которые могли быть объединены в противоположном направлении, больше не будут считаться кандидатами после того, как вы проверите AcceptTheirs.
    2. Обратите внимание, что AcceptMerge (автоматический или ручной), итоговое содержимое которого совпадает с исходным файлом, будет считаться сервером AcceptTheirs. В протоколе web-сервиса Checkin нет различий.
    3. Использование AcceptYours при включении переименований может перевернуть ваш мозг. Вы быстро окажетесь в ситуации, когда «тот же» элемент имеет разные имена в разных ветвях. Предполагая, что у вас есть веская причина отказаться от изменений в первую очередь, это явление небезопасно само по себе - на самом деле, вероятно, необходимо избегать либо перерывов, либо одноразовых настроек для ваших make-файлов. Это просто сбивает с толку людей и очень вероятно нарушит любые сценарии автоматизации, которые у вас есть, что предполагает, что древовидные структуры согласованы от ветви к ветке.
    4. AcceptMerge по умолчанию по умолчанию. Иногда это приводит к большему количеству конфликтов версий, чем кажется строго необходимым, но является самым безопасным выбором, когда требуется истинное слияние. (Например, шаг № 1 первичного руководства «слить, скопировать».) Пока вы следите за другими рекомендациями, количество слияний, требующих внимания со стороны руководства, должно падать - резко, если вы исходите из рабочий процесс, который сильно зависит от выбора вишни.
14. Ошибки должны быть связаны с набором изменений, где фактически было исправлено. Если позже вам нужно просверлить в нисходящие ветви, чтобы увидеть, когда (и, возможно, как) распространено исправление ошибок, это чисто функция контроля источника. Не нужно загрязнять рабочий элемент дополнительным багажом, а тем более изменять способ, которым вы принципиально выполняете слияния.В 2005/2008 году вы можете перемещать историю слияния с помощью команды tf merges или стороннего интерфейса, такого как Attrice SideKicks. В 2010 году вы получаете отличные визуализации, встроенные в Visual Studio. Instructions & screenshots on MSDN.

Answer 2

Я всегда только объединил ряд коммитов в ветку интеграции, указав только диапазон наборов изменений, которые я объединил.

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

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

Итак, суммируя это, я не вижу причин, почему бы не пойти с массовыми слияниями.