ru/clone.txt

   1 == Все о клонировании ==
   2
   3 В старых системах контроля версий стандартная операция для получения файлов — это checkout. Вы получаете файлы в указанном сохраненном состоянии.
   4
   5 В Git и других распределенных системах контроля версий стандартный способ — клонирование. Для получение файлов вы создаете клон всего репозитория. Другими словами, вы создаете зеркало центрального сервера. При этом все что можно делать в основном репозитории, можно делать и в локальном.
   6
   7 === Синхронизация компьютеров ===
   8
   9 По этой причине я и начал использовать Git. Я вполне приемлю синхронизацию архивами или использование *rsync* для бэкапов и простейшей синхронизации. Но я работаю то на ноутбуке, то на стационарном компьютере, которые могут никак между собой не взаимодействовать между этим.
  10
  11 Создайте репозиторий Git и сделайте коммит файлов на одном компьютере. А потом выполните на другом
  12
  13  $ git clone other.computer:/path/to/files
  14
  15 для создания второй копии файлов и репозитория Git. С этого момента
  16
  17  $ git commit -a
  18  $ git pull other.computer:/path/to/files HEAD
  19
  20 синхронизирует состояние ваших файлов с состоянием файлов другого компьютера. Если вы внесли конфликтующие изменения в тот же файл, Git даст Вам знать об этом, и вам нужно будет сделать коммит еще раз, уже после устранения конфликта.
  21
  22 === Классический контроль исходного кода ===
  23
  24 Создайте репозиторий Git для ваших файлов:
  25
  26  $ git init
  27  $ git add .
  28  $ git commit -m "Initial commit"
  29
  30 На центральном сервере создайте пустой репозиторий Git с неким именем и запустите Git-демон, если необходимо:
  31
  32  $ GIT_DIR=proj.git git init
  33  $ git daemon --detach # возможно уже запущен
  34
  35 Для создания нового пустого репозитория Git на публичных серверах следуйте их инструкциям. Обычноэто заполнение формы на веб-странице.
  36
  37 Отправьте ваши изменения в центральный репозиторий вот так:
  38
  39  $ git push git://central.server/path/to/proj.git HEAD
  40
  41 Готово. Для получения ваших исходников разработчик введёт
  42
  43  $ git clone git://central.server/path/to/proj.git
  44
  45 После внесения изменений, код отправляется на главный сервер так:
  46
  47  $ git commit -a
  48  $ git push
  49
  50 Если на сервере был изменения за это время, нужно получить последнюю версию перед сохранением собственных изменений. Для синхронизации:
  51
  52  $ git commit -a
  53  $ git pull
  54
  55 === Создание форка проекта ===
  56
  57 Не нравится путь развития проекта? Думаете можете сделать лучше? Тогда на Вашем сервере:
  58
  59  $ git clone git://main.server/path/to/files
  60
  61 Теперь расскажите всем об ответвлении (форке, прим. пер) проекта на вашем сервере.
  62
  63 Позже вы сможете в любой момент втянуть к себе изменения из первоначального проекта:
  64
  65  $ git pull
  66
  67 === Максимальные бэкапы ===
  68
  69 Хотите создать множество защищенных, географически разнесенных резервных архивов? Если в вашем проекте много разработчиков, делать ничего не надо! Каждый клон — это и есть бэкап не только текущего состояния, но и всей истории изменений проекта. Благодаря криптографическому хэшированию, повреждение какого-либо из клонов будет обнаружено при первой же попытке взаимодействия с другими клонами.
  70
  71 Если ваш проект не такой популярный, размещайте клоны на как можно большем количестве серверов.
  72
  73 Особо беспокоящимся рекомендуется всегда записывать самый последний 20-байтный SHA1 хэш HEAD в безопасном месте. В безопасном, но не тайном. Например, хороший вариант — публикация в газете, потому как сложно изменить каждую копию газеты.
  74
  75 === Многозадачность со скоростью света ===
  76
  77 Скажем, вы хотите работать над несколькими функциями параллельно. Тогда закоммитьте ваши изменения и запустите
  78
  79   $ git clone . /some/new/directory
  80
  81 При создании такого клона Git использует жесткие ссылки и обмен файлами столь интенсивно, насколько это возможно при должной безопасности; так что он будет готов мгновенно, и вы теперь сможете работать с двумя независимыми функциями одновременно. Например, можно редактировать один клон, компилируя в это время другой.
  82
  83 В любое время можно сделать коммит и вытянуть изменения из другого клона:
  84
  85  $ git pull /the/other/clone HEAD
  86
  87 === Партизанский контроль версий ===
  88
  89 Вы работаете над проектом, который использует другую систему контроля версий, и вам очень не хватает Git? Тогда создайте репозиторий Git в своём рабочем каталоге:
  90
  91  $ git init
  92  $ git add .
  93  $ git commit -m "Initial commit"
  94
  95 затем склонируйте его в новый каталог:
  96
  97  $ git clone . /some/new/directory
  98
  99 Теперь перейдите в этот новый каталог и работайте в нём с Git в своё удовольствие. Когда вам понадобиться синхронизировать изменения с другими, перейдите в изначальный каталог и синхронизируйтесь с помощью другой системы контроля версий, затем наберите
 100
 101  $ git add .
 102  $ git commit -m "Синхронизироваться с другими"
 103
 104 Теперь перейдите в новый каталог и запустите
 105
 106  $ git commit -a -m "Описание моих изменений"
 107  $ git pull
 108
 109 Процедура передачи изменений остальным зависит от используемой системы контроля версий. Новый каталог содержит файлы с вашими изменениями. Для загрузки файлов в центральный репозиторий запускайте любые необходимые команды другой системы контроля версий.
 110
 111 Команда *git svn* автоматизирует этот процесс для репозиториев Subversion и может быть использована для http://google-opensource.blogspot.com/2008/05/export-git-project-to-google-code.html[экспорта Git проекта в Subversion репозиторий].