Каков оптимальный диапазон количества живых ветвей?

Как определить, что RCS (svn или git) содержит слишком много веток?

Как насчет rule of 3:

• Одна ветка для стабильного кода — основной ствол;
• Одна ветка для нестабильной версии — разработка предстоящего релиза;
• И еще на обслуживание — исправления ошибок предыдущего релиза;

Многие проекты, размещенные на git, используют только две ветки: master для основного ствола и vNext для будущего релиза.

Используйте функцию tags для обозначения этапов разработки.

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

Попросите разработчиков добавить осмысленные имена и описания в локальные ветки. И лейбл фиксирует соответственно.

На этот вопрос нет единого ответа. Это может быть только «то, что работает для вашей организации и рабочего процесса».

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

Основываясь на вашем редактировании: если есть ветки, которые устарели или «мертвы», почему они все еще существуют? По определению от них больше нет никакой пользы, поэтому просто удалите их.

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

Главное — последовательность. Попробуйте сгруппировать ветки, чтобы они соответствовали вашему рабочему процессу. Вы можете, например, иметь

• stable — CI строит производство и/или постановку на основе этого
• staging - промежуточная сборка CI из этого
• feature/* - ветки для фич
• hotfix/* - запускается из промежуточной/стабильной ветки, используется для исправлений
• experimental/* — используется для функций НИОКР, которые могут не привести к чистому и поддерживаемому коду или могут быть заброшены на полпути.

Несколько основных советов здесь: http://nvie.com/posts/a-successful-git-branching-model/

Кроме того, если вы хотите, чтобы ваша команда быстро начала использовать хорошую структуру ветвей, попробуйте git flow: http://jeffkreefmeijer.com/2010/why-arent-you-using-git-flow/

О рефакторинге плохого кода других сотрудников. Вы можете использовать некоторые ветки refactor/*, чтобы вы могли легко увидеть, что сломано, имея атомарные слияния/перебазирования в отдельной ветке. Конечно, иметь тесты ЧРЕЗВЫЧАЙНО полезно, но если вы не сделаете простой git bisect, он покажет вам, кто и когда внес ошибку (и если вы напишете тест для проверки этой ошибки, который bisect будет использовать, у вас теперь есть значимый тест для добавления к вашему набору тестов).

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

РЕДАКТИРОВАТЬ: Под something/* я подразумеваю наличие нескольких ветвей с общим префиксом something/, таким образом имитируя структуру каталогов.

РЕДАКТИРОВАТЬ2: В SVN все по-другому, где ветвление и слияние не так уж и дешевы. Действовать с осторожностью ;)

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

РЕДАКТИРОВАТЬ4: В: "Можете ли вы, возможно, подумать о том, чтобы поставить некоторые числа или формулы на пороге, ниже которого допустимо беспорядочное ветвление и выше, какие ветки лучше организовать?"

Конечно!

Формула (по моему скромному мнению) проста.

• иметь столько «грязных» веток локально, сколько хотите (просто не передавайте их другим людям или общим репозиториям)
• старайтесь не продвигать грязные ветки, если они не представляют ценности для других разработчиков. Если они уже есть в вашем общем репозитории, сохраните их и переименуйте (на ум приходит legacy/* или просто dirty/*).

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

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

Позвольте мне привести вам пример PHP-проекта Symfony2 малого и среднего размера, над которым я работал.

Если у вас есть проект, который в течение 6-9 месяцев активно разрабатывается 5 разработчиками в гибкой (scrum) манере с демо-версией клиента каждые две недели, вы можете захотеть иметь ветки:

• на пользовательскую историю (для тесно интегрированных пользовательских историй это может быть плохой идеей), всего около 50 ветвей, думайте о них как о функциональных ветвях.
• на одного разработчика (по требованию, если разработчику нужно какое-то время над чем-то поработать), они приходят и уходят, но обычно в таких проектах у разработчиков меньше 3. Некоторые из них вообще не используют общедоступные ветки разработчиков и держат свои грязные ветки при себе.
• экспериментальный (неограниченное количество веток для исследовательских целей, например другой алгоритм или библиотека, используемая в модуле), около 7 веток, насколько я помню
• за спринт (объединено из пользовательских историй, полезно для демонстрации), около 10, это наша промежуточная/стабильная во время первоначальной разработки. Почему не теги? Теги тоже, но ветки, потому что легче применить исправление.
• исправления (обычно недолговечные, изолированные для облегчения сбора вишни), 3 вершины;)
• разное (обычно текущие общесистемные функции и/или ветки команды из 2-3 человек), около 10

Как видите, здесь тоже нет точного числа. Я сделал несколько проектов такого размера, и у большинства из них было около 70-80 веток (20-30 без веток пользовательской истории). Если они организованы логично и понятно, репозиторий кода легко просматривать.

С git рассмотрите также перебазирование вместо слияния, поэтому вы не получите пузыри слияния (ознакомьтесь с этой статьей http://stevenharman.net/git-pull-with-automatic-rebase).

Для Git и SVN есть разные способы просмотра этого. Но самое главное, что значит иметь слишком много чего-то, по причинам производительности или по причинам организации.

Итак, производительность git:

В git ветка — это не что иное, как ссылка на объект, являющийся частью репозитория git. Таким образом, для этого объекта филиала нет серьезных накладных расходов. (см. http://git-scm.com/book/en/Git-Branching-What-a-Branch-Is для получения дополнительной информации) Если вы уничтожите ветку, у вас все еще будет ВСЯ история git в вашем репозитории, это просто вопрос доступа к ней. В общем - лишнего хранилища для ветки нет. Если вы используете одноразовые ветки, удалите их, но ваши коммиты все еще существуют. Общая производительность git замедляется из-за размера репо, но ветки не создаются для его увеличения, а коммиты. Вы можете перепаковать или удалить объекты, чтобы очистить и ускорить репозиторий git.

Итак, производительность SVN:

В SVN ветки — это копии вашего рабочего дерева, однако эти копии не являются дубликатами данных. Опять же, это ссылки на существующее дерево, пока используется svn-copy. (см. http://svnbook.red-bean.com/en/1.1/ch04s02.html#svn-ch-4-sect-2.1 для получения дополнительной информации) SVN хорошо обрабатывает большие файлы и репозитории, но опять же, размер репозитория не сильно зависит филиалами, вместо этого они эффективны и дешевы. Собственно говоря, цитируя svnbook: "Суть здесь в том, что копии дешевы, как по времени, так и по пространству. Делайте ветки сколько хотите."

Организация SVN и git:

Ну, как я сказал выше, ветвление дешево, поэтому это может происходить часто, одноразовые ветки нужно удалять, но исторические ветки дешево хранить. По сути, у вас должен быть простой способ назвать ваши ветки по соглашению: release_1, bugfix_200, temp_branch_for_fun — все, что делает имя самоорганизующимся при их алфавитно-цифровом перечислении. Использование тегов также хорошо, как в SVN, так и в git — люди, как правило, чувствуют себя более комфортно с ветками, однако в git они действительно одинаковы, а в SVN они полезны для отсчета точек во времени.

Сколько слишком много ветвей - это решение бизнес-логики. Я предпочитаю иметь много одноразовых веток для Work In Progress, но иметь только исторические ветки для релизов. Но это хорошо только в итеративном рабочем процессе. В последнее время я перемещаю разработку в сторону рабочего процесса непрерывной доставки и распределенной сети git forked - тогда мне все равно, сколько ветвей имеет git fork разработчика - вместо этого мой исходный или основной репозиторий имеет только 1 постоянную ветвь: master и одноразовые ветки для исправлений с высоким приоритетом.

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

Все счастливы.

Как определить, что RCS (svn или git) содержит слишком много веток?

Никто. Такого общего правила не существует и (если какое-либо локальное все еще может быть определено), наконец, оно сильно зависит от команды и рабочего процесса.

С «Ветвью на задачу» у вас может быть много краткосрочных ветвей даже для кодовой базы небольшого и среднего размера (для любого размера команды и количества используемых языков).

Перенесено из комментария:

1-N не закрытых веток задач на разработчика (N зависит от множества факторов) 1-2 активных на разработчика + несколько общих (стабильный-нестабильный-релиз-...)

Ветки в git считаются одноразовыми. Если вам это не нужно и вы не будете использовать его снова, вы его бросаете. Однако в моем случае я управляю множеством ветвей, но только 1% из них используется. Я заблокировал остальные и убедился, что к версии релиза применены правильные теги.

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

Надеюсь, это поможет!

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