Merge branch 'multiplayer-es' of https://github.com/irtusb/gitmagic

[gitmagic/gitmagic.git] / ru / history.txt

== Уроки истории ==\r
\r
Вследствие распределенной природы Git, историю изменений можно легко редактировать. Однако, если вы вмешиваетесь в прошлое, будьте осторожны: изменяйте только ту часть истории, которой владеете вы и только вы. И также как государства бесконечно выясняют, кто же именно совершил и какие бесчинства, так и у вас будут проблемы с примирением после взаимодействия деревьев истории.\r
\r
Конечно, если вы также контролируете и все остальные деревья, то нет никаких проблем поскольку вы можете переписать их.\r
\r
Некоторые разработчики убеждены, что история должна быть неизменна со всеми огрехами и прочим.  \r
Другие считают, что деревья должны быть презентабельными, до того как они выпустят их в публичный доступ.\r
Git учитывает оба мнения. Также как клонирование, ветвление и слияние, переписывание истории - это просто еще одна возможность, которую дает вам Git. Разумное ее использование зависит только от вас.\r
\r
=== Оставаясь корректным ===\r
\r
Только что сделали коммит и уже хотите изменить запись в журнале? Запустите:\r
\r
 $ git commit --amend\r
\r
чтобы изменить последнее сообщение коммита. Осознали, что забыли добавить файл? Запустите *git add*, чтобы это сделать и выполните вышеуказанную команду.\r
\r
Захотелось добавить еще немного изменений в последний коммит? Так сделайте их и запустите:\r
\r
 $ git commit --amend -a\r
\r
=== ...И кое-что еще ===\r
\r
Давайте представим себе, что предыдущая проблема на самом деле в десять раз хуже. После длительной работы вы сделали ряд фиксаций, но вы не очень-то довольны тем, как они организованы и кое-какие записи в журнале (commit messages) надо бы слегка переформулировать. В этом случае запустите:\r
\r
 $ git rebase -i HEAD~10\r
\r
и записи в журнале от последних 10-ти фиксаций появятся в вашем любимом редаторе (задается переменной окружения  $EDITOR). Вот кусок примера:\r
\r
    pick 5c6eb73 Добавил ссылку repo.or.cz\r
    pick a311a64 Сменил порядок в "Работай как хочешь"\r
    pick 100834f Добавил цель для push в Makefile\r
\r
После чего:\r
\r
- Убираем коммиты, удаляя строки.\r
- Меняем порядок коммитов, меняя порядок строк.\r
- Заменяем "pick" на "edit", если требуется внести изменения в коммиты.\r
- Заменяем "pick" на "squash" для слияния коммита с предыдущим.\r
\r
Если вы отметили коммит для исправлений, запустите:\r
\r
 $ git commit --amend\r
\r
Если нет, запустите:\r
\r
 $ git rebase --continue\r
\r
В общем, делайте коммиты как можно раньше и как можно чаще - всегда потом сможете за собой подчистить при помощи rebase.\r
\r
=== Локальные изменения сохраняются ===\r
\r
Предположим, вы работаете над активным проектом. За какое-то время были проведены несколько коммитов, после чего синхронизируетесь с официальным деревом через слияние. Цикл повторяется несколько раз до тех пор, пока вы не готовы отправить (push) изменения в центральное дерево.\r
\r
Однако теперь история изменений в локальном клоне Git представляет собой кашу из ваших и официальных изменений. Вам бы хотелось видеть все  изменения непрерывной секцией даже после слияния с официальными.\r
\r
Это работа для команды *git rebase* в виде, описанном выше. Зачастую, имеет смысл использовать флаг *--onto*, чтобы не использовать интерактивный режим. \r
\r
Также стоит взглянуть на вывод команды *git help rebase* для получения подробных примеров использования этой замечательной команды. Вы можете объединять фиксации, вы можете даже перестраивать ветки.\r
\r
=== Переписывая историю ===\r
\r
Время от времени вам может понадобиться эквивалент "замазывания" людей на официальных фотографиях, только  для систем контроля версий, как бы стирая их из истории в духе сталинизма. Например, предположим, что мы уже собираемся выпустить релиз проекта, но он содержит файл, который не должен стать достоянием общественности по каким-то причинам. Может я сохранил номер своей кредитки в текстовый файл и случайно добавил этот файл к файлам проекта? Просто стирать файл бесполезно - из-за контроля версий всегда можно вытащить такую из старых версий, где этот документ еще есть. Нам надо удалить файл из всех версий когда-либо существовавших. Для этого:\r
\r
 $ git filter-branch --tree-filter 'rm top/secret/file' HEAD\r
\r
Стоит посмотреть вывод команды *git help filter-branch*, где обсуждается этот пример и даже предлагается  более быстрый метод решения. Короче говоря, *filter-branch* позволяет изменять существенные части истории при помощи одной-единственной команды.\r
\r
В результате директория +.git/refs/original+ будет описывать состояние дел до выполнения операции. Убедитесь, что команда filter-branch проделала все, что вы хотели, и, если хотите опять использовать команду, удалите эту директорию.\r
\r
И, наконец, замените клоны вашего проекта обновленной версией, если собираетесь в дальнейшем с ними иметь дело.\r
\r
=== Создавая Историю ===\r
\r
[[makinghistory]]\r
Хотите перевести проект под управление Git? Если сейчас он находится под управлением какой-либо из хорошо известных систем контроля версий, то весьма велики шансы на то, что кто-нибудь уже позаботился и написал необходимые скрипты для экспорта всей истории проекта в Git.\r
\r
А если все-таки нет? Тогда смотрите в сторону команды *git fast-import*, которая считывает текстовый ввод в специальном формате для создания истории Git "с нуля".\r
\r
Обычно скрипт, использующий эту команду - это наспех состряпанное нечто, \r
предназначенное для однократного использования, чтоб "перетащить" проект за один раз.\r
\r
В качестве примера, вставьте следующий листинг в какой-нибудь файл, типа '/tmp/history':\r
\r
----------------------------------\r
commit refs/heads/master\r
committer Alice <alice@example.com> Thu, 01 Jan 1970 00:00:00 +0000\r
data <<EOT\r
Стартовый коммит.\r
EOT\r
\r
M 100644 inline hello.c\r
data <<EOT \r
#include <stdio.h>\r
\r
int main() {\r
  printf("Hello, world!\n");\r
  return 0;\r
}\r
EOT\r
\r
commit refs/heads/master\r
committer Bob <bob@example.com> Tue, 14 Mar 2000 01:59:26 -0800\r
data <<EOT\r
Заменен printf() на write()\r
EOT\r
\r
M 100644 inline hello.c\r
data <<EOT \r
#include <unistd.h>\r
\r
int main() {\r
  write(1, "Hello, world!\n", 14);\r
  return 0;\r
}\r
EOT\r
\r
----------------------------------\r
\r
Затем создайте репозиторий Git из этого временного файла при помощи команд:\r
\r
$ mkdir project; cd project; git init\r
$ git fast-import < /tmp/history\r
\r
Вы можете извлечь (checkout) последнюю версию проекта при помощи команды:\r
\r
 $ git checkout master .\r
\r
Команда *git fast-export* преобразует любой репозиторий Git в формат, понимаемый командой *git fast-import*. То есть, ее выход может быть использован как образец для тех кто пишет скрипты-преобразователи и для того, чтобы переносить репозитории в формате, хоть как-то пригодном для чтения человеком. Естественно, при помощи этих команд можно пересылать репозитории текстовых файлов через каналы передачи текста.\r
\r
=== Когда же все пошло не так? ===\r
\r
Вы только что обнаружили, что кое-какой функционал вашей программы не работает, но вы совершенно отчетливо помните, что он работал всего несколько месяцев назад. Ну вот, блин! Откуда же взялась ошибка? Вы же это проверяли сразу как разработали.\r
\r
В любом случае, уже поздно сожалеть. Однако, если вам хватило ума фиксировать свои изменения часто, то Git сможет сильно помочь точно определить проблему.\r
\r
 $ git bisect start\r
 $ git bisect bad SHA1_OF_BAD_VERSION\r
 $ git bisect good SHA1_OF_GOOD_VERSION\r
\r
Git извлечет состояние ровно посередине. Проверьте работает ли то, что сломалось, и если все еще нет, то введите:\r
\r
 $ git bisect bad\r
\r
Если же работает, то замените "bad" на "good" в предыдущей команде. Git снова переместит вас в состояние посередине между "хорошей" и "плохой" ревизиями, при этом сузив круг подозреваемых ревизий вдвое.\r
\r
После нескольких итераций, этот бинарный поиск приведет вас к тому коммиту, на котором все и сломалось. После окончания выяснения, вернуть исходное состояние можно командой:\r
\r
 $ git bisect reset\r
\r
Вместо того, чтоб вручную тестировать каждое изменение - автоматизируйте этот процесс при помощи команды:\r
\r
 $ git bisect run COMMAND\r
\r
Git использует возвращаемое значение заданной команды, обычно "одноразового" скрипта, чтоб определить "хорошее" это было изменение или "плохое". Скрипт должен вернуть 0, если "хорошее", 125 если изменение надо пропустить и любое число от 1 до 127 если "плохое". Отрицательное возвращаемое значение прерывает бинарный поиск.\r
\r
На самом деле возможностей еще больше! На странице помощи объясняется как визуализировать бинарный поиск, проанализировать или даже воспроизвести журнал поиска, исключить изменения в которых точно все в порядке для ускорения поиска.\r
\r
=== Из-за кого все пошло наперекосяк? ===\r
\r
Как и многие другие системы конроля версий, Git поддерживает команду blame:\r
\r
 $ git blame FILE\r
\r
которая показывает кто и когда изменил каждую строку выбранного файла. В отличие же от многих других систем контроля версий эта операция происходит оффлайн, то есть данные берутся с локального диска.\r
\r
=== Личный опыт ===\r
\r
В централизованных системах контроля версий, изменения истории - достаточно сложная операция и для ее проведения необходимо привлечение администраторов. Процедуры клонирования, ветвления и слияния невозможно осуществить без сетевого соединения. Также обстоят дела и с такими базовыми операциями как просмотр журнала изменений или фиксация изменений. В некоторых системах сетевое соединение требуется даже для просмотра собственных изменений или открытия файла для редактирования.\r
\r
Централизованные системы исключают возможность работать оффлайн и требуют более дорогой сетевой инфраструктуры, особенно с увеличением количества разработчиков. Еще более важно, из-за того все операции происходят медленнее, пользователи избегают пользоваться "продвинутыми" командами до тех пор пока не "припечет как следует". В особо "запущенных" случаях это касается и большинства базовых команд тоже. Продуктивность страдает из-за остановок в работе, когда пользователи вынуждены запускать "долгоиграющие"  команды.\r
\r
Я испытал этот феномен на себе. Git был моей первой системой контроля версий. Я быстро привык нему и стал относится к его возможностям как к должному. Я предположил, что и другие системы похожи на него: выбор системы контроля версий не должен отличаться от выбора текстового редактора или браузера.\r
\r
Когда, немного позже, я был вынужден использовать централизованную систему контроля версий, я был шокирован. При использовании Git, мое, зачастую капризное, интернет-соединение не имело большого значения, но теперь разработка стала невыносимой когда от него потребовалась надежность как у жесткого диска. Плюс к этому, я обнаружил, что стал избегать использовать некоторые команды из-за получающихся в результате их выполнения задержек, а без них оказалось невозможным следовать моему стилю разработки.\r
\r
Когда мне было нужно запустить "медленную" команду, нарушение хода цепочки моих мыслей оказывало несоизмеримый ущерб разработке. Ожидая окончания связи с сервером, я должен был заниматься чем-то другим, чтоб скоротать время, например, чтением почты или написанием документации. Через некоторое время я возвращался к первоначальной задаче, но приходилось тратить уйму времени, чтоб вспомнить на чем же я остановился и что хотел делать дальше. Все-таки люди не очень приспособлены для многозадачности.\r
\r
Есть еще один интересный эффект, так называемая, трагедия общин: предвидя будущую загрузку сети, некоторые люди начинают использовать более "широкие" каналы чем им реально требуются для текущих операций в попытке предотвратить будущие задержки. Суммарная активность увеличивает загрузку сети, поощряя людей задействовать еще более высокоскоростные каналы в следующий раз, чтоб избежать еще больших задержек.\r