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-репозитарий с присвоением какого-нибудь имени,
  31
  32 и запустите Git-демон, если необходимо:
  33
  34  $ GIT_DIR=proj.git git init
  35  $ git daemon --detach # возможно уже запущен
  36
  37 Публичные репозитарии, такие как http://repo.or.cz[repo.or.cz], имеют собственные схемы по организации изначально пустых Git-репозитариев, которые обычно предполагают регистрацию и заполнение формы.
  38
  39 Чтобы сохранить ваши изменения в центральный репозиторий, запустите:
  40
  41  $ git push git://central.server/path/to/proj.git HEAD
  42
  43 Для клонирования, как уже было описано выше, необходимо:
  44
  45  $ git clone git://central.server/path/to/proj.git
  46
  47 После внесения изменений, код записывается на главный сервер с помощью:
  48
  49  $ git commit -a
  50  $ git push
  51
  52 Если в ходе работы на сервере уже происходили изменения, необходимо обновить локальную копию репозитария перед сохранением собственных изменений. Для синхронизации:
  53
  54  $ git commit -a
  55  $ git pull
  56
  57 === Создание форка проекта ===
  58
  59 Не нравится путь развития проекта? Думаете можете сделать лучше? Тогда на Вашем сервере:
  60
  61  $ git clone git://main.server/path/to/files
  62
  63 Теперь расскажите всем, что новый проект находится на вашем сервере.
  64
  65 В любое время вы можете объединить изменения с изначальным проектом, используя:
  66
  67  $ git pull
  68
  69 === Окончательные бэкапы ===
  70
  71 Хотите создать множество географически разнесенных, разных, защищенных, резервных архивов? Если в вашем проекте много разработчиков - делать ничего не надо! Каждый клон - это и есть бэкап, причем отражающий не только текущее состояние, но и всю историю изменений проекта. Благодаря криптографическому хэшированию, при нарушении какого-либо из клонов, этот клон будет помечен, и это будет видно при любой попытке взаимодействия с ним.
  72
  73 Если ваш проект не такой популярный, размещайте клоны на как можно большем количестве серверов.
  74
  75 Особо беспокоящимся рекомендуется всегда записывать самый последний 20-байтный SHA1 хэш HEAD в безопасном месте. В безопасном, но не тайном. Например, в газете, это будет эффективным, потому как сложно изменить каждую копию газеты.
  76
  77 === Многозадачность со скоростью света ===
  78
  79 Скажем, вы хотите выполнять несколько задач параллельно. Тогда сохраните свой проект и запустите:
  80
  81   $ git clone . /some/new/directory
  82
  83 Git использует жесткие ссылки и обмен файлами настолько безопасно, насколько это возможно для создания такого клона, он будет готов мгновенно, после чего можно будет работать с разными функциями одновременно. Например, можно редактировать один клон, компилируя в это время другой.
  84
  85 В любое время можно сделать коммит и вытянуть изменения из другого клона.
  86
  87  $ git pull /the/other/clone HEAD
  88
  89 === Другие системы контроля версий ===
  90
  91 Вы работаете над проектом, который использует другую систему контроля версий, и вам не хватает Git? Тогда инициализируйте Git-репозиторий в свою рабочую папку:
  92
  93  $ git init
  94  $ git add .
  95  $ git commit -m "Initial commit"
  96
  97 затем клонируйте его:
  98
  99  $ git clone . /some/new/directory
 100
 101 Теперь перейдите в новую директорию и работайте в ней, используя для контроля версий Git. Когда вам понадобиться синхронизировать изменения с другими, перейдите в изначальную директорию и произведите синхронизацию с помощью другой системы контроля версий, затем наберите:
 102
 103  $ git add .
 104  $ git commit -m "Синхронизироваться с другими"
 105
 106 Теперь перейдите в новую директорию и запустите:
 107
 108  $ git commit -a -m "Описание моих изменений"
 109  $ git pull
 110
 111 Процедура обмена изменениями с другими зависит от используемой системы контроля версий. Новая директория содержит файлы с вашими изменениями. Для загрузки файлов в центральный репозиторий требуется запуск любых необходимых команд другой системы контроля версий.
 112
 113 Команда *git svn* автоматизирует этот процесс для репозиториев Subversion и может быть использована для http://google-opensource.blogspot.com/2008/05/export-git-project-to-google-code.html[экспорта Git проекта в Subversion репозиторий].