Git Magic. Уроки истории

== Уроки истории ==

Вследствие распределенной природы Git, историю изменений можно легко редактировать. Однако, если вы вмешиваетесь в прошлое, будьте осторожны: изменяйте только ту часть истории, которой владеете вы и только вы. И также как государства бесконечно выясняют, кто же именно совершил и какие бесчинства, так и у вас будут проблемы с примирением после взаимодействия деревьев истории.

Конечно, если вы также контролируете и все остальные деревья, то нет никаких проблем

поскольку вы можете переписать их.

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

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

Git учитывает оба мнения. Также как клонирование, ветвление и слияние, переписывание истории - это просто еще одна возможность, которую дает вам Git. Разумное ее использование зависит только от вас.

=== Оставаясь корректным ===

Только что сделали коммит и уже хотите изменить запись в журнале? Запустите:

$ git commit --amend

чтобы изменить последнее сообщение коммита. Осознали, что забыли добавить файл? Запустите *git add*, чтобы это сделать и выполните вышеуказанную команду.

Захотелось добавить еще немного изменений в последнюю фиксацию (commit)? Так сделайте их и запустите:

$ git commit --amend -a

=== ...И кое-что еще ===

Давайте представим себе, что предыдущая проблема на самом деле в десять раз хуже. После длительной работы вы сделали ряд фиксаций, но вы не очень-то довольны тем, как они организованы и кое-какие записи в журнале (commit messages) надо бы слегка переформулировать. В этом случае запустите:

$ git rebase -i HEAD~10

и записи в журнале от последних 10-ти фиксаций появятся в вашем любимом редаторе (задается переменной окружения $EDITOR). Вот кусок примера:

pick 5c6eb73 Добавил ссылку repo.or.cz

pick a311a64 Сменил порядок в "Работай как хочешь"

pick 100834f Добавил цель для push в Makefile

После чего:

- Убираем коммиты, удаляя строки.

- Меняем порядок коммитов, меняя порядок строк.

- Заменяем "pick" на "edit", если требуется внести изменения в коммиты.

- Заменяем "pick" на "squash" для слияния коммита с предыдущим.

Если вы отметили коммит для исправлений, запустите:

$ git commit --amend

Если нет, запустите:

$ git rebase --continue

В общем, коммитте как можно раньше и как можно чаще - всегда потом сможете за собой подчистить при помощи rebase.

=== Локальные изменения сохраняются ===

Предположим, вы работаете над активным проектом. За какое-то время были проведены несколько коммитов, после чего синхронизируетесь с официальным деревом через слияние. Цикл повторяется несколько раз до тех пор, пока вы не готовы отправить (push) изменения в центральное дерево.

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

Это работа для команды *git rebase* в виде, описанном выше. Зачастую, имеет смысл использовать флаг *--onto*, чтобы не использовать интерактивный режим.

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

=== Переписывая историю ===

Время от времени вам может понадобиться эквивалент (для систем контроля версий) "замазывания" людей на официальных фотографиях, как бы стирая их из истории в духе сталинизма. Предположим, например, что мы уже собираемся выпустить релиз проекта, но он содержит файл, который не должен стать достоянием общественности по каким-то причинам. Может, я сохранил номер своей кредитки в текстовый файл и случайно добавил этот файл к файлам проекта? Просто стирать файл бесполезно - из-за контроля версий его всегда можно вытащить из старых версий, где этот документ еще есть. Нам надо удалить файл из всех когда-либо существовавших версий. Для этого:

$ git filter-branch --tree-filter 'rm top/secret/file' HEAD

Стоит посмотреть вывод команды *git help filter-branch*, где обсуждается этот пример и даже предлагается более быстрый метод решения. Короче говоря, *filter-branch* позволяет изменять существенные части истории при помощи одной-единственной команды.

В результате директория +.git/refs/original+ будет описывать состояние дел до выполнения операции. Убедитесь, что команда filter-branch проделала все, что вы хотели, и, если хотите опять использовать команду, удалите эту директорию.

И, наконец, замените клоны вашего проекта обновленной версией, если собираетесь иметь с ними дело в дальнейшем.

=== Создавая Историю ===

[[makinghistory]]

Хотите перевести проект под управление Git? Если сейчас он находится под управлением какой-либо из хорошо известных систем контроля версий, то весьма велики шансы на то, что кто-нибудь уже позаботился и написал необходимые скрипты для экспорта всей истории проекта в Git.

А если все-таки нет? Тогда смотрите в сторону команды *git fast-import*, которая считывает текстовый ввод в специальном формате для создания истории Git "с нуля".

Обычно скрипт, использующий эту команду, - это наспех состряпанное нечто,

предназначенное для однократного использования, чтобы "перетащить" проект за

один раз.

В качестве примера, вставьте следующий листинг в какой-нибудь файл, типа '/tmp/history':

----------------------------------

commit refs/heads/master

committer Alice <alice@example.com> Thu, 01 Jan 1970 00:00:00 +0000

data <<EOT

Стартовый коммит.

EOT

M 100644 inline hello.c

data <<EOT

#include <stdio.h>

int main() {

printf("Hello, world!\n");

return 0;

}

EOT

коммит refs/heads/master

committer Bob <bob@example.com> Tue, 14 Mar 2000 01:59:26 -0800

data <<EOT

Заменен printf() на write()

EOT

M 100644 inline hello.c

data <<EOT

#include <unistd.h>

int main() {

write(1, "Hello, world!\n", 14);

return 0;

}

EOT

----------------------------------

Затем создайте репозиторий Git из этого временного файла при помощи команд:

$ mkdir project; cd project; git init

$ git fast-import < /tmp/history

Вы можете извлечь (checkout) последнюю версию проекта при помощи команды:

$ git checkout master .

Команда *git fast-export* преобразует любой репозиторий Git в формат, понимаемый командой *git fast-import*. То есть ее выход может быть использован как образец для тех, кто пишет скрипты-преобразователи, и для того, чтобы переносить репозитории в формате, хоть как-то пригодном для чтения человеком. Естественно, при помощи этих команд можно пересылать репозитории текстовых файлов через каналы передачи текста.

=== Когда же все пошло не так? ===

Вы только что обнаружили, что кое-какой функционал вашей программы не работает, но вы совершенно отчетливо помните, что он работал всего несколько месяцев назад. Ну вот, блин! Откуда же взялась ошибка? Вы же это проверяли сразу как разработали.

В любом случае, уже поздно сожалеть. Однако, если вам хватило ума фиксировать свои изменения часто, то Git сможет сильно помочь точно определить проблему.

$ git bisect start

$ git bisect bad SHA1_OF_BAD_VERSION

$ git bisect good SHA1_OF_GOOD_VERSION

Git извлечет состояние ровно посередине. Проверьте, работает ли то, что сломалось, и если все еще нет, то введите:

$ git bisect bad

Если же работает, то замените "bad" на "good" в предыдущей команде. Git снова переместит вас в состояние посередине между "хорошей" и "плохой" ревизиями, при этом сузив круг подозреваемых ревизий вдвое.

После нескольких итераций, этот бинарный поиск приведет вас к тому коммиту, на котором все и сломалось. После окончания выяснения, вернуть исходное состояние можно командой:

$ git bisect reset

Вместо того, чтоб вручную тестировать каждое изменение - автоматизируйте этот процесс при помощи команды:

$ git bisect run COMMAND

Git использует возвращаемое значение заданной команды, обычно "одноразового" скрипта, чтоб определить "хорошее" это было изменение или "плохое". Скрипт должен вернуть 0, если "хорошее", 125 если изменение надо пропустить и любое число от 1 до 127 если "плохое". Отрицательное возвращаемое значение прерывает бинарный поиск.

На самом деле возможностей еще больше! На странице помощи (help page) объясняется как визуализировать бинарный поиск, проанализировать или даже воспроизвести журнал поиска, исключить изменения в которых точно все в порядке для ускорения поиска.

=== Из-за кого все пошло наперекосяк? ===

Как и многие другие системы конроля версий, Git поддерживает команду blame: