Browse files

made some translations in uk/history.txt

  • Loading branch information...
1 parent 50339a9 commit 8e3ab5165cf596f067c778a7cc695ff733425333 @VBoden committed Sep 22, 2012
Showing with 192 additions and 0 deletions.
  1. +192 −0 uk/history.txt
View
192 uk/history.txt
@@ -0,0 +1,192 @@
+== Уроки історії ==
+
+Внаслідок розподіленої природи Git, історію змін можна легко редагувати. Однак, якщо ви втручаєтеся в минуле, будьте обережні: змінюйте тільки ту частину історії, якою володієте ви і тільки ви. Інакше, як народи вічно з'ясовують, хто ж саме зробив і які безчинства, так і у вас будуть проблеми з примиренням при спробі поєднати різні дерева історії.
+
+Деякі розробники переконані, що історія повинна бути незмінна з усіма огріхами та іншим. Інші вважають, що дерева потрібно робити презентабельними перед випуском їх у публічний доступ.
+Git враховує обидві думки. Переписування історії, як і клонування, розгалуження і злиття, – лише ще одна можливість, яку дає вам Git. Розумне її використання залежить тільки від вас.
+
+=== Залишаючись коректним ===
+
+Тільки що зробили комміт і зрозуміли, що повинні були ввести інший опис? запустіть
+
+ $ 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
+
+Старі комміти передують новим коммітам у цьому списку, на відміну від команди `log`.
+Тут, 5c6eb73 є найстарішим коммітом і 100834f є найновішим. Тепер ви можете:
+
+- Видаляти комміти шляхом видалення рядків. Подібно команді revert, але видаляє запис: це буде так ніби комміта ніколи не існувало.
+- Міняти порядок коммітов, переставляючи рядки.
+- Заміняти `pick` на:
+ * `edit` щоб позначати комміт для внесення правок;
+ * `reword` щоб змінити опис у журналі;
+ * `squash` щоб злити комміт з попереднім;
+ * `fixup` щоб злити комміт з попереднім і відкинути його опис.
+
+Наприклад, ми могли б замінила другий `pick` з `squash`:
+
+ pick 5c6eb73 Додав посилання repo.or.cz
+ squash a311a64 Переставив аналогії в „Працюй як хочеш“
+ pick 100834f Додав ціль для push в Makefile
+
+After we save and quit, Git merges a311a64 into 5c6eb73. Thus *squash* merges
+into the next commit up: think ``squash up''.
+
+Git then combines their log messages and presents them for editing. The
+command *fixup* skips this step; the squashed log message is simply discarded.
+
+If you marked a commit with *edit*, Git returns you to the past, to the oldest
+such commit. You can amend the old commit as described in the previous section,
+and even create new commits that belong here. Once you're pleased with the
+``retcon'', go forward in time by running:
+
+ $ git rebase --continue
+
+Git replays commits until the next *edit*, or to the present if none remain.
+
+You can also abandon the rebase with:
+
+ $ git rebase --abort
+
+Одним словом, робіть комміти якомога раніше і якомога частіше - ви завжди зможете навести порядок за допомогою 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 сделала то, что вы хотели, и если хотите опять использовать эту команду, удалите этот каталог.
+
+И, наконец, замените клоны вашего проекта исправленной версией, если собираетесь в дальнейшем с ними взаимодействовать.
+
+=== Создавая Историю ===
+
+[[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
+
+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, но делает разработку невыносимой, когда от него требуют надежности как у жесткого диска. Вдобавок я обнаружил, что стал избегать некоторых команд из-за задержек в их выполнении, что помешало мне следовать предпочтительному рабочему процессу.
+
+Когда мне было нужно запустить медленную команду, нарушение хода моих мыслей оказывало несоизмеримый ущерб разработке. Ожидая окончания связи с сервером, я вынужден был заниматься чем-то другим, чтобы скоротать время; например, проверкой почты или написанием документации. К тому времени, как я возвращался к первоначальной задаче, выполнение команды было давно закончено, но мне приходилось тратить уйму времени, чтоб вспомнить, что именно я делал. Люди не очень приспособлены для переключения между задачами.
+
+Кроме того, есть интересный эффект «трагедии общественных ресурсов»: предвидя будущую перегруженность сети, некоторые люди в попытке предотвратить грядущие задержки начинают использовать более широкие каналы, чем им реально требуется для текущих задач. Суммарная активность увеличивает загрузку сети, поощряя людей задействовать всё более высокоскоростные каналы для предотвращения еще больших задержек.

0 comments on commit 8e3ab51

Please sign in to comment.