Как бы вы планировали объединить несколько филиалов?

Question

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

Как бы вы выбрали ветку, чтобы начать слияние? Тот, у кого наименее страшные изменения? Тот, который самый страшный? Будете ли вы синхронизировать все ветви с транком после слияния одного из проектов в транк? Есть ли лучшая практика, которой нужно следовать при работе со многими ветвями, которые сильно разошлись?

Или я должен просто перестать беспокоиться и начать объединять их один за другим?

Answer 1

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

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

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

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

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

Answer 2

Полагаю, что для каждого подпроекта существует множество копий / zip-файлов, но разные «ветви» находятся в разных папках / компьютерах или различаются другими способами.

Тогда у вас есть два варианта: либо реконструируйте всю историю проекта, либо используйте текущие выпуски как отдельные базы слияния.

Восстановление истории

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

Первая проблема - определить, какие версии были скопированы друг с другом.Вы можете использовать временные метки файла, чтобы получить приблизительную оценку истории (ищите самый новый файл в каждой копии).После того, как у вас есть временная шкала, вы можете импортировать их в VCS и посмотреть, не появятся ли вспять патчи (что-то включено в rev4, исключено в rev5 и снова включено в rev6), что является индикатором того, что порядок неправильный.Также посмотрите, имеют ли изменения в основном смысл (изменения создают больше функций и меньше ошибок).Будьте готовы выполнить этот шаг более одного раза, пока не получите правильный заказ.Так что не используйте для этого финальную VCS, так как вы можете выбросить промежуточные шаги.Я также рекомендую иметь репозиторий на локальной машине, так как вам нужно делать много различий между несколькими версиями и не требовать задержек в сети (для таких задач я использую mercurial и tortoiseHg).

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

Поэтому, когда у вас есть что-то вроде этого:

Base --> A --> A'
         \
          \---> B --> B'
                \
                 \--> C

Вы можете начать с создания ствола с помощью Base, добавить туда изменения A и A '.Затем вы создаете ветвь B с A в качестве родителя и добавляете B '.Затем создайте ветвь C с B в качестве родителя.И так далее для каждой имеющейся у вас копии.

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

Только выпуски

Импорт базовой версии в VCS.Затем создайте ветку для каждого другого выпуска и поместите каждый выпуск в соответствующую ветку.После этого вы можете объединить все.

Answer 3

Один из возможных способов объединения этих различных кодовых баз состоит в том, чтобы использовать в SVN, например, ветви поставщиков .

Пример:

A - самая старая ветвь кода B- вторая самая старая ветвь кода C - и т. д. и т. д.

Импорт A Импорт поставщика B, исправление импорта C поставщика, исправление и т. д.

Answer 4

Перед тем, как начать слияние, я должен подумать, какой инструмент контроля версий использовать (вы не упомянули, что используете). Определенно избегайте VSS, CVS и Perforce. Subversion и Perforce в порядке, но если вы создадите много веток, то обнаружите, что есть административные издержки, чтобы все это работало. GIT, Accurev и PureCM - лучшие инструменты, которые я использовал для слияния. Если вам нравится распределенная модель, используйте GIT, в противном случае я бы выбрал PureCM, который очень дешев.

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