Волшебство Git. Групповая работа в Git

== Групповая работа в Git ==

Изначально я использовал Git для работы над проектом, в котором я был единственным разработчиком.
Из всех команд, связанных с распределенными свойствами Git, я использовать только *pull* и *clone* для хранения одного проекта в разных местах.

Позже я решил опубликовать свой код в Git и принять изменения других участников. Мне пришлось научиться управлять проектами, над которыми работают группы разработчиков со всего мира. Так уж случилось, что эта особенность как раз служит преимуществом Git и, возможно, даже смыслом ее существования.

=== Кто я? ===

Каждый коммит содержит имя автора и адрес электронной почты, которые отображаются по команде *git log*.
По умолчанию Git использует системные настройки для заполнения этих полей.
Чтобы установить их явно, введите:

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

Чтобы установить эти параметры только для текущего репозитория, опустите флаг --global.

=== Git через SSH, HTTP ===

Предположим, у вас есть SSH доступ к веб-серверу, но Git не установлен. Git может использовать менее эффективное (нежели его собственный протокол) http-соединение.

Скачайте, скомпилируйте и установите Git в своем аккаунте, а затем создайте репозиторий в своей веб-директории:

$ GIT_DIR=proj.git git init

В директории "proj.git" выполните:

$ git --bare update-server-info
$ cp hooks/post-update.sample hooks/post-update

В старых версиях Git команда копирования не работает, поэтому нужно запустить:

$ chmod a+x hooks/post-update

Теперь можно публиковать свои последние правки через SSH из любой копии:

$ git push web.server:/path/to/proj.git master

после этого ваш проект станет доступен всем через HTTP:

$ git clone http://web.server/proj.git

=== Git через что угодно ===

Хотите синхронизировать репозитории без серверов или даже без сетевого подключения?
Необходимо импровизировать в чрезвычайной ситуации?
Мы рассмотрели, как <<makinghistory, *git fast-export* и *git fast-import* могут преобразовать
репозитории в один файл и обратно >>. Мы можем обмениваться такими файлами между репозиториями
git с помощью любых носителей, но более эффективным инструментом является *git bundle*.

Отправитель создает пакет ('bundle'):

$ git bundle create somefile HEAD

Затем перенесите bundle, +somefile+, такими средствами, как: email, флешка, дискета, *xxd* печать и последующее распознавание символов, чтение битов по телефону, дымовые сигналы и т. д. Получатель восстанавливает
коммиты из пакета, вводя:

$ git pull somefile

Получатель может сделать это даже с пустым хранилищем. Несмотря на свой размер, +somefile+ содержит весь исходный Git репозиторий.

В больших проектах для уменьшения объема пакет содержит только изменения, которых нет в других репозиториях:

$ git bundle create somefile HEAD ^COMMON_SHA1

Если это делается часто, то можно легко забыть, какой коммит был отправлен последним. Справка
предлагает для решения этой проблемы использовать метки. А именно, после передачи пакета введите:

$ git tag -f lastbundle HEAD

и создавайте пакеты обновления с помощью:

$ git bundle create newbundle HEAD ^lastbundle

=== Патчи: Общее применения ===

Патчи представляют собой текст изменений, которые могут быть легко поняты как с помощью компьютеров,
так и людей. Это дает им всеобщую привлекательность. Можно послать электронное письмо с патчем для разработчиков, независимо от того, какую систему контроля версий они используют. Пока ваши корреспонденты могут читать электронную почту, они могут увидеть ваши изменения. Аналогичным образом с Вашей стороны все, что Вам требуется, - это адрес электронной почты: нет необходимости в установке онлайн хранилища Git.

Напомним, в первой главе:

$ git diff COMMIT

выводит патч, который может быть вставлен в сообщение электронной почты для обсуждения. В Git
репозитории, введите:

$ git apply < FILE

чтобы применить патч.

В более формальной обстановке, когда имя автора и подписи должны быть зарегистрированы, генерируйте соответствующие патчи с определенной точки, набрав:

$ git format-patch START_COMMIT

Полученные файлы могут быть отправлены с помощью *git-send-email* или вручную. Вы также можете указать диапазон коммитов:

$ git format-patch
START_COMMIT..END_COMMIT

На принимающей стороне сохраните email в файл и введите:

$ git am < FILE

Это применит входящие исправления, а также создаст коммит, включая такую информацию, как автор.

С web-клиентом электронной почты вам, возможно, потребуется нажать кнопку, чтобы посмотреть электронную почту в своем первоначальном виде до сохранения исправлений в файл.

Есть небольшие различия для Mbox-подобных клиентов электронной почты, но если вы используете один
из них, вы, вероятно, тот человек, который может легко настроить его без чтения руководства!

=== К сожалению, мы переехали ===

Из предыдущих главах, мы видели, что после клонирования репозитория, набор *git push* или *git pull* автоматически проталкивает или стягивает с оригинального URL. Каким образом Git это делает? Секрет кроется в параметрах конфигурации инициализирован создан с клоном. Давайте выполним команду:

$ git config --list

Опция +remote.origin.url+ контролирует исходный URL; "origin" - имя исходного
репозитория. Как и имя ветки "master" - это соглашение, мы можем
изменить или удалить этот ник, но как правило, нет причин для этого.

Если адрес оригинального репозитория изменился, можно обновить его с помощью команды:

$ git config remote.origin.url NEW_URL

Опция +Branch.master.merge+ задает удаленную ветвь по умолчанию для
*git pull*. В ходе первоначального клонирования, он установлен на текущую ветвь
исходного репозитория, так что даже если HEAD исходных кодов впоследствии
переходит на другую ветку, впоследствии pull будет выполняться для исходной ветви.

Этот параметр применим только к хранилищу мы впервые клонировали, в котором
записано в настройках +branch.master.remote+. Если мы вытягиваем из других
хранилищах мы должны прямо указать какой ветви мы хотим:

$ git pull ANOTHER_URL master

Выше объясняет, почему для некоторых из наших более ранних примеров push и pull
иногда необходимые аргументы.

=== Удаленные Ветки ===

Когда вы клонируете репозиторий, вы также клонируете все его ветки. Вы можете не
заметить это, потому что Git скрывает их: вы должны указать это явно.
Это предотвращает пересечение веток в удаленном хранилище с вашими, а также делает
Git проще для начинающих.

Список удаленных веток можно посмотреть коммандой:

$ git branch -r

Вы должны увидеть что-то вроде:

origin/HEAD
origin/master
origin/experimental

Они представляют собой ветки и HEAD в удаленном хранилище, и могут быть использованы
в обычных командах Git. Например, предположим, что вы сделали много коммитов, и
хотели бы сравнить с последней загруженной версией. Вы можете найти через
журналы для соответствующего SHA1 хэш, но это гораздо легче набрать:

$ git diff origin/HEAD

Также можно увидеть лог ветки "experimental" набрав:

$ git log origin/experimental

=== Несколько Удаленных Веток ===

Предположим, что два других разработчиков работает над нашим проектом, и мы хотим
следить за обоими. Мы можем наблюдать более чем за одним хранилище одновременно введя:

$ git remote add other ANOTHER_URL
$ git pull other some_branch

Сейчас мы объединились в ветвь второго хранилища, и мы получили
легкий доступ для всех ветвей во всех репозиториях:

$ git diff origin/experimental^ other/some_branch~5

Но что, если мы просто хотим сравнить их изменения, не затрагивающие нашу собственную
работу? Иными словами, мы хотим, чтобы изучить их ветки без изменения нашей рабочей папки.
В этом случае вместо pull наберите:

$ git fetch # Fetch from origin, the default.
$ git fetch other # Fetch from the second programmer.

Это выбирает их историю, и ничего больше, так что, хотя рабочий каталог остается
нетронутыми, мы можем обратиться в любую ветвь в любом хранилище командами Git.
Кстати, за кулисами, pull просто fetch за которым следует *git merge*;
а последний добавляется в рабочую директорию.
Обычно мы используем pull, потому что мы хотим объединить после выполнения fetch;
эта ситуация представляет собой заметное исключение.

См. *git help remote* о том, как удалить удаленные хранилища, игнорировать определенные
ветки и многое другое.

=== Мои Настройки ===

Для моих проектов я люблю использовать готовые Git репозитории, в которые я могу сделать pull. Некоторые Git хостинги позволяют создавать собственные ветки проекта нажатием одной кнопки.

После того как я выгрузил дерево, я запускаю Git команды для навигации и изучения изменении, которые в идеале хорошо организованны и описаны. Я объединяю мои собственные неопубликованные изменения, и, возможно, делаю дальнейшие изменения. После изменения, я выгружаю изменения в официальный репозиторий.

Хотя я редко получают взносы, я считаю, этот подход хорошо масштабируется. Смотрите http://torvalds-family.blogspot.com/2009/06/happiness-is-warm-scm.html[этот пост в блоге Линуса Торвальдса].

Пребывание в мире Git немного более удобно, чем патч-файлы, как это экономит мне шаги конвертации их в коммиты Git. Кроме того, Git автоматически обрабатывает информацию, такую как запись с именем автора и адресом электронной почты, а также время и дату, и просит автора описывать свои собственные изменения.