From ce51f26db20ba518d7bd3bf98bb9ed9b55739817 Mon Sep 17 00:00:00 2001 From: Tikhon Tarnavsky Date: Sun, 1 Aug 2010 21:45:51 +0300 Subject: [PATCH] ru/multiplayer.txt editing finished --- ru/multiplayer.txt | 34 ++++++++++++++++++---------------- 1 file changed, 18 insertions(+), 16 deletions(-) diff --git a/ru/multiplayer.txt b/ru/multiplayer.txt index 5dee68f..2ffbcb6 100644 --- a/ru/multiplayer.txt +++ b/ru/multiplayer.txt @@ -107,15 +107,15 @@ 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 @@ -123,9 +123,9 @@ web.server:/path/to/proj.git master === Удаленные ветки === -Когда вы клонируете хранилище, вы также клонируете все его ветки. Вы можете не заметить это, потому что Git скрывает их: вы должны спросить о них явно. Это предотвращает противоречие между ветками в удаленном хранилище и вашими ветками, а также делает Git проще для начинающих. +При клонировании хранилища вы также клонируете все его ветки. Вы можете не заметить этого, потому что Git скрывает их: вы должны запросить их явно. Это предотвращает противоречие между ветками в удаленном хранилище и вашими ветками, а также делает Git проще для начинающих. -Список удаленных веток можно посмотреть коммандой +Список удаленных веток можно посмотреть командой $ git branch -r @@ -135,19 +135,19 @@ 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 некая_ветка Сейчас мы сделали слияние с веткой из второго хранилища. Теперь у нас есть легкий доступ ко всем веткам во всех хранилищах: @@ -155,23 +155,25 @@ web.server:/path/to/proj.git master $ 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 управляет деталями вроде сохранения имени автора и адреса электронной почты, а также даты и времени, и просит авторов описывать свои изменения. -- 2.11.4.GIT