ru/clone.txt

   1 == Все о клонировании ==
   2
   3 В старых системах контроля версий стандартная операция для получения файлов — это checkout. Вы получаете файлы в конкретном сохраненном состоянии.
   4
   5 В Git и других распределенных системах контроля версий стандартный способ — клонирование. Для получение файлов вы создаете «клон» всего хранилища. Другими словами, вы создаете зеркало центрального сервера. При этом все что можно делать в основном хранилище, можно делать и в локальном.
   6
   7 === Синхронизация компьютеров ===
   8
   9 Я вполне приемлю синхронизацию архивами или использование *rsync* для резервного копирования и простейшей синхронизации. Но я работаю то на ноутбуке, то на стационарном компьютере, которые могут никак между собой не взаимодействовать между этим.
  10
  11 Создайте хранилище Git и сделайте коммит файлов на одном компьютере. А потом выполните на другом
  12
  13  $ git clone другой.компьютер:/путь/к/файлам
  14
  15 для создания второй копии файлов и хранилища Git. С этого момента
  16
  17  $ git commit -a
  18  $ git pull другой.компьютер:/путь/к/файлам HEAD
  19
  20 синхронизирует состояние ваших файлов с состоянием файлов другого компьютера. Если вы внесли конфликтующие изменения в один и тот же файл, Git даст вам знать, и нужно будет сделать коммит еще раз, после устранения конфликта.
  21
  22 === Классический контроль исходного кода ===
  23
  24 Создайте хранилище Git для ваших файлов:
  25
  26  $ git init
  27  $ git add .
  28  $ git commit -m "Начальный коммит"
  29
  30 На центральном сервере создайте т.н. «голое» (bare) хранилище Git с неким именем:
  31
  32  $ mkdir proj.git
  33  $ cd proj.git
  34  $ git init --bare
  35  $  # вариант «в одну строчку»: GIT_DIR=proj.git git init
  36
  37 Запустите Git-демон, если необходимо:
  38
  39  $ git daemon --detach # возможно уже запущен
  40
  41 Для создания нового пустого хранилища Git на публичных серверах следуйте их инструкциям. Обычно, нужно заполненить форму на веб-странице.
  42
  43 Отправьте ваши изменения в центральное хранилище вот так:
  44
  45  $ git push git://центральный.сервер/путь/к/proj.git HEAD
  46
  47 Для получения ваших исходников разработчик вводит
  48
  49  $ git clone git://центральный.сервер/путь/к/proj.git
  50
  51 После внесения изменений разработчик сохраняет изменения локально:
  52
  53  $ git commit -a
  54
  55 Для обновления до последней версии:
  56
  57  $ git pull
  58
  59 Любые конфликты слияния нужно разрешить и закоммитить:
  60
  61  $ git commit -a
  62
  63 Для закачки локальных изменений в центральное хранилище:
  64
  65  $ git push
  66
  67 Если на главном сервере были новые изменения, сделанные другими разработчиками, команда push прервётся с ошибкой. В этом случае разработчику нужно будет сгрузить к себе (pull) последнюю версию, разрешить возможные конфликты слияний и попробовать ещё раз.
  68
  69 === Голые (bare) хранилища ===
  70
  71 Голое (bare) хранилище называются так потому, что у него нет рабочего каталога. Оно содержит только файлы, которые обычно скрыты в подкаталоге .git. Другими словами, голое хранилище содержит историю изменений, но не содержит снимка какой-либо определенной версии.
  72
  73 Голое хранилище играет роль, похожую на основной сервер в централизованной системе контроля версий: это дом вашего проекта. Разработчики клонируют с него проект и закачивают в него свежие официальные изменения. Как правило, он располагается на сервере, который мало что делает, кроме раздачи данных. Разработка идет в клонах, поэтому домашнее хранилище может обойтись и без рабочего каталога.
  74
  75 Многие команды Git не работают в голых хранилищах, если переменная среды `GIT_DIR` не содержит путь до хранилища или не указан параметр `--bare`.
  76
  77 === Push или pull? ===
  78
  79 Зачем вводится команда push, вместо использования уже знакомой pull? Прежде всего, pull не работает в голых хранилищах, вместо нее нужно использовать команду 'fetch', которая будет рассмотрена позже. Но даже если держать на центральном сервере нормальное хранилище, использование команды pull в нем будет затруднительным. Нужно будет сначала войти на сервер интерактивно и сообщить команде pull адрес машины, с которой мы хотим забрать изменения. Этому могут мешать сетевые брандмауэры (firewall), но в первую очередь: что если у нас нет интерактивного доступа к серверу?
  80
  81 Тем не менее, не рекомендутся push-ить в хранилище, помимо этого случая, из-за путаницы, которая может возникнуть, если у целевого хранилища есть рабочий каталог.
  82
  83 Короче, пока изучаете Git, push-те только в голые хранилища. В остальных случаях pull-те.
  84
  85 === Создание форка проекта ===
  86
  87 Не нравится путь развития проекта? Думаете, можете сделать лучше? Тогда на Вашем сервере:
  88
  89  $ git clone git://main.server/path/to/files
  90
  91 Теперь расскажите всем об ответвлении (форке, прим. пер) проекта на вашем сервере.
  92
  93 Позже вы сможете в любой момент втянуть к себе изменения из первоначального проекта:
  94
  95  $ git pull
  96
  97 === Максимальные бэкапы ===
  98
  99 Хотите создать множество защищенных, географически разнесенных резервных архивов? Если в вашем проекте много разработчиков, делать ничего не надо! Каждый клон — это и есть бэкап не только текущего состояния, но и всей истории изменений проекта. Благодаря криптографическому хэшированию, повреждение какого-либо из клонов будет обнаружено при первой же попытке взаимодействия с другими клонами.
 100
 101 Если ваш проект не такой популярный, размещайте клоны на как можно большем количестве серверов.
 102
 103 Особо беспокоящимся рекомендуется всегда записывать самый последний 20-байтный SHA1 хэш HEAD в безопасном месте. В безопасном, но не тайном. Например, хороший вариант — публикация в газете, потому как сложно изменить каждую копию газеты.
 104
 105 === Многозадачность со скоростью света ===
 106
 107 Скажем, вы хотите работать над несколькими функциями параллельно. Тогда закоммитьте ваши изменения и запустите
 108
 109   $ git clone . /some/new/directory
 110
 111 При создании такого клона Git использует жесткие ссылки и обмен файлами столь интенсивно, насколько это возможно при должной безопасности; так что он будет готов мгновенно, и вы теперь сможете работать с двумя независимыми функциями одновременно. Например, можно редактировать один клон, компилируя в это время другой.
 112
 113 В любое время можно сделать коммит и вытянуть изменения из другого клона:
 114
 115  $ git pull /the/other/clone HEAD
 116
 117 === Партизанский контроль версий ===
 118
 119 Вы работаете над проектом, который использует другую систему контроля версий, и вам очень не хватает Git? Тогда создайте хранилище Git в своём рабочем каталоге:
 120
 121  $ git init
 122  $ git add .
 123  $ git commit -m "Initial commit"
 124
 125 затем склонируйте его в новый каталог:
 126
 127  $ git clone . /some/new/directory
 128
 129 Теперь перейдите в этот новый каталог и работайте в нём с Git в своё удовольствие. Когда вам понадобиться синхронизировать изменения с другими, перейдите в изначальный каталог и синхронизируйтесь с помощью другой системы контроля версий, затем наберите
 130
 131  $ git add .
 132  $ git commit -m "Синхронизироваться с другими"
 133
 134 Теперь перейдите в новый каталог и запустите
 135
 136  $ git commit -a -m "Описание моих изменений"
 137  $ git pull
 138
 139 Процедура передачи изменений остальным зависит от используемой системы контроля версий. Новый каталог содержит файлы с вашими изменениями. Для загрузки файлов в центральное хранилище запускайте любые необходимые команды другой системы контроля версий.
 140
 141 Subversion (вероятно, наилучшая централизованная система контроля версий) используется неисчислимым множествов проектов. Команда *git svn* автоматизирует этот процесс для хранилищ Subversion и может быть использована для http://google-opensource.blogspot.com/2008/05/export-git-project-to-google-code.html[экспорта проекта Git в хранилище Subversion].
 142
 143 === Mercurial ===
 144
 145 Mercurial — похожая система контроля версий, которая может работать в паре с Git практически без лишних телодвижений. С плагином `hg-git` пользователь Mercurial может без каких либо потерь push-ить и pull-ить из репозитория Git.
 146
 147 Получить `hg-git` можно с помощью Git:
 148
 149  $ git clone git://github.com/schacon/hg-git.git
 150
 151 или Mercurial:
 152
 153  $ hg clone http://bitbucket.org/durin42/hg-git/
 154
 155 К сожалению, мне неизвестен аналогичный плагин для Git. Поэтому, я рекомендую использовать Git, а не Mercurial, для центрального репозитория, даже если вы предпочитаете Mercurial. Для проектов, использующих Mercurial, обычно какой-нибудь доброволец поддерживает параллельный репозиторий Git, в то время как, благодаря `hg-git`, проекты, использующие Git, автоматически доступны пользователям Mercurial.
 156
 157 Хотя плагин может сконвертировать репозиторий Mercurial в Git путем push'а в пустой репозиторий, эту задачу легче решить, используя сценарий `hg-fast-export.sh`, доступный как:
 158
 159  $ git clone git://repo.or.cz/fast-export.git
 160
 161 Для конвертации, выполните в пустом каталоге:
 162
 163  $ git init
 164  $ hg-fast-export.sh -r /hg/repo
 165
 166 после добавления сценария в ваш `$PATH`.
 167
 168 === Bazaar ===
 169
 170 Упомянем вкратце Bazaar, так как это наиболее популярная распределенная система контроля версий после Git и Mercurial.
 171
 172 Bazaar относительно молода, поэтому у нее есть преимущество идущего следом. Его разработчики могут учиться на ошибках предшественников и избавиться от исторически сложившихся наростов. Кроме того, его разработчики заботятся о переносимости и взаимодействии с другими системами контроля версий.
 173
 174 Дополнение `bzr-git` позволяет пользователям Bazaar до некоторой степени работать с репозиториями Git. Программа `tailor` конвертирует репозитории Bazaar в Git и делает это инкрементально, в то время как `bzr-fast-export` хорошо приспособлена для разовых преобразований.
 175
 176 === Почему я использую Git ===
 177
 178 Изначально, я выбрал Git потому, что слышал, что он может справиться с невообразимо неуправляемыми исходными текстами ядра Linux. У меня никогда не было потребности сменить его на что-то другое. Git работает замечательно и мне еще только предстоит напороться на его недостатки. Так как я, в основном, использую Linux, проблемы на других системах меня не касаются.
 179
 180 Я также предпочитаю программы на C и сценарии на bash исполняемым файлам вроде сценариев на Python-е: у них меньше зависимостей и я привык к быстрому выполнению.
 181
 182 Я думал о том, как можно улучшить Git, вплоть до того, чтобы написать собственный инструмент, похожий на Git, но только как академическое упражнение. Завершив проект, я бы все равно продолжил пользоваться Git, потому что выигрыш слишком мал, чтобы оправдать использование самодельной системы.
 183
 184 Естественно, ваши потребности и пожелания вероятно отличаются от моих и лучше будет воспользоваться другой системой. Тем не менее, использование Git не будет слишком уж неправильным.