ru/multiplayer.txt editing finished

ru/multiplayer.txt

@@ -107,25 +107,25 @@ web.server:/path/to/proj.git master
 
  $ git config --list
 
-Опция +remote.origin.url+ контролирует исходный адрес; «origin» — имя первоначального хранилища. Как и имя ветки «master», это соглашение: мы можем изменить или удалить этот ник, но как правило, нет причин для этого.
+Опция +remote.origin.url+ задает исходный адрес; origin — имя первоначального хранилища. Как и имя ветки master, это соглашение. Мы можем изменить или удалить это сокращённое имя, но как правило, нет причин для этого.
 
-Если адрес оригинального хранилища изменился, можно обновить его с командой
+Если оригинальное хранилище переехало, можно обновить его адрес командой
 
  $ git config remote.origin.url git://новый.url/proj.git
 
 Опция +branch.master.merge+ задает удаленную ветку по умолчанию для *git pull*. В ходе первоначального клонирования она устанавливается на текущую ветку исходного хранилища, так что даже если HEAD исходного хранилища впоследствии переместится на другую ветку, pull будет верно следовать изначальной ветке.
 
-Этот параметр обращается только к хранилищу, который мы изначально клонировали и который записан в параметре +branch.master.remote+. Если мы выполняем pull из других  хранилищ, то мы должны указать нужную ветку:
+Этот параметр обращается только к хранилищу, который мы изначально клонировали и который записан в параметре +branch.master.remote+. При выполнении pull из других хранилищ мы должны указать нужную ветку:
 
  $ git pull git://пример.com/other.git master
 
 Это объясняет, почему некоторых из наших предыдущих примеров push и pull не имели аргументов.
 
 === Удаленные ветки ===
 
-Когда вы клонируете хранилище, вы также клонируете все его ветки. Вы можете не заметить это, потому что Git скрывает их: вы должны спросить о них явно. Это предотвращает противоречие между ветками в удаленном хранилище и вашими ветками, а также делает Git проще для начинающих.
+При клонировании хранилища вы также клонируете все его ветки. Вы можете не заметить этого, потому что Git скрывает их: вы должны запросить их явно. Это предотвращает противоречие между ветками в удаленном хранилище и вашими ветками, а также делает Git проще для начинающих.
 
-Список удаленных веток можно посмотреть коммандой
+Список удаленных веток можно посмотреть командой
 
  $ git branch -r
 
@@ -135,43 +135,45 @@ web.server:/path/to/proj.git master
  origin/master
  origin/experimental
 
-Эти имена отвечают веткам и HEAD в удаленном хранилище; их можно использовать в обычных командах Git. Например, вы создали много коммитов, и хотели бы сравнить текущее состояние с последней загруженной версией. Вы можете исать в журналах нужный SHA1 хеш, но гораздо легче набрать
+Эти имена отвечают веткам и «голове» в удаленном хранилище; их можно использовать в обычных командах Git. Например, вы сделали много коммитов, и хотели бы сравнить текущее состояние с последней загруженной версией. Вы можете искать в журналах нужный SHA1 хеш, но гораздо легче набрать
 
  $ git diff origin/HEAD
 
-Также можно увидеть, для чего была создана ветка «experimental», набрав:
+Также можно увидеть, для чего была создана ветка experimental:
 
  $ git log origin/experimental
 
 === Несколько удаленных хранилищ ===
 
-Предположим, что над нашим проектом работают еще два разработчика, и мы хотим следить за обоими. Мы можем наблюдать более чем за одним хранилищем одновременно так:
+Предположим, что над нашим проектом работают еще два разработчика, и мы хотим следить за обоими. Мы можем наблюдать более чем за одним хранилищем одновременно, вот так:
 
- $ git remote add other git://пример.com/some_repo.git
+ $ git remote add other git://пример.com/некое_хранилище.git
  $ git pull other некая_ветка
 
 Сейчас мы сделали слияние с веткой из второго хранилища. Теперь у нас есть легкий доступ ко всем веткам во всех хранилищах:
 
  $ git diff origin/experimental^
 other/некая_ветка~5
 
-Но что, если мы просто хотим сравнить их изменения, не затрагивая свою работу? Иными словами, мы хотим, чтобы изучить чужие ветки, не давая их изменениям вторгаться в наш рабочий каталог. Тогда вместо pull наберите
+Но что, если мы просто хотим сравнить их изменения, не затрагивая свою работу? Иными словами, мы хотим изучить чужие ветки, не давая их изменениям вторгаться в наш рабочий каталог. Тогда вместо pull наберите
 
  $ git fetch # Перенести из origin, по
 умолчанию.
  $ git fetch other # Перенести от
 второго программиста.
 
-Так мы переносим лишь их историю. Оставляя рабочий каталог нетронутыми, мы можем обратиться к любой ветке в любом хранилище команды, работающей с Git, т.к. теперь у нас есть рабочая копия. Держим в уме, что pull это просто *fetch*, а затем  *merge*. Обычно мы используем *pull*, потому что мы хотим влить к себе последний коммит после получения чужой ветки; описанная ситуация — примечательное исключение.
+Так мы лишь переносим их историю. Хотя рабочий каталог остается нетронутыми, мы можем обратиться к любой ветке в любом хранилище команды, работающей с Git, так как теперь у нас есть локальная копия.
 
-О том, как отключить удаленные хранилища, игнорировать определенные ветки и многом другом см. *git help remote*.
+Держим в уме, что pull это просто *fetch*, а затем  *merge*. Обычно мы используем *pull*, потому что мы хотим влить к себе последний коммит после получения чужой ветки. Описанная ситуация — примечательное исключение.
+
+О том, как отключить удаленные хранилища, игнорировать отдельные ветки и многом другом см. *git help remote*.
 
 === Мои Настройки ===
 
-Для моих проектов я люблю использовать готовые хранилища, из которых я могу получить изменения. Некоторые Git хостинги позволяют создавать собственные форки проекта в одно касание.
+Я предпочитаю, чтобы люди, присоединяющиеся к моим проектам, создавали хранилища, из которых я смогу получать изменения с помощью pull. Некоторые Git хостинги позволяют создавать собственные форки проекта в одно касание.
 
-После получения дерева из удаленного хранилища я запускаю команды Git для навигации и изучения изменении, в идеале хорошо организованых и описаных. Я вливаю свои изменения и возможно меняю что-то еще. По окончании, я выгружаю изменения в главное хранилище.
+После получения дерева из удаленного хранилища я запускаю команды Git для навигации и изучения изменений, в идеале хорошо организованных и описанных. Я делаю слияние со своими изменения и возможно вношу дальнейшие правки. Когда я доволен результатом, я заливаю изменения в главное хранилище.
 
-Хотя со мной немного сотрудничают, я охотно верю, что этот подход хорошо масштабируется. См. http://torvalds-family.blogspot.com/2009/06/happiness-is-warm-scm.html[этот пост в блоге Линуса Торвальдса].
+Хотя со мной мало сотрудничают, я верю, что этот подход хорошо масштабируется. См. http://torvalds-family.blogspot.com/2009/06/happiness-is-warm-scm.html[эту пост в блоге Линуса Торвальдса].
 
-Оставаться в мире Git несколько удобнее, чем использовать патч-файлы, т.к. это избавляет меня от преобразования их в коммиты Git. Кроме того, Git управляет деталями вроде сохранения имени автора и адреса электронной почты, а также даты и времени, и просит автора описать свои изменения.
+Оставаться в мире Git несколько удобнее, чем использовать патч-файлы, так как это избавляет меня от преобразования их в коммиты Git. Кроме того, Git управляет деталями вроде сохранения имени автора и адреса электронной почты, а также даты и времени, и просит авторов описывать свои изменения.