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

Question

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

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

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

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

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

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

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

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

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

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

Спасибо ТТР

Answer 1

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

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

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

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

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

Answer 2

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

Одна вещь, которую следует спланировать, — это переход от модели без багажника к модели с багажником.

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

/
 filea.html
 fileb.html
 dira/
  filex

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

например:

svn cp / /branchA

В результате появится каталог, который выглядит так:

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

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

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

svn cp / /trunk

Сейчас вы можете сделать свои ветки:

svn cp /trunk /branches/branchA

Предоставляя вам структуру вроде:

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

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

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

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

Просто быстрое предупреждение, удачи в этом.