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

Question

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

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

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

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

Answer 1

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

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

Скорее всего, действия, которые вам необходимо предпринять, описаны в ссылках, предоставленных Git Howto Index . Хороший шпаргалка всегда приятно иметь под рукой. Кроме того, я подозреваю, что продолжение поста Эрика Синкса « DVCS и DAGs, часть 1 » будет содержать что-то полезное (не было, но, тем не менее, было интересно читать).

Дополнительные полезные ссылки: Git Magic , Git Ready и SourceMage Git Guide

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

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

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

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

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

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

Answer 2

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

git rebase

команды и когда все облажалось:

git reflog

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

git reset --hard HEAD@{ref}