7.13 Инструменты Git - Замена

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

Команда replace позволяет вам указать объект Git и сказать «каждый раз, когда встречается этот объект, заменяй его другим». В основном, это бывает полезно для замены одного коммита в вашей истории другим.

Например, допустим в вашем проекте огромная история изменений и вы хотите разбить ваш репозиторий на два — один с короткой историей для новых разработчиков, а другой с более длинной историей для людей, интересующихся анализом истории. Вы можете пересадить одну историю на другую, «заменяя» самый первый коммит в короткой истории последним коммитом в длинной истории. Это удобно, так как вам не придётся по-настоящему изменять каждый коммит в новой истории, как это вам бы потребовалось делать в случае обычного объединения историй (так как родословная коммитов влияет на SHA-1).

Давайте испробуем как это работает, возьмём существующий репозиторий и разобьём его на два — один со свежими правками, а другой с историческими, и затем посмотрим как мы можем воссоединить их с помощью операции replace, не изменяя при этом значений SHA-1 в свежем репозитории.

Мы будем использовать простой репозиторий с пятью коммитами:

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

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

Теперь мы можем отправить только что созданную ветвь history в ветку master нашего нового репозитория:

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

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

Для того, чтобы сделать это, нам нужно выбрать точку разбиения, которой для нас будет третий коммит, хеш которого 9c68fdc. Таким образом, наш базовый коммит будет основываться на этом дереве. Мы можем создать наш базовый коммит, используя команду commit-tree, которая просто берет дерево и возвращает SHA-1 объекта, представляющего новый сиротский коммит.

Хорошо. Теперь когда у нас есть базовый коммит, мы можем перебазировать нашу оставшуюся историю на этот коммит используя git rebase --onto. Значением аргумента --onto будет SHA-1 хеш коммита, который мы только что получили от команды commit-tree, а перебазируемой точкой будет третий коммит (родитель первого коммита, который мы хотим сохранить, 9c68fdc):

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

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

Теперь у этого пользователя его собственные свежие коммиты будут находиться в ветке master, а исторические коммиты в ветке project-history/master.

Для объединения этих веток вы можете просто вызывать git replace, указав коммит, который вы хотите заменить, и коммит, которым вы хотите заменить первый. Так мы хотим заменить «четвёртый» коммит в основной ветке «четвёртым» коммитом из ветки project-history/master:

Если теперь вы посмотрите историю ветки master, то должны увидеть нечто подобное:

Здорово, не правда ли? Не изменяя SHA-1 всех коммитов семейства, мы можем заменить один коммит в нашей истории совершенно другим коммитом и все обычные утилиты (bisect, blame и т. д.) будут работать как от них это и ожидается.

Интересно, что для четвёртого коммита SHA-1 хеш выводится равный 81a708d, хотя в действительности он содержит данные коммита c6e1e95, которым мы его заменили. Даже если вы выполните команду типа cat-file, она отобразит заменённые данные:

Помните, что настоящим родителем коммита 81a708d был наш вспомогательный базовый коммит (622e88e), а не 9c68fdce как это отмечено здесь.

Другое интересное замечание состоит в том, что информация о произведённой замене сохранена у нас в ссылках:

Следовательно можно легко поделиться заменами — для этого мы можем отправить их на наш сервер, а другие люди могут легко скачать их оттуда. Это не будет полезным в случае если вы используете replace для пересадки истории (так как в этом случае все люди будут скачивать обе истории, тогда зачем мы разделяли их?), но это может быть полезным в других ситуациях.