Стратегии ветвления

Я настоятельно рекомендую прочитать мнение Эрика Синка по этому поводу:

Глава 7: Филиалы

Я, как и Эрик, предпочитаю ветвление в стиле «папка», о котором он говорит.

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

Какой VSC вы используете?

В настоящее время у нас есть одна ветка для текущего обслуживания, одна ветка для «новых инициатив», что означает просто «вещи, которые появятся когда-нибудь в будущем; мы не уверены, когда». Также время от времени у нас были две ветки обслуживания: одна для предоставления исправлений для того, что в настоящее время находится в производстве, а другая все еще находится на стадии контроля качества.

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

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

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

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

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

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

Что касается Subversion, я согласен с комментарием Райана Даффилда. Глава, на которую он ссылается, дает хороший анализ того, какую систему использовать.

Причина, по которой я спросил, заключается в том, что Perforce предоставляет совершенно другой способ создания веток из SVN или CVS. Плюс ко всему, есть все DVCS, у которых есть собственная философия ветвления. Ваша стратегия ветвления будет зависеть от того, какие инструменты вы используете.

К вашему сведению, Svnmerge.py - это инструмент, помогающий объединить ветки в SVN. Он работает очень хорошо, если вы используете его часто (каждые 10-30), иначе инструмент может запутаться.

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

Структура папок будет выглядеть следующим образом (1 строка QA, 2 выпуска исправлений и магистраль):

/branches

/REL-1.0

/tags

/REL-1.0

/REL-1.0.1

/REL-1.0.2

/trunk

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

/ trunk - передний край. Следующий крупный выпуск кода. Может работать или не работать в любой момент времени.

/branches/1.0, 1.1 и др. Стабильное сопровождение веток кода. Используется для исправления ошибок, стабилизации новых выпусков. Если это обслуживающая ветка, она должна скомпилироваться (если применимо) и быть готова к обеспечению качества / отправке в любой момент времени. Если ветвь стабилизации, она должна быть скомпилирована и иметь полную функциональность. Не следует добавлять новые функции, проводить рефакторинг и очищать код. Вы можете добавить префикс для обозначения ветвей стабилизации и ветвей обслуживания.

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

/tags/1.0.1, 1.0.2, 1.1.3a и т. д. Используется для маркировки упакованного и отправленного релиза. НИКОГДА не меняется. Создавайте столько тегов, сколько хотите, но они неизменяемы.

Мы используем дикий, дикий, западный стиль git-branch. У нас есть несколько веток, имена которых известны по соглашению, но в нашем случае теги на самом деле более важны для нас, чтобы соответствовать требованиям нашей политики корпоративных процессов.

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

Наш репозиторий выглядит так:

/trunk
/branches
/sandbox
/vendor
/ccnet

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

/ветви - это то место, где мы вносим «санкционированные» большие изменения, то есть то, что мы ЗНАЕМ, внесет это в магистраль, но может потребовать некоторой работы и нарушит CI. Также мы работаем над отладочными версиями, у которых есть собственные проекты CI.

/ песочница у каждого разработчика есть собственная песочница, а также общая песочница. Это касается таких задач, как «Давайте добавим поставщика LINQ к нашему продукту», которые вы выполняете, когда не выполняете свою настоящую работу. Со временем он может попасть в транк, а может и нет, но он там и находится под контролем версий. Здесь нет CI.

/продавец стандартная ветвь поставщика для проектов, которые мы компилируем, но не поддерживаем этот код.

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

Альтернативы, которую я здесь не вижу, - это философия «ветвления перемен».

Что делать, если ствол - это не «Дикий Запад», а «Текущий выпуск»? Это хорошо работает, когда одновременно выпускается только одна версия приложения - например, веб-сайт. Когда требуется новая функция или исправление ошибки, создается ветка для хранения этого изменения. Часто это позволяет переносить исправления в выпуск по отдельности и предотвращает случайное добавление вашими ковбойскими кодировщиками функции в выпуск, которой вы не планировали. (Часто это бэкдор - «Просто для разработки / тестирования»)

Указатели Бена Коллинза весьма полезны для определения того, какой стиль лучше всего подходит для вашей ситуации.

Контроль версий для нескольких Agile-команд Хенрика Книберга также имеет ряд хороших моментов, которые следует учитывать.

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

Джефф Этвуд написал об этом в хорошем сообщении в блоге; в этом посте есть несколько важных ссылок.

1. Одна ветка для активной разработки (/ main или master, в зависимости от жаргона)
2. Одна ветка для каждого отладочного выпуска -> он будет получать только очень мелкие исправления, в то время как все основные разработки идут в / main
3. Одна ветка для каждой новой задачи: создайте новую ветку для работы с каждой новой записью в вашей Bugzilla / Jira / Rally. Часто совершайте фиксацию, самостоятельно документируйте изменение, используя дюймовые отметки, и объединяйте его обратно в свою «родительскую» ветвь, только когда она будет завершена и хорошо протестирована.

Взгляните на этот http://codicesoftware.blogspot.com/2010/03/branching-strategies.html для лучшего объяснения

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

   trunk - tags
     |
    next
   /  \  \
bugfix  f1  f2
        /   \  \          
       f11    f21 f22

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

Первое: ЦЕЛОВАТЬ (Держите это просто глупо!)

/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

Практические правила:

1. Папку Теги не нужно извлекать
2. Только небольшое количество кода в ветках выпуска (упрощает слияние) - без очистки кода и т. д.
3. Никогда не кодировать в папке тегов
4. Никогда не помещайте информацию о конкретной версии в исходные файлы. Используйте Place-holders или 0.0.0.0, который механизм сборки заменит номером версии, которую вы создаете.
5. Никогда не помещайте сторонние библиотеки в систему управления версиями (также никто не будет добавлять библиотеки STL, MFC и т. д. В SVN ;-))
6. Только коммитить код, который компилируется
7. Предпочитайте использовать переменные среды вместо жестко заданных путей (абсолютных и относительных путей)

--hfrmobile

Gnat написал этот отличный прорыв о различных советах, которые вы можете найти по стратегиям ветвления.

Не существует одной стратегии ветвления, она подходит для:

• Размер вашей команды
• Ваш продукт и периоды жизненного цикла
• Используемая технология (веб, встроенные приложения, приложения для Windows)
• Ваш исходный элемент управления, например Git, TFS, Hg

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