Глава 6. Уроки истории

Только что сделали коммит и поняли, что должны были ввести другое описание? Запустите

$ git commit --amend

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

Захотелось добавить еще немного изменений в последний коммит? Так сделайте их и запустите

$ git commit --amend -a

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

$ git rebase -i HEAD~10

и последние десять коммитов появятся в вашем любимом редакторе (задается переменной окружения $EDITOR). Например:

pick 5c6eb73 Добавил ссылку repo.or.cz
pick a311a64 Переставил аналогии в «Работай как хочешь»
pick 100834f Добавил цель для push в Makefile

Теперь вы можете:

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

$ git commit --amend

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

$ git rebase --continue

Одним словом, делайте коммиты как можно раньше и как можно чаще — вы всегда сможете навести порядок при помощи rebase.

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

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

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

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

Время от времени вам может понадобиться в системе управления версиями аналог «замазывания» людей на официальных фотографиях, как бы стирающего их из истории в духе сталинизма. Например, предположим, что мы уже собираемся выпустить релиз проекта, но он содержит файл, который не должен стать достоянием общественности по каким-то причинам. Возможно, я сохранил номер своей кредитки в текстовый файл и случайно добавил его в проект. Удалить файл недостаточно: он может быть доступен из старых коммитов. Нам надо удалить файл из всех ревизий:

$ git filter-branch --tree-filter 'rm совершенно/секретный/файл' HEAD

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

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

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

Хотите перевести проект под управление 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

commit 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 --date-format=rfc2822 < /tmp/history

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

$ git checkout master .

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

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

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

$ git bisect start
$ git bisect bad HEAD
$ git bisect good 1b6d

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

$ git bisect bad

Если же работает, то замените «bad» на «good». Git снова переместит вас в состояние посередине между «хорошей» и «плохой» ревизиями, сужая круг поиска. После нескольких итераций, этот двоичный поиск приведет вас к тому коммиту, на котором возникла проблема. После окончания расследования, вернитесь в исходное состояние командой

$ git bisect reset

Вместо ручного тестирования каждого изменения автоматизируйте поиск, запустив

$ git bisect run my_script

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

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

Как и во многих других системах управления версиями, в Git есть команда blame (ответственность, прим. пер.):

$ git blame bug.c

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

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

Централизованные системы исключают возможность работы без сети и требуют более дорогой сетевой инфраструктуры, особенно с увеличением количества разработчиков. Что важнее, все операции происходят медленнее, обычно до такой степени, что пользователи избегают пользоваться «продвинутыми» командами без крайней необходимости. В радикальных случаях это касается даже большинства базовых команд. Когда пользователи вынуждены запускать медленные команды, производительность страдает из-за прерываний рабочего процесса.

Я испытал этот феномен на себе. Git был моей первой системой управления версиями. Я быстро привык к нему и стал относится к его возможностям как к должному. Я предполагал, что и другие системы похожи на него: выбор системы управления версиями не должен отличаться от выбора текстового редактора или браузера.

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

Когда мне было нужно запустить медленную команду, нарушение хода моих мыслей оказывало несоизмеримый ущерб разработке. Ожидая окончания связи с сервером, я вынужден был заниматься чем-то другим, чтобы скоротать время; например, проверкой почты или написанием документации. К тому времени, как я возвращался к первоначальной задаче, выполнение команды было давно закончено, но мне приходилось тратить уйму времени, чтоб вспомнить, что именно я делал. Люди не очень приспособлены для переключения между задачами.

Кроме того, есть интересный эффект «трагедии общественных ресурсов»: предвидя будущую перегруженность сети, некоторые люди в попытке предотвратить грядущие задержки начинают использовать более широкие каналы, чем им реально требуется для текущих задач. Суммарная активность увеличивает загрузку сети, поощряя людей задействовать всё более высокоскоростные каналы для предотвращения еще больших задержек.