Russian translation updated

ru/branch.txt

@@ -75,30 +75,23 @@
 После исправления ошибки сделайте
 
  $ git commit -a -m "Ошибка исправлена"
- $ git push # в центральное хранилище
  $ git checkout master
 
 и вернитесь к работе над вашими исходными задачами.
 
-Вы можете даже «влить» только что сделанное вами исправление ошибки, набрав
+Вы можете даже «влить» только что сделанное исправление ошибки:
 
  $ git merge fixes
 
-или
-
- $ git pull
-
-поскольку вы уже отправили это исправление в основное хранилище.
-
 === Слияния ===
 
 В некоторых системах управления версиями создавать ветки легко, а вот сливать их воедино трудно. В Git слияние столь тривиально, что вы можете его не заметить.
 
-Действительно, хотя мы только познакомились с *git merge*, мы сталкивались со слияниями уже давно. Команда *pull* по сути получает коммиты, а затем сливает их с вашей текущей веткой. Если у вас нет локальных изменений, слияние произойдёт само собой, как вырожденный случай вроде получения последней версии в централизованной системе управления версиями. Если же у вас есть локальные изменения, Git автоматически произведет слияние и сообщит о любых конфликтах.
+На самом деле мы сталкивались со слияниями уже давно. Команда *pull* по сути получает коммиты, а затем сливает их с вашей текущей веткой. Если у вас нет локальных изменений, слияние произойдёт само собой, как вырожденный случай вроде получения последней версии в централизованной системе управления версиями. Если же у вас есть локальные изменения, Git автоматически произведет слияние и сообщит о любых конфликтах.
 
 Обычно у коммита есть один «родитель», а именно предыдущий коммит. Слияние веток приводит к коммиту как минимум с двумя родителями. Отсюда возникает вопрос: к какому коммиту на самом деле отсылает HEAD~10? Коммит может иметь несколько родителей, так за которым из них следовать далее?
 
-Оказывается, такая запись всегда выбирает первого родителя. Это хороший выбор, потому что коммиты в текущей ветке становятся первыми родителями во время слияния. Часто вас интересуют только изменения, сделанные вами в текущей ветке, а не те, которые влились из других веток.
+Оказывается, такая запись всегда выбирает первого родителя. Это хороший выбор, потому что текущая ветка становятся первым родителем во время слияния. Часто вас интересуют только изменения, сделанные вами в текущей ветке, а не те, которые влились из других веток.
 
 Вы можете обращаться к конкретному родителю с помощью символа «^». Например, чтобы показать запись в журнале от второго родителя, наберите
 
@@ -127,34 +120,35 @@
 Затем работайте над второй частью, попутно внося коммиты ваших изменений. Человеку свойственно ошибаться, и часто вы хотите вернуться и поправить что-то в первой части. Если вы везучи или очень искусны, можете пропустить эти строки.
 
  $ git checkout master  # Возвращаемся к первой части.
- $ edit files           # Исправляем её.
+ $ вносим_исправления
+ $ git commit -a        # Фиксируем изменения
  $ git checkout part2   # Возвращаемся ко второй части.
  $ git merge master     # Вливаем сделанные исправления.
 
 В конечном счёте, первая часть утверждена:
 
  $ git checkout master  # Возвращаемся к первой части.
- $ некая_команда        # Некая команда, которую вам нужно выполнить,
-                        # когда текущий рабочий каталог формально готов.
+ $ отправка файлов	# Выпускаем в мир!
  $ git merge part2      # Вливаем вторую часть.
- $ git branch -d part2
+ $ git branch -d part2  # Удаляем ветку part2.
 
 Теперь вы снова в ветке master, а вторая часть — в вашем рабочем каталоге.
 
 Этот приём легко расширить на любое количество частей. Столь же легко сменить ветку задним числом. Предположим, вы слишком поздно обнаружили, что должны были создать ветку семь коммитов назад. Тогда введите:
 
- $ git branch -m master part2
- $  # Переименовываем ветку master в part2.
- $ git checkout HEAD~7 -b master
+ $ git branch -m master part2 # Переименовываем ветку master в part2.
+ $ git branch master HEAD~7   # Создаём новую ветку master семью коммитами выше.
+
+Теперь ветка master содержит только первую часть, а ветка part2 — всё остальное. В последней мы и находимся. Мы создали ветку master, не переключаясь на неё, потому что хотим продолжить работу над part2. Это непривычно: до сих пор мы переключались на ветки сразу же после их создания, вот так:
 
-Теперь ветка master содержит только первую часть, а ветка part2 — всё остальное.
+ $ git checkout HEAD~7 -b master  # Создаём ветку и переключаемся на неё.
 
 === Изменяем состав смеси ===
 
 Предположим, вам нравится работать над всеми аспектами проекта в одной и той же ветке. Вы хотите закрыть свой рабочий процесс от других, чтобы все видели ваши коммиты только после того, как они будут хорошо оформлены. Создайте пару веток:
 
- $ git checkout -b sanitized
- $ git checkout -b medley
+ $ git branch sanitized    # Создаём ветку для очищенных коммитов.
+ $ git checkout -b medley  # Создаём ветку для работы и переключаемся на неё.
 
 Далее делайте всё что нужно: исправляйте ошибки, добавляйте новые функции, добавляйте временный код и так далее, при этом почаще выполняя коммиты. После этого
 
@@ -193,6 +187,6 @@
 
 Возможно, вы сомневаетесь, стоят ли ветки таких хлопот. В конце концов, клоны почти столь же быстрые и вы можете переключаться между ними с помощью *cd* вместо загадочных команд Git.
 
-Посмотрим на веб-браузеры. Зачем нужна поддержка вкладок вдобавок к окнам? Поддержка и тех, и других позволяет приспособиться к широкому разнообразию стилей работы. Некоторым пользователям нравится держать открытым единственное окно и использовать вкладки для множества веб-страниц. Другие могут впасть в другую крайность: множество окон без каких-либо лишних вкладок. Третьи предпочтут нечто среднее.
+Посмотрим на веб-браузеры. Зачем нужна поддержка вкладок вдобавок к окнам? Поддержка и тех, и других позволяет приспособиться к широкому разнообразию стилей работы. Некоторым пользователям нравится держать открытым единственное окно и использовать вкладки для множества веб-страниц. Другие могут впасть в другую крайность: множество окон без вкладок вообще. Третьи предпочтут нечто среднее.
 
 Ветки похожи на вкладки для рабочего каталога, а клоны — на новые окна браузера. Эти операции быстры и выполняются локально, так почему бы не поэкспериментировать и не найти наиболее удобную для себя комбинацию? Git позволяет работать в точности так, как вам нравится.

ru/grandmaster.txt

@@ -161,11 +161,9 @@ Git записывает каждый подсчитанный им хеш ко
 
 === Предотвращаем плохие коммиты ===
 
-История многих моих проектов полна глупых ошибок. Самое ужасное это проблема недостающих файлов, вызванная забытым *git add*. К счастью, я пока не терял критичных данных при таких случайных пропусках, потому что я редко удаляю оригинальные рабочие каталоги. Обычно я замечаю ошибку несколько коммитов спустя, так что единственный вред это небольшая потеря истории и глупое чувство вины.
+Глупые ошибки загрязняют мои хранилища. Самое ужасное это проблема недостающих файлов, вызванная забытым *git add*.
 
-Также я регулярно совершаю менее серьезный проступок: завершающие пробелы. Несмотря на безвредность, я не хотел бы, чтобы это появлялось в публичных записях.
-
-И наконец я беспокоюсь о неразрешенных конфликтах слияний, хотя пока они не приносили вреда. Обычно я замечаю их при сборке проекта, но иногда могу проглядеть.
+Примеры менее серьезных проступков: завершающие пробелы и неразрешённые конфликты слияния. Несмотря на безвредность, я не хотел бы, чтобы это появлялось в публичных записях.
 
 Если бы я только поставил защиту от дурака, используя _хук_, который бы предупреждал меня об этих проблемах:
 
@@ -181,6 +179,4 @@ if git ls-files -o | grep '\.txt$'; then
  exit 1
 fi
 
-Несколько операций Git поддерживают хуки, смотрите *git help hooks*. Вы можете добавить хуки, которые будут сообщать о грамматических ошибках в описаниях коммитов, добавлять новые файлы, расставлять абзацные отступы, прибавлять запись к веб-странице, проигрывать звуки и так далее.
-
-Мы использовали пример хука *post-update* раньше, при обсуждении использования Git через http; это заставило Git запускать этот скрипт при каждом перемещении «головы». Пример скрипта *post-update* обновляет несколько файлов, которые нужны Git для связи через не считающиеся с ним средства сообщения, такие как HTTP.
+Несколько операций Git поддерживают хуки, смотрите *git help hooks*. Мы использовали пример хука *post-update* раньше, при обсуждении использования Git через http. Он запускался при каждом перемещении «головы». Пример скрипта *post-update* обновляет файлы, которые нужны Git для связи через не считающиеся с ним средства сообщения, такие как HTTP.

ru/preface.txt

@@ -27,6 +27,7 @@ http://git.or.cz/[Git] это швейцарский нож управления
 
  - http://docs.google.com/View?id=dfwthj68_675gz3bw8kj[	Китайский (упрощенный)]: JunJie, Meng и JiangWei.
  - link:/~blynn/gitmagic/intl/es/[Испанский]: Rodrigo Toledo.
+ - link:/~blynn/gitmagic/intl/de/[German]: Benjamin Bellee и Armin Stebich. Armin также разместил http://gitmagic.lordofbikes.de/[немецкий перевод  на его сайте].
  - http://www.slideshare.net/slide_user/magia-git[Португальский]: Leonardo Siqueira Rodrigues [http://www.slideshare.net/slide_user/magia-git-verso-odt[в формате ODT]].
 
 .Другие варианты
@@ -37,11 +38,11 @@ http://git.or.cz/[Git] это швейцарский нож управления
 
 === Благодарности ===
 
-Dustin Sallings, Alberto Bertogli, James Cameron, Douglas Livingstone, Michael Budde, Richard Albury, Tarmigan, Derek Mahar, Frode Aannevik, Keith Rarick, Andy Somerville, Ralf Recker, Øyvind A. Holm, Miklos Vajna, Sébastien Hinderer, Thomas Miedema, и Joe Malin содействовали в правках и доработках.
+Dustin Sallings, Alberto Bertogli, James Cameron, Douglas Livingstone, Michael Budde, Richard Albury, Tarmigan, Derek Mahar, Frode Aannevik, Keith Rarick, Andy Somerville, Ralf Recker, Øyvind A. Holm, Miklos Vajna, Sébastien Hinderer, Thomas Miedema, Joe Malin и Tyler Breisacher содействовали в правках и доработках.
 
 François Marier сопровождает пакет Debian, изначально созданный Daniel Baumann.
 
-JunJie, Meng, JiangWei, Rodrigo Toledo, и Leonardo Siqueira Rodrigues работали над переводами этого руководства.
+JunJie, Meng, JiangWei, Rodrigo Toledo, Leonardo Siqueira Rodrigues, Benjamin Bellee и Armin Stebich работали над переводами этого руководства.
 
 Мои благодарности остальным за вашу поддержку и похвалы. Мне очень хотелось процитировать вас здесь, но это могло бы возвысить ваше тщеславие до невообразимых высот.
 

ru/secrets.txt

@@ -32,9 +32,7 @@ Git эвристически находит файлы, которые были
 
 Поскольку считывание этой информации значительно быстрее, чем чтение всего файла, то если вы редактировали лишь несколько файлов, Git может обновить свой индекс почти мгновенно.
 
-Мы отмечали ранее, что индекс это буферная зона. Тогда как индекс может быть всего лишь набором свойств файлов?
-
-Индекс может восприниматься как буферная зона, потому что команда add помещает файлы в базу данных Git и в соответствии с этим обновляет индекс; тогда как команда commit без опций создает коммит на основе состояния индекса.
+Мы отмечали ранее, что индекс это буферная зона. Почему набор свойств файлов выступает таким буфером? Потому что команда add помещает файлы в базу данных Git и в соответствии с этим обновляет эти свойства; тогда как команда commit без опций создает коммит, основанный только на этих свойствах и файлах, которые уже в базе данных.
 
 === Происхождение Git ===