Git me!

Практически любой процесс разработки программного обеспечения в которой принимает участие как минимум несколько человек не обходится без использования системы контроля версий (version control system). Думаю для любого разработчика это не является открытием и всякий наверняки знаком с такими системами. До недавного времени наиболее распространенными числились Subversion (svn) и mercurial. В моих кругах имело место также использование Visual Source Safe (vss) – но я не считаю это за тренд, скорее наооборот пережиток прошлого.

С недавних же пор все чаще стали говорить и использовать «новую» систему контроля версий - Git. Создателем ее является небезызвестный Линус Торвальдс, которого не устроили существующие продукты и он опять решил перевернуть весь мир. Если посмотреть в будущее, даже самое недалекое, то мне кажется, что Git в скором времени может затмить собой и Subversion и Mercurial и все остальные системы вместе взятые.

В чем же причина? В фуникциональности и удобстве. Не буду описывать все плюшечки и бенефиты системы, наверняка вы и сами сможете с ними разобраться. Уже сегодня есть целые ресурсы, которые посвящены именно подобным вопросам. Например, вот этот http://whygitisbetterthanx.com

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

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

Я работаю под Windows и все операции провожу с использованием утилиты Git Bash. Для ее запуска необходимо выбрать в проводнике (или чем вы там еще пользуетесь) директорию с проектом и через контекстное меню запустить Git Bash.

Для начала работы необходимо получить Git репозиторий. Для этого воспользуемся коммандой git clone. Команда принимает только один параметр – URL родительноского репозитория

git clone ssh://here_is_your_url.com/project.git

После выполнения мы получим локальную копию репозитория в директории из под которой вызвали Git Bash. Команда выполняется только один раз когда у нас еще нету репозитория.

После этого можно работать с файлами проекта, редактировать, добавлять и удалять. После того как назрела необходимость зафиксировать изменения, опять запускаем Git Bash и выполняем команду git status. Команда призвана показать какие изменения были произведены. Увереные в себе люди могут этой командой не пользоватьсяJ

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

git add .

Команда подготовит все файлы, в том числе и новые, которых в репозитории нету.

Иногда возникает необходимость не добавлять какие то файлы или даже целые директории, например папки Debug, bin или файлы с расширением *.obj. Для этого целесообразно добавить нежелательные файлы в исключения, которые описываются файлом .gitignore. Просто создайте файл .gitignore в корне репозитория и добавьте содержимое, которое должно игнорироваться гитом. Например для случая, который я расмотрел выше содержимое файла будет следующим:

Debug

Bin

*.obj

После того как все файлы подготовлены делаем коммит:

git commit –m "Message of the commit"

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

Получаем обновления из удаленного репозитория, наверняка пока мы работали уже кто-то что-то обновил.

git fetch

Теперь начинается магия – мы склеиваем полученную удаленную версию с нашей локальной. Для этого используем rebase.

git rebase origin master

Если в процессе склеивания конфликтных ситуация не было, то работа практически сделана – все что нам нужно – это отослать изменения на сервер:

git push

Если же возникли сложности при ребейсе, я использую araxis merge для фикса конфликтов. Хотя на самом деле можно использовать любой другой инструмент – тут личное дело каждого. Настройки утилит мерджинга задаются в файле .gitconfig а сам файл находится в пользовательской папке (С:\users\me). Что бы настроить araxis или любой другой инструмент нужно в этом файле указать следующее:

[diff]

    tool = araxis

[difftool "araxis"]

    path = full_path_to_exe

[merge]

    tool = araxis

[mergetool "araxis"]

    path = full_path_to_exe

Вернемся к команде rebase которая не смогла выполнится из-за наличия конфликта. Для разрешения конфликта пользуемся командой:

git mergetool

Команда откроет araxis и там необходимо зарезолвить конфликт и сохранить все файлы которые имеют отношение к кнофликту. Необходимо отметить что araxis будет вызван ровно столько раз сколько кофликтных файлов у нас имеется.

После того как все конфликты исправлены, завершаем rebase следующей командой:

git rebase --continue

После того как rebase завершен, как и в случае когда конфликтов не было не забываем заливать все изменения на сервер командой git push.

Вот и все.