Что такое git
git — это распределенная система контроля версий. Отличается от SVN отсутствием необходимости в центральном репозитории (который все же хорошо было бы держать) и легкостью работы с ветками (branch). Изначально я решил попробовать его в работе прочитав эту статью, что всем рекомендую.
У себя в компании я смог перевести клиентскую разработку на git и до сих пор не пожалел ни минуты. Время от времени я натыкаюсь на споры по поводу какая система контроля версий лучше, часто приходится объяснять чем все-таки мне нравится git.
Я давно уже обещал написать эту статью, но все откладывал. Тем не менее, вот она. Не стоит удивляться флэшерской специфике, в первую очередь статья ориентирована на братьев Флэш разработчиков. Но, будет полезна и всем остальным.
Почему git
Все мы понимаем, что использовать систему контроля версий жизненно необходимо. git в повседневном использовании показал себя очень хорошо и позволил решить ряд проблем. Приведу основные плюсы и “фишки”.
- Распределенность
Создать репозиторий в локальной папке можно просто написав git init. В отличие от SVN, где нужно некоторое центральное хранилище, все изменения, ветки и комиты хранятся локально. Чтобы синхронизировать код с другим разработчиком, надо чтобы он спулил к себе (от слова pull) нужную ветку, тем самым создав локальный клон проекта. Таким образом в локальных (распределенных) репозиториях могут существовать синхронизированные ветки вместе с ветками, которые никому кроме хозяина этой конкретной копии проекта не нужны (во времена SVN флэшеры очень боялись создавать ветки, что уж говорить о каких-то временных экспериментальных). При этом вполне может быть где-то и центральный репозиторий (аналогично SVN), в который пушат (от слова push) и из которого пулят измененния все участники проекта.
- Наличие стабильного клиента
Процесс разработки без ветвлений выглядит примерно так: версия … разработка … версия … разработка …
Видно, что в каждый момент времени наличие стабильной версии, на которой можно поправить баги и зарелизить, не гарантировано. А точнее, получается так, что исправить некий выловленный баг можно только закончив разработку текущей версии. Простые ветки в git позволяют в любое время достать версию любого предыдущего релиза и работать с ней не мешая идущей разработке. Исправить баги в отдельной ветке, смержить в предыдущий релиз и в текущую разработку.
- Удобство использования
git хранит все свои данные в одном каталоге, а не плодит повсюду папки .svn. Переключить проект с одной ветки на другую можно всего одной командой или парой кликов в клиенте. При этом содержимое папки проекта заменяется новым, которое соответствует выбранной ветке. Для разных веток не нужно создавать новые папки или проекты. В большинстве случаев, Flash Builder сам обновит все классы и перекомпилит зависимости.
- Нет необходимости в постоянном конекте к центральному хранилищу
Как я уже сказал, все комиты сохраняются локально и становятся частью общего репозитория только тогда, когда непосредственно пушатся в него. Это сложно вообразить, но порой получается так, что нет доступа в интернет, а работать нужно. Или вы как обычно забыли настроить VPN к рабочему репозиторию. Радует скорость комитов и ощущение полного контроля над локальной копией.
- Удобные частичные комиты
Непосредственно перед комитом помечаются файлы, которые в него войдут с помощью git add. При этом существует возможность в отдельный комит внести часть изменений в файле, а не файл целиком.
- Возможность припрятать изменения.
В git есть интересная возможность — припрятать (stash) незакомиченные файлы и потом достать их снова. Иногда бывает полезно таким образом переносить или временно откатывать изменения, например, я часто забываю переключать ветки.
- Наличие графических клиентов.
Для git не такой уж и большой выбор графических клиентов. Мне больше всего понравился GUI клиент SmartGit. Он кроссплатформенный и для некоммерческого использования доступен бесплатно. Обладает всеми нужными функцими, но все же иногда бывает нужно залезть в Terminal и выполнить пару команд git. Хорошо бы в них примерно разбираться. Для Винды есть TortoiseGit, на Маке я пользовался некоторое время GitX, но тогда он был уж сильно хуже, чем SmartGit. Для Eclipse (то есть для Flash Builder) есть плагин EGit, который давно мне чем-то не понравился. Надо будет вернуться к нему еще раз, тем более он только что обновился. Возможно, это не фишка клиента, а часть дистрибутива git, но тем не менее, хочется упомянуть еще классное отображение веток. В сложном проекте выглядит как карта метро Нью Йорка. Люблю я такие абстрактные картиночки.
TODO или что еще нужно проверить
Я так и не удосужился поставить git-svn и соединить git репозитории с их svn копиями, потому что у нас в компании официально используют svn, но мы не могли больше терпеть. Надеюсь, все перейдут в итоге на git и это не понадобится.
Пока же я предлагал GitHub как интересный вариант хранения проектов с разграничением доступа. Но, понимаете ли, корпоративная секурность итд (хотя код воруют направо и налево и без этого). Сам я использую его для своих личных проектов. Удобненько.
Установка и настройка
Git. Mac / Linux
Для начала нужно установить сам git. Линуксоиды без сомнения разберутся и сами, а скорее всего он у них уже установлен. Маководы могут скачать дистрибутив с официального сайта или установить через MacPorts. Как ставить MacPorts тоже разобраться труда не составляет.
В MacPorts открываем Terminal и вводим.
sudo port
Скорее всего не через админский акаунт ничего установить не разрешит, так что вызываем через sudo и вводим пароль. Дальше смотрим какие есть репозитории начинающиеся с git.
list git*
На экране появится что-то типа
git-core @1.7.2.1 devel/git-core
GitX @0.7.1 devel/GitX
GitX — это GUI клиент, о котором я уже писал. Нас же интересует git-core. Чтобы установить его, нужно написать
install git-core
Проверить правильность установки можно набрав в консоли git --version.
Для доступа к удаленным репозиториям Вам понадобится SSH ключ. Сгенерить его на Mac не составляет никаких проблем.
Git. Windows
Для Windows существует порт msysgit. Качаем последнюю версию и устанавливаем.
Git изначально какбы чужероден для Windows. С этим могут быть связаны некоторые проблемы. Например, мы какое-то время не могли заставить его работать с удаленными репозиториями. Ругался на SSH ключ. Спасибо GitHub’у за решение этой проблемы. Так вот, не пытайтесь сгенерить ключ с помощью Putty. Чтобы сгенерить правильный ключ нужно:
- Запустить Git Bash console из Start -> Programs -> Git
- Выполнить
ssh-keygen -t rsa -C "your@email.com", чтобы сгенерить ключ
GUI клиент
Теперь ставим мой любимый SmartGit. Очень приятно, что он кроссплатформенный.
Во время установки SmartGit, если не найдет файл .gitconfig, спросит имя и e-mail, которые будут использоваться в информации о комитах.
Переносы строк
При работе с git репозиторием с разных операционных систем, рано или поздно (лучше рано) сталкиваешься с проблемой переносов строк. Сообщество так и не пришло к единому мнению, но GitHub рекомендует следующие настройки:
- Создавать репозиторий лучше не с Windows машины
- На Linux и Mac установить параметр core.autocrlf в значение input
- На Windows установить параметр core.autocrlf в значение true
Это делается либо командой git config --global core.autocrlf true либо редактированием .gitconfig. Туда нужно добавить
[core]
autocrlf = true
При этих настройках пользователи Mac будут работать с LF переносами строк и комитить LF в репозиторий, а пользователи Windows будут работать с привычными CRLF, но комитить LF.
Если сразу же не настроить переносы строк, то при каждом пуше большинство файлов будут помечаться как измененные, хотя никаких изменений в них нет. При этом все равно время от времени появляются такие файлы, им вручную приходится делать revert. Подскажите, если кто знает что с этим можно сделать?
Перевод существующего проекта
Данный способ предполагает полную потерю истории SVN. Начало, так сказать, с чистого листа.
Сделайте svn export проекта, чтобы избавиться от .svn папок. Или в корне проекта выполните команду find ./ -name ".svn" | xargs rm -Rf
Если у вас проект состоит из нескольких отдельных Flash Builder подпроектов, имеет смысл сразу же их перенести в одну папку и создать один git репозиторий в ней, а не отдельный на каждый подпроект. В будущем будет проще отмечать версии проекта в целом, вместо того, чтобы по каждому подпроекту искать нужное его состояние где-то в прошлом. Если вы решили перенести папку с проектом, лучше его удалить из проектов Flash Builder (разумеется, не удаляя при этом содержимое каталога).
В каталоге с будущим git репозиторием рекомендую сразу создать файл .gitignore со следующим содержимым:
bin
bin-debug
bin-release
Это скажет git не включать в репозиторий скомпилированные бинарники проекта.
Далее запускаем SmartGit, выбираем Open an existing or create a new local Git working tree и указываем папку с проектом. SmartGit создаст в ней новый репозиторий.
Сразу же нужно найти в списке файл .gitignore, выделить его, нажать кнопку Stage и Commit. Первый Commit Message пусть будет что-то вроде “initial commit”. Теперь, если зарефрешить текущее состояние каталога, исчезнут все файлы упомянутые в .gitignore. Они вам не нужны. Выделяем все остальные файлы, Stage, Commit, в окне комита отметьте галочку Amend foregoing commit…, тем самым вместо нового комита вы добавите текущие изменение к последнему (возможно, вы увидите множество сообщений CRLF will be replaced by LF in .. — это означает, что git следуя настройкам меняет концы строк файлов, которые добавляются в репозиторий, на правильный LF).
Поздравляю, теперь у вас есть свой git репозиторий.
Если вы вдруг создали репозиторий до того, как выставить правильные настройки переносов строк, то следуйте инструкции GitHub и выполните следующий скрипт:
# Remove everything from the index
$ git rm --cached -r .
# Re-add all the deleted files to the index
# You should get lots of messages like: “warning: CRLF will be replaced by LF in <file>.”
$ git diff –cached –name-only -z | xargs -0 git add
# Commit
$ git commit -m “Fix CRLF”
# If you’re doing this on a Unix/Mac OSX clone then optionally remove
# the working tree and re-check everything out with the correct line endings.
$ git ls-files -z | xargs -0 rm
$ git checkout .
Если вы удаляли проект из Flash Builder, сейчас самое время добавить его заново (через File -> Import -> Flash Builder Project) и убедиться, что все работает. Возможно, придется сделать некоторые изменения, например в путях импорта и конфигах, если вы переносили проекты в одну папку. После сделанных изменений не забудьте их закомитить.
Работа с проектом
Если вы еще не прочитали эту статью, рекомендую сделать это сейчас, потому что описанный ниже процесс работы с проектом в git практически полностью взят оттуда. Во время написания этой статьи я все еще работаю на Mail.ru и пишу клиенты социальных игр на Флэше. Отсюда некоторая специфика.
Раз уж мы используем git, будем на полную пользоваться его основной фишкой — ветками. Итак, все проекты у меня состоят из набора веток с разными функциями и строго определенным алгоритмом работы с ними.
- master — основная ветка содержит только релизные версии, которые сейчас онлайн. Они помечены тэгами (tag) с датой заливки. От мало информативных номеров версий я отказался. Если вдруг что-то ломается на боевом сервере, мы без проблем переключаемся на master, делаем с него ветку, фиксим баг и мержим обратно (плюс еще в другие ветки, чтобы потом заного тот же баг не фиксить)
- develop — основная девелоперская ветка. Отражает стабильное состояние разработки, которое когда-то в будущем уйдет в релиз и будет смержено в master.
- dev-* — ветки для отдельных фич. Многие из них локальные и в главный репозиторий не попадают. В них ведется разработка конкретных новых фич игры. Это могут быть совсем небольшие изменения на один-два комита, а может быть огромный патч, который разрастается на месяц и более.
- fix-* — локальные ветки срочных фиксов. Обычно появляются от master, реже от develop. Сразу мержатся в нужные места.
- release — временная ветка для релиза, которая вольется в master и будет удалена. В нужный момент бранчится с develop, и в нее вносятся необходимые правки перед заливкой.
Алгоритм работы следующий:
- Практически для каждого изменения заводится своя девелоперская ветка, которые либо в итоге будут смержены в develop, либо удалены за ненадобностью.
- Ветки более-менее больших изменений идут в центральный репозиторий, мелкие обычно остаются локально у разработчиков.
- Слияние больших фичей я стараюсь контролировать, просматривая проделанные изменения. Очень удобно на данном этапе отсекать всякий говнокод.
- Во время подготовки к релизу, создается ветка release, которая потом мержится в master. В ней делаются временные изменения, которые нигде больше не нужны, например “нам в этом релизе нужно спрятать эту кнопку, потому что функционал еще не готов”. На этом этапе лучше больших багов не иметь, потому что тогда придется делать отдельную ветку с фиксами этих багов и постоянно переключаться между ней и release.
- После заливки, release мержится в master и удаляется. Текущее состояние master помечается тэгом с датой заливки.
- Разработка продолжается.
Тем самым, у нас всегда есть исходник текущей онлайн версии, куда можно оперативно внести какие-то изменения. Каждый разработчик занят своим делом и не пачкает своими грязными экспериментами стерильный центральный репозиторий. При этом продолжает записываться история комитов, которую всегда можно при надобности поднять.
Проблемы, с которыми я столкнулся
Конечно, не все так идеально, как вы могли подумать. На пути к просвещению мне все же пришлось понаступать на грабли, о которых я напишу ниже. Возможно, эта информации кому-то пригодится.
- Сопротивление админов
Я несколько раз пытался объяснить зачем нам еще одна система контроля версий, ведь вроде бы есть отличная SVN. Админы жаловались, что git сложно интегрировать в существующую систему раздачи прав и разграничения доступа к ресурсам в сети. Это дело так с мертвой точки и не сдвинулось, пришлось мне “центральный репозиторий держать у себя локально”.
- Обучение коллег
Коллег пришлось заставить перейти на новую систему контроля версий, понять чем оно отличается от привычного SVN и научиться пользоваться новым софтом. Ничего сложного на самом деле, но нужно быть готовым к последующим постоянным вопросам.
- Проблема переносов строк
О проблеме и ее решении я уже писал выше, но так как это конкретно выносило мой мозг какое-то время, я не мог об этом не написать в разделе “проблемы”. Очень важно пофиксить переносы строк в самом начале проекта, когда существует только одна ветка. Потом это обернется в солидную головную боль.
- Руки из ж…
Что касается юниксоподобных систем и командной строки, тут у меня руки растут явно не из того места. Будучи какое-то время центральным репозиторием на Маке, мне постоянно пришлось сталкиваться со следующими проблемами, связанными с тем, что я с самого начала все правильно не настроил: залоченный файлы и владельцы файлов.Каким-то образом файлы git репозитория становились залоченными так, что никак, даже из самого-самого рута разлочиваться не хотели. Гугл подсказал скрипт, который рекурсивно разлочивает файлы в каталоге.После пуша ко мне от коллег разработчиков, некоторые файлы переходили под владение nobody, что приводило к полной неработоспособности репозитория. Приходилось каталогу каждый раз рекурсивно выставлять права, типа, sudo chmod -R 777 /users/valyard/Work/work/Panda/.git/
В итоге я написал скрипт, который делал эти две вещи на всех проектах, и запускал его время от времени.
- Внимательнее смотрите что идет в репозиторий, а что нет
Разумеется, скомпилированные бинарники и графические ассеты нужно сразу добавить в .gitignore. У нас в проекте есть ant скрипт для сборки барахла и он немного отличается на разных машинах. Возможно, его стоило тоже туда добавить, но я просто сделал два разных скрипта: для винды и для мака.
- Надоедливые файлы проекта
Почему-то Flash Builder время от времени в метаданных проекта считает своим долгом перенести половину строк сверху вниз, чем он не делает ничего полезного, зато раздражает git при отображении изменений. Но, все же, не комитить файлы проекта я считаю плохой идеей.
- Проблема генерации SSH ключей на WIndows
- Нелюбовь флэшеров к консоли
Как выяснилось, флэшеры не любят работать в консоли. А GUI клиенты предоставляют лишь малую часть функционала git. Порой приходится лезть в командную строку, чтобы выполнить какую-то операцию посложнее.
Полезные советы
Пара слов в конце.
- Убедитесь, что Вы понимаете отличия git от svn.
- Постарайтесь донести это до начальства.
- Найдите человека, который сможет грамотно настроить главный git репозиторий.
- Постарайтесь все же использовать один и тот же IDE в команде, тогда можно комитить файлы проекта.
- Разделите проект на несколько репозиториев.
- Делайте комиты и мержи чаще, все-таки даже такой классный инструмент как git не может автоматически смержить две ветки с двухмесячной историей комитов. Придется посидеть вручную потыкать кнопочки.
- Не повторяйте моих ошибок.
- Не слушайте тех, кто ругает git.
Полезные ссылки
Итог
Но все же все минусы были перекрыты огромными плюсами. Были моменты, когда я готов был поцеловать себя в зад за то, что все-таки перевел проект на git, чего и Вам желаю (конечно, не поцеловать меня в зад, а перевести проект на git)!
P.S. Вопросы.
- Как и кто у вас контролирует слияние с основной веткой (master) и есть ли механизм разграничения полномочий для выполнения подобных операций?
Контролирует главный флэшер на проекте. В моих проектах это делаю я. На уровне git я не знаю есть ли какие-то разграничения по доступным операциям.
