Управление объединением нескольких версий репо в базовую ветку c - лучший практический процесс?

Question

Мне было поручено «взять на себя ответственность» за один из наших плагинов, который в течение нескольких лет расходился в разные версии для разных клиентов, так что у нас есть около 5 разных версий «prod» некоторые с теми же добавленными функциями, некоторые с отсутствующими функциями.

По сути, мне нужно создать одну базовую ветку c, объединяющую все различные изменения и следящую за тем, чтобы ничего не пропущено. Затем мы хотим начать использовать ветку generi c для всех клиентов.

Как лучше всего подойти к этому?

• Я мог бы начать с «последней» ветки (ie. Тот, в который было внесено наибольшее количество изменений) и создайте из него новую ветвь, а затем (например, base-branch) попробуйте выполнить ребазинг в других ветвях 'prod'.
• Или я мог бы начните с ответвления master (которое сейчас немного позади) и попробуйте внести в него все.
• Или есть лучший способ сделать это?

I ' Мы не делали ничего подобного с большим проектом и множеством разных версий, поэтому я не уверен, что лучшие практики обеспечат, во-первых, чтобы я не пропустил ни одного коммита, и в конечном итоге отсутствовали функции, а во-вторых, просто общий рабочий процесс. это сделает это максимально безболезненным.

Спасибо.

Answer 1

git немного напоминает машину времени.

Теперь вы находитесь в затруднительном положении, потому что у вас есть пять уникальных версий программного обеспечения для согласования в единый продукт , Оглядываясь назад, эта проблема даже не существовала бы, если бы ветви были объединены и преобразованы в общий продукт по мере добавления функций. Возможно, у вас есть что-то похожее на это дерево:

           C--D
          /
R--*--*--*--*--*--E
    \  \
     A  B

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

Что было бы удивительно, если бы мы могли go вернуться в то время, когда у нас был первый форк (A, * 1014) *) и объединить их в base-branch. Вы можете сделать это с помощью команды git checkout;

$ git checkout -b base-branch R

Дает;

R--*--*
    \  \
     A  B

Это кажется более управляемым; git merge A - быстрая перемотка вперед, тогда git merge B потребует некоторого рефакторинга, но у нас будет;

     *--B   
    /    \
R--*---a--b <- (base-branch)
    \ /
     A

Это именно то, чего вы хотели бы добиться. Первый набор функций A будет объединен с base-branch, за которым следует набор функций B, для которого потребуется весь необходимый рефакторинг.

Представьте, что вы снова вернулись во времени, но на этом графике мы получил base-branch и мы только что выпустили C, D и E. Мы хотим эти наборы функций в базовой ветви. Вы можете продолжить с git merge C, рефакторинг, git merge D, рефакторинг, так как он больше не может быть перемоткой вперед. Наконец, git merge E, рефакторинг, и все готово.

         *--*--E
        /       \
       *--C--D   \
      /    \  \   \
     *--B   \  \   \
    /    \   \  \   \
R--*---a--b---c--d---e <- (base-branch)
    \ /
     A

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

Это будет непросто, и вы будете проводить больше рефакторинга, чем gitting . Поместите себя в мышление авторов в то время и объедините их так, как если бы они были немного приукрашены.

Answer 2

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

Более простой подход - это взять вашу ветку latest, и

• создать новую ветвь «рефакторинга»
• объединить (вместо перебазирования) другую ветвь в эту ветку рефакторинга, следуя Адам ответ
• сортировка того, что задано c для среды, из того, что генерируется c
• добавление переменных-заполнителей и файлов значений везде, где указана среда c data
• использовать драйвер фильтра содержимого , чтобы иметь возможность извлекать один и тот же код для другой среды.

^{(изображение из "Настройка Git - Git Атрибуты" из " Pro Git book ")}