Subversion - должен ли кто-нибудь развиваться вне ствола?

Question

При использовании Subversion должны ли разработчики работать за транком или транк должен использоваться только для слияний из каждой отдельной ветки разработчика и отслеживаться службой непрерывной интеграции?

Answer 1

Существует две основные стратегии:

• нестабильная магистраль - магистраль всегда содержит самый последний код, ветки сделаны для релизов
• стабильная магистраль - код разрабатывается в филиалах и проверяется в магистрали только после полного тестирования и выпуска из магистрали

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

Так что, как обычно, однозначного ответа нет!

Answer 2

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

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

Answer 3

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

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

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

Взгляните также на следующий сайт:

http://www.cmcrossroads.com/bradapp/acme/branching/

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

• S1. Магистраль
• S2. Параллельное обслуживание / разработка
• S3. Перекрывающиеся релизы
• S4. Стыковочная линия
• S5. Ступенчатые линии интеграции
• S6. Изменить очереди распространения
• S7. Кодекс третьей стороны
• S8. Внутренние / Внешние Линии

Answer 4

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

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

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

Answer 5

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

Answer 6

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

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

Хммм, мне больно, когда я думаю о том, как много наших программных практик работает "достаточно хорошо".

Answer 7

Существует аргумент, что разработчики должны работать на транке.

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

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

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

Answer 8

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

После того, как бета была в порядке, мы выпускаем в продукт.

Answer 9

Как сказал Нейл Баттерворт , это зависит; существует несколько действительных способов.

Однако лично я бы порекомендовал иметь стабильный транк и делать все основные разработки для временных веток. (То есть, только небольшие, независимые изменения, которые будут полностью сделаны с одним коммитом, должны идти непосредственно в транк.) Чтобы избежать того, чтобы ветки с более долгим сроком действия слишком далеко от основной линии, (авто) объединяют все, что идет во все ветви разработки, по крайней мере, ежедневно. Да, и CI должен следить за всем - не только транком, но и всеми ветвями разработки. Особенно с Хадсоном это совсем несложно и приводит к очень небольшим накладным расходам.

Если вас интересует, как мы применили это, есть некоторые подробности в этом ответе . (Я бы не хотел повторяться слишком много ...:)

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

Answer 10

Сегодня я работаю над версией 3.0 нашего продукта и проверяю изменения кода в стволе. Релиз еще на несколько недель вперед.

Сотрудник экспериментирует с некоторыми функциями, которые могут сделать его в 4.0, но определенно не в 3.0. Она проверяет свои вещи в отдельной ветке. Было бы неправильно проверять такие вещи в багажнике.

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

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

P.S. о слиянии. Мы могли бы выборочно объединить некоторые вещи из ветки 2.5 в магистраль позже, но не из магистрали обратно в ветку. Объединение между стволом и веткой 4.0 может идти обоими путями.