Моя компания объединяет филиалы неправильно?

28

Недавно я наткнулся на статью MSDN о ветвлении и слиянии и SCM: Учебник по ветвлению и слиянию - Крис Бирмеле .

В статье говорится, что «слияние большого взрыва» - это антипаттерн слияния:

Big Bang Merge - отложенная ветвь, сливающаяся до конца разработки и пытающаяся объединить все ветви одновременно.

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

Я работаю в очень маленькой компании с одним человеком, выступающим в качестве окончательного обзора + полномочия по слиянию стволов. У нас есть 5 разработчиков (включая меня), каждому из нас будет назначено отдельное задание / ошибка / проект, и каждый из нас отделится от текущего транка (subversion), а затем выполнит работу по разработке в нашей ветви, протестирует результаты, напишет документацию при необходимости проведите экспертную оценку и обратную связь с другими разработчиками, а затем отправьте ветку на проверку + объедините наше программное обеспечение для управления проектами.

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

Мы нередко имеем 10-20 активных веток, которые находятся в финальной очереди просмотра и объединяются в транк.

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

У меня есть несколько прямых вопросов:

Мы демонстрируем тот самый анти-паттерн, который был описан как «слияние большого взрыва»?
Некоторые из проблем, которые мы видим в результате этого процесса слияния?
Как мы можем улучшить этот процесс слияния, не увеличивая узкое место моего босса?

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

Любое другое понимание этой ситуации будет оценено.

— user6567423
источник

2

Почему объединение отложено? Обычно есть причина не делать это немедленно. один парень перегружен работой, а отставание становится таким большим? Есть ли какая-то другая причина, почему слияние не выполняется своевременно?

— Полигном

1

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

— МечМК1

3

Что происходит, когда босс уходит в отпуск?

— Лиат

Как бы вы определили стратегию ветвления / слияния ядра Linux?

— Брайам

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

— Григорий Нисбет

60

Некоторые предложения:

Нет ничего плохого в том, чтобы иметь много ветвей функций или исправлений, если изменения, внесенные в каждую ветвь, достаточно малы, и вы все равно можете эффективно обрабатывать возникающие конфликты слияния. Это должно быть вашим критерием, если ваш способ работы в порядке, а не статья MSDN.
Всякий раз, когда ветка объединяется с транком, она должна быть слита как можно скорее во все открытые ветви разработки. Это позволило бы всем людям в команде разрешать конфликты слияния параллельно в их собственной ветви и таким образом брать на себя некоторую нагрузку от привратника магистрали.
Это будет работать лучше, если привратник не будет ждать, пока 10 ветвей «готовы к слиянию в транк» - для разрешения конфликтов слияния из последних интеграций транков всегда требуется некоторое время для группы, поэтому, вероятно, лучше работать в переплетенных временных интервалах - одна интеграция привратником, одна повторная слияние командой, следующая интеграция привратником, следующая повторная слияние командой и т. д.
Чтобы ветки были небольшими, это может помочь разделить большие функции на несколько более мелких задач и разработать каждую из этих задач в отдельной ветви. Если функция не готова к работе до тех пор, пока не будут реализованы все подзадачи, скрывайте ее от производства за переключателем функций, пока все подзадачи не будут выполнены.
Рано или поздно вы столкнетесь с задачами рефакторинга, которые затрагивают многие файлы в базе кода - они имеют высокий риск возникновения большого количества конфликтов слияния со многими ветвями. Лучше всего с ними справиться, четко сообщив об этом в группе, и убедитесь, что обрабатывали их точно так, как я написал выше: сначала интегрируя их во все ветви dev перед реинтеграцией, и разбивая их на более мелкие субрефакторинги.
Для вашего текущего размера команды наличие одного привратника может все еще работать. Но если ваша команда увеличится в размерах, нет никакого способа обойтись вторым привратником (или более). Заметьте, я не предлагаю разрешить всем слиться в транк, но это не значит, что это может сделать только ваш босс. Вероятно, есть один или два старших разработчика, которые также могут быть кандидатами на работу привратника. И даже для размера вашей текущей команды второй привратник может упростить вашу команду для интеграции в транк чаще и раньше, или когда ваш босс недоступен.

— Док Браун
источник

2

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

— user6567423

@ user6567423 Еще одна вещь, которую вы могли бы рассмотреть, - создание веток для каждой версии разработки (например, 5.2.3 или любой другой), которую каждый разработчик может разветвить для работы с функциями, а затем объединить, и которая затем может быть объединена с основной ветвь релиза боссом после завершения разработки.

— nick012000

@ nick012000: не станет ли это предположение не затруднит привратнику принятие или отклонение отдельных ветвей функций для / против интеграции в магистраль? Я имею в виду, что если несколько функций смешать в одну ветку разработки, реинтеграция этих изменений частично в транк станет очень сложной. Или я что-то упустил?

— Док Браун

10

« Разрешать конфликты слияния параллельно в своей собственной ветви и, таким образом, брать на себя некоторую нагрузку от привратника магистрали ». «Это лучше для компании, НО ТАКЖЕ легче для вас », похоже, является главным аргументом при предложении этого боссу. Это больше относится к офисной политике, которой SE не занимается, но в этой ситуации, без поддержки со стороны босса, все остальное в этом технически превосходном ответе просто не произойдет.

— Р. Шмитц

@DocBrown Да, было бы, но это также означало бы, что у вас было бы намного меньше конфликтов между ветвями разработчика, и это все равно дало бы вам степень безопасности, обеспечиваемую прямым слиянием с основной веткой - и он может просто отказаться принять работу как выполненную и выполнить слияние, пока он не будет доволен состоянием кода в целом.

— nick012000

18

Мы демонстрируем тот самый анти-паттерн, который был описан как «слияние большого взрыва»?

Похоже, это так.

Некоторые из проблем, которые мы видим в результате этого процесса слияния?

определенно

Как мы можем улучшить этот процесс слияния, не увеличивая узкое место моего босса?

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

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

— Мэтью
источник

1

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

— user6567423

5

@ user6567423: Если ваш начальник становится узким местом, которым он теперь является в соответствии с вашим описанием, ему придется либо изменить свой подход, либо согласиться с тем, что он является причиной задержек (в этом его сотрудники не могут быть обвинены). Отказ от изменения вашего подхода, игнорирование проблем, которые вы создаете, и обвинение других - это не способ ведения бизнеса.

— Флейтер

1

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

— user6567423

1

@ user6567423 Мне любопытно, объяснил ли он, почему он единственный, кто может слиться с транком.

— Мэтью

13

По сути, именно так работают многие проекты с открытым исходным кодом, в том числе ядро Linux, которое имеет гораздо больше веток, чем вы в любой момент времени. Типичный способ избежать слияния большого взрыва в этих проектах - создать другую ветвь (или несколько ветвей) для непрерывной интеграции. Это ветвь, которую вы используете, чтобы убедиться, что ваши изменения работают вместе с вашими коллегами, и она периодически перекладывается в магистраль, когда привратник приступает к проверке.

При желании вы можете использовать эту ветку, чтобы объединить несколько ваших собственных запросов на получение запросов в один большой связный запрос, который ваш босс может просмотреть. Линус Торвальдс обычно получает запросы извлечения, которые были интегрированы на два или более уровня глубиной и могут иметь размер порядка, например, полного нового драйвера файловой системы.

— Карл Билефельдт
источник

Спасибо, я думаю, что советы по объединению ветвей и предотвращению конфликтов, вероятно, будут нашим лучшим способом действий.

— user6567423

8

Я согласен с обоими доктором Брауном, но я также вижу другой антипаттерн:

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

В моем смирении есть некоторые антипаттерны управления:

Он / она - единственная заслонка, ограничивающая скорость команды. Ваш фактор шины равен 1. Теория ограничений говорит, что вы должны приложить усилия для улучшения самой медленной части цепи.
Ваш менеджер замедляет цикл обратной связи и снижает ловкость вашей команды. Можете ли вы выпускать каждую неделю?
Сложность слияний растет экспоненциально с количеством кода. Лучше сделать 10 слияний со 100 линиями, чем 1 из 1000 строк. Это только одна из причин, почему вы должны сделать это как можно скорее
Если вы обнаружите сбой в магистрали, вы сделаете это позже. Какая из нескольких веток была проблемной
Решения должны принимать те, кто больше о них знает. Кто знает больше в этом случае? Могу поспорить, что разработчики, которые сделали код.
Вы не можете исправить ошибку в производственном процессе, если ваш менеджер работает в праздничные дни.
Вы переделываете работу и отбрасываете ветви. Это пустая трата времени. Время, необходимое для достижения производства, также является ненужным.

Рекомендации:

Ваш менеджер должен делегировать ответственность команде. Нужно показать, что команда зрелая, профессиональная. Дайте понять, что они могут доверять команде
Реализуйте некоторый метод обзора. Может быть, вам нужно одобрение двух других членов команды.
Может быть, использование SVN усложняет. Попробуйте Git и посмотрите, поможет ли это вам. Даже больше. Если вы используете GitHub, вы можете использовать механизм Pull Request, чтобы слияние требовало определенных голосов.
Читайте и делитесь информацией о гибких методах, непрерывной интеграции и DevOps.

— Borjab
источник

7

Я профессионально работал как с SVN, так и с git, и я бы сказал, что SVN определенно является частью проблемы: он навязывает политику единого слияния-возврата для веток, которых нет в git. В git все слияния равны, в SVN одни более равны, чем другие. Кроме того, отсутствие локальных коммитов значительно усложняет эксперименты с SVN, чем с git, а отсутствие промежуточной зоны только усиливает негибкость SVN. Есть причина, по которой Торвальдс не просто использовал SVN вместо разработки git ...

— cmaster

Git намного лучше, чем svn, на мой взгляд, по причинам, изложенным @cmaster и более

— reggaeguitar

Я согласен, что git, вероятно, решит некоторые из наших проблем слияния, и, боже мой, мне бы хотелось, чтобы ребаз был доступен. Но я не думаю, что мы собираемся сделать переключение в ближайшее время :(

— user6567423

1

@ user6567423, в прошлом году я провел консультацию, в которой помог небольшой команде перейти с svn на Git и изменить их рабочий процесс, включая обучение их работе с Git и настройку их с помощью GitLab Community Edition (с открытым исходным кодом) для проверки кода и совместной работы. , Они были в восторге от этого; это была разница между днем и ночью. (Также это заняло всего три дня.)

— Wildcard

2

Когда вы выполняете работу с компонентами в отдельных ветвях, вы не можете легко провести интеграционное тестирование, пока одна из ветвей не будет объединена с внешней линией и не перетянута в другие ветви функций. По моему опыту, это главная проблема с анти-паттерном Big Bang Merge. В идеале вы должны выполнить работу с функцией, протестировать ее в ветви функции, слить ее в транк, и в этот момент вы закончите работу с функцией. Если он не был объединен, вы должны пересматривать его каждый раз, когда что-то еще сливается в магистраль перед этим. Беда этого анти-паттерна в том, что в конце цикла разработки у вас появляется много ошибок интеграционного типа.

— bmm6o
источник

1

Итак, у вас есть 20 филиалов. Ветвь 1 только что слилась. Затем разработчик ветви 2 должен слить ветку 1 в свою ветку, чтобы иметь возможность без конфликтов сливаться с основной, а затем сливается. Затем разработчик ветви 3 должен объединить ветвь 1 и ветвь 2 в их ветку, чтобы иметь возможность сливаться с основной без конфликта, а затем сливается.

Упражнение для читателя: Напишите программу, которая печатает мой полный пост :-)

Это безумие. Вы будете тратить невероятное количество времени на слияние.

— gnasher729
источник

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

— user6567423

2

Нормальное поведение слияния SVN, насколько я могу судить ...

— cmaster

0

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

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

— Мартин Маат
источник

1

И как вы собираетесь обрабатывать релиз, если только одна из этих функций имеет ошибку или не завершена вовремя? «Само по себе ветвление - это то, что вы не хотите делать, если у вас нет веских причин для этого». Если у вас есть 5 человек, работающих над несколькими функциями, вам придется использовать ветвление, если у вас нет очень веских причин не делать этого.

— Иво ван дер Викен

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

— Мартин Маат

1

Я бы

— расценил