Сортировка Git mess

Question

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

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

Как я могу принести 3-х различных источников вместе, так что я могу:

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

Answer 1

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

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

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

Дополнительных хорошо бы иметь ссылки являются: Git Magic, Git Ready и SourceMage Git Guide

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

Что касается поддержки настроек, нам повезло:

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

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

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

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

Answer 2

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

git rebase

команд и когда вещи получили зажмурила:

git reflog

следует

git reset --hard HEAD@{ref}