Блог

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

Как бы вы выбрали ветку для начала слияния? Ту, в которой меньше всего страшных изменений? Та, которая самая страшная? Вы бы синхронизировали все ветви с магистралью после объединения одного из проектов в магистраль? Существует ли наилучшая практика, которой следует следовать при работе со многими ветвями, которые сильно разошлись?

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

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

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

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

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

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

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

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

Реконструкция истории

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

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

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

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

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

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

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

Выпускаются только

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

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

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

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

Пример:

A — самая старая ветвь кода B — вторая по старшинству ветвь кода C — и т.д. и т.п.

Импортируйте импорт поставщика B, исправьте импорт поставщика C, исправьте и т. Д