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

Question

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

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

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

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

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

Итак, Разработчик А будет иметь свою собственную копию на этом компьютере и перейдет в хранилище Разработчика А.(Или ветвь)

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

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

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

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

Спасибо TTR

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/
   ...

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

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

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

Просто быстренько, удачи.