(Опубликовано Mabel aka Yababay, 2009-05-03)

Всем хорош нетбук или наладонник, только вот компилировать на нем серьезные проекты вряд ли получится. И на мощной-то машине иной раз минуты по 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:[email protected]/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, что Остап Бендер перевел как «Не ешьте на ночь сырых помидоров».