Определение рабочего процесса для разработки на основе возможностей с использованием SVN

Question

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

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

Описанный выше метод хорош, так как у меня есть ветка на сервере clearcase. Как решить эту проблему с отключенными средствами управления версиями, такими как SVN и GIT? Требуется ли настроить отдельный сервер и поделиться с разработчиками для достижения этой цели?

Answer 1

Вы захотите использовать концепцию ветвления в Subversion или Git - нет необходимости в каком-либо отдельном сервере. Две системы работают совершенно по-разному:

• Subversion: , вы создаете ветку foo, копируя с /trunk на /branches/foo. В Subversion нет понятия «ветвь», но, поскольку вы можете объединять папки, вы можете эмулировать ветки таким образом. Это описано в книге SVN .

• Git: вы создаете реальную ветвь с git branch foo. Филиалы - это первоклассные граждане в Git и неотъемлемая часть того, как вы используете систему. Любой хороший учебник Git будет касаться веток, пожалуйста, смотрите мою ссылку на книгу Git.

Answer 2

Вслед за фоном и Мартином

• SVN на самом деле не полностью «отключен» VCS (как Git или любой другой DVCS ), потому что на этапе фиксации-обновления рабочая копия разработчика (снимок некоторого дерева из центрального репо в какой-то момент ) взаимодействовать с центральным сервером, и локальные изменения не могут быть сохранены в gepo до объединения «других изменений» (если они появились до попытки фиксации)
• «Разветвление на элемент», при котором возможно более одного разработчика (в SVN-мире), даже в двух немного разных формах:
  1. Прямая аналогия (и плохой рабочий процесс ) с CC - каждый разработчик может иметь собственную персональную ветвь, но в процессе разработки они периодически объединяют другие ветви с собственными (и с магистрали в ветку), все законченные ветви объединены в багажник
  2. Одна ветвь для любого количества разработчиков (широко распространенный способ), svn up является обязательным условием перед любыми изменениями кода, чтобы получить новые зафиксированные изменения от других в локальной рабочей копии (без этого изменения не могут быть зафиксированы для репозиторий, обновление + слияние поверх собственных изменений может нарушить код)

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

Answer 3

Для Git вам не нужно устанавливать отдельную функцию.
Вы можете создать столько веток объектов, сколько необходимо, и объединить их без ускоренной перемотки вперед для достижения той же цели.

См. " Почему git использует ускоренное слияние по умолчанию? " для получения дополнительной информации.

SVN может предложить такой же тип рабочего процесса, за исключением того, что для слияния с основной веткой может потребоваться «merge --reintegrate», немного отличающийся от классического слияния (и с несколькими ожидающими ошибками , такими как с SVN 1.7).

Разница между ними касается публикации ветвей:

• SVN объявит ветку в своем центральном репо, видимую для всех
• Пользователи Git объявляют свои ветви в своем локальном репо, могут объединяться с основной общей веткой, но выбирают то, что они возвращают к центральному репо: только обновлять общую ветку с новыми коммитами и / или также их особенность ветвь.

См. " этот вопрос ", чтобы узнать больше об ортогональном аспекте, представленном DVCS (например, Git), по сравнению с централизованной VCS, такой как SVN.