Разбираемся с беспорядком в Git

Question

Я только что унаследовал проект, который поддерживался с помощью Git.В какой-то момент код был развернут на 3 отдельных системах, и каждая система имела собственный децентрализованный репозиторий Git.

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

Как мне объединить три разных источника, чтобы я мог:

1. найти общую базу для работы;
2. узнать, какие изменения являются исправлениями ошибок, которые следует применить во всех трех системах;и
3. поддерживать три системы разумным образом, чтобы существовала только одна общая ветвь, и разделять настройки, необходимые для трех разных систем?

Answer 1

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

Хороший инструмент визуализации, такой как git-age, Gitnub, gitx, хихикать может творить чудеса, но ваша задача, вероятно, будет довольно утомительной, если вы не сможете найти точки ветвления.Если ко всем веткам применены аналогичные патчи, вы можете использовать (интерактивно) перебазировать изменить порядок ваших коммитов так, чтобы они находились в одном и том же порядке.Затем вы можете начать «сжимать» свои ветки, перемещая точку ветвления вверх, помещая коммиты в мастер.Хорошее описание того, как изменить порядок коммитов с помощью rebase, можно найти. здесь.

Скорее всего, действия, которые вам необходимо предпринять, описаны в ссылках, предоставленных Указатель инструкций по Git.Хороший шпаргалка всегда приятно иметь под рукой.Кроме того, я подозреваю, что это продолжение поста Эрика Синкса "DVCS и DAG, часть 1" будет содержать что-то полезное (это не так, но, тем не менее, было интересно прочитать).

Дополнительные полезные ссылки: Git-магия, Git готов и Руководство по Git SourceMage

Я надеюсь, что во всех репозиториях есть хорошие сообщения о коммитах, которые сообщают вам цель каждого патча, это или проверка кода :)

Что касается сохранения настроек, нам повезло со следующим:

Мы начали с отделения (или сохранения отдельно) индивидуального кода от общего кода.Затем мы попробовали два подхода;оба работали нормально:

1. Все развертывания имели собственные репозитории, в которых хранились настройки.
2. Все развертывания получили собственную ветку в репозитории «кастомизации».

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

И да, мы пытаемся безжалостно провести рефакторинг всякий раз, когда замечаем смещение разделения ядра и настройки :)

Answer 2

ХОРОШО.После немалых усилий мне удалось это сделать.Для любого другого, решающего подобную задачу, это потребует множества действий:

git rebase

команды и когда что-то пошло не так:

git reflog

с последующим

git reset --hard HEAD@{ref}