Ветвление разработчиков в SVN

Question

Нашей команде предлагается обновить CVS до SVN, и хотя ее не совсем Mercurial или Git, на которые я надеялся, это, по крайней мере, шаг в правильном направлении.

Я знаю, что a big hangup для разработчиков - по крайней мере, с SVN (или любой другой отраслевой SCM) - это тема разветвления и слияния.

Я читал статьи, проповедующие, что «ветви признаков» (ветви, охватывающие развитие определенной новой черты) - это чистое зло. И, прочитав их, я склонен согласиться. Но тогда возникает вопрос о том, , когда нужно разветвить и , когда нужно объединить?

Я занимался идеей о том, что разработчики проверяют сундук/но каждый из них имеет свои (отдельные) ветви разработчиков и передает новый код этим ветвям. Затем, всякий раз, когда разработчик завершает свою работу, мы просто объединяем код, относящийся к этой работе (расположенный внутри их собственной, «частной» ветки) с соединительной линии. Таким образом, они не удерживают кого-либо еще, и если они отстанут, они не остановят выпуск.

Просто интересно, какие мысли СО были сосредоточены на проявителе. Если это ужасная идея, почему? Какой лучший подход? Спасибо заранее!

Answer 1

Я один из тех типов, которые считают, что ветви являются злыми. Проверьте этот родственный вопрос для некоторого обсуждения по этой теме (в том числе и ответа по себе): Is using “feature branches” compatible with refactoring?

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

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

В заключение, вот мои ответы на ваши вопросы полужирный:

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

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

Answer 2

CollabNet, Inc., оригинальный спонсор Subversion, собрал список Subversion Best Practices.

Последний раздел списка «Знать, когда создавать ветки».

Филиалы зависят от культуры вашего программного проекта. CollabNet описывает три общие системы ветвей, которые используются.

• Никогда Дочернее система
• всегда-Branch Система
• Отделение-в случае необходимости система

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

Система Always-Branch часто используется проектами, которые способствуют интенсивному управлению и надзору.

Каждый разработчик создает/работает на частной ветке для каждой задачи кодирования. Когда кодирование завершено, кто-то или что-то просматривает все частные изменения ветвей и объединяет их в/trunk.

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

Система Branch-When-Needed - это система, используемая самим проектом Subversion. Это система, которая имеет смысл, когда группа разработчиков выпускает свой продукт путем управления версиями.

Пользователи фиксируют свою повседневную работу в/ствол. Пользователи не фиксируют до тех пор, пока после модульного тестирования. Регулярно тестируется ретрансляция.

Каждый тактный багажник помечен определенным выпуском или версией продукта. Если обнаружена ошибка в предыдущей версии продукта, для исправления проблемы создается ветка из тега версии. Это исправление затем объединяется в/trunk.

Answer 3

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

Есть три основные причины, почему вы должны расшириться:

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

2. У вас есть несколько десятков программистов, работающих над проектом в версии 1.0.Когда проект приближается к точке выпуска, вы хотите прекратить добавлять функции и исправлять ошибки. Тем не менее, это оставляет большинству ваших программистов ничего не поделать, кроме как закручивать их большие пальцы, в то время как два или три программиста, ответственных за выпуск, работают над завершением выпуска. Для каждого просто недостаточно работы. В этом случае вы отпустите Release 1.0 и отпустите свою ветку. Тем временем остальные разработчики могут продолжить работу над выпуском 2.0. \

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

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

---

Вопрос в том, почему дело № 3 намного сложнее, чем в двух других случаях. Ответ заключается в том, отходят ли ветви друг от друга или сходятся друг к другу. В случае №1 и случая № 2 ветви расходятся. В случае №2 код версии 1.0 будет отличаться от кода версии 2.0, а код версии 1.0 будет отличаться от кода версии 3.0. Фактически, когда-нибудь в будущем код в ветке версии 1.0 будет неактуальным.

Между тем, в случае № 3, ветви много сходятся друг к другу. Это означает, что вы должны синхронизировать их. Это требует усилий и надзора. Требуется много энергии, чтобы убедиться, что ветви, которые в конечном итоге должны будут объединиться оптом, должны оставаться в синхронизации.

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

---

Кстати, это одна из причин того, что распределенные системы контроля версий не всегда лучше централизованных. Я видел слишком много мест, которые использовали Git, а затем разработчики все работали в своем небольшом репозитории и никогда не разговаривали друг с другом. За неделю до релиза, мы получили clobbered с дюжиной patches и после этого имеем гонку для того чтобы объединить весь код в поставляемую версию.

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