Ветви для каждой маленькой перемены?

Question

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

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

Спасибо!

Редактировать : Это действительно сложный вопрос, чтобы выбрать правильный ответ. Спасибо всем за ваши великолепные ответы.

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

Answer 7

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

:)

Answer 8

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

Answer 9

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

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

Answer 10

Если предполагаемые часы больше 8, используйте ветку.