GIT

Системы управления версиями (Version Controll Systems) нужны для того, чтобы хранить все промежуточные изменения вносимые в файл. Это не обязательно инструмент программиста, но программистам возможность вернуться к моменту «когда все работало» наиболее нужно. А еще это инструмент совместной работы — когда каждое изменение фиксируется в репозитории, а потом оттуда синхронизируется у всех остальных участников команды. Однако, VCS это прежде всего система управления версиями, а потом уже — инструмент для совместной работы. Программисту-одиночке она так же полезна, как и разбросанной по всему миру большой команде разработчиков. Ну, так вот…

Их много, всех эти CSV, Subversion, Bazaar, Mercurial и так далее. У каждой своя концепция, свой подход. Но и общее есть — хранить все изменения («revision» — в глупом буквальном переводе «ревизия», более логичное и правильное слово «версия» было занято термином «version»), фиксировать ключевые моменты версиями и по необходимости разделять разработку на ветви («branch»), которые используются для параллельной разработке нескольких вариантов продукта, существенно отличающихся друг от друга функционалом. Ветки, впрочем можно снова сливать между собой и снова разделять, условно разделяя их на «стабильные» (то есть проверенные и идущие в работу), «текущие» (то есть те, в которых идет дальнейшая разработка и исправление ошибок), «устаревшие» (не развивающиеся, но в которых продолжается исправление ошибок) и любых других по желанию (вплоть до отдельной ветки для каждого клиента системы с их индивидуальными настройками). А различие в основном — использовать ли централизованное хранилище («репозиторий» от английского «repository») или каждую рабочую копию использовать как автономный репозиторий; как нумеровать изменения и версии — в CVS принята система 1.0.1, 1.1, 2.0 и так далее, а в Subversion все изменения нумеруются последовательно, а версии оформляются отдельными ветками с произвольным именованием (tag/1.0, tag/2-pre-alpha или, к примеру, tag/final). Заканчиваем с общими словами и переходим к GIT…

GIT — распределенная система управления версиями. Это значит, что лютая директория с рабочими файлами может быть превращена в репозиторий, в котором отслеживаются изменения, хранится вся информация о версиях и ветках разработки и который может быть синхронизирован с другим репозиторием, который, в свою очередь, тоже может являться для кого-то рабочей копией. Это только кажется очень сложным, на самое деле все просто и функционально — а это очень редкое сочетание.

Создание репозитория

Итак, у вас есть директория в которой хранятся все файлы и поддиректории вашего проекта. Перейдите в нее и выполните команду:

[bash]
git init
[/bash]

Репозиторий создан. Пустой. Двинемся дальше:

[bash]
git add .
[/bash]

Все файлы текущей директории (включая поддиректории всех уровней) помечены для добавления.

[bash]
git commit -m "Initial commit"
[/bash]

Вот теперь все файлы сохранены в репозитории. Вы можете их менять, переименовывать, удалять — все равно первый шаг останется в репозитории и к нему всегда можно будет вернуться. Это изменение будет помечено труднозапоминаемым хэшем (такова особенность git) и снабжено комментарием «Initial commit». Если при сохранении очередного изменения в будете указывать «говорящий» комментарий о сути этих изменений, вам будет легче ориентироваться в процессе разработке. Не говоря уже о других членах команды, если вы работаете не один.

Сохранение изменений

Вы внесли нужные изменения, проверили их работоспособность (или исправили найденную ошибку) и хотите зафиксировать это радостное событие.

[bash]
git commit -am "Fixed bug with startup crash"
[/bash]

Префикс -a автоматически пометит к сохранению все изменившиеся файлы. Если вы хотите сохранить только некоторый из них, явно укажите измененные файлы

[bash]
git add templates/conf*.php
[/bash]

а потом сохраните их при помощи git commit без «-a». Новые файлы также придется добавлять вручную. Чтобы оценить изменения, используйте команду

[bash]git status[/bash]

и вы увидите все новые, удаленные и измененные файлы. Для удаления существует команда

[bash]git rm template/setup*.inc[/bash]

действие которой обратно «git add». Чем чаще вы будете сохранять сделанные изменения, чем меньше эти изменения будут, тем проще вам будет их отслеживать в истории файлов и веток по сравнению с большими «кумулятивными» коммитами, в которых очень просто заблудиться.

Работу с ветками я пропускаю намеренно — даже если вы начнете работать с git, какое-то время они вам не понадобятся, а загружать избыточной информацией «первое знакомство» я считаю неправильным.

Все описанное до сих пор — стандартные операции, типичные для любой vcs. А сейчас начнется магия :)

Удаленный репозиторий

Возьмите всю свою рабочую директорию и перенесите на сервер. Например, при помощи ssh. Затем удалите свою рабочую копию. Не страшно — она ведь осталась на сервере, не так ли. А теперь…

[bash]git clone ssh://alex@a-site.com:22/home/alex/project/.git[/bash]

…и вы получите обратно ваш репозиторий. Никаких демонов, никаких серверов — просто установленный консольный git и доступ по ssh. Если у вас настроен доступ по ключам, вам даже не потребуется вводить пароль. Впрочем, это совсем другая история. Факт в том, что вы можете хранить репозитарий где угодно, а работать в его клоне, время от времени обновляя тот, условно-«главный». Заметим, что к тому репозиторию могут подключаться и другие разработчики. И даже более того — вы можете сделать репозиторий открытым для чтения, просто поместив его в директорию веб-сервера, после чего любой желающий сможет получить код командой:

[bash]git clone http://a-site.com/project/.git%5B/bash%5D

Опять же — без серверов, демонов, только консольный git и ssh/httpd. Однако, при желании можно поставить git-daemon. Он быстрее и надежней. Хотя это непринципиально.

Автономность

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

Вообще не подключаясь — вы можете работать в самолете, без интернета. Не важно — когда у вас появится интернет, вы сохраните всю накопленную историю разом.

[bash]git push[/bash]

А можете и вовсе не пользоваться внешними репозиториями — просто работать на локальной машине в качестве единоличного разработчика. Ну, и напоследок — обещанная магия…

Крюки

Это очередная неловкая попытка перевести термин «hooks», означающий события, на которые можно «повесить» (как на крюк — отсюда и название, скорее всего) какие-либо действия. Для этого в служебной директории .git/hooks есть набор исполняемых файлов с именами событий. В них можно добавить любые действия, которые будут выполняться в случае возникновения этих событий.

Предположим, вы пишите сайт на локальной машине. На боевом сервере, куда у вас есть ssh- доступ, вы сохраняете весь проект в директории веб- сервера вместе с репозиторием, «клонируете» себе рабочую копию, вносите в нее изменения, сохраняете ее на репозиторий боевого сервера. Для того, чтобы рабочая копия на боевом сервере (а не только репозиторий!) обновилась, вам потребуется в консоли выполнить:

[bash]git reset —hard HEAD[/bash]

А можно вписать в файл .git/hooks/post-receive строки:

[bash] #!/bin/sh
cd ..
env -i /usr/bin/git reset —hard
[/bash]

и все! Теперь при каждом git push будет выполняться обновление рабочей копии на сервере.

Чем не магия? :)

Кстати, теперь ваш проект может забрать с сервера кто угодно. OpenSource это хорошо, но не все хотят раздавать свой код прямо с рабочих серверов. Чтобы этого избежать, поместите в .git файл .htaccess со строкой:

[bash]Deny from all[/bash]

…и никто, кроме вас, не сможет добраться до ваших исходников.

Отмечено ,

2 ответа на “GIT

  1. rxs:

    Спасибо. Интересная информация. Прочитал и взял на заметку.
    Хотелось бы, чтоб сразу были ссылки на объекты: CSV, Subversion, Bazaar, Mercurial, GIT.
    Да, найти не сложно, но комфорт чтения улучшается, когда сразу можно посмотреть что это такое.

  2. Sol:

    Будет отдельная статья про VCS «вообще».

Добавить комментарий

Please log in using one of these methods to post your comment:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s