Ветви для каждого небольшого изменения?

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

Мы думаем использовать ветку для каждого запроса на изменение. Это безумие? Какие другие решения могут работать?

Спасибо!

Изменить. Это очень трудный вопрос для выбора правильного ответа. Спасибо всем за ваши замечательные ответы.

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

Изменить. Теперь это почти месяц спустя, и мой коллега/клиент убедил меня в том, что несколько веток - это путь. Это происходит не только из-за неуверенности клиента, но и от нашей потребности в том, чтобы иметь возможность определить, "функция готова" или "нужна больше работы" или что-то еще. У меня нет SVN со мной, но мы сливаемся с помощью совета из Cookbook SVN: вы объедините ветвь от, ревизия которой была разветвлена до пересмотра главы.

Кроме того, используя эту систему, мы объединяем все ветки в какой-то момент, и это становится новым QA, а затем строит live. Затем мы отделяемся от этого.

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

Два года спустя: Теперь мы используем GIT, и теперь эта система на самом деле вполне разумна.

Ответ 1

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

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

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

Ответ 2

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

Если вы посмотрите на GIT вместо SVN, вы найдете систему управления версиями, которая будет более мощной при объединении в целом. Кроме того, у него есть особая особенность "набора вишни". То есть, отдельные коммиты могут быть легко "выбраны" из одного дерева разработки и добавлены к другому (живая ветка). Кроме того, в GIT легко и удобно объединить несколько коммитов в один один (вы даже можете добавить к конкретному фиксации из другого дерева).

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

Ответ 3

Как насчет создания ветки для вашей живой версии клиента, ветки для вашей новой разработки и ветки для ваших текущих изменений.

Работайте в новой ветке разработки, когда вы не наводнены задачами.

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

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

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

Ответ 4

Сценарий, объясненный открывателем потоков, является примером шаблона ветвей признаков: http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html#svn.branchmerge.commonpatterns.feature

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

Недостатком является то, что вы должны синхронизировать различные ветки с туловищем: пока ветка для функции A находится в разработке, ветвь для функции B может достигать стабильного состояния и закрываться и сливаться в туловище: в этой ситуации вам необходимо объединить изменения, внесенные ветвью B из ствола в ветвь A. Таким образом, хорошая привычка часто объединять ветки с туловищем, чтобы избежать проблемной ситуации с уникальным большим слиянием в конце жизни ветки с большим количеством конфликтов для отслеживания и разрешения.

Ответ 5

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

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

Это действительно агматическая система SCM, но Subversion, безусловно, может делать то, что необходимо.

Ответ 6

Филиал на проверен, работает.
Тег для выпуска версии.

Развивайтесь в багажнике.
Повторите.

Ответ 7

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

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

Что мы делаем в любом случае.

Ответ 8

На моем рабочем месте мы имеем следующую систему:

Стабильная ветка: здесь проверяется и проверяется стабильный код.
Отдела поддержки: это исправление ошибок в конюшне. Когда все проверено на работу, оно сливается до стабильной ветки.
Специфичные для проекта ветки: каждый подпроект в нашем продукте имеет одну ветвь. В заданное время в течение года все проекты, которые будут включены в выпуск этого года, объединяются в "Отделение выпуска". Это значит, что все слияния и прочее не делаются за неделю до выпуска.
Отключить ветку: здесь вся грязная разработка текущей версии происходит после слияния подпроектов. Слияние с стабильной после выпуска.

Ответ 9

С git я делаю ветку для каждого маленького изменения, и мне это нравится!

Ответ 10

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

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

Ответ 11

Когда расчетные часы превышают 8, используйте ветку.