Разветвление за особенностью - Преимущества / недостатки?

Question

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

Одна вещь, о которой мы говорили, - это ветвление по функциям. У нас очень разные взгляды на то, что хорошо и что плохо с этим конкретным методом.

Есть ли у вас опыт делать это раньше? Это сработало хорошо? У вас были проблемы - какие проблемы?

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

Answer 1

Мы используем функцию ветвления, и она очень хорошо работает для нас.Самое большое преимущество состоит в том, что функциональные группы знают, что то, над чем они работают, не влияет на другие функциональные команды, пока новая функция не будет интегрирована (в нашем случае в Main).

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

В нашем случае никто не работает в основной ветке.Вся разработка ведется в тематической ветке.Начальная разработка (перед первым выпуском в Production) выполняется в ветке разработки.После первого выпуска в производство все разработки выполняются в новой функциональной ветви.

Answer 2

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

ОПИСАНИЕ

Вот пример, который я нашел, чтобы сбалансировать производительность с безопасностью контроля версий (для команды ~ 25 разработчиков и ~ 3 тестеров):

1. Работа в одной и той же ветке: Разработчики, работающие над слабосвязанным или несвязанным кодом, могут относительно безопасно работать напрямую в одной и той же ветке разработки (или "интеграции"). Здесь хорошо вписываются исправления и неразрывные изменения (более низкий риск серьезных регрессий, влияющих на других разработчиков). Непрерывная интеграция и стробированные сборки - это две лучшие практики, которые снижают риск того, что многие разработчики работают в одной и той же ветке. Переключатель Примечание: Переключатели функций можно использовать для дальнейшего избежания необходимости ветвления, но убедитесь, что накладные расходы на тестирование / поддержание поведения переключения не более рискованны, чем при использовании ветви.

2. Наборы полок: Используйте функцию системы контроля версий, чтобы сохранить ожидающие изменения в специализированных ветвях разработчика. Разработчики, регистрирующиеся в TFS (Team Foundation Server), могут использовать наборы полок вместо личных веток (или многих ветвей микро-функций / задач), если они единственные, кому нужно разработать и протестировать эту функцию, прежде чем регистрироваться в ветке интеграции / dev. , Я считаю, что другие системы контроля версий имеют аналогичные конструкции ANTIPATTERN: Локальные рабочие пространства автоматически обеспечивают временную изоляцию для каждого разработчика ... но разработчики должны часто / ежедневно проверять свои изменения где-нибудь в системе контроля версий, чтобы предотвратить риск потерять дни + локальной работы. )

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

Основным преимуществом вышеупомянутого рабочего процесса является то, что он сводит к минимуму налог на слияние (время, затрачиваемое на интеграцию вперед / назад (слияние вниз / вверх)) вместо разработки функций, которые непосредственно улучшают удовлетворенность клиентов.

Пример сценария: Новая функция «Круто» сломает существующую функциональность и строит до завершения. Также требуется более 2 разработчиков для совместной работы над одной и той же кодовой базой (исключая возможность использовать Shelveset). Владелец разработки для "Cool" Создает ветку с именем Cool1 , затем разрабатывает и тестирует интеграцию первой версии функции. Владелец разработчика отвечает за ежедневное объединение родительских изменений (в большинстве случаев еженедельно). Подтвердите готовность к слиянию (родитель слился с дочерью (FI), все UT и основные приемочные тесты выполняются и продолжают проходить). Слияние с родительским (RI), затем подтверждение работ в родительской ветви (все UT и основные приемочные тесты проходят), затем удалите Cool1 функциональную ветвь (очистка).
Тщательно протестируйте функцию Cool после слияния с веткой разработки / интеграции. (Ресурсы тестирования ограничены, поэтому избегайте полной тестовой среды для каждой ветви.) Исправления и тактические улучшения / рефакторинг для Cool были бы сделаны непосредственно в ветви Dev (используя наборы полок, когда назначенному dev требуется много дней для локальной разработки / тестирования перед регистрацией). Если позже потребуется крупная (для нескольких разработчиков) переделка Cool, создайте новую ветку Cool2 .

Перемещение / переименование TFS2010 Примечание: Изменено поведение перемещения и переименования TFS 2010 (с TFS 2008) для перемещения, а Renames = "перейти к новому имени / местоположению, а затем пометить исходный элемент как удаленный".Это означает, что вы должны просто удалить неактивные функциональные ветви, если вы не хотите видеть их в системе управления версиями \ Dev \, вместо того, чтобы перемещать ветку в другую папку.Это также означает, что разработчики, которые разрешают просмотр удаленных папок, всегда будут видеть эти удаленные (или перемещенные или переименованные) недолговечные ветви как «призраки», которые могут быть загромождены.(Вот так вы можете просмотреть историю или восстановить удаленный элемент.)

Answer 3

Альтернативой ветвям для функций могут быть переключатели функций (т.е. переключатель в коде, который может сделать функцию доступной или нет).Они могут быть действительно полезны в этом отношении.Они могут позволять разрабатывать и развертывать новые функции, но доступны только после того, как переключение ... хорошо переключено (это даже слово).Я полагаю, что это что-то вроде идеи Google Labs.

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

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

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

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

Недавно я посетил конференцию, организованную Thoughtworks, где Мартин Фаулер обсуждал эту тему.Доклад был посвящен непрерывной доставке и тому, как это может помочь преодолеть медленные и рискованные развертывания.См. http://www.thoughtworks.com/events/thoughtworks-continuous-delivery-devops или просто выполните поиск для непрерывной доставки для получения дополнительной информации.

Answer 4

Git намного лучше, чем TFS.Я использую git уже более 7 лет и до этого использовал TFS.Недавно я сменил работу, где я должен использовать TFS.Простая ветка разработчика и все разработчики, работающие над одним и тем же разработчиком, не дают возможности для правильной проверки.Мне нравится тот факт, что в git-обзоре кода это формальный процесс.

С помощью git я работал над локальной ветвью, создавая ветки, связанные с особенностями / рабочими элементами.По завершении работы вы можете отправить ее в удаленный филиал.Затем из удаленной ветви вы отправите запрос на удаление в вашу ветку разработки / интеграции.Как только запрос на просмотр будет рассмотрен, рецензент объединит PR с веткой dev.Это сработало для меня очень хорошо.

Answer 5

Чем больше команд работает над целью слияния со своими собственными ветвями, тем лучше будет ваше общение для разрешения конфликтов.

Остерегайтесь высокого оттока, связанных и общих областей в вашем коде. Это будут спорные районы.

Ветвление за функцией может быть эффективно выполнено в TFS, но, как и в случае с dev, чем сложнее вы получаете, тем больше накладных расходов вы получаете.