Недавно я наткнулся на статью MSDN о ветвлении и слиянии и SCM: Учебник по ветвлению и слиянию - Крис Бирмеле .
В статье говорится, что «слияние большого взрыва» - это антипаттерн слияния:
Big Bang Merge - отложенная ветвь, сливающаяся до конца разработки и пытающаяся объединить все ветви одновременно.
Я понял, что это очень похоже на то, что делает моя компания со всеми производимыми отраслями.
Я работаю в очень маленькой компании с одним человеком, выступающим в качестве окончательного обзора + полномочия по слиянию стволов. У нас есть 5 разработчиков (включая меня), каждому из нас будет назначено отдельное задание / ошибка / проект, и каждый из нас отделится от текущего транка (subversion), а затем выполнит работу по разработке в нашей ветви, протестирует результаты, напишет документацию при необходимости проведите экспертную оценку и обратную связь с другими разработчиками, а затем отправьте ветку на проверку + объедините наше программное обеспечение для управления проектами.
Мой босс, единственный авторитет в репозитории ствола, фактически откладывает все проверки веток до момента, когда он будет выполнять обзоры столько, сколько он может, некоторые ветви будут отброшены для улучшений / исправлений, некоторые ветви будут сливаться прямо в ствол, некоторые ветви будут отброшены из-за конфликтов и т. д.
Мы нередко имеем 10-20 активных веток, которые находятся в финальной очереди просмотра и объединяются в транк.
Нам также часто приходится разрешать конфликты на заключительном этапе проверки и слияния, поскольку две ветви были созданы из одной и той же магистрали, но изменили один и тот же фрагмент кода. Обычно мы избегаем этого, просто переразбивая магистраль и повторно применяя наши изменения и разрешая конфликты, а затем отправляя новую ветку на проверку (ребаз плохого человека).
У меня есть несколько прямых вопросов:
- Мы демонстрируем тот самый анти-паттерн, который был описан как «слияние большого взрыва»?
- Некоторые из проблем, которые мы видим в результате этого процесса слияния?
- Как мы можем улучшить этот процесс слияния, не увеличивая узкое место моего босса?
Изменить: Я сомневаюсь, что мой босс ослабит свою хватку в хранилище ствола, или позволит другим разработчикам сливаться с стволом. Не уверен, каковы его причины, но я не собираюсь поднимать эту тему, потому что она поднималась раньше и сбивалась довольно быстро. Я думаю, что они просто не доверяют нам, что не имеет смысла, потому что все равно отслеживается.
Любое другое понимание этой ситуации будет оценено.
источник
Ответы:
Некоторые предложения:
Нет ничего плохого в том, чтобы иметь много ветвей функций или исправлений, если изменения, внесенные в каждую ветвь, достаточно малы, и вы все равно можете эффективно обрабатывать возникающие конфликты слияния. Это должно быть вашим критерием, если ваш способ работы в порядке, а не статья MSDN.
Всякий раз, когда ветка объединяется с транком, она должна быть слита как можно скорее во все открытые ветви разработки. Это позволило бы всем людям в команде разрешать конфликты слияния параллельно в их собственной ветви и таким образом брать на себя некоторую нагрузку от привратника магистрали.
Это будет работать лучше, если привратник не будет ждать, пока 10 ветвей «готовы к слиянию в транк» - для разрешения конфликтов слияния из последних интеграций транков всегда требуется некоторое время для группы, поэтому, вероятно, лучше работать в переплетенных временных интервалах - одна интеграция привратником, одна повторная слияние командой, следующая интеграция привратником, следующая повторная слияние командой и т. д.
Чтобы ветки были небольшими, это может помочь разделить большие функции на несколько более мелких задач и разработать каждую из этих задач в отдельной ветви. Если функция не готова к работе до тех пор, пока не будут реализованы все подзадачи, скрывайте ее от производства за переключателем функций, пока все подзадачи не будут выполнены.
Рано или поздно вы столкнетесь с задачами рефакторинга, которые затрагивают многие файлы в базе кода - они имеют высокий риск возникновения большого количества конфликтов слияния со многими ветвями. Лучше всего с ними справиться, четко сообщив об этом в группе, и убедитесь, что обрабатывали их точно так, как я написал выше: сначала интегрируя их во все ветви dev перед реинтеграцией, и разбивая их на более мелкие субрефакторинги.
Для вашего текущего размера команды наличие одного привратника может все еще работать. Но если ваша команда увеличится в размерах, нет никакого способа обойтись вторым привратником (или более). Заметьте, я не предлагаю разрешить всем слиться в транк, но это не значит, что это может сделать только ваш босс. Вероятно, есть один или два старших разработчика, которые также могут быть кандидатами на работу привратника. И даже для размера вашей текущей команды второй привратник может упростить вашу команду для интеграции в транк чаще и раньше, или когда ваш босс недоступен.
источник
Похоже, это так.
определенно
В моей компании каждый разработчик имеет возможность слияния. Мы назначаем запрос на слияние другому разработчику, проходим цикл обзора / обратной связи / обновления, пока обе стороны не будут удовлетворены. Затем рецензент сливает код.
10-20 веток, ожидающих слияния, являются признаком того, что ваш процесс имеет недостатки. Если бы у нас их было столько, вся работа разработчиков прекратилась бы, пока она не была прояснена.
источник
По сути, именно так работают многие проекты с открытым исходным кодом, в том числе ядро Linux, которое имеет гораздо больше веток, чем вы в любой момент времени. Типичный способ избежать слияния большого взрыва в этих проектах - создать другую ветвь (или несколько ветвей) для непрерывной интеграции. Это ветвь, которую вы используете, чтобы убедиться, что ваши изменения работают вместе с вашими коллегами, и она периодически перекладывается в магистраль, когда привратник приступает к проверке.
При желании вы можете использовать эту ветку, чтобы объединить несколько ваших собственных запросов на получение запросов в один большой связный запрос, который ваш босс может просмотреть. Линус Торвальдс обычно получает запросы извлечения, которые были интегрированы на два или более уровня глубиной и могут иметь размер порядка, например, полного нового драйвера файловой системы.
источник
Я согласен с обоими доктором Брауном, но я также вижу другой антипаттерн:
В моем смирении есть некоторые антипаттерны управления:
Рекомендации:
источник
Когда вы выполняете работу с компонентами в отдельных ветвях, вы не можете легко провести интеграционное тестирование, пока одна из ветвей не будет объединена с внешней линией и не перетянута в другие ветви функций. По моему опыту, это главная проблема с анти-паттерном Big Bang Merge. В идеале вы должны выполнить работу с функцией, протестировать ее в ветви функции, слить ее в транк, и в этот момент вы закончите работу с функцией. Если он не был объединен, вы должны пересматривать его каждый раз, когда что-то еще сливается в магистраль перед этим. Беда этого анти-паттерна в том, что в конце цикла разработки у вас появляется много ошибок интеграционного типа.
источник
Итак, у вас есть 20 филиалов. Ветвь 1 только что слилась. Затем разработчик ветви 2 должен слить ветку 1 в свою ветку, чтобы иметь возможность без конфликтов сливаться с основной, а затем сливается. Затем разработчик ветви 3 должен объединить ветвь 1 и ветвь 2 в их ветку, чтобы иметь возможность сливаться с основной без конфликта, а затем сливается.
Упражнение для читателя: Напишите программу, которая печатает мой полный пост :-)
Это безумие. Вы будете тратить невероятное количество времени на слияние.
источник
Учитывая то, как вы работаете, и что ваш босс является ответственным управляющим, похоже, проблема в ветвлении. Вместо того чтобы создавать ветку для каждой функции, пусть каждый разработчик закрепит свою функцию по частям прямо в стволе. Это накладывает бремя интеграции на разработчика в несколько меньших шагов (беспроигрышный вариант). Привратник может отслеживать более мелкие изменения в течение более длительного периода в начале цикла разработки и при этом оставаться главным рецензентом.
Само ветвление - это то, что вы не хотите делать, если у вас нет веских причин для этого или у вас нет другого выбора. Вы достаточно малы, чтобы держать вещи в синхронизации более плотно, что будет проще и безопаснее.
источник