Пособие для начинающего git'ариста

Всем хорош нетбук или описанный в предыдущей статье denis_aka_xaos'ом наладонник, только вот компилировать на нем серьезные проекты вряд ли получится. И на мощной-то машине иной раз минуты по 3 уходит на серьезную компиляцию java-программы (особенно это касается сайтов на GWT), а уж процессор типа Intel Atom будет пыхтеть над некоторыми програмистскими задумками добрую четверть часа. Так что же, отказаться от идеи написания программ в мобильных условиях? Конечно же, нет. В этой ситуации на помощь программисту приходит система управления версиями. И лучше, если это будет git - еще одно замечательное детище Лайнуса Торвальдса.

Исходные данные:

• слабый, но имеющий соединение с Интернетом нетбук;
• мощный удаленный хост с доступом по ssh;
• десктопный ПК дома;
• десктопный ПК на работе.

Требуется: девелопить код с любой из этих машин.

Если бы эта задача ставилась года два-три назад, то можно было бы применить SVN - централизованную систему контроля версий. Организовать центральный репозитарий на мощном удаленном хосте и коммитить туда код с остальных машин, так сказать, "звездообразно".  Но у централизованных репозитариев есть масса недостатков. О них написано много, в частности, в течение целого часа на одной из конференций, организованных Google, о недостатках CVS и SVN рассказывал Лайнус Торвальдс в 2007 году (ролик на английском языке). Взамен он предложил децентрализованную систему с открытым кодом git, которая дает разработчику гораздо больше простора для творчества. Вот ею и воспользуемся.

Я пишу программы в одиночку, ни в каких "командах" не участвую, так что git для меня - процентов на 70 средство переброски свежих версий файлов между компьютерами. Но  даже при таком примитивном использовании он гораздо лучше, чем банальный FTP: позволяет создавать экспериментальные ветки, возвращаться от неудачных версий к стабильным, да и просто иметь большое количество актуальных  резервных копий на разных машинах без дополнительных усилий. К тому же не нужен ftp-сервер, а это значит, что хост будет иметь на одну потенциальную брешь в защите меньше.

Есть у git и недостаток: освоить его несколько труднее, чем svn, поскольку децентрализация требует, так сказать, жертв. Но не так всё страшно. Вот алгоритм, который позволит легко закидывать код со "слабой" машинки на "сильную" и компилировать там по мере надобности. Такой подход не требует постоянного нахождения online и "толстых" каналов. Достаточно обычных консольных инструментов и любого периодического доступа в Интернет (коммиты можно отправлять даже по электронной почте).

Первое, что нужно сделать - создать репозитарии на мощном удаленном сервере (далее по тексту - "сильная" машина). Я использую несколько изолированных репозитариев: один для своих собственных многократно используемых библиотек и по одному на каждый проект. Так что в каталоге-лаборатории MyLab на "сильной" стороне я создал подкаталог _git, а в нем подкаталоги reusable и projects (там для каждого проекта, в свою очередь, собственная "папочка"). Дальнейшее изложение пойдет на примере создания репозирария reusable.

Входим на удаленный сервер по ssh и делаем следующее:

mkdir -p ~/MyLab/_git/reusable

cd ~/MyLab/_git/reusable

git init --bare --shared=true

В получившемся каталоге мы никогда не увидим файлов с расширениями *.java, build.xml, Makefile и т.п., которые присутствуют в програмистских проектах. Это просто каталог, где git в очень специфическом виде хранит свою базу данных. Так что вручную править там абсолютно нечего.

С сервера пока уходим.  Теперь на "пишущей машинке" ("слабом" компьютере, на котором не получится компилировать, отлаживать и запускать сложные приложения, но вполне пригодном для набора кода) тоже создаем git-репозитарий, но несколько другого рода: он будет хранить свои вспомогательные файлы в подкаталоге .git текущего каталога, то есть в непосредственной близости от файлов с исходными текстами. На "слабой" машине делаем:

mkdir -p ~/MyLab/_reusable

cd ~/MyLab/_reusable

git init

Как видим, здесь всё немножко по-другому.

Создаем примитивный тестовый файл и коммитим его в локальный (!) репозитарий:

echo "Yo!" > test

git add .

git commit -a -m "My first file here"

В отличие от svn, git коммитит только явно указанные файлы. Чтобы сообщить ему, что мы хотим закоммитить все измененные со времени последнего коммита файлы, нужен ключ -a. Ключ -m, как и в svn, означает комментарий-пояснение. В отличие от svn, он не может быть пустым, то есть такие вещи, как -m "" не проходят, обязательно нужно что-нибудь сказануть по поводу сделанных изменений. Если пропустить ключ -m, то git сам вызовет текстовой редактор, в котором можно набрать необходимый текст.

Далее можно было бы рассказать о разных "вкусностях", таких как создание веток и их слияние, откаты к предыдущим версиям и т.п., но это освоить не сложно. Цель статьи - показать как выкладывать свежий код на удаленный сервер, поэтому на "слабой" машине продолжаем:

git remote add superpupermegaserver ssh://yababay@superpupermegaserver.su/home/yababay/MyLab/_git/reusable

Я написал в примере superpupermegaserver не только для того, чтобы поглумиться, а чтобы показать, что здесь может быть любая метка (в одно слово и латинскими буквами, вестимо). Дело в том, что во всемозможных tutorial вместо superpupermegaserver пишут origin  и у начинающего пользователя git складывается ощущение, что origin - это ключевое слово. Это не так, поэтому таких удаленных репозитариев можно прописать несколько и коммитить "в белый свет как в копеечку" по всему миру. В svn такие фокусы, насколько мне известно, невозможны.

Теперь "выталкиваем" содержимое локального ("слабого") репозитария на удаленную ("сильную") машину:

git push superpupermegaserver master

Здесь master - имя ветки по умолчанию, которая создается при инициализации репозитория. Понять механизм работы git с удаленными репозитариями помогает знание значений английских глаголов: push - выталкивать, pull - тянуть. Второй из них нам тоже вскоре понадобится.

Заходим по ssh на удаленную "сильную" машину, создаем директорию, аналогичную той, что имеется на "слабой" и клонируем содержимое "сильного" репозитария, куда со "слабой" уже кое-что "капнуло" (а именно файл test):

cd ~/MyLab/

git clone _git/reusable _reusable

Получаем каталог _reusable, в котором нас уже ждет служебный подкаталог .git и (какая прелесть!) файл test. Здесь (в отличие от хранилища ~/MyLab/_git/reusable) его можно править, закидывать в различные ветки репозитария (как локального, так и "удаленного") и всяко разно извращаться и изощряться в написании этого и других файлов. Можно, конечно же, и компилировать, отлаживать, запускать готовое ПО и выполнять массу действий, невозможных на "слабой" машинке. Но вот вы отключились от "сильного" сервера и поехали на дачу, захватив с собой тяпку,  рассаду, нетбук и gprs-модем. На свежем воздухе вам пришла в голову гениальная идея и вы, с возгласом "Эврика!" отбросив хозинвентарь и, к ужасу тещи, сокрушая на своем пути зеленые насаждения, бросаетесь к нетбуку и делаете следующее:

cd ~/MyLab/_reusable

echo "line 2" >> test

git commit -a -m "Added second line!"

git push superpupermegaserver master

После этого входим по ssh на "сильный" сервер и делаем:

cd ~/MyLab/_reusable

git pull

cat test

Пришли изменения? О тож!

Вот как-то так примерно... Конечно, это алгоритм лишь в общих чертах: чтобы каждый раз не вводить пароль нужно настроить ssh-соединение по ключам и выполнить кучу других вспомогательных действий. Но, как говорили древние латинцы, Sapienci sat, что Остап Бендер перевел как "Не ешьте на ночь сырых помидоров".