Практика Subversion с несколькими ветками разработки

Question

Раньше я работал на месте в федеральном департаменте. Я встретил там руководителя группы «Джек», который возглавлял небольшую группу разработчиков, специализирующихся на C #, Delphi, PHP и т. Д. Джек просто приземлился там около 2 месяцев и уже порадовал директоров департамента, контролируя хаос и представляя прогресс через красивые таблицы и графики.

На собрании команды Джек продвигал такую ​​практику использования SVN:

1. Каждый разработчик, работающий над одним и тем же проектом, должен создать ветку, и ни один разработчик не должен работать над стволом.
2. Когда каждый разработчик завершит свою часть работы по разработке, объединитесь обратно в магистраль.

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

Как вы думаете, такая практика использования SVN с несколькими ветвями разработки?

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

Answer 1

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

Я не согласен с Майклом в отношении возможности фиксациидля быстрого исправления, потому что:

• Dura lex, sed lex
• Ад слияния не существует в ветвях с коротким сроком действия и в долгоживущих с правильной политикой слияния

Answer 2

Отказ от ответственности: я максимально использовал свой опыт работы с SVN <1,5, поэтому мои знания SVN теперь могут быть устаревшими. </p>

То, что хочет Джек, является моделью разработки по умолчанию для DVCS, такой как Git или Mercurial. В этом мире все отлично работает.

До того, как мы перешли на Mercurial в нашей компании, у нас была модель "все в стволе". Это вызывало всевозможные неприятные проблемы, потому что мы всегда наступали друг другу на ноги, вызывая действительно болезненный опыт. Но модель развития, которую описывает Джек, звучит как хорошее смягчение этой проблемы. Я не могу сказать, работает ли это на практике, так как мы осуществили переход до выхода версии 1.5 (это была версия SVN, где они начали отслеживать слияние). Но когда теперь работает отслеживание слияний, это хорошая модель разработки.

Answer 3

Ветвление должно быть не только для релизов или экспериментов. Он также обычно используется для работы над реализацией важных функций, которые могут повлиять на ряд файлов, когда нецелесообразно вносить такие значительные изменения в ствол. Таким образом, я бы сказал, что Джек на правильном пути.

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

Если эта стратегия ветвления принесла успех Джеку и его команде, они, вероятно, должны придерживаться этого.

Answer 4

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

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