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 веб.сервер:/путь/к/proj.git master
  40
  41 и кто угодно сможет взять ваш проект с помощью
  42
  43  $ git clone http://веб.сервер/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 некий-файл HEAD ^1b6d
  62
  63 Если это делается часто, можно легко забыть, какой коммит был отправлен последним. Справка предлагает для решения этой проблемы использовать теги. А именно, после передачи пакета введите
  64
  65  $ git tag -f последний-пакет HEAD
  66
  67 и создавайте обновленные пакеты с помощью
  68
  69  $ git bundle create новый-пакет HEAD ^последний-пакет
  70
  71 === Патчи: общее применение ===
  72
  73 Патчи это тексты изменений, вполне понятные как человеку, так и компьютеру. Это делает их очень привлекательным форматом обмена. Патч можно послать разработчикам по электронной почте, независимо от того, какую систему управления версиями они используют. Вашим корреспондентам достаточно возможности читать электронную почту, чтобы увидеть ваши изменения. Точно так же, с Вашей стороны требуется лишь адрес электронной почты: нет нужды в настройке онлайн хранилища Git.
  74
  75 Вспомним из первой главы:
  76
  77  $ git diff 1b6d
  78
  79 выводит патч, который может быть вставлен в письмо для обсуждения. В Git хранилище введите
  80
  81  $ git apply < мой.patch
  82
  83 для применения патча.
  84
  85 В более формальных случаях , когда нужно сохранить имя автора и подписи, создавайте соответствующие патчи с заданной точки, набрав
  86
  87  $ git format-patch 1b6d
  88
  89 Полученные файлы могут быть отправлены с помощью *git-send-email* или вручную. Вы также можете указать диапазон коммитов:
  90
  91  $ git format-patch 1b6d..HEAD^^
  92
  93 На принимающей стороне сохраните письмо в файл и введите:
  94
  95  $ git am < email.txt
  96
  97 Это применит входящие исправления и создаст коммит, включающий имя автора и другую информацию.
  98
  99 С web-интерфейсом к электронной почте вам, возможно, потребуется нажать кнопку, чтобы посмотреть электронную почту в своем первоначальном виде перед сохранением патча в файл.
 100
 101 Для клиентов электронной почты, использующих mbox, есть небольшие отличия; но если вы используете один из них, то вы, по всей видимости, можете легко разобраться в этом без чтения описаний!
 102
 103 === Приносим извинения, мы переехали ===
 104
 105 После клонирования хранилища команды *git push* или *git pull* автоматически отправляют и получают его по первоначальному адресу. Каким образом Git это делает? Секрет кроется в настройках, заданных при создании клона. Давайте взглянем:
 106
 107  $ git config --list
 108
 109 Опция +remote.origin.url+ задает исходный адрес; origin — имя первоначального хранилища. Как и имя ветки master, это соглашение. Мы можем изменить или удалить это сокращённое имя, но как правило, нет причин для этого.
 110
 111 Если оригинальное хранилище переехало, можно обновить его адрес командой
 112
 113  $ git config remote.origin.url git://новый.url/proj.git
 114
 115 Опция +branch.master.merge+ задает удаленную ветку по умолчанию для *git pull*. В ходе первоначального клонирования она устанавливается на текущую ветку исходного хранилища, так что даже если HEAD исходного хранилища впоследствии переместится на другую ветку, pull будет верно следовать изначальной ветке.
 116
 117 Этот параметр обращается только к хранилищу, которое мы изначально клонировали и которое записано в параметре +branch.master.remote+. При выполнении pull из других хранилищ мы должны указать нужную ветку:
 118
 119  $ git pull git://пример.com/other.git master
 120
 121 Это объясняет, почему некоторых из наших предыдущих примеров push и pull не имели аргументов.
 122
 123 === Удаленные ветки ===
 124
 125 При клонировании хранилища вы также клонируете все его ветки. Вы можете не заметить этого, потому что Git скрывает их: вы должны запросить их явно. Это предотвращает противоречие между ветками в удаленном хранилище и вашими ветками, а также делает Git проще для начинающих.
 126
 127 Список удаленных веток можно посмотреть командой
 128
 129  $ git branch -r
 130
 131 Вы должны увидеть что-то вроде
 132
 133  origin/HEAD
 134  origin/master
 135  origin/experimental
 136
 137 Эти имена отвечают веткам и «голове» в удаленном хранилище; их можно использовать в обычных командах Git. Например, вы сделали много коммитов, и хотели бы сравнить текущее состояние с последней загруженной версией. Вы можете искать в журналах нужный SHA1 хеш, но гораздо легче набрать
 138
 139  $ git diff origin/HEAD
 140
 141 Также можно увидеть, для чего была создана ветка experimental:
 142
 143  $ git log origin/experimental
 144
 145 === Несколько удаленных хранилищ ===
 146
 147 Предположим, что над нашим проектом работают еще два разработчика, и мы хотим следить за обоими. Мы можем наблюдать более чем за одним хранилищем одновременно, вот так:
 148
 149  $ git remote add other git://пример.com/некое_хранилище.git
 150  $ git pull other некая_ветка
 151
 152 Сейчас мы сделали слияние с веткой из второго хранилища. Теперь у нас есть легкий доступ ко всем веткам во всех хранилищах:
 153
 154  $ git diff origin/experimental^
 155 other/некая_ветка~5
 156
 157 Но что если мы просто хотим сравнить их изменения, не затрагивая свою работу? Иными словами, мы хотим изучить чужие ветки, не давая их изменениям вторгаться в наш рабочий каталог. Тогда вместо pull наберите
 158
 159  $ git fetch # Перенести из origin, по
 160 умолчанию.
 161  $ git fetch other # Перенести от
 162 второго программиста.
 163
 164 Так мы лишь переносим их историю. Хотя рабочий каталог остается нетронутыми, мы можем обратиться к любой ветке в любом хранилище команды, работающей с Git, так как теперь у нас есть локальная копия.
 165
 166 Держим в уме, что pull это просто *fetch*, а затем  *merge*. Обычно мы используем *pull*, потому что мы хотим влить к себе последний коммит после получения чужой ветки. Описанная ситуация — примечательное исключение.
 167
 168 О том, как отключить удаленные хранилища, игнорировать отдельные ветки и многом другом смотрите в *git help remote*.
 169
 170 === Мои Настройки ===
 171
 172 Я предпочитаю, чтобы люди, присоединяющиеся к моим проектам, создавали хранилища, из которых я смогу получать изменения с помощью pull. Некоторые хостинги Git позволяют создавать собственные форки проекта в одно касание.
 173
 174 После получения дерева из удаленного хранилища я запускаю команды Git для навигации и изучения изменений, в идеале хорошо организованных и описанных. Я делаю слияние со своими изменения и возможно вношу дальнейшие правки. Когда я доволен результатом, я заливаю изменения в главное хранилище.
 175
 176 Хотя со мной мало сотрудничают, я верю, что этот подход хорошо масштабируется. Смотрите http://torvalds-family.blogspot.com/2009/06/happiness-is-warm-scm.html[эту запись в блоге Линуса Торвальдса].
 177
 178 Оставаться в мире Git несколько удобнее, чем использовать файлы патчей, так как это избавляет меня от преобразования их в коммиты Git. Кроме того, Git управляет деталями вроде сохранения имени автора и адреса электронной почты, а также даты и времени, и просит авторов описывать свои изменения.