ru/multiplayer.txt

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