1 == Все о клонировании ==
3 В старых системах управления версиями стандартная операция для получения файлов — это checkout. Вы получаете файлы в конкретном сохраненном состоянии.
5 В Git и других распределенных системах управления версиями стандартный способ — клонирование. Для получение файлов вы создаете «клон» всего хранилища. Другими словами, вы создаете зеркало центрального сервера. При этом всё, что можно делать в основном хранилище, можно делать и в локальном.
7 === Синхронизация компьютеров ===
9 Я вполне приемлю создание архивов или использование *rsync* для резервного копирования и простейшей синхронизации. Но я работаю то на ноутбуке, то на стационарном компьютере, которые могут никак между собой не взаимодействовать между этим.
11 Создайте хранилище Git и сделайте коммит файлов на одном компьютере. А потом выполните на другом
13 $ git clone другой.компьютер:/путь/к/файлам
15 для создания второго экземпляра файлов и хранилища Git. С этого момента
18 $ git pull другой.компьютер:/путь/к/файлам HEAD
20 синхронизирует состояние ваших файлов с состоянием файлов другого компьютера. Если вы внесли конфликтующие изменения в один и тот же файл, Git даст вам знать, и нужно будет сделать коммит заново после устранения конфликта.
22 === Классическое управление исходным кодом ===
24 Создайте хранилище Git для ваших файлов:
28 $ git commit -m "Начальный коммит"
30 На центральном сервере создайте т.н. «голое» (bare) хранилище Git с неким именем:
35 $ # вариант «в одну строчку»: GIT_DIR=proj.git git init
37 Запустите Git-демон, если необходимо:
39 $ git daemon --detach # возможно уже запущен
41 Для создания нового пустого хранилища Git на публичных серверах следуйте их инструкциям. Обычно, нужно заполнить форму на веб-странице.
43 Отправьте ваши изменения в центральное хранилище вот так:
45 $ git push git://центральный.сервер/путь/к/proj.git HEAD
47 Для получения ваших исходников разработчик вводит
49 $ git clone git://центральный.сервер/путь/к/proj.git
51 После внесения изменений разработчик сохраняет изменения локально:
55 Для обновления до последней версии:
59 Любые конфликты слияния нужно разрешить и закоммитить:
63 Для закачки локальных изменений в центральное хранилище:
67 Если на главном сервере были новые изменения, сделанные другими разработчиками, команда push прервётся с ошибкой. В этом случае разработчику нужно будет сгрузить к себе (pull) последнюю версию, разрешить возможные конфликты слияний и попробовать ещё раз.
69 === Голые (bare) хранилища ===
71 Голое (bare) хранилище называются так потому, что у него нет рабочего каталога. Оно содержит только файлы, которые обычно скрыты в подкаталоге .git. Другими словами, голое хранилище содержит историю изменений, но не содержит снимка какой-либо определенной версии.
73 Голое хранилище играет роль, похожую на основной сервер в централизованной системе управления версиями: это дом вашего проекта. Разработчики клонируют с него проект и закачивают в него свежие официальные изменения. Как правило, он располагается на сервере, который не делает почти ничего кроме раздачи данных. Разработка идет в клонах, поэтому домашнее хранилище может обойтись и без рабочего каталога.
75 Многие команды Git не работают в голых хранилищах, если переменная среды GIT_DIR не содержит путь до хранилища или не указан параметр --bare.
77 === Push или pull? ===
79 Зачем вводится команда push, вместо использования уже знакомой pull? Прежде всего, pull не работает в голых хранилищах, вместо нее нужно использовать команду 'fetch', которая будет рассмотрена позже. Но даже если держать на центральном сервере нормальное хранилище, использование команды pull в нем будет затруднительным. Нужно будет сначала войти на сервер интерактивно и сообщить команде pull адрес машины, с которой мы хотим забрать изменения. Этому могут мешать сетевые брандмауэры (firewall), но в первую очередь: что если у нас нет интерактивного доступа к серверу?
81 Тем не менее, не рекомендутся push-ить в хранилище помимо этого случая: из-за путаницы, которая может возникнуть, если у целевого хранилища есть рабочий каталог.
83 Короче говоря, пока изучаете Git, push-те только в голые хранилища. В остальных случаях pull-те.
85 === Создание форка проекта ===
87 Не нравится путь развития проекта? Думаете, можете сделать лучше? Тогда на вашем сервере выполните
89 $ git clone git://main.server/path/to/files
91 Теперь расскажите всем о форке (ответвлении, прим. пер.) проекта на вашем сервере.
93 Позже вы сможете в любой момент втянуть к себе изменения из первоначального проекта:
97 === Максимальные бэкапы ===
99 Хотите создать множество защищенных, географически разнесённых избыточных архивов? Если в вашем проекте много разработчиков, не делайте ничего! Каждый клон — это и есть резервная копия; не только текущего состояния, но и всей истории изменений проекта. Благодаря криптографическому хэшированию, повреждение какого-либо из клонов будет обнаружено при первой же попытке взаимодействия с другими клонами.
101 Если ваш проект не такой популярный, найдите как можно больше серверов для размещения клонов.
103 Особо беспокоящимся рекомендуется всегда записывать самый последний 20-байтный SHA1 хэш HEAD в каком-нибудь безопасном месте. Оно должно быть безопасным, а не тайным. Например, хороший вариант — публикация в газете, потому что атакующему сложно изменить каждую копию газеты.
105 === Многозадачность со скоростью света ===
107 Скажем, вы хотите работать над несколькими функциями параллельно. Тогда закоммитьте ваши изменения и запустите
109 $ git clone . /some/new/directory
111 При создании такого клона Git использует жесткие ссылки и обмен файлами столь сильно, насколько это возможно при должной безопасности; так что он будет готов мгновенно, и вы теперь сможете работать с двумя независимыми функциями одновременно. Например, можно редактировать один клон, компилируя в это время другой.
113 В любое время можно сделать коммит и вытянуть изменения из другого клона:
115 $ git pull /the/other/clone HEAD
117 === Партизанское управление версиями ===
119 Вы работаете над проектом, который использует другую систему управления версиями, и вам очень не хватает Git? Тогда создайте хранилище Git в своём рабочем каталоге:
123 $ git commit -m "Начальный коммит"
125 затем склонируйте его в новый каталог:
127 $ git clone . /некий/новый/каталог
129 Теперь перейдите в этот новый каталог и работайте в нём с Git в своё удовольствие. Когда вам понадобиться синхронизировать изменения со всеми остальными, перейдите в изначальный каталог и синхронизируйтесь с помощью другой системы управления версиями, затем наберите
132 $ git commit -m "Синхронизация с остальными"
134 Теперь перейдите в новый каталог и запустите
136 $ git commit -a -m "Описание моих изменений"
139 Процедура передачи изменений остальным зависит от используемой системы управления версиями. Новый каталог содержит файлы с вашими изменениями. Для загрузки файлов в центральное хранилище запускайте любые необходимые команды другой системы управления версиями.
141 Subversion (вероятно, наилучшая централизованная система управления версиями) используется неисчислимым множествов проектов. Команда *git svn* автоматизирует описанный процесс для хранилищ Subversion и может быть использована для http://google-opensource.blogspot.com/2008/05/export-git-project-to-google-code.html[экспорта проекта Git в хранилище Subversion].
145 Mercurial — похожая система управления версиями, которая может работать в паре с Git практически без накладок. С плагином hg-git пользователь Mercurial может без каких либо потерь push-ить и pull-ить из репозитория Git.
147 Получить hg-git можно с помощью Git:
149 $ git clone git://github.com/schacon/hg-git.git
153 $ hg clone http://bitbucket.org/durin42/hg-git/
155 К сожалению, мне неизвестен аналогичный плагин для Git. Поэтому, я рекомендую использовать Git, а не Mercurial, для центрального хранилища, даже если вы предпочитаете Mercurial. Для проектов, использующих Mercurial, обычно какой-нибудь доброволец поддерживает параллельное хранилище Git, тогда как проекты, использующие Git, благодаря hg-git автоматически доступны пользователям Mercurial.
157 Хотя дополнение может сконвертировать хранилище Mercurial в Git путем push'а в пустое хранилище, эту задачу легче решить, используя сценарий hg-fast-export.sh, доступный как
159 $ git clone git://repo.or.cz/fast-export.git
161 Для преобразования выполните в пустом каталоге
164 $ hg-fast-export.sh -r /hg/repo
166 после добавления сценария в ваш $PATH.
170 Упомянем вкратце Bazaar, так как это самая популярная распределенная система управления версиями после Git и Mercurial.
172 Bazaar относительно молода, поэтому у нее есть преимущество идущего следом. Его проектировщики могут учиться на ошибках предшественников и избавиться от исторически сложившихся неровностей. Кроме того, его разработчики заботятся о переносимости и взаимодействии с другими системами управления версиями.
174 Дополнение bzr-git позволяет пользователям Bazaar до некоторой степени работать с репозиториями Git. Программа tailor конвертирует репозитории Bazaar в Git и может делать это инкрементно, тогда как bzr-fast-export хорошо приспособлена для разовых преобразований.
176 === Почему я использую Git ===
178 Изначально я выбрал Git потому, что слышал, что он может справиться с невообразимо неуправляемыми исходными текстами ядра Linux. Я никогда не ощущал потребности сменить его на что-то другое. Git работает замечательно и мне еще только предстоит напороться на его недостатки. Так как я в основном использую Linux, проблемы на других системах меня не касаются.
180 Я также предпочитаю программы на C и сценарии на bash исполняемым файлам вроде сценариев на Python-е: у них меньше зависимостей и я привык к быстрому выполнению.
182 Я думал о том, как можно улучшить Git, вплоть до того, чтобы написать собственный инструмент, похожий на Git, но только как академическое упражнение. Завершив проект, я бы все равно продолжил пользоваться Git, потому что выигрыш слишком мал, чтобы оправдать использование самодельной системы.
184 Естественно, ваши потребности и пожелания вероятно отличаются от моих и вы, возможно, лучше уживётесь с другой системой. И всё же вы не слишком ошибётесь, используя Git.