Одной из самых полезных технических средств организации труда в команде является система контроля версий.

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

Вообще говоря, если вы ещё не пробовали использовать никакую систему контроля версий, вы не умеете работать в команде.

Мы в своё время остановились на Git среди прочих, и вот по каким причинам:

— Не нужно выделенного сервера для репозитория.

В условиях не безграничных вычислительных ресурсов очень приятно, что не требуется выделять память, процессорное время и собственное внимание лишнему сервису.

— Удобное ветвление и смешивание.

Часто бывает необходимо попробовать новую возможность, не ломая стабильный код (и продолжая его развивать параллельно). С Git’ом создавать и смешивать не сможет научиться только очень ленивый. Вы можете с лёгкостью поддерживать несколько параллельных нитей развития кода, смешивая их по необходимости.

— Лёгкое взаимодействие между репозиториями.

Также, как и с локальными ветками, работа с удалёнными очень проста.

— Логичность.

Если вы всерьёз попробуете использовать Git (а вы когда-нибудь это обязательно сделаете, по своему желанию или нет), заметите, что некоторые вещи настолько самоочевидные и логичные, что их отсутствие в других системах контроля версий кажется ужасно нелепым.

Цель данной статьи — показать на конкретных маленьких примерах, как можно использовать Git в команде из двух человек.

Общая схема такая: есть центральный репозиторий на сервере, с которого происходит deploy продукта, отдельные разработчики ведут локальные зеркала, периодически синхронизируя их с сервером.

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

Всё просто. Репозиторий = каталог. Доступ к нему можно получить по множеству протоколов, при этом меньше всего настройки требуется в случае ssh (так как он уже настроен на любом сервере). Выполните следующие команды на сервере.

mkdir Project

cd Project

git init

Готово.

2. Клонирование репозитория

Каждый из разработчиков должен создать себе локальную копию. Делается это очень просто.

git clone ssh://server.example.com/path/to/Project

server.example.com — имя вашего сервера

3. Внесение изменений

Мелкие поправки вносятся простым коммитом с последующим закидыванием изменений на сервер.

git add ...

git status

git commit -m "Commit message"

Первой команде в качестве аргументов следует указать имена добавляемых файлов. Следует заметить, что для git’а изменённый файл является новым объектом. Поэтому для того, чтобы обновить файл в репозитории, также как и добавить новый файл, следует выполнить для него git add перед коммитом.

git status наглядно покажет состояние файлов вашего дерева (неизвестные системе файлы, изменённые, не изменённые, находящиеся в конфликте и т.д.)

Серьёзную работу следует вести в отдельных ветвях для облегчения процесса смешивания нитей разработки обоих участников процесса.

git branch new-feature

git checkout new-feature

...сделать что-нибудь...

git add ...

git commit -m "Commit message"

Первыми двумя командами мы создали новую ветвь и обновили дерево (то есть переписали файлы в каталоге их версиями из новой ветви; в данном случае, на самом деле, ничего не изменится, новая ветвь пока копия основной ветви master, но в будущем вы можете легко переключаться между ветвями командой checkout, при этом дерево файлов будет соответствующим образом обновляться).

Структуру ветвей можно посмотреть в виде красивого графа командой gitk (она же даёт и другую полезную информацию).

Команда git branch покажет, что у нас две ветви: master и new-feature. Командой checkout можно переключаться между ними (и делать затем коммиты в каждую, не затрагивая другую). Когда вы закончите разрабатывать новую возможность, настанет время примешать изменения в основную ветвь, master.

git checkout master

git merge new-feature

Если изменения не могут быть примешаны автоматически (например, в каком-то файле в ветви master одна из строк изменилась иным образом, чем в ветви new-feature), следует использовать ключ -s resolve у команды merge:

git merge -s resolve new-feature

...увидите, какие файлы находятся в состоянии конфликта...

...отредактируете файлы нужным образом...

git commit -a -m "Merged new-feature"

Обратите внимание, что в первом случае коммит создаётся автоматически, во втором же вручную, после устранения конфликтов. Ещё можно заметить полезный ключ у команды commit: -a. Это равносильно тому, чтобы сделать git add для всех уже известных git’у файлов (то есть тех, чьи старые версии есть в репозитории).

4. Отправка изменений и приём изменений основной ветки (master)

Итак, у нас в ветви master имеются изменения, которые неплохо бы отдать своему коллеге (ну и выложить на сервер с целью последующего deploy’а новой версии).

git push origin

Всё. Изменения внесены.

Чтобы получить изменения, следует сделать

git pull origin

В некоторых случаях изменения с сервера невозможно автоматически добавить в вашу ветвь master, тогда вместо pull’a следует использовать merge:

git merge origin/master

...или, в плохом случае...

git merge -s resolve origin/master

Откуда взялся origin? Это имя удалённого репозитория, автоматически добавленное командой git clone. Источник клонирования. Ваш тот самый сервер из первого пункта, как вы уже догадались. Можно добавить другие удалённые репозитории

git remote add second-server ssh://second.example.com/path/to/repo

Формат команды очевиден. Все remote-репозитории одинаковы, origin не является чем-то особенным. Просто его создали автоматически :-)

В нашем случае сервер лишь один, поэтому работа с remote рассматриваться далее не будет.

5. Обмен изменениями без затрагивания ветки master

В обычных конфигурациях предполагается, что, если на сервер в ветку master что-то попало, то его можно сразу выкладывать в production.

Что же делать, если вы не хотите затрагивать master, а хотите обменяться какими-то наработками в других ветвях?

Ничего сложного.

git checkout new-feature

git merge origin/new-feature

...сделать что-нибудь...

git push origin new-feature:new-feature

Последняя команда отправит на сервер лишь ветку new-feature (последний аргумент показывает, что локальная ветка new-feature будет отправлена в удалённую ветку new-feature, в общем случае их названия не обязательно должны совпадать).

6. Что дальше?

Собственно, это вся база, что требуется для начала использования Git’a.

Подробные разъяснения формата команд и их действия вы можете получить, набрав git command –help.