ru/multiplayer.txt

   1 == Многопользовательский Git ==
   2
   3 Сначала я использовал Git для личного проекта, в котором был единственным разработчиком. Среди команд, связанных с распределенными свойствами Git, мне требовались только *pull* и *clone*, чтобы хранить один и тот же проект в разных местах.
   4
   5 Позднее я захотел опубликовать свой код при помощи Git и включать изменения помощников. Мне пришлось научиться управлять проектами, которые разрабатываются множеством людей со всего мира. К счастью, в этом сильная сторона Git и, возможно, сам смысл его существования.
   6
   7 === Кто я? ===
   8
   9 Каждый коммит содержит имя автора и адрес электронной почты, которые выводятся командой *git log*. По умолчанию Git использует системные настройки для заполнения этих полей. Чтобы установить их явно, введите
  10
  11   $ git config --global user.name "John
  12 Doe"
  13   $ git config --global user.email
  14 johndoe@example.com
  15
  16 Чтобы установить эти параметры только для текущего хранилища, опустите флаг --global.
  17
  18 === Git через SSH, HTTP ===
  19
  20 Предположим, у вас есть SSH доступ к веб-серверу, но Git не установлен. Git может связываться через HTTP, хотя это и менее эффективно, чем его собственный протокол.
  21
  22 Скачайте, скомпилируйте, установите Git
  23 в вашем аккаунте; создайте хранилище в
  24 каталоге, доступном через web:
  25
  26  $ GIT_DIR=proj.git git init
  27  $ cd proj.git
  28  $ git --bare update-server-info
  29  $ cp hooks/post-update.sample
  30 hooks/post-update
  31
  32 Для старых версий Git команда копирования выдаст ошибку, и вы должны будете запустить
  33
  34  $ chmod a+x hooks/post-update
  35
  36 Теперь вы можете публиковать свои последние правки через SSH с любого клона:
  37
  38  $ git push
  39 web.server:/path/to/proj.git master
  40
  41 и кто угодно сможет взять ваш проект через HTTP:
  42
  43  $ git clone http://web.server/proj.git
  44
  45 === Git через что угодно ===
  46
  47 Хотите синхронизировать хранилища без серверов или вообще без сетевого подключения? Вынуждены изобретать средства на ходу в непредвиденной ситуации? Мы видели, как <<makinghistory, *git fast-export* и *git fast-import* могут преобразовать хранилища в один файл и обратно>>. Посредством обмена такими файлами мы можем переносить хранилища git любыми доступными средствами, но есть более эффективный инструмент: *git bundle*.
  48
  49 Отправитель создает пакет (bundle):
  50
  51  $ git bundle create некий-файл HEAD
  52
  53 Затем передает «пакет», +некий-файл+, другой команде любыми средствами, как то: электронная почта, флешка, *xxd* печать и последующее распознавание текста, надиктовка битов по телефону, дымовые сигналы и т.д. Получатель восстанавливает коммиты из пакета, введя
  54
  55  $ git pull некий-файл
  56
  57 Получатель может сделать это даже в пустом хранилище. Несмотря на свой размер, +некий-файл+ содержит всё исходное хранилище Git.
  58
  59 В больших проектах для устраннения излишков объема пакетируют только изменения, которых нет в других хранилищах. К примеру, пусть коммит «1b6d…» — последний, общий для обеих групп:
  60
  61  $ git bundle create somefile HEAD ^1b6d
  62
  63 Если это делается часто, можно легко забыть, какой коммит был отправлен последним. Справка предлагает для решения этой проблемы использовать теги. А именно, после передачи пакета введите
  64
  65  $ git tag -f последний-пакет HEAD
  66
  67 и создавайте обновления пакеты с помощью
  68
  69  $ git bundle create новый-пакет HEAD
  70 ^последний-пакет
  71
  72 === Патчи: общее применение ===
  73
  74 Патчи это тексты изменений, вполне понятные как человеку, так и компьютеру. Это делает их очень привлекательным форматом обмена. Патч можно послать разработчикам по электронной почте, независимо от того, какую систему управления версиями они используют. Вашим корреспондентам достаточно возможности читать электронную почту, чтобы увидеть ваши изменения. Точно так же, все, что требуется с Вашей стороны, — это адрес электронной почты: нет необходимости в установке онлайн хранилища Git.
  75
  76 Вспомним первую главу:
  77
  78  $ git diff 1b6d
  79
  80 выводит патч, который может быть вставлен в письмо для обсуждения. В Git хранилище введите
  81
  82  $ git apply < мой.patch
  83
  84 для применения патча.
  85
  86 В более формальной обстановке, когда нужно сохранить имя автора и подписи, создавайте соответствующие патчи с определенной точки, набрав
  87
  88  $ git format-patch 1b6d
  89
  90 Полученные файлы могут быть отправлены с помощью *git-send-email* или вручную. Вы также можете указать диапазон коммитов:
  91
  92  $ git format-patch 1b6d..HEAD^^
  93
  94 На принимающей стороне сохраните email в файл и введите:
  95
  96  $ git am < email.txt
  97
  98 Это применит входящие исправления и создаст коммит, включающий имя автора и другую информацию.
  99
 100 С web-интерфейсом к электронной почте вам, возможно, потребуется нажать кнопку, чтобы посмотреть электронную почту в своем первоначальном виде до сохранения патча в файл.
 101
 102 Есть небольшие различия для клиентов электронной почты, использующих mbox, но если вы используете один из них, то вы, по всей видимости, можете легко разобраться в этом без чтения руководства!
 103
 104 === Приносим извинения, мы переехали ===
 105
 106 После клонирования хранилища команды *git push* или *git pull* автоматически отправляют и получают его по первоначальному адресу. Каким образом Git это делает? Секрет кроется в настройках, заданных при создании клона. Давайте взглянем:
 107
 108  $ git config --list
 109
 110 Опция +remote.origin.url+ контролирует исходный адрес; «origin» — имя первоначального хранилища. Как и имя ветки «master», это соглашение: мы можем изменить или удалить этот ник, но как правило, нет причин для этого.
 111
 112 Если адрес оригинального хранилища изменился, можно обновить его с командой
 113
 114  $ git config remote.origin.url git://новый.url/proj.git
 115
 116 Опция +branch.master.merge+ задает удаленную ветку по умолчанию для *git pull*. В ходе первоначального клонирования она устанавливается на текущую ветку исходного хранилища, так что даже если HEAD исходного хранилища впоследствии переместится на другую ветку, pull будет верно следовать изначальной ветке.
 117
 118 Этот параметр обращается только к хранилищу, который мы изначально клонировали и который записан в параметре +branch.master.remote+. Если мы выполняем pull из других  хранилищ, то мы должны указать нужную ветку:
 119
 120  $ git pull git://пример.com/other.git master
 121
 122 Это объясняет, почему некоторых из наших предыдущих примеров push и pull не имели аргументов.
 123
 124 === Удаленные ветки ===
 125
 126 Когда вы клонируете хранилище, вы также клонируете все его ветки. Вы можете не заметить это, потому что Git скрывает их: вы должны спросить о них явно. Это предотвращает противоречие между ветками в удаленном хранилище и вашими ветками, а также делает Git проще для начинающих.
 127
 128 Список удаленных веток можно посмотреть коммандой
 129
 130  $ git branch -r
 131
 132 Вы должны увидеть что-то вроде
 133
 134  origin/HEAD
 135  origin/master
 136  origin/experimental
 137
 138 Эти имена отвечают веткам и HEAD в удаленном хранилище; их можно использовать в обычных командах Git. Например, вы создали много коммитов, и хотели бы сравнить текущее состояние с последней загруженной версией. Вы можете исать в журналах нужный SHA1 хеш, но гораздо легче набрать
 139
 140  $ git diff origin/HEAD
 141
 142 Также можно увидеть, для чего была создана ветка «experimental», набрав:
 143
 144  $ git log origin/experimental
 145
 146 === Несколько удаленных хранилищ ===
 147
 148 Предположим, что над нашим проектом работают еще два разработчика, и мы хотим следить за обоими. Мы можем наблюдать более чем за одним хранилищем одновременно так:
 149
 150  $ git remote add other git://пример.com/some_repo.git
 151  $ git pull other некая_ветка
 152
 153 Сейчас мы сделали слияние с веткой из второго хранилища. Теперь у нас есть легкий доступ ко всем веткам во всех хранилищах:
 154
 155  $ git diff origin/experimental^
 156 other/некая_ветка~5
 157
 158 Но что, если мы просто хотим сравнить их изменения, не затрагивая свою работу? Иными словами, мы хотим, чтобы изучить чужие ветки, не давая их изменениям вторгаться в наш рабочий каталог. Тогда вместо pull наберите
 159
 160  $ git fetch # Перенести из origin, по
 161 умолчанию.
 162  $ git fetch other # Перенести от
 163 второго программиста.
 164
 165 Так мы переносим лишь их историю. Оставляя рабочий каталог нетронутыми, мы можем обратиться к любой ветке в любом хранилище команды, работающей с Git, т.к. теперь у нас есть рабочая копия. Держим в уме, что pull это просто *fetch*, а затем  *merge*. Обычно мы используем *pull*, потому что мы хотим влить к себе последний коммит после получения чужой ветки; описанная ситуация — примечательное исключение.
 166
 167 О том, как отключить удаленные хранилища, игнорировать определенные ветки и многом другом см. *git help remote*.
 168
 169 === Мои Настройки ===
 170
 171 Для моих проектов я люблю использовать готовые хранилища, из которых я могу получить изменения. Некоторые Git хостинги позволяют создавать собственные форки проекта в одно касание.
 172
 173 После получения дерева из удаленного хранилища я запускаю команды Git для навигации и изучения изменении, в идеале хорошо организованых и описаных. Я вливаю свои изменения и возможно меняю что-то еще. По окончании, я выгружаю изменения в главное хранилище.
 174
 175 Хотя со мной немного сотрудничают, я охотно верю, что этот подход хорошо масштабируется. См. http://torvalds-family.blogspot.com/2009/06/happiness-is-warm-scm.html[этот пост в блоге Линуса Торвальдса].
 176
 177 Оставаться в мире Git несколько удобнее, чем использовать патч-файлы, т.к. это избавляет меня от преобразования их в коммиты Git. Кроме того, Git управляет деталями вроде сохранения имени автора и адреса электронной почты, а также даты и времени, и просит автора описать свои изменения.