В компании, с которой я работаю, начинают возникать проблемы с их нынешней моделью ветвления, и мне было интересно узнать, какие разные стратегии ветвления, к которым было привлечено сообщество?
Есть ли хорошие для разных ситуаций? Что использует ваша компания? Каковы его преимущества и недостатки?
Вот метод, который я использовал в прошлом с хорошим успехом:
/trunk - край кровотечения. Следующий основной выпуск кода. Может или может не работать в любой момент времени.
/branches/1.0, 1.1 и т.д. Стабильные ветки обслуживания кода. Используется для исправления ошибок, стабилизации новых релизов. Если ветка обслуживания, она должна скомпилировать (если применимо) и быть готовым к QA/отправке в любой момент времени. Если ветвь стабилизации, она должна компилироваться и быть полной. Никакие новые функции не должны добавляться, рефакторинг и очистка кода отсутствуют. Вы можете добавить префикс для указания ветвей стабилизации и ветвей обслуживания.
/ветки/cool_feature. Используется для высоко экспериментальной или деструктивной работы, которая может или не может попасть в багажник (или ветвь обслуживания). Никаких гарантий, связанных с компиляцией, работой или другим поведением в отношении безопасности. Должно существовать минимальное время, возможное до слияния с основной линией.
/tags/1.0.1, 1.0.2, 1.1.3a и т.д. Используется для маркировки упакованной и отгруженной версии. Никогда НИКОГДА не меняется. Сделайте столько тегов, сколько хотите, но они неизменяемы.
Я очень рекомендую прочитать мнение Эрика Синка по этому вопросу:
Я, как и Эрик, предпочитаю разветвление стиля "папка", о котором он говорит.
Для материнской части на ветвящихся рисунках см. Brad Appleton Потоковые линии: Ветвящиеся шаблоны для параллельной разработки программного обеспечения. Это тяжелый долг, но я не видел ничего, чтобы превзойти его с точки зрения широты и глубины знаний о ветвлении.
Наш репозиторий выглядит так:
/trunk
/branches
/sandbox
/vendor
/ccnet
/trunk - это стандартное, кратковременное развитие. Мы используем CI, поэтому он должен всегда строить и проходить тесты.
/branches, где мы помещаем "санкционированные" большие изменения, то есть то, что мы ЗНАЕМ, превратит его в багажник, но может потребоваться некоторая работа и сломает CI. Также мы работаем над версиями технического обслуживания, которые имеют свои собственные проекты CI.
/песочница у каждого разработчика есть своя песочница, а также совместная песочница. Это касается таких вещей, как "Позволяет добавить тип LINQ для нашего продукта", который вы выполняете, когда не выполняете свою настоящую работу. Он может в конечном итоге войти в багажник, он может и не быть, но он есть и под контролем версий. Здесь нет CI.
/vendor стандартная ветка поставщика для проектов, в которых мы компилируем, но это не код, который мы поддерживаем.
/ccnet это наши теги CI, здесь может писать только сервер CI. Оглядываясь назад, мы бы переписали это на нечто более общее, такое как CI, BUILDS и т.д.
Взгляните на http://codicesoftware.blogspot.com/2010/03/branching-strategies.html для лучшего объяснения
Первое: KISS (держите его просто глупо!)
/branches /RB-1.0 (*1) /RB-1.1 (*1) /RB-2.0 (*1) /tags /REL-1.0 (or whatever your version look like e.g. 1.0.0.123 *2) /REL-1.1 /REL-2.0 /trunk current development with cool new features ;-)
* 1) Сохраняйте поддерживаемую версию. Пакеты обновления, исправления, исправления, которые могут быть объединены в магистраль, если необходимо и/или необходимо) * 2) major.minor.build.revision
Правила большого пальца:
- hfrmobile
Мы свяжемся, когда релиз готов к окончательному QA. Если во время процесса QA обнаружены какие-либо проблемы, ошибки фиксируются в ветке, проверяются и затем объединяются в магистраль. Как только ветка проходит QA, мы помечаем ее как выпуск. Любые исправления для этой версии также выполняются в ветке, проверяются, объединяются в магистраль и затем помечены как отдельный выпуск.
Структура папок будет выглядеть следующим образом (1 строка QA, 2 выпуска исправлений и соединительная линия):
/ветки
/REL-1.0
/теги
/REL-1.0
/REL-1.0.1
/REL-1.0.2
/багажник
Мы используем дикий, дикий, западный стиль git -branches. У нас есть несколько веток, которые имеют известные имена, определенные конвенцией, но в нашем случае теги на самом деле важнее для нас, чтобы соответствовать требованиям корпоративной политики процесса.
Я увидел ниже, что вы используете Subversion, поэтому я думаю, вы, вероятно, должны проверить раздел о ветвлении в Subversion Book. В частности, посмотрите раздел "Расположение репозитория" в Обслуживание ветки и Общие шаблоны ветвей.
Альтернативой, которую я здесь не вижу, является философия "Филиал на изменение".
Вместо того, чтобы ваш багажник "Дикий Запад", что, если багажник - "Текущий выпуск"? Это хорошо работает, когда выпущена только одна версия приложения - например, веб-сайт. Когда требуется новая функция или исправление ошибок, для этого изменения требуется ветвь. Часто это позволяет перенести исправления для отдельного выпуска и не позволяет вашим кобелям-коврикам случайно добавить функцию для выпуска, которую вы не планировали. (Часто это бэкдор - "Только для разработки/тестирования" )
Указатели от Бена Коллинза весьма полезны при определении того, какой стиль будет хорошо работать для вашей ситуации.
Henrik Kniberg Контроль версий для нескольких гибких команд также имеет некоторые хорошие моменты, чтобы принять во внимание.
В настоящее время у нас есть один филиал для текущего обслуживания, один филиал для "новых инициатив", который просто означает "материал, который выйдет когда-нибудь в будущем, мы не знаем, когда". Мы также иногда проводили две ветки обслуживания: один для обеспечения исправлений для того, что в настоящее время находится в производстве, и того, которое все еще находится в ОК.
Основным преимуществом, которое мы видели, является способность быстрее реагировать на запросы пользователей и чрезвычайные ситуации. Мы можем сделать исправление на ветке, которая находится в производстве, и освободить ее, не выпуская ничего лишнего, которое уже было проверено.
Основным недостатком является то, что мы в конечном итоге делаем много слияния между ветвями, что увеличивает вероятность того, что что-то будет пропущено или слито неправильно. До сих пор это не было проблемой, но это определенно нужно иметь в виду.
Прежде чем мы установили эту политику, мы, как правило, делали все развитие в багажнике и только разветвлялись, когда мы выпускали код. Затем мы исправляли эту ветку по мере необходимости. Это было проще, но не так гибко.
Jeff Atwood написал об этом в хорошем сообщении в блоге; этот пост имеет некоторые важные ссылки в нем.
Гнат написал этот отличный отрыв по различным советам, которые вы можете найти по стратегиям ветвления.
Там не одна стратегия ветвления, это то, что работает для:
Jeff Atwood post раскрывает множество возможностей. Еще одна добавка - концепция продвижения (от ссылки Райана Даффилда). В этой настройке у вас есть ветвь dev, test bracnh и ветвь release. Вы продвигаете свой код до тех пор, пока он не достигнет ветки выпуска и не будет развернут.
Философия, которой мы руководствуемся на работе, заключается в том, чтобы держать багажник в состоянии, в котором вы можете нажать в любое время без серьезного вреда сайту. Это не означает, что багажник всегда будет в идеальном состоянии. Конечно, в нем будут ошибки. Но дело в том, чтобы никогда, никогда не оставлять его сломанным радикально.
Если у вас есть функция для добавления, ветвь. Изменение дизайна, ответвление. Было так много раз, когда я думал: "О, я могу просто сделать это в багажнике, это не займет столько времени", а затем через 5 часов, когда я не могу понять ошибку, которая нарушает вещи, которые я делаю действительно хотел, чтобы у меня была разветвленная.
Когда вы держите багажник в чистоте, вы позволяете быстро применять и выталкивать исправления ошибок. Вам не нужно беспокоиться о сломанном коде, который у вас есть, что вы удобно отделили.
Это будет зависеть от того, какую систему управления версиями вы используете. Каждый VCS имеет разные подходы к ветвлению.
Какой VSC вы используете?
Для Subversion я согласен с комментарием Райана Даффиста. В главе, на которую он ссылается, содержится хороший анализ того, какую систему использовать.
Причина, по которой я спросил, заключается в том, что Perforce предоставляет совершенно другой способ создания ветвей из SVN или CVS. Кроме того, есть все DVCS, которые придают ей собственную философию для ветвления. Ваша стратегия ветвления будет определяться тем инструментом, который вы используете.
FYI, Svnmerge.py - это инструмент, помогающий слиянию ветвей в SVN. Он работает очень хорошо, пока вы его часто используете (каждые 10-30) совершает, иначе инструмент может запутаться.
Независимо от того, какой шаблон ветвления выбран, вы должны попытаться сохранить свои ветки в форме двоичного дерева следующим образом:
trunk - tags
|
next
/ \ \
bugfix f1 f2
/ \ \
f11 f21 f22