Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

ru/multyplayer.txt updated to upstream english version

  • Loading branch information...
commit f558d6465736b13bc73b3128c259b57fe3affd69 1 parent 89baf34
@t-t t-t authored
Showing with 19 additions and 44 deletions.
  1. +19 −44 ru/multiplayer.txt
View
63 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,7 +299,7 @@ other/некая_ветка~5
работу? Иными словами, мы хотим, чтобы
изучить чужие ветки, не давая их
изменениям вторгаться в наш рабочий
-каталог. В этом случае вместо pull
+каталог. Тогда вместо pull
наберите
$ git fetch # Перенести из origin, по
@@ -317,18 +307,7 @@ other/некая_ветка~5
$ git fetch other # Перенести от
второго программиста.
-Так мы переносим их историю, и ничего
-больше, т.е., оставляя рабочий каталог
-нетронутыми, можем обратиться к любой
-ветке в любом хранилище команды,
-работающей с Git. Кстати, pull это
-просто fetch, а затем *git merge*;
-вспомните: последняя команда делает
-слияние заданного коммита с рабочим
-каталогом. Обычно мы используем pull,
-потому что нам нужно слияние после
-получения чужой ветки; описанная
-ситуация — примечательное исключение.
+Так мы переносим лишь их историю. Оставляя рабочий каталог нетронутыми, мы можем обратиться к любой ветке в любом хранилище команды, работающей с Git, т.к. теперь у нас есть рабочая копия. Держим в уме, что pull это просто *fetch*, а затем *merge*. Обычно мы используем *pull*, потому что мы хотим влить к себе последний коммит после получения чужой ветки; описанная ситуация — примечательное исключение.
О том, как отключить удаленные
хранилища, игнорировать определенные
@@ -338,9 +317,8 @@ remote*.
=== Мои Настройки ===
Для моих проектов я люблю использовать
-готовые хранилища Git, в которые я могу
-влить свои изменения. Некоторые Git
-хостинги позволяют создавать
+готовые хранилища, из которых я могу
+получить изменения. Некоторые Git хостинги позволяют создавать
собственные форки проекта в одно
касание.
@@ -348,13 +326,10 @@ remote*.
хранилища я запускаю команды Git для
навигации и изучения изменении, в
идеале хорошо организованых и описаных.
-Я вливаю свои неопубликованные
-изменения и возможно меняю что-то ещё.
-По окончании, я выгружаю изменения в
-официальное хранилище.
+Я вливаю свои изменения и возможно меняю что-то ещё. По окончании, я выгружаю изменения в главное хранилище.
Хотя со мной немного сотрудничают, я охотно верю, что этот подход хорошо масштабируется. См.
http://torvalds-family.blogspot.com/2009/06/happiness-is-warm-scm.html[этот
пост в блоге Линуса Торвальдса].
-Оставаться в мире Git несколько удобнее, чем использовать патч-файлы, т.к. это избавляет меня от шага конвертации их в коммиты Git. Кроме того, Git автоматически управляет деталями вроде сохранения имени автора и адреса электронной почты, а также даты и времени, и просит автора описать свои изменения.
+Оставаться в мире Git несколько удобнее, чем использовать патч-файлы, т.к. это избавляет меня от преобразования их в коммиты Git. Кроме того, Git управляет деталями вроде сохранения имени автора и адреса электронной почты, а также даты и времени, и просит автора описать свои изменения.
Please sign in to comment.
Something went wrong with that request. Please try again.