ru/multyplayer.txt updated to upstream english version

ru/multiplayer.txt

@@ -48,9 +48,7 @@ johndoe@example.com
 каталоге, доступном через web:
 
  $ GIT_DIR=proj.git git init
-
-В каталоге "proj.git" запустите
-
+ $ cd proj.git
  $ git --bare update-server-info
  $ cp hooks/post-update.sample
 hooks/post-update
@@ -94,12 +92,7 @@ web.server:/path/to/proj.git master
 
 Затем передаёт «пакет», +некий-файл+,
 другой команде любыми средствами, как
-то: электронная почта, флешка, дискета,
-*xxd* печать и последующее
-распознавание текста, надиктовка битов
-по телефону, дымовые сигналы и т.д.
-Получатель восстанавливает коммиты из
-пакета, введя
+то: электронная почта, флешка, *xxd* печать и последующее распознавание текста, надиктовка битов по телефону, дымовые сигналы и т.д. Получатель восстанавливает коммиты из пакета, введя
 
  $ git pull некий-файл
 
@@ -111,10 +104,9 @@ web.server:/path/to/proj.git master
 В больших проектах для устраннения
 излишков объема пакетируют только
 изменения, которых нет в других
-хранилищах:
+хранилищах. К примеру, пусть коммит «1b6d…» — последний, общий для обеих групп:
 
- $ git bundle create somefile HEAD
-^COMMON_SHA1
+ $ git bundle create somefile HEAD ^1b6d
 
 Если это делается часто, можно легко
 забыть, какой коммит был отправлен
@@ -150,13 +142,13 @@ web.server:/path/to/proj.git master
 
 Вспомним первую главу:
 
- $ git diff COMMIT
+ $ git diff 1b6d
 
 выводит патч, который может быть
 вставлен в письмо для обсуждения. В Git
 хранилище введите
 
- $ git apply < FILE
+ $ git apply < мой.patch
 
 для применения патча.
 
@@ -165,20 +157,19 @@ web.server:/path/to/proj.git master
 создавайте соответствующие патчи с
 определенной точки, набрав
 
- $ git format-patch START_COMMIT
+ $ git format-patch 1b6d
 
 Полученные файлы могут быть отправлены
 с помощью *git-send-email* или вручную.
 Вы также можете указать диапазон
 коммитов:
 
- $ git format-patch
-START_COMMIT..END_COMMIT
+ $ git format-patch 1b6d..HEAD^^
 
 На принимающей стороне сохраните email
 в файл и введите:
 
- $ git am < FILE
+ $ git am < email.txt
 
 Это применит входящие исправления, а
 также создаст коммит, включающий такую
@@ -205,8 +196,7 @@ START_COMMIT..END_COMMIT
 отправляют и получают его по
 первоначальному адресу. Каким образом
 Git это делает? Секрет кроется в
-настройках, заданных исзначально при
-создании клона. Давайте взглянём:
+настройках, заданных при создании клона. Давайте взглянём:
 
  $ git config --list
 
@@ -221,7 +211,7 @@ Git это делает? Секрет кроется в
 изменился, можно обновить его с
 командой
 
- $ git config remote.origin.url NEW_URL
+ $ git config remote.origin.url git://новый.url/proj.git
 
 Опция +branch.master.merge+ задает
 удаленную ветку по умолчанию для
@@ -241,7 +231,7 @@ Git это делает? Секрет кроется в
 хранилищ, то мы должны указать нужную
 ветку:
 
- $ git pull ANOTHER_URL master
+ $ git pull git://пример.com/other.git master
 
 Это объясняет, почему некоторых из
 наших предыдущих примеров push и pull
@@ -293,7 +283,7 @@ Git это делает? Секрет кроется в
 наблюдать более чем за одним
 хранилищем одновременно так:
 
- $ git remote add other ДРУГОЙ_URL
+ $ git remote add other git://пример.com/some_repo.git
  $ git pull other некая_ветка
 
 Сейчас мы сделали слияние с веткой из
@@ -309,26 +299,15 @@ other/некая_ветка~5
 работу? Иными словами, мы хотим, чтобы
 изучить чужие ветки, не давая их
 изменениям вторгаться в наш рабочий
-каталог. В этом случае вместо pull
+каталог. Тогда вместо pull
 наберите
 
  $ git fetch # Перенести из origin, по
 умолчанию.
  $ git fetch other # Перенести от
 второго программиста.
 
-Так мы переносим их историю, и ничего
-больше, т.е., оставляя рабочий каталог
-нетронутыми, можем обратиться к любой
-ветке в любом хранилище команды,
-работающей с Git. Кстати, pull это
-просто fetch, а затем  *git merge*;
-вспомните: последняя команда делает
-слияние заданного коммита с рабочим
-каталогом. Обычно мы используем pull,
-потому что нам нужно слияние после
-получения чужой ветки; описанная
-ситуация — примечательное исключение.
+Так мы переносим лишь их историю. Оставляя рабочий каталог нетронутыми, мы можем обратиться к любой ветке в любом хранилище команды, работающей с Git, т.к. теперь у нас есть рабочая копия. Держим в уме, что pull это просто *fetch*, а затем  *merge*. Обычно мы используем *pull*, потому что мы хотим влить к себе последний коммит после получения чужой ветки; описанная ситуация — примечательное исключение.
 
 О том, как отключить удаленные
 хранилища, игнорировать определенные
@@ -338,23 +317,19 @@ remote*.
 === Мои Настройки ===
 
 Для моих проектов я люблю использовать
-готовые хранилища Git, в которые я могу
-влить свои изменения. Некоторые Git
-хостинги позволяют создавать
+готовые хранилища, из которых я могу
+получить изменения. Некоторые Git хостинги позволяют создавать
 собственные форки проекта в одно
 касание.
 
 После получения дерева из удалённого
 хранилища я запускаю команды Git для
 навигации и изучения изменении, в
 идеале хорошо организованых и описаных.
-Я вливаю свои неопубликованные
-изменения и возможно меняю что-то ещё.
-По окончании, я выгружаю изменения в
-официальное хранилище.
+Я вливаю свои изменения и возможно меняю что-то ещё. По окончании, я выгружаю изменения в главное хранилище.
 
 Хотя со мной немного сотрудничают, я охотно верю, что этот подход хорошо масштабируется. См.
 http://torvalds-family.blogspot.com/2009/06/happiness-is-warm-scm.html[этот
 пост в блоге Линуса Торвальдса].
 
-Оставаться в мире Git несколько удобнее, чем использовать патч-файлы, т.к. это избавляет меня от шага конвертации их в коммиты Git. Кроме того, Git автоматически управляет деталями вроде сохранения имени автора и адреса электронной почты, а также даты и времени, и просит автора описать свои изменения.
+Оставаться в мире Git несколько удобнее, чем использовать патч-файлы, т.к. это избавляет меня от преобразования их в коммиты Git. Кроме того, Git управляет деталями вроде сохранения имени автора и адреса электронной почты, а также даты и времени, и просит автора описать свои изменения.