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

Ответ 1

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

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

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

В большинстве проектов git -hosted используются только две ветки: master для основной магистрали и vNext для будущей версии.

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

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

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

Ответ 2

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

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

На основе вашего редактирования: Если есть ветки, которые устарели или "мертвы", почему они все еще существуют? По определению, для них больше не используется, поэтому просто удалите их.

Ответ 3

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

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

• stable - CI строит производство и/или этап из этого
• staging - создание CI из этого
• feature/* - ветки для функций
• hotfix/* - началось с промежуточной/стабильной ветки, используемой для исправлений
• experimental/* - используется для функций R & D, которые могут не привести к чистому и поддерживаемому коду или могут быть оставлены на полпути через

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

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

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

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

EDIT: Под something/* я имею в виду наличие нескольких ветвей с общим префиксом something/, таким образом имитируя структуру каталогов.

EDIT2: все похоже на SVN-понравившиеся, где разветвление и слияние не так уж и дешевы. Будьте осторожны;)

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

EDIT4: Q: "можете ли вы подумать о том, чтобы положить некоторые числа или формулы на порог, ниже которого допустимо беспорядочное разветвление, и над которыми лучше всего организованы ветки?"

Конечно!

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

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

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

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

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

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

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

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

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

Ответ 4

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

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

С "Branch for task" у вас может быть много кратковременных ветвей для даже малой и средней размерности кода (для любого размера команды и количества используемых языков)

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

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

Ответ 5

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

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

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

So Производительность 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, они полезны для привязки точек во времени.

Сколько из них слишком много, это решение бизнес-логики. Я предпочитаю иметь много одноразовых веток для работы в процессе, имея только исторические ветки для релизов. Но это только хорошо в Iterative Workflow. Недавно я продвигался в направлении непрерывного потока работ и распределенной сети с разветвленной сетью Git, тогда мне все равно, сколько ветвей имеет вилка dev Git - вместо этого у моего источника или репозитория Mainline только 1 постоянный branch: master и одноразовые ветки для критических исправлений High Priority Critical.

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

Каждый счастлив.

Ответ 6

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

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

Надеюсь на эту помощь!

Ответ 7

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