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

Question

В конечном итоге я запутался, когда дело доходит до Trunk/Branches и тегов. Ниже приведен мой запрос:

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

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

Итак, теперь я ищу какое-то решение, где эти разработчики могут работать отдельно, но по одному и тому же коду. Что-то вроде этого:

Разработчик А работает на Новый модуль A Developer B работает на Новый модуль B Developer C работает на багофиксы модуля C (который уже на живых, но несколько ошибок должно быть исправлено)

Таким образом, у разработчика A будет своя собственная копия на этом компьютере и будет передана репозиторию разработчика A. (Или филиал)

Та же логика применяется к разработчику B, но разработчик C будет работать с общей стабильной копией, которая будет где-то в тегах, и как только работа будет выполнена, она будет помечена и перенесена в Trunk для загружать на живой сервер.

После того, как разработчик A будет готов к работе, он будет загружать все свои файлы в Trunk для прямой загрузки. (Это должно объединить некоторые общие файлы в багажнике тоже). Такая же логика применяется к разработчику B.

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

Любые предложения приветствуются.

Благодаря TTR

Answer 1

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

Хорошо, но если вам нужны ветки, они легки. Существует несколько подходов к этому, но в основном все связаны с «главной» версией, где конечный код заканчивается. это может быть багажник, или некоторые люди предпочитают вносить изменения в магистраль, а затем объединить код для выпуска ветвей. Тем не менее, «багажник - мастер» - самая легкая концепция.

В svn, делая ветку легко - ее дешевая копия, поэтому ваша единственная проблема заключается в заполнении каталога с помощью вещей (я рекомендую удалить ветку, как только вы закончите с ней). SVN дает вам специальную ветку для этого типа работы - reintegration branch. Это особенность, поскольку SVN отслеживает, что с ним происходит, его спроектировали, что вы создаете ветку с туловища, работаете над ней, время от времени обновляя ее с изменениями, внесенными в trunk, а затем реинтегрируйте всю свою работу на этой ветке в туловище в одном последний удар. Затем вы можете начать все заново. Похоже, это может быть то, что вы хотите - обычно, хотя у вас не было бы ветви на разработчика, у вас была бы ветка для каждого пакета работ.

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

Поскольку svn делает дешевые копии, я бы, вероятно, рекомендовал разветвлять весь багажник для каждого разработчика. Я нахожу, что его легче запомнить, вместо того, чтобы разветвлять отдельные каталоги, и вы всегда сможете изменять общие или распространенные файлы, не беспокоясь о том, что если их совершить, они сломают другую ветку. (т. е. если вы подключаетесь к ветке/магистрали/модулю А, а затем находите, что вам нужно изменить/trunk/include/common_file, тогда общий файл не будет находиться в вашей ветке, когда вы разветвляете подмножество. Так что просто ветвь в корне, t стоит вам дополнительно)

Answer 2

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

Планирование - это переход от модели без транков к модели багажника.

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

/ 
filea.html 
fileb.html 
dira/ 
    filex 

слова предупреждения - не пытается в филиале корневой каталог под собой.

например:

svn cp//branchA 

Это приведет к директории, которая выглядит как:

/ 
filea.html 
fileb.html 
dira/ 
    filex 
branchA/ 
    ... 
branchB/ 
    ... 

Unpicking что часть корневой ветви и подотраслей становится довольно неразрешимыми довольно быстро.

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

svn cp//trunk 

Теперь вы можете сделать свои филиалы:

svn cp /trunk /branches/branchA 

Давать вам структуру, как:

/ 
trunk/ 
    filea.html 
    fileb.html 
    dira/ 
    filex 
branches/ 
    branchA/ 
    ... 

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

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

Когда ветка закончена, разработчики могут объединить изменения в туловище так же, как предлагает gbjbaanb.

Просто быстрый хедз-ап, удачи в этом.